Clash 처음 설치 및 설정 방법: 플랫폼별 초기화와 흔한 오류

설치 전 확인: 운영체제, 아키텍처, 클라이언트 코어

Clash를 처음 설정할 때 첫 단계는 설치 패키지를 바로 실행하는 것이 아니라 운영체제, 프로세서 아키텍처, 클라이언트 유형을 확인하는 일입니다. 파일 다운로드가 완료되었다고 해서 현재 기기에 적합하다는 뜻은 아닙니다. 아키텍처를 잘못 선택하면 설치 프로그램이 실행되지 않거나, 시스템에서 호환되지 않는 앱이라고 알리거나, 실행 직후 프로그램이 종료될 수 있습니다.

Windows에서 흔히 사용하는 기기는 x64 아키텍처이며, ARM 프로세서를 탑재한 일부 초경량 노트북과 태블릿은 ARM64 버전이 필요합니다. macOS는 Intel과 Apple Silicon을 구분해야 합니다. M 시리즈 칩은 Apple Silicon 또는 arm64에 해당하고, 구형 Intel Mac은 x64에 해당합니다. Linux는 x86_64와 arm64뿐 아니라 패키지 형식도 확인해야 합니다. Debian과 Ubuntu는 보통 deb를 사용하고, Fedora와 Rocky Linux 등에서는 rpm이 흔합니다. AppImage는 클라이언트가 현재 아키텍처를 명시적으로 제공하고 지원할 때 선택해야 합니다.

클라이언트 이름과 프록시 코어도 구분해서 이해해야 합니다. 데스크톱 클라이언트는 설정 관리, 구독 업데이트, 시스템 프록시 전환, 로그 표시를 담당하고, 코어는 규칙 매칭, 연결 전달, DNS, TUN 등 실제 네트워크 작업을 처리합니다. 현재 지속적으로 관리되는 클라이언트 중에는 mihomo 코어를 사용하는 경우가 많습니다. mihomo는 Clash Meta에서 이어진 후속 발전 프로젝트로, 일반적인 Clash 설정과 호환되며 규칙, 프로토콜, 트래픽 가로채기 기능을 확장합니다. 구독 서비스와 클라이언트가 지원하는 설정 형식만 일치한다면, 초보자가 이름이 다르다는 이유로 코어를 자주 바꿀 필요는 없습니다.

다운로드 파일을 빠르게 선택하는 순서

1. 먼저 Windows, macOS, Linux 중 해당 운영체제의 페이지를 선택합니다.
2. 그다음 x64, arm64 또는 Apple Silicon으로 프로세서 아키텍처를 구분합니다.
3. Linux 사용자는 시스템에서 관리할 수 있는 패키지 형식을 선택합니다.
4. 클라이언트가 현재도 유지 관리되는지 확인하고, 버전 안내에서 최소 시스템 요구 사항을 읽습니다.
5. 기존 클라이언트에 설정이 있다면 먼저 설정을 내보내거나 구독 주소를 기록한 뒤 마이그레이션합니다.

파일 이름에 있는 “범용 버전”만으로 호환성을 판단하는 것은 권장하지 않습니다. 일부 범용 설치 패키지는 macOS용 두 아키텍처를 함께 담았다는 뜻이고, 다른 패키지는 여러 시스템 버전을 지원한다는 의미일 뿐입니다. 최종적으로는 다운로드 페이지의 표기와 클라이언트 릴리스 안내를 기준으로 판단하세요.

플랫폼별 설치: 프로그램 설치와 첫 실행 완료

플랫폼마다 화면은 다르지만 초기화 목표는 같습니다. 클라이언트가 설정을 저장하고 프록시 코어를 실행하며, 시스템 프록시를 변경하거나 가상 네트워크 인터페이스를 생성하는 데 필요한 권한을 확보해야 합니다. 첫 실행 단계에서는 다른 프록시, VPN, 네트워크 필터링 도구를 동시에 실행하지 마세요. 포트 충돌과 라우팅 충돌로 인해 원인을 판단하기 어려워질 수 있습니다.

Windows: 설치 경로와 권한 안내

아키텍처에 맞는 설치 프로그램을 실행하고 마법사의 안내에 따라 설치를 완료합니다. 일반적인 데스크톱 사용에서는 프로그램을 특수한 디렉터리에 설치할 필요가 없으며, 이유를 확인하지 않은 채 계속 관리자 권한으로 실행해서도 안 됩니다. 이후 TUN을 활성화하면 클라이언트가 별도로 권한 상승을 요청하거나 가상 네트워크 구성 요소를 설치할 수 있습니다. 이때 표시되는 안내가 방금 설치한 클라이언트에서 나온 것인지 확인하세요.

실행 후에는 코어 상태, 설정 페이지, 로그 페이지가 정상적으로 열리는지 먼저 확인합니다. 창이 나타나지 않는다면 작업 표시줄 알림 영역을 확인하세요. 일부 클라이언트는 기본적으로 트레이로 최소화됩니다. 실행 아이콘을 반복해서 눌러도 새 창이 만들어지는 대신 기존 프로세스만 깨울 수 있습니다.

macOS: 응용 프로그램 폴더와 시스템 권한

dmg로 설치할 때는 보통 앱을 “응용 프로그램” 폴더로 드래그한 뒤 해당 폴더에서 실행합니다. Intel과 Apple Silicon 설치 패키지는 임의로 섞어 사용할 수 없습니다. 처음 시스템 프록시를 활성화하면 클라이언트가 네트워크 설정 변경 권한을 요청할 수 있습니다. TUN 또는 강화 모드를 켤 때는 네트워크 확장, 보조 서비스, 관리자 암호 입력 안내가 나타날 수도 있습니다.

시스템에서 앱 실행을 차단하면 먼저 파일 출처와 클라이언트 릴리스 정보를 확인한 다음 macOS의 “개인정보 보호 및 보안” 설정에서 관련 기록을 확인하세요. 시스템 보안 기능을 끄는 것을 일반적인 설치 절차로 여기면 안 됩니다. 클라이언트를 업데이트한 뒤 권한 안내가 다시 나타나면 이전 보조 프로세스가 종료되었는지 확인하세요.

Linux: 패키지, 데스크톱 세션, 프록시 환경

deb 또는 rpm 패키지는 시스템 패키지 관리자로 설치하면 의존성과 제거 정보가 함께 등록됩니다. AppImage는 일반적으로 실행 권한을 추가한 뒤 실행해야 하지만, 구체적인 절차는 클라이언트 배포 방식에 따라 다릅니다. 데스크톱 환경의 “시스템 프록시”는 GNOME, KDE 또는 환경 변수 설정을 읽는 앱에만 적용될 수 있으며, 터미널 프로그램과 시스템 서비스가 자동으로 따르는 것은 아닙니다.

Linux에서 TUN을 활성화하려면 네트워크 관리, 라우팅 테이블, 장치 권한 설정이 필요한 경우가 많습니다. 처음 설정할 때는 먼저 일반 시스템 프록시로 구독과 노드를 확인하고, 프록시 코어 자체가 연결되는지 검증한 뒤 TUN 권한을 처리하세요. 이렇게 하면 “노드를 사용할 수 없음”과 “가상 인터페이스 설정 실패”를 서로 독립적인 문제로 나눌 수 있습니다.

구독 가져오기: 설정 주소에서 사용 가능한 정책 그룹까지

Clash 클라이언트는 일반적으로 구독 주소, 원격 설정 파일, 로컬 YAML 파일을 지원합니다. 처음 설치하는 사용자에게 가장 흔한 방법은 서비스 제공업체가 발급한 Clash 구독 주소를 붙여 넣는 것입니다. 이 주소에는 접근 인증 정보가 포함될 수 있으므로 계정 키처럼 취급해야 합니다. 스크린샷, 공개 로그, 코드 저장소, 채팅방에 게시하지 마세요.

클라이언트의 설정 또는 Profiles 페이지로 이동해 “구독 추가”, “URL에서 가져오기” 또는 이와 비슷한 메뉴를 찾습니다. 전체 주소를 붙여 넣고 저장한 뒤 업데이트를 실행합니다. 다운로드 성공은 클라이언트가 설정 파일을 받았다는 뜻일 뿐이며, 이어서 해당 설정을 현재 활성 항목으로 지정해야 합니다. 일부 클라이언트는 가져온 뒤 자동으로 활성화하지만, 다른 클라이언트는 설정 이름을 직접 클릭해야 합니다.

정상적으로 불러온 설정에는 보통 프록시 노드, 정책 그룹, 규칙, DNS 등이 표시됩니다. 정책 그룹은 별도의 노드가 아니라 특정 트래픽에 어떤 노드, 자동 선택 방식, 직접 연결 동작을 사용할지 결정하는 설정 단위입니다. 예를 들어 “노드 선택”은 회선을 수동으로 지정할 수 있고, “자동 선택”은 지연 시간 테스트 결과에 따라 전환할 수 있으며, “DIRECT”는 직접 연결을 의미합니다.

가져온 후 순서대로 확인할 항목

1. 설정 목록에 계속 회전 중이거나 오류 상태가 아니라 업데이트 성공 시간이 표시됩니다.
2. 프록시 페이지에 노드 또는 정책 그룹이 있고, 그룹 안에 선택 가능한 항목이 하나 이상 있습니다.
3. 현재 설정이 선택되어 있으며 코어 로그에 파싱 실패가 계속 보고되지 않습니다.
4. 규칙 모드에서 주요 정책 그룹이 노드 또는 유효한 자동 정책을 선택한 상태입니다.
5. 구독 자동 업데이트 간격이 적절하게 설정되어 짧은 시간 동안 원격 주소를 반복 요청하지 않습니다.

로컬 YAML 가져오기는 이미 설정 파일이 있거나 규칙을 직접 관리해야 하는 사용자에게 더 적합합니다. YAML은 들여쓰기와 문자 형식에 민감하므로 Tab, 전각 문장 부호, 중복 필드, 계층 오류가 파싱 실패를 일으킬 수 있습니다. 수정하기 전에 원본 파일을 보관하고, 한 번에 작은 부분만 변경한 뒤 클라이언트에서 다시 불러와 첫 번째 오류 로그를 확인하세요.

mode: rule
mixed-port: 7890
allow-lan: false
log-level: info

위의 예시는 일반적인 기본 필드만 보여 주며 완전한 설정 파일이 아닙니다. 실제 구독에는 프록시 노드, 정책 그룹, 규칙 등이 추가로 필요합니다. 포트도 7890으로 고정되지 않으므로 현재 클라이언트에 표시된 값을 기준으로 해야 합니다. 클라이언트가 포트를 자동 관리한다면 예시를 맞추기 위해 기존 설정을 강제로 덮어쓰지 마세요.

프록시 활성화: 규칙 모드, 시스템 프록시, TUN의 올바른 순서

설정을 가져온 후에는 먼저 “규칙” 모드를 선택하고, 사용 가능한 노드를 지정한 다음, 마지막으로 시스템 프록시를 켜는 것이 좋습니다. 규칙 모드는 설정의 규칙에 따라 직접 연결, 프록시, 연결 거부를 결정하므로 일상적인 사용에 적합합니다. 전역 모드는 대부분의 일치하는 트래픽을 선택한 프록시로 보내 단시간 비교 테스트에 유용하지만, 모든 문제를 해결하는 유일한 방법으로 사용하기에는 적합하지 않습니다. 직접 연결 모드는 프록시를 우회하므로 문제가 프록시 경로와 관련 있는지 확인할 때 사용할 수 있습니다.

시스템 프록시는 가장 쉽게 확인할 수 있는 진입점입니다. 클라이언트가 운영체제 설정에 로컬 HTTP, HTTPS 또는 SOCKS 프록시 주소를 기록하면 브라우저와 시스템 프록시를 따르는 데스크톱 앱이 연결을 Clash에 전달합니다. 모든 프로그램을 자동으로 가로채는 것은 아닙니다. 일부 게임, 명령줄 도구, 시스템 서비스, 자체 네트워크 스택을 구현한 소프트웨어는 시스템 프록시를 무시할 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 더 넓은 범위의 트래픽을 가로채며, 시스템 프록시 설정을 읽지 않는 앱에도 적합합니다. 또한 코어 설정과 함께 UDP 및 DNS를 처리할 수 있습니다. 일반적으로 더 높은 권한이 필요하고, 다른 VPN, 가상 머신 네트워크, 게임 가속기, 보안 소프트웨어의 네트워크 드라이버와 충돌할 수 있습니다. 처음 설치할 때 시스템 프록시, TUN, 여러 네트워크 도구를 동시에 켜지 마세요. 인터넷이 끊겼을 때 어느 계층에서 문제가 발생했는지 판단하기 어려워집니다.

TUN이 필요한 경우

• 대상 프로그램이 운영체제의 프록시 설정을 따르지 않는 경우
• 일부 UDP 트래픽을 가로채야 하며 노드, 코어, 설정이 해당 기능을 모두 지원하는 경우
• 프로토콜별로 프록시 주소를 설정하는 대신 여러 프로토콜을 규칙 매칭으로 통합하고 싶은 경우
• 시스템 프록시가 정상적으로 작동하는 것을 확인했으며 앱 적용 범위를 더 넓히려는 경우

브라우저와 일반적인 데스크톱 앱만 사용한다면 시스템 프록시가 대체로 관리하기 쉽습니다. TUN은 “속도 향상 스위치”가 아니라 트래픽이 코어로 들어오는 방식을 바꾸는 기능입니다. 실제 연결 성능은 여전히 회선 품질, 노드 부하, 대상 사이트에 의해 크게 좌우됩니다.

기본 확인: 노드, 규칙, DNS, 로그를 단계별로 점검

“연결됨”으로 표시된다고 해서 모든 트래픽이 예상대로 전달되는 것은 아닙니다. 신뢰할 수 있는 확인 방법은 코어 상태에서 시작해 노드 지연 시간, 브라우저 요청, 규칙 매칭, DNS 결과를 차례로 확인하는 것입니다. 테스트 중에는 한 번에 하나의 변수만 관찰하고, 노드·모드·설정을 연속해서 바꾸지 마세요.

1단계: 코어와 포트

클라이언트 상태 페이지에서 코어가 실행 중인지 확인하고 HTTP, SOCKS 또는 Mixed 포트를 확인합니다. 로그에 “address already in use” 또는 포트 사용 중이라는 안내가 나타나면 같은 포트를 다른 Clash 프로세스, 이전 클라이언트, 다른 프록시 프로그램이 사용 중일 수 있습니다. 충돌하는 프로그램을 종료한 뒤 코어를 다시 시작하거나, 클라이언트에서 허용하는 범위 내에서 수신 포트를 변경하세요.

2단계: 정책 그룹과 노드

지연 시간 테스트는 당시 테스트 주소와 연결을 설정할 수 있었다는 사실만 보여 줄 뿐, 다운로드 속도나 장기 안정성을 완전히 나타내지는 않습니다. 먼저 지연 시간 테스트를 완료할 수 있는 노드를 선택한 뒤 평소 안정적으로 열리는 사이트에 접속하세요. 자동 정책 그룹이 계속 전환된다면 잠시 수동 노드로 바꾸어 정책 변화로 인한 변수를 제거하세요.

3단계: 규칙 매칭

연결 기록 또는 실시간 로그를 열고 대상 도메인이 어떤 규칙과 일치했는지, 최종적으로 어느 정책 그룹으로 들어갔는지 확인합니다. 대상이 잘못 DIRECT로 배정되었다면 규칙 순서와 현재 설정을 점검하세요. 프록시 그룹에 들어갔지만 연결에 실패한다면 노드, DNS, 원격 응답을 계속 확인합니다. 규칙은 대개 설정된 순서대로 매칭되므로 앞쪽의 광범위한 규칙이 뒤쪽의 구체적인 규칙을 덮어쓸 수 있습니다.

4단계: DNS

도메인은 열리지 않지만 알려진 IP에 직접 접속했을 때 응답이 있다면 DNS 문제일 수 있습니다. 로그에서 이름 해석 시간 초과, 업스트림 연결 불가, 순환 전달 안내를 확인하세요. 시스템에서 DNS를 변경하는 다른 도구를 함께 사용 중이라면 먼저 명확한 하나의 해석 경로만 유지하세요. TUN 모드에서는 클라이언트가 요구하는 DNS 설정이 활성화되어 있는지도 확인해야 합니다. 가상 인터페이스가 트래픽을 가로챈 뒤에도 요청이 연결할 수 없는 주소로 전달되는 상황을 피해야 합니다.

확인이 끝나면 정상적으로 작동한 설정 이름, 모드, 노드, 프록시 활성화 상태를 기록하세요. 이후 클라이언트를 업그레이드하거나 구독을 바꿀 때 이 상태를 되돌림 기준으로 사용할 수 있습니다.

흔한 오류: 장애가 발생한 위치부터 해결

구독 다운로드 실패 또는 시간 초과

먼저 구독 주소가 완전한지, 복사 과정에서 공백·줄바꿈·중국어 문장 부호가 추가되지 않았는지 확인합니다. 그다음 시스템 시간이 정확한지, 일반 네트워크로 구독 서버에 접속할 수 있는지, 서비스 제공업체가 구독 주소 갱신을 요구하는지 확인하세요. 이전 클라이언트에서는 업데이트되지만 새 클라이언트에서 실패한다면 두 클라이언트의 사용자 에이전트 요구 사항, 네트워크 출구, 구독 형식 지원 여부를 비교해 보세요. 실패했다고 짧은 시간에 계속 새로 고치면 원격 서비스가 요청 빈도를 제한할 수 있습니다.

구독 업데이트는 성공했지만 노드가 보이지 않음

설정이 아직 활성화되지 않았거나 프록시 제공자 참조만 포함되어 클라이언트가 provider 내용을 추가로 불러와야 할 수 있습니다. 설정 상세 정보와 로그에서 원격 제공자가 정상적으로 다운로드되었는지 확인하세요. 로그에 지원하지 않는 필드 또는 YAML 파싱 오류가 표시되면 구독 형식과 현재 코어가 맞지 않는 것입니다. 서비스 제공업체가 제공한 Clash 또는 mihomo 형식을 사용하고, 다른 클라이언트용 형식의 파일 이름만 바꿔 가져오지 마세요.

시스템 프록시를 켠 후 브라우저가 인터넷에 연결되지 않음

먼저 코어가 계속 실행 중인지, 시스템 프록시가 가리키는 포트가 클라이언트의 수신 포트와 일치하는지 확인합니다. 그런 다음 시스템 프록시를 끄고 직접 연결이 복구되는지 확인한 뒤 코어를 다시 시작하세요. 클라이언트가 비정상 종료된 후에도 시스템에 이전 프록시 주소가 남아 있다면 운영체제 네트워크 설정에서 수동 프록시를 끄세요. 복구한 뒤에는 프록시 클라이언트 하나만 실행해 다시 테스트합니다.

노드에는 지연 시간이 있지만 웹페이지가 열리지 않음

지연 시간 테스트 주소와 대상 웹사이트는 동일한 연결이 아닙니다. 실시간 로그에서 대상 도메인, 규칙 매칭, 정책 그룹, 오류 유형을 확인하세요. 연결 시간 초과라면 같은 구독의 다른 노드로 바꿔 비교합니다. 특정 도메인에서만 실패하면 규칙과 DNS를 중점적으로 확인하고, 모든 노드가 동시에 실패하면 포트를 하나씩 바꾸기보다 로컬 네트워크, 구독 상태, 서버 상태를 먼저 점검하세요.

TUN 활성화 실패 또는 활성화 후 네트워크 끊김

클라이언트가 가상 인터페이스를 생성하는 데 필요한 권한을 얻었는지 확인하고, 다른 VPN·이전 프록시 코어·라우팅을 변경할 수 있는 네트워크 도구를 종료하세요. Windows에서는 비정상적인 가상 어댑터가 남아 있는지 확인하고, macOS에서는 네트워크 확장 권한을 확인하며, Linux에서는 TUN 장치, 라우팅 권한, 네트워크 관리 서비스를 점검해야 합니다. TUN을 끈 뒤 시스템 프록시가 정상 작동한다면 노드와 구독은 대체로 정상이며, 문제는 권한·라우팅·DNS 가로채기 계층에 집중되어 있습니다.

로컬 네트워크 기기에서 이 컴퓨터의 프록시를 사용할 수 없음

기본 로컬 수신 설정은 보통 이 컴퓨터에서 시작된 연결만 허용합니다. 로컬 네트워크 기기에 프록시를 제공해야 한다면 클라이언트에서 LAN 연결 허용을 활성화하고 다른 기기에서 접근할 수 있는 주소를 수신하도록 설정해야 합니다. 운영체제 방화벽에서도 해당 포트를 허용해야 합니다. 외부에 열기 전에 현재 네트워크를 신뢰할 수 있는지 확인하고 클라이언트가 지원하는 접근 제어를 설정하세요. 이 컴퓨터에서만 사용할 때는 LAN 접근을 꺼 두면 불필요한 노출을 줄일 수 있습니다.

클라이언트 업데이트 후 기존 설정이 작동하지 않음

먼저 설정이 마이그레이션되지 않은 것인지, 코어 경로가 바뀐 것인지, 새 버전에서 이전 필드를 더 이상 지원하지 않는 것인지 판단합니다. 이전 설정 사본을 보관하고 업데이트 후 발생한 첫 번째 파싱 오류를 확인하세요. 모든 설정을 한 번에 삭제하지 마세요. 구독을 다시 받을 수 있다면 새 설정을 만든 뒤 다시 가져오고, 로컬 규칙 일부만 수동으로 복원하는 것이 우선입니다. 클라이언트 간 마이그레이션에서는 화면 설정, 오버라이드 규칙, 스크립트가 구독만으로 자동 이전되지 않는 경우가 많습니다.

초기화 완료 후 유지 관리 목록

Clash가 정상적으로 실행된 뒤에는 설정 출처를 명확히 유지하고 중복 네트워크 구성 요소를 줄이며, 변경이 발생했을 때 비교 가능한 상태를 남기는 것이 중요합니다. 클라이언트 업그레이드, 구독 규칙 업데이트, 운영체제 네트워크 초기화는 기존 프록시 동작을 바꿀 수 있습니다.

• 현재 정상적으로 작동하는 클라이언트 버전, 설정 이름, 아키텍처 정보를 보관합니다.
• 구독 서비스가 권장하는 주기에 맞춰 업데이트하고, 의미 없이 연속해서 새로 고치지 않습니다.
• 네트워크를 바꾼 뒤에는 프로그램을 바로 재설치하지 말고 노드 지연 시간과 DNS를 다시 확인합니다.
• 동일한 시스템 프록시 포트와 TUN 라우팅은 하나의 클라이언트만 담당하게 합니다.
• 클라이언트를 종료하기 전에 시스템 프록시를 끄고, 비정상 종료 후에는 운영체제 프록시 설정을 확인합니다.
• YAML, 오버라이드 규칙, DNS 설정을 수정하기 전에 원본 설정을 저장합니다.
• 문제 해결 시 로그에 기록된 첫 번째 오류부터 확인한 뒤 연쇄적으로 나타난 후속 안내를 처리합니다.

Clash 처음 설치 과정은 올바른 설치 패키지 선택, 코어 실행 확인, 구독 가져오기 및 활성화, 규칙 모드와 노드 선택, 시스템 프록시를 통한 우선 검증, 필요에 따른 TUN 설정으로 정리할 수 있습니다. 단계별로 처리하면 연결 실패가 발생해도 문제가 설치, 설정, 노드, 규칙, DNS, 트래픽 가로채기 중 어느 부분에 있는지 빠르게 판단할 수 있습니다.