Clash 클라이언트 첫 설치: 플랫폼별 초기 설정과 초보자가 자주 겪는 문제

Clash 계열 클라이언트를 처음 실행할 때는 시스템 프록시, TUN, 시작 프로그램 등록을 한꺼번에 켜지 마세요. ‘설치 파일 → 설정 → 정책 그룹 → 트래픽 연결 → 연결 확인’ 순서로 진행하고, 단계마다 결과를 확인하세요. 그래야 인터넷이 끊겼을 때 구독 다운로드 실패인지, 기기 트래픽이 커널에 전달되지 않은 것인지 구분하기 쉽습니다.

1. 설치 파일과 시스템 아키텍처

Clash 계열 클라이언트는 대개 그래픽 인터페이스와 프록시 커널로 구성됩니다. 인터페이스에서는 설정 가져오기, 정책 관리, 시스템 설정 변경을 담당하고, 커널은 포트 대기, 규칙 매칭, 연결을 처리합니다. 인터페이스를 설치했다고 사용할 수 있는 노드가 생기는 것도 아니고, 모든 앱이 자동으로 프록시를 사용하는 것도 아닙니다.

플랫폼	먼저 확인할 항목	설치 파일 선택 기준
Windows	‘설정’ → ‘시스템’ → ‘정보’ → ‘장치 사양’	일반적인 Intel·AMD 데스크톱은 x64를 선택하세요. ARM 기기는 클라이언트의 네이티브 지원 여부를 먼저 확인해야 합니다.
macOS	Apple 메뉴 → ‘이 Mac에 관하여’	Apple 칩은 arm64, Intel 프로세서는 x64를 선택하세요. macOS 최소 요구 버전도 확인해야 합니다.
Linux	터미널에서 `uname -m` 실행	`x86_64`는 x64, `aarch64`는 arm64에 해당합니다. Debian 계열과 RPM 계열은 각각 맞는 패키지를 선택하세요.
Android	운영체제 버전, 기기 프로세서, 설치 페이지의 요구 사항	최근 기기는 대부분 arm64-v8a를 사용합니다. 구형 기기는 다른 아키텍처가 필요할 수 있으므로 브랜드만 보고 판단하지 마세요.
iOS / iPadOS	앱 스토어 제품 페이지의 호환성 안내	호환되는 설정의 클라이언트를 선택하세요. Windows용 EXE나 Android용 APK를 다른 플랫폼에 설치할 수는 없습니다.

설치에 실패하면 시스템 안내부터 확인

호환되지 않는다는 안내: 운영체제 버전과 프로세서 아키텍처를 대조하세요. 파일 이름만 비슷한 패키지를 여러 개 연달아 설치하지 마세요.
실행 환경이 없다는 안내: 해당 클라이언트의 릴리스 안내에 따라 필요한 런타임 구성 요소를 설치하세요. 출처가 불분명한 다운로드 사이트에서 같은 이름의 DLL을 받지 마세요.
출처 또는 서명에 문제가 있다는 안내: 다운로드 출처, 게시자, 프로젝트 안내를 먼저 확인하세요. 보안 경고가 일괄적으로 ‘계속’을 눌러도 되는 상황을 뜻하지는 않습니다. 기기 관리 정책을 보안 기능 해제로 우회해서도 안 됩니다.

Windows에서 시스템 프록시만 처음 테스트하는 경우, 일반적으로 그래픽 인터페이스 전체를 계속 관리자 권한으로 실행할 필요는 없습니다. 서비스를 설치하거나 가상 네트워크 어댑터를 만들 때 해당 권한 요청을 처리하세요. 조직에서 관리하는 PC라면 네트워크 서비스 설치가 허용되는지 먼저 확인해야 합니다.

2. 구독 가져오기와 설정 활성화

일반적인 클라이언트에는 ‘설정’, ‘Profiles’ 또는 ‘구독’ 메뉴가 있습니다. 서비스 제공업체에서 받은 Clash 또는 mihomo 호환 구독 주소를 복사한 뒤 해당 페이지에서 ‘가져오기’, ‘원격 설정 추가’ 또는 ‘Download’를 선택하세요. 구버전 CFW의 경우 ‘Profiles’ → 상단 URL 입력란 → ‘Download’ 순서로 진행합니다. 다운로드가 끝나면 해당 설정 카드를 눌러 현재 설정으로 활성화해야 합니다.

형식을 확인하세요: 일반 웹 주소, 노드 공유 링크, 다른 클라이언트 전용 구독 주소는 Clash YAML 설정으로 불러오지 못할 수 있습니다.
다운로드 결과를 확인하세요: 설정 목록에 새 항목이 표시되고 업데이트 성공 상태인지 확인합니다. URL만 저장되고 다운로드에 실패했다면 가져오기가 완료된 것이 아닙니다.
활성화 여부를 확인하세요: ‘프록시’ 또는 ‘Proxies’ 페이지로 이동해 설정에 정의된 정책 그룹이 표시되는지 확인합니다. 화면이 비어 있다면 현재 선택된 설정부터 확인하세요.
커널 호환성을 확인하세요: 오류에 알 수 없는 프로토콜, 알 수 없는 필드, 지원되지 않는 프록시 유형이 포함되어 있다면 업데이트를 반복해서 누르기보다 구독에 필요한 커널을 확인하세요.

구독 다운로드 실패와 노드 연결 실패는 서로 다른 문제입니다

구독 다운로드는 설정 서버에 접속하는 과정이고, 노드 테스트는 선택한 프록시를 통해 대상 주소에 접속하는 과정입니다. 구독 요청에 HTTP 401 또는 403이 반환되면 링크 유효성, 권한, 서비스 제공업체의 제한을 먼저 확인하세요. HTML이 반환된다면 로그인 페이지나 오류 페이지를 받은 것일 수 있습니다. 파서에서 YAML 오류가 발생하면 들여쓰기를 감으로 고치기 전에 응답 내용이 실제 설정인지 확인하세요.

일부 클라이언트는 원격 설정의 로컬 사본을 저장합니다. 이 사본을 직접 수정하면 다음 구독 업데이트 때 변경 내용이 덮어써질 수 있습니다. 처음 설정할 때는 원본 설정으로 먼저 확인하고, 사용자 지정 규칙이 필요하다면 클라이언트가 제공하는 재정의, 병합 또는 확장 기능을 살펴보세요.

3. 규칙 모드와 정책 선택

설정을 불러온 뒤 Rule(규칙) 모드를 선택하고 정책 그룹에서 노드를 하나 고르세요. Global(전역) 모드는 일반적으로 커널에 들어온 연결을 전역 정책으로 처리하고, Direct(직접 연결) 모드는 프록시 없이 연결할 때 사용합니다. 여기서 ‘전역’은 커널이 이미 받은 트래픽을 처리하는 방식을 뜻하며, 커널에 전달되지 않은 프로그램까지 자동으로 연결된다는 의미는 아닙니다.

그룹에서 직접 선택: 일반적인 유형은 select이며, 노드 또는 하위 정책 그룹을 직접 선택해야 합니다.
자동 테스트 그룹: 일반적인 유형은 url-test이며, 설정에 지정된 테스트 주소, 간격, 허용 오차 등이 선택 결과에 영향을 줍니다.
규칙의 대상: 규칙은 특정 정책 그룹을 지정하거나 DIRECT 또는 REJECT를 지정할 수 있습니다. 그룹 하나만 바꿔도 모든 웹사이트의 연결 경로가 바뀌는 것은 아닙니다.

지연 시간 테스트에 밀리초 값이 표시되더라도 해당 테스트 요청에서 응답을 받았다는 뜻일 뿐, 동영상 비트레이트나 다운로드 속도를 보장하지는 않습니다. 처음 연결을 확인할 때는 실제 웹페이지 하나를 열고 클라이언트의 ‘연결’ 또는 ‘Connections’ 페이지도 함께 살펴보세요. 요청에 어떤 규칙이 적용되고 어떤 정책을 사용하는지 확인할 수 있습니다.

4. 시스템 프록시와 모바일 VPN 권한

Windows: 대기 주소와 포트부터 확인

구버전 CFW에서는 ‘General’ 페이지에서 포트를 확인하고 ‘System Proxy’를 켤 수 있습니다. 다른 클라이언트에서는 보통 홈 화면이나 설정 페이지에 해당 메뉴가 있습니다. 다음은 필드 간 관계를 설명하기 위한 설정 예시입니다. 노드와 규칙을 포함한 완전한 구독 설정이 아니며, 모든 클라이언트의 기본값도 아닙니다.

mixed-port: 7890
allow-lan: false
mode: rule

mixed-port: 7890은 같은 대기 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있다는 뜻입니다. 클라이언트가 실제로 7897 포트에서 대기한다면 7897을 사용해야 하며, 이 글의 7890을 그대로 복사하면 안 됩니다. 로컬 기기에서만 사용할 경우 앱의 연결 주소는 보통 127.0.0.1입니다. allow-lan: false는 로컬 네트워크의 접속을 제한하므로, 브라우저로 인터넷을 사용하기 위해 로컬 네트워크 공유를 켤 필요는 없습니다.

시스템 프록시를 켠 뒤 Windows 11의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 설정을 확인하세요. 일반적으로 수동 프록시에 로컬 주소와 포트를 지정하지만, 일부 클라이언트는 프록시 스크립트를 사용합니다. 모든 항목을 켜야 하는 것이 아니라 시스템 설정과 클라이언트의 트래픽 처리 방식이 일치하는지가 중요합니다.

macOS·Linux·모바일 기기의 차이

macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인할 수 있습니다. 일부 클라이언트는 시스템 네트워크 설정을 변경하기 위해 보조 프로그램 설치를 요청합니다.
Linux: 데스크톱 환경의 네트워크 프록시 설정이 터미널 프로그램이나 모든 앱에 적용되는 것은 아닙니다. 브라우저, 패키지 도구, 명령줄 도구가 서로 다른 프록시 설정을 읽을 수 있습니다.
Android: 일반적으로 Windows의 ‘System Proxy’ 스위치를 그대로 사용하는 대신 로컬 VPN 서비스를 시작하고 시스템 권한을 허용합니다. 앱별 프록시 설정과 우회 목록도 실제로 트래픽을 처리하는 범위에 영향을 줍니다.
iOS / iPadOS: 보통 클라이언트에서 VPN 설정을 만든 뒤 시스템 안내에 따라 권한을 허용합니다. 지원 프로토콜, 백그라운드 동작, 설정 호환성은 사용하는 앱에 따라 다릅니다.

시스템 프록시는 시스템 설정을 따르는 앱에서 주로 사용됩니다. 게임이나 명령줄 도구가 연결 목록에 나타나지 않는다고 해서 노드에 문제가 있는 것은 아닙니다. 해당 프로그램이 시스템 프록시를 읽지 않을 수 있습니다. 먼저 앱 자체의 프록시 설정을 확인한 다음 TUN 사용을 고려하세요.

5. 포트 충돌과 연결 확인

처음 연결을 테스트할 때는 프록시 클라이언트를 하나만 실행하는 것이 좋습니다. 이전 클라이언트, 개발 도구, 백그라운드 서비스가 포트를 점유할 수 있습니다. 로그에 address already in use 또는 bind 실패가 표시되면 구독을 다시 다운로드하기보다 대기 포트를 먼저 확인하세요.

Windows에서 7890 포트 사용 여부 확인

netstat -ano | findstr :7890

결과에 로컬 포트가 7890이고 상태가 LISTENING인 행이 있는지 확인하세요. 마지막 열의 값은 PID입니다. ‘작업 관리자’ → ‘세부 정보’에서 PID에 해당하는 프로그램을 찾으세요. 사용하지 않는 이전 프록시임을 확인한 경우 정상적으로 종료하세요. 정체를 알 수 없는 시스템 프로세스를 강제로 종료하지 마세요. 사용 중이지 않은 다른 포트로 변경할 수도 있지만, 시스템 프록시와 수동 설정을 사용하는 앱도 함께 수정해야 합니다.

프록시를 명시한 요청으로 문제 범위 좁히기

실제로 대기 중인 포트가 로컬 HTTP 또는 혼합 포트 7890이라면 Windows 터미널에서 다음 진단 명령을 실행할 수 있습니다. macOS와 Linux에서는 curl.exe를 curl로 바꾸세요.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

이 명령은 프록시 포트에 직접 연결하므로 브라우저가 시스템 설정을 읽는지 여부와 관계없이 테스트할 수 있습니다. 다만 커널의 규칙은 그대로 적용되므로 응답에 성공했다고 해서 반드시 원격 노드를 통과한 것은 아닙니다. 규칙이 직접 연결을 선택했다면 대상에 직접 접속할 수 있습니다. 연결 패널에서 경로를 함께 확인하세요. 예시의 10초는 연결 단계의 제한 시간이고 20초는 전체 요청의 최대 시간이며, 측정 결과가 아닙니다.

확인된 증상	먼저 확인할 항목
로컬 포트 연결 실패가 즉시 표시됨	커널이 실행 중인지, 대기 포트가 일치하는지, 포트 바인딩 오류가 있는지 확인하세요.
요청이 연결 패널에 표시된 뒤 시간 초과됨	선택한 정책, 노드 연결 로그, 대상 사이트, 로컬 네트워크에서 해당 연결을 허용하는지 확인하세요.
명령은 성공하지만 브라우저에서는 접속할 수 없음	시스템 프록시, 브라우저 자체 프록시 설정, 확장 프로그램, 브라우저에 캐시된 기존 연결을 확인하세요.
브라우저는 되지만 특정 앱은 연결되지 않음	앱의 프록시 지원 여부, 시스템 설정 우회 여부, 추가 트래픽 처리 기능이 필요한지 확인하세요.

6. 인증서 경고와 TUN 권한

브라우저 인증서 오류를 무시하지 마세요

일반적인 HTTP CONNECT 터널이나 SOCKS 전달을 사용한다면 HTTPS 사이트를 보기 위해 출처를 모르는 루트 인증서를 설치할 필요가 없습니다. 브라우저에 인증서 만료, 도메인 불일치, 신뢰할 수 없는 발급 기관 경고가 표시되면 먼저 시스템 날짜, 시간대, 시간 동기화를 확인하세요. 다음으로 조직 네트워크 검사, 백신의 HTTPS 검사, 로그인 인증 페이지가 있는지 살펴보세요.

클라이언트 설치 중의 앱 서명 경고, 구독 다운로드 중의 TLS 오류, 브라우저로 사이트에 접속할 때의 인증서 오류는 서로 다른 단계에서 발생합니다. 모든 인증서 관련 옵션을 끄기보다 정확한 오류와 발생 위치를 기록하는 편이 문제 해결에 도움이 됩니다. skip-cert-verify를 만능 해결책처럼 사용하지 마세요. 해당 연결의 인증서 검증 방식이 바뀌며, 실제 문제가 노드에 있는지 가려질 수도 있습니다.

기본 연결 확인 후 TUN 설정

TUN은 가상 네트워크 인터페이스와 라우팅 설정을 통해 조건에 맞는 IP 트래픽을 처리합니다. 시스템 프록시를 사용하지 않는 프로그램에 유용하지만, 켰다고 모든 트래픽이 프록시를 통과하는 것은 아닙니다. 라우팅 제외 설정, 앱별 설정, IPv6, DNS 처리, 시스템 권한에 따라 적용 범위가 달라집니다.

먼저 시스템 프록시를 사용해 브라우저가 정상적으로 접속되고 연결 패널의 정책이 예상대로 표시되는지 확인하세요.
사용 중인 클라이언트의 안내에 따라 서비스를 설치하거나 활성화한 뒤 TUN을 켜세요. Windows에서는 서비스 설치나 권한 상승이 필요한 경우가 많고, macOS와 Linux에서는 보조 프로그램이나 네트워크 관리 권한이 필요할 수 있습니다.
로그에서 가상 인터페이스 생성 실패, 라우팅 설정 실패, DNS 대기 충돌이 발생했는지 확인하세요. 다른 VPN의 트래픽 처리 기능을 동시에 켜지 마세요.
원래 시스템 프록시를 따르지 않던 프로그램으로 연결을 테스트하세요. 켠 뒤 기기 전체에서 인터넷이 끊기면 먼저 TUN을 꺼서 네트워크를 복구한 다음 로그를 확인하세요.

DNS 가로채기 규칙은 특정 DNS 트래픽을 커널로 전달하기 위한 것입니다. 브라우저 내장 암호화 DNS, 모든 네트워크 인터페이스, 모든 앱이 반드시 같은 경로를 따른다는 뜻은 아닙니다. 처음 설정할 때 DNS 모드, IPv6 정책, 라우팅 옵션을 한꺼번에 바꾸지 마세요. 한 번에 하나씩 바꿔야 어떤 설정이 영향을 줬는지 확인할 수 있습니다.

7. 종료 후 복구와 최종 점검표

초기 설정을 마친 뒤 자동 시작, 시작 시 연결, 구독 자동 업데이트를 켤지 결정하세요. 먼저 클라이언트를 정상적으로 종료해 보세요. 트래픽 처리 스위치를 끄고 트레이나 메뉴에서 클라이언트를 종료한 다음 일반 네트워크가 복구되는지 확인합니다. 프로세스를 강제 종료하면 시스템 프록시는 로컬 주소를 가리키는데 해당 포트에서 대기하는 프로그램은 없는 상태로 남을 수 있습니다.

Windows에서 종료 후 인터넷에 연결되지 않으면 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 남아 있는 수동 프록시나 스크립트 설정을 확인하세요. 직접 추가한 설정만 되돌리고, 조직에서 관리하는 PC의 기존 프록시 정책은 함부로 삭제하지 마세요. 모바일 기기에서는 시스템 VPN 상태와 ‘항상 켜기’, ‘VPN 연결 없이 연결 차단’ 옵션을 확인하세요.

설치: 아키텍처, 최소 운영체제 요구 사항, 클라이언트 유지보수 상태를 확인했습니다.
설정: 구독 다운로드에 성공했고 현재 설정이 활성화되어 있으며 정책 그룹이 정상적으로 표시됩니다.
모드: 규칙 모드를 사용하고 테스트 요청에 실제로 적용된 규칙과 정책을 확인했습니다.
포트: 시스템 프록시 또는 앱 설정의 포트가 실제 대기 포트와 일치하며, 여러 클라이언트가 같은 포트를 두고 경쟁하지 않습니다.
권한: 서비스, VPN 또는 TUN이 필요한 경우에만 해당 권한을 허용했으며, 보안 검증을 끄는 방식으로 문제를 해결하지 않았습니다.
복구: 트래픽 처리를 끄고 정상 종료한 뒤 네트워크가 연결되는지 확인했으며, 남은 설정을 되돌릴 위치도 알고 있습니다.

이 여섯 가지를 모두 확인한 다음 사용자 지정 규칙, 앱별 라우팅, TUN 트래픽 처리를 추가하세요. 이후 문제가 생겨도 같은 순서로 돌아가 확인하면 됩니다. 설정이 유효한지, 커널이 포트를 열고 있는지, 트래픽이 전달되는지, 규칙이 어떻게 적용되는지, 외부 연결이 가능한지 점검하세요. 반복해서 삭제하고 다시 설치하는 것보다 문제를 찾기 쉽습니다.