Clash 설치·설정
Windows·macOS·Android·iOS·Linux

01 / PREPARE

공통 준비 작업: 클라이언트, 구독 및 네트워크 범위

클라이언트, 코어, 구독부터 구분하기

설치를 시작하기 전에 자주 혼동하는 세 가지 개념을 먼저 구분해야 합니다. 클라이언트는 사용자가 직접 조작하는 그래픽 인터페이스로, 설정 가져오기, 정책 전환, 로그 확인과 시스템 프록시 제어를 담당합니다. Mihomo와 같은 코어는 설정을 해석하고 규칙을 매칭하며 프록시 연결을 수립합니다. 구독은 서비스 제공자가 전달하는 설정 진입점으로, 일반적으로 노드, 정책 그룹, 규칙과 업데이트 주소를 포함합니다. 클라이언트를 설치한다고 사용할 수 있는 노드가 자동으로 생기지는 않으며, 코어만 내려받는다고 완전한 데스크톱 인터페이스가 만들어지는 것도 아닙니다. 일반적인 데스크톱과 모바일 기기에서는 그래픽 인터페이스가 있는 클라이언트를 우선 선택하고, 서버·라우터·자동화 환경에서는 코어를 직접 실행하는 방식이 더 적합합니다.

이 사이트의 다운로드 페이지에서는 플랫폼별 선택 가능한 소프트웨어를 안내하며, 각 플랫폼의 첫 번째 항목으로 Clash Plus를 배치했습니다. Windows에서는 Clash Verge Rev, FlClash, Clash Nyanpasu와 보관 버전인 Clash for Windows도 선택할 수 있습니다. macOS에서는 Clash Verge Rev, FlClash와 보관 버전인 ClashX Meta를 제공합니다. Android에서는 Clash Meta for Android, FlClash 또는 Surfboard를 사용할 수 있고, Linux 데스크톱에서는 Clash Verge Rev와 FlClash를 선택할 수 있습니다. 클라이언트마다 메뉴 이름은 조금 다를 수 있지만 기본 흐름은 같습니다. 구독 가져오기, 설정 선택, 노드 테스트, 정책 선택, 프록시 활성화, 외부 IP 확인 순서로 진행합니다.

필요한 정보를 기록하고 시스템 아키텍처 확인하기

다운로드 전에 기기의 운영체제 버전과 프로세서 아키텍처를 확인하세요. Windows는 대개 x64이며 일부 최신 기기는 ARM64를 사용합니다. Apple Silicon Mac은 Apple Silicon 또는 ARM 빌드를, 구형 Intel Mac은 x64 빌드를 선택해야 합니다. Android 설치 패키지는 arm64, arm 또는 범용 아키텍처로 나뉠 수 있으며, Linux에서는 Debian 계열, RPM 계열과 압축 형식의 독립 바이너리를 구분해야 합니다. 아키텍처가 맞지 않으면 설치 프로그램이 실행을 거부하거나 시작 후 형식 오류를 표시할 수 있습니다. 확실하지 않다면 기기 외관으로 추측하지 말고 시스템의 ‘이 Mac에 관하여’ 또는 ‘기기 정보’를 확인하거나 시스템 명령을 사용하세요.

# Windows PowerShell
$env:PROCESSOR_ARCHITECTURE

# macOS
uname -m

# Linux
uname -m
cat /etc/os-release

유효한 구독 주소, 필요한 로그인 정보와 구독 진입점에 정상적으로 접근할 수 있는 네트워크도 미리 준비하세요. 구독 주소에는 인증 매개변수가 포함되는 경우가 많으므로 비밀번호처럼 보관하고, 공개 스크린샷·질문 게시물·공유 로그에 붙여 넣지 마세요. 서비스 제공자가 QR 코드를 제공한다면 모바일에서는 스캔해 가져올 수 있고, 데스크톱에서는 보통 URL을 클립보드에 붙여 넣습니다. 로컬 YAML 파일을 받은 경우에는 ‘구독 링크’가 아니라 ‘로컬 설정 가져오기’를 사용해야 합니다. 로컬 파일은 원격 업데이트를 자동으로 따라가지 않기 때문입니다.

설치 전 기준 상태 만들기

프록시를 활성화하기 전에 기기 시간, 브라우저 접속과 DNS 조회가 정상인지 확인하세요. 시스템 시간이 어긋나면 TLS 연결이 실패할 수 있고, 기존 VPN·기업 보안 소프트웨어·가상 네트워크 어댑터·다른 프록시 프로그램이 포트를 점유하거나 라우팅을 변경할 수 있습니다. 먼저 유사한 네트워크 도구를 잠시 종료하고 기존 시스템 프록시 설정을 기록한 뒤 Clash 클라이언트를 설치하는 것이 좋습니다. 이렇게 하면 연결 문제가 발생했을 때 원래 네트워크, 클라이언트의 트래픽 적용 또는 구독 내용 중 어디에서 비롯되었는지 구분하기 쉽습니다.

시스템 프록시와 TUN 선택하기

시스템 프록시는 운영체제의 프록시 설정을 따르는 브라우저와 데스크톱 앱에 주로 영향을 줍니다. 설정이 간단하고 적용 범위가 명확해 처음 연결할 때 적합합니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅 계층에서 더 많은 트래픽을 넘겨받으므로 시스템 프록시를 읽지 않는 프로그램, 일부 명령줄 도구와 게임까지 처리할 수 있지만 더 높은 권한이 필요하며 다른 VPN·가상 머신·컨테이너 네트워크·보안 소프트웨어와 충돌하기 쉽습니다. 둘은 속도 단계가 아니라 트래픽을 처리하는 방식의 차이입니다. 특별한 요구가 없다면 먼저 시스템 프록시를 사용하고, 앱이 시스템 프록시를 우회할 때 TUN을 검토하세요.

02 / WINDOWS

Windows 설치·설정: 시스템 프록시, 서비스 모드와 TUN

다운로드하고 처음 설치 완료하기

Windows 사용자는 Windows 다운로드 영역에서 Clash Plus를 선택하거나 필요에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 선택할 수 있습니다. Clash for Windows는 유지 관리가 중단되었으므로 기존 설정과의 호환을 위한 보관 항목일 뿐, 새로운 환경에서 장기간 사용하는 것은 권장하지 않습니다. 다운로드 전에 ‘설정 → 시스템 → 시스템 정보’에서 시스템 종류를 확인하세요. 대부분의 데스크톱 PC는 x64입니다. 설치 프로그램에서 시스템 보안 확인이 표시되면 파일명과 다운로드 출처를 확인한 뒤 일반적인 앱 설치 절차를 진행하세요.

설치가 끝나면 클라이언트를 한 번 정상적으로 실행해 설정 디렉터리와 기본 설정을 만들게 하세요. 화면이 열리지 않는다고 곧바로 호환 모드를 사용하거나 반복해서 재설치하지 마세요. 먼저 작업 관리자에서 같은 이름의 프로세스가 이미 실행 중인지 확인하고, 백그라운드 프로세스를 종료한 뒤 다시 시작하세요. 포터블 버전과 설치 버전은 데이터 디렉터리가 다를 수 있습니다. 마이그레이션할 때 실행 파일만 복사하지 말고, 클라이언트가 제공하는 설정 디렉터리 경로를 통해 profiles, logs와 관련 데이터를 찾으세요.

구독 가져오기 및 설정 활성화

클라이언트의 구독·설정 또는 Profiles 페이지를 열고 입력란에 구독 URL을 붙여 넣은 뒤 가져오기를 실행하세요. 가져오기가 완료되면 보통 설정 이름, 업데이트 시간과 정책 그룹이 표시됩니다. 설정 카드가 보인다고 활성화된 것은 아니므로 해당 설정을 클릭하거나 현재 설정으로 지정해야 합니다. 그런 다음 프록시 또는 Proxies 페이지로 이동해 후보 노드의 지연 시간을 먼저 테스트하세요. 지연 테스트가 실패했다고 구독을 바로 삭제할 필요는 없습니다. ICMP, TCP 탐색과 실제 웹 접속은 서로 다른 방식을 사용할 수 있으므로 노드를 하나 선택해 실제 접속도 확인하세요.

구독 업데이트가 실패하면 먼저 브라우저에서 구독 진입점에 접속할 수 있는지 확인하세요. 브라우저에서는 열리지만 클라이언트에서 오류가 난다면 URL 복사 과정에서 끝부분의 매개변수가 빠졌는지, 공백이 섞였는지, 클라이언트가 구독 업데이트에 현재 프록시를 잘못 사용하고 있는지 확인합니다. 일부 클라이언트는 ‘직접 연결로 업데이트’ 또는 업데이트 프록시 옵션을 제공합니다. 기본 네트워크가 정상일 때 전환해 테스트하세요. 원격 설정을 업데이트하면 구독 제공자가 지정한 노드와 규칙이 덮어써지므로, 수동으로 수정하기 전에 클라이언트가 오버라이드 기능을 제공하는지 확인하세요.

시스템 프록시 활성화 및 모드 선택

처음 연결할 때는 규칙 모드를 권장합니다. 사용 가능한 노드나 정책 그룹을 선택한 뒤 ‘시스템 프록시’ 스위치를 켜세요. 클라이언트가 Windows 프록시 설정을 기록하며, 일반적인 로컬 주소는 루프백 주소이고 포트는 현재 설정이나 클라이언트 설정에 따라 달라집니다. 브라우저는 대개 새 설정을 즉시 읽지만 이미 실행 중인 일부 앱은 다시 시작해야 합니다. 글로벌 모드는 대부분의 요청을 선택한 정책으로 보내므로 규칙이 잘못 분기되는지 잠시 확인할 때 유용하고, 직접 연결 모드는 일시적으로 프록시를 우회할 때 사용합니다. 문제를 확인한 뒤에는 프록시 적용 범위를 불필요하게 넓히지 않도록 규칙 모드로 돌아가세요.

시스템 프록시가 켜져 있는데도 브라우저가 직접 연결된다면 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 수동 프록시가 입력되었는지 확인하고, 기업 정책이나 다른 소프트웨어가 해당 값을 즉시 덮어쓰지 않는지도 확인하세요. 여러 클라이언트의 시스템 프록시를 동시에 켜지 마세요. 동일한 시스템 설정을 서로 차지하려고 경쟁하게 됩니다. 클라이언트가 비정상 종료된 뒤 웹페이지에 전혀 접속할 수 없다면, 시스템이 이미 종료된 로컬 포트를 계속 가리키고 있을 가능성이 큽니다. 이때 수동 프록시를 끄면 기본 네트워크를 복구할 수 있습니다.

서비스 모드 및 TUN 권한

Windows의 TUN은 보통 관리자 권한이 필요하거나 클라이언트가 백그라운드 서비스를 설치해야 합니다. 서비스 모드는 코어 또는 네트워크 구성 요소를 제한된 권한 환경에서 실행하기 위한 것으로, 노드 서비스와는 다릅니다. 서비스를 설치한 뒤 TUN을 켜면 새로운 가상 네트워크 어댑터와 관련 라우팅이 추가됩니다. 처음 활성화할 때 보안 소프트웨어에서 네트워크 접근을 확인할 수 있으므로 현재 필요한 네트워크 유형에서 클라이언트 통신을 허용하세요. 서비스 설치에 실패하면 이전 버전 클라이언트를 종료하고 시스템 서비스에 같은 이름의 잔여 항목이 없는지 확인한 뒤, 관리자 권한으로 클라이언트의 서비스 설치 기능을 실행하세요.

Windows 고유 문제 확인

스토어 앱, 명령줄 프로그램과 일부 게임은 시스템 프록시를 반드시 따르지 않습니다. 일반 브라우저는 연결되지만 특정 앱만 연결되지 않는다면 먼저 해당 앱이 WinINET 또는 시스템 프록시를 읽는지 확인하세요. 읽지 않는 경우에만 TUN을 사용하고, 처음부터 구독 규칙을 수정하지는 마세요. 로컬 네트워크 기기만 본체의 프록시에 접속하지 못한다면 ‘LAN 연결 허용’ 설정, Windows 방화벽 인바운드 규칙과 수신 주소를 확인해야 합니다. 다만 LAN 수신을 허용하면 같은 네트워크의 기기가 해당 포트에 접속할 수 있으므로 꼭 필요할 때만 켜세요.

HTTPS 인증서 오류가 발생하면 먼저 Windows 시간과 시간대, 브라우저 인증서 세부 정보, 패킷 캡처나 필터링 소프트웨어의 동시 실행 여부를 확인하고 HTTPS 인증서 오류 문제 해결을 참고하세요. 프록시 프로토콜 자체 때문에 웹페이지에서 제공하는 인증서를 임의로 설치해야 하는 경우는 일반적이지 않습니다. 특정 브라우저에서만 문제가 발생한다면 해당 브라우저의 프록시 확장 기능과 네트워크 정책을 먼저 정리한 뒤 시스템 전체 문제인지 판단하세요.

03 / MACOS

macOS 설치·설정: 칩 아키텍처, 시스템 확장과 프록시 권한

Apple Silicon 또는 Intel 빌드 선택

macOS 사용자는 Clash Plus를 우선 선택할 수 있으며, Clash Verge Rev와 FlClash도 사용할 수 있습니다. ClashX Meta는 유지 관리가 중단되어 기존 환경의 호환성 참고용으로 주로 사용됩니다. 화면 왼쪽 상단의 Apple 메뉴에서 ‘이 Mac에 관하여’를 열고, 칩 항목에 Apple M 시리즈가 표시되면 Apple Silicon 또는 ARM 빌드를, Intel이 표시되면 x64 빌드를 선택하세요. 터미널에서 uname -m을 실행해도 됩니다. 출력이 arm64이면 Apple 칩, x86_64이면 Intel입니다.

다운로드한 앱은 보통 ‘응용 프로그램’ 디렉터리로 드래그한 뒤 해당 위치에서 실행합니다. 디스크 이미지나 다운로드 폴더에서 계속 실행하면 자동 업데이트, 권한 기록과 데이터 경로가 불안정해질 수 있습니다. 시스템은 네트워크에서 내려받은 앱을 처음 열 때 보안 확인을 수행하므로 Finder에서 앱을 찾아 시스템 안내에 따라 처리하세요. 안내를 우회하려고 시스템 보안 설정을 전체적으로 낮추지 마세요. 잘못된 아키텍처를 내려받은 경우 Apple 칩에서 호환 계층을 통해 x64 버전을 실행할 수 있지만 네트워크 확장, 성능과 보조 구성 요소에 차이가 생길 수 있으므로 일치하는 아키텍처 빌드로 바꾸는 것이 좋습니다.

구독 가져오기 및 메뉴 막대 사용

실행 후 Profiles, 설정 또는 구독 페이지에서 구독 URL을 붙여 넣고 저장한 다음 방금 가져온 설정을 선택하세요. macOS 클라이언트는 메인 창과 메뉴 막대 진입점을 함께 제공하는 경우가 많으며, 시스템 프록시·실행 모드·현재 정책이 메뉴 막대 아이콘 안에 있을 수 있습니다. 가져온 뒤 현재 설정 이름이 실제로 전환되었는지 확인하고 정책 그룹에서 노드를 선택하세요. 메인 창을 닫아도 메뉴 막대 아이콘이 남아 있다면 클라이언트가 백그라운드에서 실행 중인 것입니다. 완전히 종료하려면 창 닫기 버튼이 아니라 메뉴의 종료 명령을 사용하세요.

구독에 여러 정책 그룹이 포함되어 있다면 먼저 ‘노드 선택’ 또는 비슷한 이름의 수동 선택 그룹을 설정한 뒤 자동 선택·장애 조치 그룹이 올바른 노드를 참조하는지 확인하세요. 규칙은 특정 서버가 아니라 정책 그룹 이름을 최종 대상으로 지정하는 경우가 많습니다. 특정 웹사이트의 연결에 문제가 생기면 첫 화면에 표시된 노드만 반복해서 바꾸지 말고 연결 기록에서 적용된 규칙과 정책을 확인하세요.

시스템 프록시 적용 및 복구

시스템 프록시를 켜면 클라이언트가 현재 네트워크 서비스의 웹 프록시 설정을 변경합니다. macOS는 Wi‑Fi, 유선 네트워크와 기타 네트워크 서비스의 설정을 각각 관리하므로 네트워크를 전환한 뒤 새 서비스가 제대로 적용되었는지 확인해야 합니다. ‘시스템 설정 → 네트워크 → 현재 네트워크 → 세부사항 → 프록시’에서 웹 프록시와 보안 웹 프록시 상태를 확인할 수 있습니다. 정상적인 경우 클라이언트가 이 항목을 관리하도록 두고, 자동 입력과 수동 포트 입력을 동시에 사용하지 마세요.

클라이언트가 충돌한 뒤 Safari와 다른 앱이 네트워크에 접속하지 못한다면 먼저 남아 있는 프로세스를 종료한 다음 시스템 네트워크 프록시 페이지에서 더 이상 유효하지 않은 로컬 프록시를 해제하세요. 명령으로 특정 네트워크 서비스를 확인할 수도 있지만 서비스 이름은 언어와 사용자 설정에 따라 달라질 수 있으므로 먼저 이름을 나열한 뒤 조회해야 합니다:

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

터미널의 curl, 패키지 관리자와 개발 도구가 그래픽 시스템 프록시를 일관되게 읽는 것은 아닙니다. 일부 도구는 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY 환경 변수를 읽고, 다른 도구는 독립적인 프록시 설정을 사용합니다. 그래픽 앱은 정상인데 터미널 명령이 직접 연결된다면 먼저 해당 도구의 프록시 동작을 확인하세요. 더 많은 프로세스에 적용해야 할 때 TUN을 검토할 수 있지만, 환경 변수와 TUN을 영구 설정으로 동시에 사용하면서 출처를 기록하지 않는 것은 피해야 합니다.

TUN, 네트워크 확장과 시스템 승인

TUN을 활성화하면 macOS에서 관리자 암호, VPN 구성 승인 또는 네트워크 확장 허가를 요구할 수 있습니다. 시스템 팝업에 따라 한 번 승인하면 되며, 이후 시스템의 VPN 및 네트워크 관련 설정에서 상태를 확인할 수 있습니다. TUN이 켜지면 클라이언트가 가상 인터페이스로 라우팅 트래픽을 받으므로 Docker Desktop, 가상 머신, 기업 VPN, 네트워크 필터와 로컬 개발망에 영향을 줄 수 있습니다. 회사 내부망이나 LAN 서비스에 갑자기 접속할 수 없다면 규칙에서 사설 주소를 직접 연결하도록 유지했는지, TUN 자동 라우팅이 전용 경로를 덮어쓰지 않았는지 확인하세요.

DNS 및 절전 모드 이후 연결 문제

macOS는 시스템 DNS 캐시를 유지하며, 브라우저도 자체 보안 DNS를 사용할 수 있습니다. Clash DNS 설정을 변경한 뒤에도 이전 결과가 사용된다면 먼저 브라우저를 완전히 종료하고 네트워크에 다시 연결하세요. 캐시 문제임을 확인한 경우에만 시스템 캐시를 새로 고치세요. 절전 모드에서 깨어난 뒤 ‘노드 테스트는 되지만 웹페이지가 열리지 않는’ 경우에는 가상 인터페이스가 복구되지 않았거나, 시스템 프록시가 이전 프로세스를 가리키거나, 상위 네트워크의 DNS 주소가 바뀐 것이 원인일 수 있습니다. ‘적용 해제 → 직접 연결 확인 → 클라이언트 재시작 → 다시 적용’ 순서로 처리하면 문제가 발생한 계층을 구분할 수 있습니다.

04 / ANDROID

Android 설치·설정: VPN 승인, 백그라운드 실행과 앱별 분기

클라이언트 설치 및 최초 승인 완료

Android에서는 Clash Plus를 우선 선택할 수 있으며, Clash Meta for Android, FlClash 또는 Surfboard도 사용할 수 있습니다. 설치 패키지를 내려받을 때 기기 아키텍처에 맞는 arm64, arm 또는 범용 빌드를 선택하세요. 최근 주류 기기는 대개 arm64이지만 Android 버전만으로 판단할 수는 없습니다. 기기 정보 앱이나 시스템 하드웨어 정보에서 더 정확한 ABI를 확인할 수 있습니다. 설치에 실패하면 파일이 완전히 다운로드되었는지, 아키텍처가 맞는지, 현재 브라우저나 파일 관리자가 앱 설치를 실행하도록 허용되었는지 먼저 확인하세요.

클라이언트를 처음 실행하고 연결을 켜면 Android에서 VPN 연결 요청이 표시됩니다. 이는 앱 트래픽을 클라이언트로 전달하기 위한 로컬 가상 네트워크 인터페이스의 시스템 승인입니다. 승인 후 상태 표시줄에 VPN 아이콘이 나타나는 경우가 많습니다. Android는 일반적으로 한 번에 하나의 일반 VPN 연결만 허용하므로 기업 VPN, 다른 프록시 클라이언트 또는 시스템의 상시 연결 VPN과 Clash가 충돌할 수 있습니다. 연결을 만들 수 없다면 시작 버튼을 계속 누르기보다 시스템 VPN 설정에서 현재 연결을 점유한 앱을 먼저 확인하세요.

URL·파일·QR 코드로 구독 가져오기

설정 페이지에서 구독 URL을 붙여 넣거나 로컬 설정 파일을 선택하고, QR 코드 메뉴를 통해 가져올 수도 있습니다. QR 코드에 전체 구독 주소가 포함될 수 있으므로 가져온 뒤에도 설정 정보를 보호해야 합니다. 원격 구독을 성공적으로 가져왔다면 설정을 선택하고 코어가 로드될 때까지 기다리세요. YAML 파싱 오류가 표시된다면 휴대폰 네트워크 권한보다 원격 서버가 로그인 페이지·오류 페이지 또는 호환되지 않는 내용을 반환한 경우가 많습니다. 브라우저에서 구독 주소를 열어 실제로 설정 데이터가 응답되는지 확인하세요.

모바일 네트워크와 Wi‑Fi는 서로 다른 IPv6, DNS와 접근 정책을 사용할 수 있습니다. 한 네트워크에서만 업데이트가 실패한다면 클라이언트가 손상되었다고 단정하지 말고 구독 주소와 노드 연결을 각각 테스트하세요. 일부 구독은 정기 업데이트가 필요하므로 설정 페이지에서 명확한 수동 업데이트를 실행하고 업데이트 시간과 오류 메시지를 확인하는 것이 좋습니다. 업데이트 후 노드 이름이 바뀌면 이전에 수동으로 선택한 정책이 기본값으로 돌아갈 수 있으니 정책 그룹을 다시 확인하세요.

규칙 모드·글로벌 모드와 앱별 분기

Android에서도 처음 연결할 때는 규칙 모드를 권장합니다. 노드를 선택한 뒤 VPN을 시작하고 브라우저로 외부 IP를 확인하세요. 글로벌 모드는 특정 규칙 때문에 직접 연결되는지 잠시 확인할 때 사용하고, 테스트가 끝나면 규칙 모드로 돌아갑니다. 앱별 분기를 사용하면 프록시를 통과할 앱과 우회할 앱을 지정할 수 있지만, 클라이언트에 따라 ‘선택한 앱만 프록시’와 ‘선택한 앱 제외’처럼 서로 반대되는 의미를 사용할 수 있습니다. 저장하기 전에 현재 모드를 반드시 확인해 프록시가 필요한 앱을 실수로 우회 목록에 넣지 않도록 하세요.

앱별 분기는 트래픽이 클라이언트로 들어갈지만 결정하며, 들어온 뒤에는 도메인·IP·정책 규칙을 계속 매칭합니다. 한 앱이 공용 API, LAN 기기와 푸시 서비스를 동시에 사용한다면 앱 전체를 단순히 프록시 처리해 로그인 문제가 생길 수 있습니다. 더 안정적인 방법은 먼저 앱을 규칙 모드로 통과시킨 뒤 연결 로그를 바탕으로 특정 도메인 규칙을 추가하는 것입니다. 은행·결제·LAN 제어·통신사 서비스는 로컬 네트워크 환경에 더 의존하는 경우가 많으므로 실제 사용 목적에 따라 직접 연결 규칙을 결정하세요.

백그라운드 제한 및 시스템에 의한 연결 회수

Android 제조사는 백그라운드 앱에 배터리 제한을 적용하는 경우가 많습니다. 화면을 잠근 뒤 몇 분 후 VPN 아이콘이 사라지거나 알림이 지워지고 연결을 다시 시작해야 한다면 클라이언트의 배터리 최적화, 백그라운드 활동, 자동 시작과 알림 권한을 확인하세요. 앱을 ‘제한 없음’으로 설정하면 백그라운드 유지 가능성이 높아지지만 배터리 사용량도 늘 수 있으므로 기기에서 제공하는 항목을 필요한 만큼만 조정하세요. 상시 알림은 포그라운드 서비스 상태의 일부이므로 알림 권한을 끄면 시스템의 서비스 관리에 영향을 줄 수 있습니다.

Wi‑Fi에서 모바일 네트워크로 전환하면 기존 연결의 출발지 주소와 라우팅이 바뀝니다. 클라이언트가 보통 연결을 자동으로 재구성하지만 일부 장기 연결은 앱이 다시 요청해야 합니다. 네트워크 전환 후 특정 앱만 멈추면 해당 앱을 강제 종료한 뒤 다시 열어 보세요. 모든 트래픽이 실패할 때만 클라이언트 연결을 재시작합니다. 자동 연결 끊김이 반복되면 절전 모드, 데이터 절약 모드 또는 제조사의 절전 앱 목록도 확인하세요.

비공개 DNS, IPv6 및 핫스팟 공유

Android의 비공개 DNS는 암호화된 조회를 사용하므로 클라이언트의 DNS 가로채기나 fake-ip 방식과 두 개의 조회 경로를 만들 수 있습니다. 도메인 조회가 실패하거나 브라우저는 되는데 다른 앱이 되지 않는다면 비공개 DNS를 잠시 자동으로 바꾸어 비교 테스트하세요. 충돌이 확인되면 시스템 비공개 DNS를 유지할지 Clash가 조회를 통합 처리할지 결정합니다. IPv6도 노드·통신사·설정의 지원 여부에 따라 활성화해야 하며, 무조건 끄는 것은 장기적인 해결책이 아닙니다. 로그를 통해 실패한 요청이 IPv4와 IPv6 중 어느 쪽을 사용했는지 확인하세요.

휴대폰 핫스팟을 공유해도 하위 기기의 트래픽이 Android 본체의 VPN으로 자동 전달된다고 보장할 수 없습니다. 핫스팟 트래픽을 처리할 수 있는지는 시스템 구현, 클라이언트 기능과 기기 권한에 따라 달라집니다. 다른 기기에 프록시를 제공해야 한다면 클라이언트에서 LAN 연결을 허용하고 하위 기기에 휴대폰의 LAN 주소와 프록시 포트를 직접 입력하는 방식이 더 명확합니다. 신뢰할 수 있는 네트워크에서만 사용하세요. 공유할 필요가 없다면 LAN 수신을 끄고 불필요한 노출 범위를 줄이세요.

05 / IOS

iOS 설치·설정: App Store, VPN 구성과 주문형 연결

App Store에서 설치하고 시스템 권한 확인하기

iPhone과 iPad에서는 App Store를 통해 Clash Plus를 받을 수 있습니다. 설치 후 처음 연결을 만들 때 iOS가 VPN 구성 추가를 요청하며, 기기 암호·생체 인증 또는 시스템 확인으로 승인을 완료합니다. 승인되어야 클라이언트가 로컬 네트워크 터널을 만들고 트래픽을 처리할 수 있습니다. 이 권한은 시스템에서 통합 관리하며 ‘설정 → 일반 → VPN 및 기기 관리’ 또는 해당 버전의 VPN 설정에서 확인할 수 있습니다. 학교나 회사에서 관리하는 기기라면 정책상 VPN 구성 추가가 제한될 수 있으므로 먼저 기기 정책을 확인하세요.

iOS에서는 한 번에 하나의 주요 VPN 구성만 활성 상태가 될 수 있습니다. 다른 VPN, 기업 보안 클라이언트, 콘텐츠 필터 또는 비공개 릴레이 기능이 실제 경로를 바꿀 수 있습니다. 연결을 누르자마자 끊긴다면 먼저 시스템 VPN 페이지에서 충돌하는 구성이 있는지 확인한 뒤 클라이언트의 오류 정보를 확인하세요. 모든 시스템 네트워크 설정 삭제는 Wi‑Fi와 다른 구성에도 영향을 주므로 첫 번째 문제 해결 방법으로 사용하지 마세요.

구독 가져오기 및 현재 설정 선택

클라이언트에서 설정 또는 구독 메뉴를 열고 서비스 제공자가 준 URL을 붙여 넣거나 QR 코드를 스캔하세요. 채팅 앱에서 링크를 복사했다면 줄바꿈, 앞뒤 공백 또는 잘린 쿼리 매개변수가 없는지 확인합니다. 가져온 뒤 해당 설정을 선택하고 정책 페이지에서 노드를 선택하세요. 일부 클라이언트는 가져오기가 끝나면 자동으로 로드하지만, 수동 정책 그룹까지 자동으로 정해 주지는 않습니다. 처음 연결하기 전에 주 노드 그룹과 최종 기본 정책을 최소한 확인하세요.

‘파일’ 앱에서 YAML을 가져올 때 파일이 iCloud Drive 또는 로컬 저장소에 있을 수 있습니다. 클라우드 다운로드가 끝나지 않았다면 클라이언트가 읽지 못할 수 있으므로 먼저 ‘파일’ 앱에서 열리는지 확인한 뒤 공유 또는 가져오기를 실행하세요. 원격 구독과 로컬 파일은 업데이트 방식이 다릅니다. 원격 구독은 원본 서버에 다시 요청할 수 있지만 로컬 파일은 수정한 버전을 다시 가져와야 합니다. 구독에서 생성된 노드 필드를 직접 편집하지 마세요. 다음 업데이트에서 대부분 변경 사항이 덮어써집니다.

연결·규칙 모드와 주문형 시작

설정과 노드를 선택한 뒤 연결을 켜면 상태 표시줄이나 제어 센터에 VPN 상태가 표시됩니다. 먼저 Safari로 자주 사용하는 사이트에 접속한 다음 다른 앱을 확인하세요. 규칙 모드는 설정의 규칙에 따라 직접 연결 또는 프록시를 결정합니다. 글로벌 모드는 규칙 문제를 잠시 확인할 때 사용할 수 있고, 직접 연결 모드는 프록시를 끈 기본 네트워크를 확인할 때 사용합니다. Safari는 정상인데 특정 앱만 실패한다면 서버만 바꾸지 말고 해당 앱의 도메인이 거부·직접 연결 또는 부적절한 정책 그룹에 매칭되었는지 확인하세요.

주문형 연결은 네트워크 변화에 따라 VPN을 자동으로 시작할 수 있지만 조건이 너무 넓으면 모든 Wi‑Fi와 모바일 네트워크에서 계속 연결되고, 너무 좁으면 네트워크 전환 후 실행되지 않을 수 있습니다. 처음 설치할 때는 수동 연결로 구독·노드·DNS가 정상인지 확인한 뒤 주문형 규칙을 설정하세요. 신뢰할 수 있는 가정용 네트워크에서 비활성화하려면 네트워크 식별자로 예외를 구성하고, 라우터 이름을 바꾼 뒤에도 조건이 여전히 일치하는지 정기적으로 확인하세요.

iOS의 네트워크 변화와 백그라운드 동작

iOS는 배터리, 네트워크 상태와 시스템 스케줄에 따라 백그라운드 활동을 관리하지만, 이미 만들어진 VPN 터널은 시스템 네트워크 확장이 유지합니다. 일반 앱이 계속 전면에 떠 있어야 하는 것과는 다릅니다. 화면을 잠근 뒤 연결이 자주 끊긴다면 클라이언트 로그의 중지 원인, 저전력 모드와 네트워크 전환 상황을 확인하세요. 모바일 네트워크와 Wi‑Fi 사이를 전환하면 기존 TCP 연결이 끊길 수 있는데, 이는 출발지 주소가 바뀌어 발생하는 정상적인 현상입니다. 영향을 받은 앱을 다시 열면 새 연결이 만들어지는 경우가 많습니다.

일부 Wi‑Fi는 먼저 웹 인증을 완료해야 합니다. 이런 네트워크에 연결할 때 VPN이 이미 자동으로 시작되면 인증 페이지가 나타나지 않을 수 있습니다. 클라이언트를 잠시 끄고 암호화되지 않은 웹페이지를 열어 인증을 유도한 뒤 다시 연결하세요. 호텔·공항·공용 네트워크는 특정 프로토콜을 제한할 수 있습니다. 모바일 네트워크에서는 노드가 정상인데 공용 Wi‑Fi에서 모두 실패한다면 설정을 반복해서 삭제하기보다 네트워크 제한 여부를 먼저 판단하세요.

DNS, LAN 및 푸시 서비스

iOS 앱은 LAN 기기, 시스템 푸시 서비스와 지역별 API에 접근할 수 있습니다. 규칙 설정에서는 사설 주소와 로컬 도메인을 직접 연결하도록 남겨 가정용 스토리지·프린터·스마트 기기가 원격 프록시로 전송되어 연결이 끊기지 않게 하세요. LAN에 처음 접근할 때 시스템이 로컬 네트워크 권한을 물을 수 있습니다. 거부해도 클라이언트 자체는 인터넷에 연결될 수 있지만 LAN 검색과 공유 기능은 제한됩니다. 시스템 개인정보 보호 설정에서 권한을 다시 확인할 수 있습니다.

알림이 늦지만 웹 접속은 정상이라면 푸시 관련 연결에 적용된 정책, 노드 안정성과 시스템 알림 설정을 확인하세요. 푸시 문제만으로 글로벌 모드로 바꾸지는 마세요. 글로벌 모드는 더 많은 앱의 외부 연결 경로를 바꿉니다. DNS 문제는 Safari, 앱 내부와 다른 네트워크에서 같은 도메인이 어떻게 동작하는지 비교해야 합니다. DNS 외부 경로와 fake-ip 판단 방법은 Clash DNS 누출 감지 및 해결에서 계속 확인할 수 있습니다.

06 / LINUX

Linux 설치·설정: 데스크톱 클라이언트, 코어 서비스와 권한

데스크톱 클라이언트와 독립 코어 선택

Linux 데스크톱 사용자는 Linux 다운로드 영역에서 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 구독 관리, 정책 전환과 로그 화면을 제공하므로 일상적인 데스크톱 환경에 적합합니다. 서버·소프트 라우터·GUI가 없는 기기에서는 Mihomo 코어를 직접 실행할 수 있지만 설정 파일, 시작 매개변수, 권한과 서비스 수명 주기를 직접 관리해야 합니다. 두 방식을 동시에 같은 포트에서 수신하도록 설정하지 마세요. 시작 실패가 발생하거나 트래픽이 잘못된 프로세스로 들어갈 수 있습니다.

설치 패키지는 배포판에 맞아야 합니다. Debian·Ubuntu 및 파생 시스템은 보통 deb를 사용하고, RPM 패키지 관리자를 사용하는 배포판은 rpm을 사용합니다. 독립 압축 패키지는 실행 파일을 직접 배치하고 의존성을 관리해야 합니다. 프로세서 아키텍처는 uname -m으로 확인할 수 있으며, x86_64는 AMD64, aarch64는 ARM64에 해당합니다. 라우터 기기는 ARMv7이나 MIPS 변형을 사용할 수도 있습니다. 잘못 선택하면 ‘바이너리 파일을 실행할 수 없음’이라는 오류가 흔히 표시됩니다.

데스크톱 환경의 시스템 프록시

GNOME, KDE와 기타 데스크톱 환경은 시스템 프록시를 저장하는 방식이 서로 다르므로 클라이언트의 ‘시스템 프록시’ 스위치가 모든 환경에 적용된다고 보장할 수 없습니다. 활성화한 뒤 데스크톱 네트워크 설정에서 HTTP·HTTPS·SOCKS 프록시가 클라이언트의 수신 포트를 가리키는지 확인하세요. 브라우저는 데스크톱 프록시를 읽을 수도 있고 자체 설정을 사용할 수도 있습니다. 터미널 프로그램은 환경 변수에 의존하는 경우가 많습니다. 그래픽 앱은 정상인데 명령줄이 실패한다고 해서 노드가 고장 난 것은 아니므로 해당 프로그램이 어떤 프록시 설정을 읽는지 먼저 확인하세요.

# 현재 터미널 세션에만 적용되며, 포트는 클라이언트의 실제 수신 포트와 일치해야 합니다
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891

# 테스트가 끝나면 복원
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

변수 이름에 대소문자 형식이 함께 존재하면 도구마다 읽는 순서가 다를 수 있습니다. 임시 테스트 변수를 모든 셸 시작 파일에 바로 기록하지 마세요. 클라이언트를 종료한 뒤에도 패키지 관리자와 개발 도구가 사용 중지된 포트를 가리킬 수 있습니다. 장기간 설정해야 한다면 활성화와 비활성화를 위한 별도 스크립트를 만들고 포트의 출처를 명확히 기록하세요.

Mihomo를 서비스로 실행하기

독립 코어는 일반적으로 -d로 설정 디렉터리를 지정하고 -f로 설정 파일을 지정합니다. 처음 실행하기 전에 파일 권한과 작업 디렉터리를 확인하세요. 특히 systemd로 시작하면 서비스 사용자의 홈 디렉터리, 상대 경로와 대화형 터미널이 달라집니다. 설정과 실행 데이터를 전용 디렉터리에 보관하고 서비스 사용자에게 필요한 읽기·쓰기 권한만 부여하는 것이 좋습니다. 모든 기능을 최고 권한으로 장기간 실행하지 마세요. TUN 생성이나 라우팅 작성처럼 실제로 추가 권한이 필요한 작업에만 권한을 부여하세요.

# 전면 실행으로 테스트하고 로그에 파싱 오류가 없는지 확인한 뒤 서비스 관리자를 사용합니다
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml

# 수신 포트 확인
ss -lntup | grep -E '7890|7891|9090'

systemd 서비스에는 명확한 시작 명령, 재시작 정책과 작업 디렉터리를 설정해야 합니다. 설정을 업데이트한 뒤 먼저 전면 실행이나 독립 명령으로 검증하고 서비스를 재시작하세요. 잘못된 설정으로 반복 종료되는 것을 막을 수 있습니다. 로그는 서비스 관리자로 확인하거나 클라이언트 설정에 따라 파일로 기록할 수 있습니다. 제어 인터페이스를 LAN에서 수신해야 한다면 접근 제어를 설정하고 방화벽에서 출처를 제한하세요. 본체에서만 관리한다면 루프백 주소에서 수신하는 편이 안전합니다.

TUN, 라우팅 및 DNS 권한

Linux TUN을 사용하려면 시스템에 /dev/net/tun이 존재해야 하며, 프로세스에 인터페이스 생성과 라우팅 수정 권한이 있어야 합니다. 컨테이너·제한된 VPS·일부 NAS 환경에서는 해당 장치가 매핑되지 않아 관리자 계정으로도 생성할 수 없습니다. 자동 라우팅을 활성화한 뒤에는 기본 경로, 정책 라우팅 테이블과 방화벽 규칙을 먼저 확인해 로컬 네트워크, 원격 관리 진입점과 프록시 서버 자체의 트래픽이 다시 TUN으로 들어가 순환하지 않게 하세요.

DNS 가로채기는 방화벽 또는 라우팅 기능에 의존하며, 시스템에 따라 nftables, iptables, systemd-resolved 또는 NetworkManager를 사용할 수 있습니다. 여러 구성 요소가 /etc/resolv.conf를 반복해서 덮어쓰도록 두지 마세요. systemd-resolved를 사용한다면 해당 인터페이스를 통해 실제 상위 DNS를 확인하고, NetworkManager가 관리한다면 연결 설정에서 조정해야 합니다. 변경 전에 현재 DNS 상태를 기록하고 클라이언트를 종료한 뒤 시스템 조회가 복구되는지 확인하세요.

Linux에서 흔한 시작 및 권한 문제

그래픽 클라이언트가 시작되지 않으면 터미널에서 실행해 누락된 라이브러리, 디스플레이 서비스 또는 샌드박스 메시지를 확인할 수 있습니다. Wayland와 X11에서는 트레이 지원이 다를 수 있으므로 창을 닫은 뒤에도 프로세스가 백그라운드에 남아 있는지 확인하세요. 코어에서 포트가 사용 중이라고 표시되면 ss 또는 lsof로 점유한 프로세스를 찾으세요. 모든 포트를 무작정 바꾸면 브라우저, 환경 변수와 LAN 기기가 여전히 이전 값을 참조할 수 있습니다. 설정 디렉터리가 읽기 전용이라면 전체 디렉터리를 모든 사용자에게 쓰기 허용하지 말고 소유자와 권한을 바로잡으세요.

07 / CONFIGURATION

공통 설정 및 규칙 기반 분기: 포트, DNS, 정책 그룹과 TUN

설정 파일의 실행 순서 이해하기

Clash 설정은 일반적으로 기본 수신 설정, 프록시 노드, 프록시 그룹, 규칙 제공자, 규칙, DNS와 TUN 등의 부분으로 구성됩니다. 노드 정의는 연결 매개변수를 지정하고, 정책 그룹은 노드나 다른 정책 중 선택할 대상을 정하며, 규칙은 요청을 특정 정책 그룹으로 보냅니다. 문제를 확인할 때는 ‘도메인 조회 → 규칙 매칭 → 정책 그룹 선택 → 노드 연결’ 순서로 판단하세요. 노드 지연 시간이 정상이라는 사실만으로 DNS와 규칙 경로가 올바르다고 할 수 없습니다. 반대로 규칙이 프록시에 매칭되었다고 해서 대상 노드의 연결 가능성이 보장되는 것도 아닙니다.

YAML은 들여쓰기로 계층을 표현하므로 공백만 사용하고 같은 수준의 들여쓰기를 일관되게 유지해야 합니다. 콜론 뒤에는 공백이 필요하며 특수 문자가 포함된 텍스트는 따옴표를 사용할 수 있습니다. 노드 비밀번호, 구독 매개변수와 제어 인터페이스 키는 민감한 정보이므로 로그나 설정 일부를 공유하기 전에 삭제하세요. 구독 파일을 원본 서버가 관리한다면 본문을 직접 수정해도 업데이트 후 사라질 수 있습니다. 클라이언트가 제공하는 오버라이드, 확장 스크립트 또는 로컬 규칙 병합 기능을 우선 사용하세요.

수신 포트 및 LAN 접근

mixed-port는 하나의 포트에서 HTTP와 SOCKS 요청을 함께 받아 일반적인 데스크톱 사용에 적합합니다. port와 socks-port를 각각 설정하면 프로토콜별 관리가 편리합니다. allow-lan은 LAN 기기가 수신 포트에 연결할 수 있는지 제어하며, 끄면 보통 본체에서만 사용할 수 있습니다. 공유가 필요하다면 bind-address, 시스템 방화벽과 라우터 격리 설정도 확인해야 합니다. LAN 프록시는 자동 검색 기능을 제공하지 않으므로 하위 기기에 Clash를 실행하는 기기의 LAN 주소와 포트를 직접 입력해야 합니다.

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

external-controller: 127.0.0.1:9090

외부 제어 인터페이스는 그래픽 UI나 관리 도구가 상태를 읽기 위한 것으로 일반 프록시 포트가 아닙니다. 본체에서만 관리한다면 루프백 주소에서 수신하세요. 원격 관리가 꼭 필요하다면 접근 제어를 설정하고 방화벽에서 출처를 제한해 신뢰할 수 없는 네트워크에 제어 기능을 직접 노출하지 않도록 해야 합니다. 포트를 변경하면 시스템 프록시, 브라우저 확장, 터미널 환경 변수와 LAN 기기도 함께 업데이트해야 합니다.

규칙 모드 및 매칭 우선순위

규칙은 일반적으로 위에서 아래로 매칭되며, 처음 일치한 규칙이 정책을 결정하고 마지막에는 앞에서 처리하지 못한 요청을 기본 규칙으로 처리합니다. 도메인 규칙은 안정적인 사이트 범위에 적합하고, IP 규칙은 조회 결과에 의존하며, 프로세스 규칙은 플랫폼과 권한의 제약을 받습니다. 지나치게 넓은 규칙을 앞에 두면 뒤의 더 정확한 규칙이 가려집니다. 예를 들어 전체 최상위 도메인 규칙을 먼저 작성한 뒤 특정 하위 도메인을 직접 연결하도록 해도 뒤의 규칙은 매칭되지 않을 수 있습니다.

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - DOMAIN,printer.lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,FINAL

위 예시의 PROXY와 FINAL은 실제로 존재하는 정책 그룹 이름과 일치해야 합니다. no-resolve는 IP 대역을 매칭할 때 이 규칙을 위해 별도의 도메인 조회를 실행하지 않는다는 뜻으로, 사설 주소 규칙에 적합합니다. 실제 설정에는 루프백, 링크 로컬과 직접 연결해야 하는 다른 네트워크도 포함해야 합니다. 도메인·IP·프로세스 규칙의 작성법과 배열 순서를 체계적으로 이해하려면 Clash 사용자 지정 규칙 문법과 우선순위를 참고하세요.

정책 그룹 선택 로직

수동 선택 그룹은 사용자가 노드를 지정할 수 있고, 자동 테스트 그룹은 탐색 결과에 따라 선택하며, 장애 조치 그룹은 현재 항목을 사용할 수 없을 때 순서대로 전환합니다. 부하 분산 그룹은 설정한 정책에 따라 연결을 배분합니다. 자동 테스트 결과는 지정된 테스트 URL과 테스트 시점만 반영하며 모든 웹사이트의 실제 사용 경험과 같지 않습니다. 잦은 탐색은 모바일 기기의 배터리와 네트워크 요청을 늘리므로 사용 환경에 맞게 테스트 간격을 정하세요.

정책 그룹은 다른 정책 그룹을 참조할 수 있어 ‘지역 선택 → 자동 선택 → 특정 노드’와 같은 계층을 구성합니다. 가장 바깥쪽 정책을 바꾸어도 실제 외부 연결은 내부 단계의 결과에 따라 결정됩니다. 잘못된 외부 연결을 확인할 때는 현재 선택을 단계별로 펼쳐 연결 기록에서 최종적으로 어떤 노드를 사용했는지 확인하세요. 정책 그룹 이름을 바꾸면 규칙 참조에 영향을 주므로 구독 업데이트 후 정책을 찾을 수 없다는 로그가 나타나면 원본에서 그룹 이름을 변경했는지 확인하세요.

DNS의 fake-ip 및 redir-host

fake-ip 모드는 도메인에 예약 주소를 반환하고 코어 내부에서 도메인 매핑을 유지해 이후 연결 단계에서도 도메인 정보를 보존하며, 규칙 매칭을 더 완전하게 처리하는 데 도움이 됩니다. 일부 LAN 기기·게임·시간 동기화·실제 IP에 의존하는 프로그램은 fake-ip에 적합하지 않을 수 있으므로 필터 목록을 통해 해당 도메인은 실제 주소를 반환하게 해야 합니다. redir-host는 전통적인 조회 경로에 더 가깝지만 일부 트래픽 적용 환경에서는 도메인 맥락을 잃을 수 있습니다. 어느 방식을 선택할지는 앱 호환성과 로그를 기준으로 판단하고, 한쪽이 항상 더 빠르다고 보지는 마세요.

dns:
  enable: true
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

예시에 사용한 공용 DNS 주소는 구조를 설명하기 위한 것일 뿐입니다. 실제로는 현재 네트워크, 개인정보 보호 요구와 접근 가능성을 기준으로 선택하세요. 암호화 DNS를 사용할 때는 해당 DNS 서버의 도메인을 조회할 부트스트랩 DNS도 정상이어야 하며, 그렇지 않으면 순환 의존이 발생합니다. 브라우저 자체의 보안 DNS는 시스템 조회 경로를 우회할 수 있으므로 DNS 외부 경로를 점검할 때 브라우저 설정, 시스템 조회와 클라이언트 로그를 각각 확인하세요.

TUN 설정의 핵심 항목

TUN의 핵심은 가상 인터페이스, 자동 라우팅과 DNS 적용입니다. 코어 버전과 클라이언트에 따라 지원하는 필드가 다를 수 있으므로 현재 클라이언트가 생성하거나 문서에서 지원하는 설정을 기준으로 하세요. auto-route를 활성화하면 코어가 라우팅을 작성하고, strict-route는 라우팅 제약을 강화하지만 LAN·가상 머신·다중 네트워크 카드 환경에 영향을 주기 쉽습니다. 모바일 클라이언트는 보통 UI에서 이러한 매개변수를 관리하므로 병합 규칙을 모르는 상태에서 화면 스위치와 하위 YAML을 동시에 수정하지 마세요.

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false
  dns-hijack:
    - any:53

활성화하기 전에 시스템 프록시 경로가 정상인지 확인하고 TUN은 별도로 테스트하세요. 켠 뒤 네트워크가 끊기면 즉시 TUN을 끄고 직접 연결을 확인한 다음 권한, 기본 경로, DNS 가로채기와 다른 VPN을 점검합니다. 가상 네트워크 어댑터의 적용 범위와 플랫폼별 권한 차이는 Clash TUN 모드와 전체 트래픽 적용에서 확인할 수 있습니다.

08 / TROUBLESHOOTING

일반적인 설정 문제: 구독·노드·DNS·라우팅을 경로별로 확인하기

계층별 문제 해결 순서 세우기

Clash 문제는 외부에서 내부로 계층을 나누어 처리해야 합니다. 첫 번째 계층은 기본 네트워크입니다. 시스템 프록시와 TUN을 끈 상태에서 기기가 로컬 네트워크와 구독 진입점에 정상적으로 접속하는지 확인합니다. 두 번째는 클라이언트 상태로, 설정이 성공적으로 로드되었는지, 코어가 실행 중인지, 포트가 수신 중인지 확인합니다. 세 번째는 노드 연결로, 대상 주소에 연결할 수 있는지와 인증·프로토콜 매개변수가 유효한지 확인합니다. 네 번째는 규칙과 정책으로, 요청이 어느 규칙에 매칭되고 어떤 정책 그룹에 들어가며 최종적으로 어느 노드를 선택했는지 확인합니다. 다섯 번째는 DNS와 시스템 라우팅으로, 도메인 조회가 예상한 경로를 사용하는지와 가상 인터페이스 및 기본 경로가 충돌하지 않는지 확인합니다.

한 번에 하나의 변수만 바꾸고 결과를 기록하세요. 노드·모드·DNS·TUN을 반복해서 전환하면 여러 계층의 상태가 동시에 바뀌어 연결이 복구되어도 실제 원인을 판단하기 어렵습니다. 다음 세 가지 결과를 비교해 두는 것이 좋습니다. 적용을 끈 직접 연결 상태, 규칙 모드와 시스템 프록시 상태, 규칙 모드와 TUN 상태입니다. 이 세 결과로 문제가 기본 네트워크, 앱 프록시 또는 라우팅 적용 중 어디에 있는지 빠르게 판단할 수 있습니다.

구독 가져오기 실패 또는 가져온 뒤 노드가 없음

구독 가져오기에 실패하면 브라우저에서 구독 진입점을 열어 로그인 페이지·오류 페이지·인증 코드 페이지로 이동하지 않는지 확인하세요. 주소가 완전한지, 만료되지 않았는지, 채팅 앱에서 잘리지 않았는지와 기기 시간이 정확한지도 확인합니다. 클라이언트 로그에 HTTP 상태 오류가 나타나면 먼저 구독 서비스 접근 문제를 처리해야 합니다. YAML 파싱 오류라면 반환된 내용이 실제로 호환되는 설정인지 확인하세요. 웹페이지 HTML을 저장한 뒤 YAML로 이름만 바꾸어도 형식이 변환되지는 않습니다.

가져오기는 성공했지만 노드가 없다면 설정에 규칙만 포함되어 있거나, provider가 노드를 늦게 로드하거나, 원본 서버가 빈 내용을 반환했을 수 있습니다. 설정의 proxies, proxy-providers와 클라이언트 로그를 확인해 provider 주소에 접근할 수 있는지 확인하세요. 노드는 있는데 정책 그룹이 비어 있다면 정책 그룹의 필터 표현식이 모든 노드를 제외했는지, 참조 이름이 provider와 일치하는지 확인합니다. 원격 설정 업데이트 후 발생했다면 마지막으로 정상 작동한 설정과 정책 그룹 구조를 비교하세요.

노드 테스트는 실패하지만 웹페이지가 간헐적으로 열림

지연 시간 테스트는 보통 미리 정해진 URL에 접속하며 테스트 주소, DNS, 노드 외부 연결과 대상 사이트의 제한에 영향을 받습니다. 테스트 실패가 모든 연결 실패를 뜻하는 것은 아니며, 테스트 성공도 실제 서비스 이용 가능성을 보장하지 않습니다. 노드를 선택한 뒤 실제 대상에 접속하고 연결 로그에서 상태를 확인하세요. 모든 노드가 동시에 실패한다면 구독 매개변수, 기본 네트워크, 시스템 시간 또는 클라이언트 코어 문제일 가능성이 더 큽니다. 일부 노드만 실패할 때는 개별 노드 상태를 검토하세요.

같은 노드가 모바일 네트워크에서는 되지만 Wi‑Fi에서는 되지 않는다면 네트워크 경로나 DNS가 다를 가능성이 있습니다. 대상 서버 주소의 조회 결과, IPv4·IPv6 접근 가능성과 공용 네트워크의 프로토콜 제한을 비교해 보세요. 노드 테스트를 짧은 간격으로 계속 실행해 연결을 복구하려 하지 마세요. 동시 요청이 늘고 상위 서비스의 제한을 받을 수 있습니다.

시스템 프록시를 켠 뒤 네트워크가 완전히 끊김

먼저 클라이언트 코어가 실행 중이며 시스템 프록시에 입력된 포트에서 수신 중인지 확인하세요. 클라이언트가 종료되었는데 시스템에 수동 프록시가 남아 있으면 시스템 프록시를 따르는 모든 앱이 존재하지 않는 로컬 서비스에 연결하려 합니다. 이때 시스템 프록시를 끄거나 시스템 설정에서 수동 주소를 삭제하면 복구할 수 있습니다. 포트가 정상적으로 수신 중이라면 직접 연결 모드로 전환해 테스트하세요. 직접 연결은 되지만 규칙 모드가 안 되면 규칙과 정책을 중점적으로 확인하고, 직접 연결도 안 되면 포트 유형·인증 설정과 로컬 방화벽을 점검하세요.

브라우저는 되지만 명령줄이 되지 않는다면 명령줄 도구가 시스템 프록시나 환경 변수를 읽는지 확인하세요. 특정 앱만 되지 않을 때는 해당 앱이 프록시를 우회하는지, QUIC를 사용하는지, DNS를 고정했는지 또는 TUN이 필요한지 확인합니다. 하나의 앱이 시스템 프록시를 따르지 않는다고 전체 클라이언트가 고장 났다고 판단하지 마세요.

TUN을 켠 뒤 LAN 또는 전체 네트워크가 작동하지 않음

즉시 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음 가상 인터페이스가 시스템에서 삭제되었는지와 기본 경로가 복원되었는지 확인하세요. LAN이 작동하지 않으면 사설 주소 직접 연결 규칙, 자동 라우팅 제외 항목과 다중 네트워크 카드 우선순위를 점검합니다. 전체 네트워크가 끊겼다면 관리자 권한, TUN 장치, DNS 가로채기와 다른 VPN의 충돌을 중점적으로 확인하세요. Linux는 방화벽과 정책 라우팅도 확인해야 하고, Windows는 서비스 모드와 가상 어댑터를, macOS와 모바일 기기는 시스템 VPN 구성을 확인해야 합니다.

원격 서버에서 발생한 TUN 문제는 잘못된 라우팅으로 관리 연결까지 끊길 수 있어 더 위험합니다. 관리 출처의 직접 연결을 미리 남겨 두고 콘솔이나 예비 세션을 통해 복구하세요. 컨테이너에서 실행한다면 호스트가 TUN 장치를 매핑했는지와 필요한 네트워크 권한을 부여했는지도 확인해야 합니다. 이러한 조건이 없다면 TUN을 억지로 켜지 말고 명시적인 프록시 포트를 사용하세요.

도메인 조회 오류·비정상적인 DNS 외부 경로 또는 fake-ip 충돌

먼저 같은 도메인을 브라우저, 시스템 조회 도구와 클라이언트 로그에서 비교하세요. 브라우저 결과만 다르면 브라우저 보안 DNS를 확인하고, 시스템 조회는 정상인데 앱이 실패하면 앱 캐시와 독립적인 조회 설정을 점검하세요. 모든 조회가 실패한다면 Clash DNS가 활성화되었는지, 상위 DNS에 접근할 수 있는지와 부트스트랩 DNS가 순환을 이루지 않는지 확인합니다. 시스템 조회 결과에 fake-ip 주소가 나타난다고 반드시 오류는 아닙니다. 강화 모드의 정상적인 동작일 수 있으며, 핵심은 이후 연결이 코어에서 원래 도메인으로 올바르게 복원되는지입니다.

LAN 도메인, 프린터, 화면 공유와 일부 게임이 fake-ip과 호환되지 않는다면 명확한 도메인만 필터 목록에 추가하고 사설 주소는 직접 연결로 유지하세요. 모든 도메인을 필터에 넣으면 fake-ip의 주요 이점을 잃게 됩니다. 변경 후에는 앱이 다시 조회하도록 해야 하며, 필요하면 영향을 받은 앱을 재시작하세요. 웹페이지만 새로 고치는 것으로는 충분하지 않을 수 있습니다.

HTTPS 인증서 오류와 시스템 시간

여러 웹사이트에서 동시에 인증서가 아직 유효하지 않거나 만료되었거나 발급자가 이상하다고 표시되면 먼저 시스템 날짜·시간대와 자동 시간 설정을 확인하세요. 특정 브라우저에서만 이상하다면 브라우저 확장 기능, 독립 프록시와 인증서 캐시를 점검합니다. 특정 네트워크 필터 소프트웨어를 켠 뒤에만 문제가 생긴다면 중간 처리 구성 요소를 단계별로 끄며 어느 계층에서 연결이 바뀌었는지 확인하세요. 공용 Wi‑Fi의 인증 페이지도 놓치지 마세요. 요청이 인증 진입점으로 리디렉션되어 인증서 도메인이 일치하지 않을 수 있습니다.

인증서 세부 정보의 대상 도메인, 발급자와 유효 기간을 확인하면 시간 오류·네트워크 인증·중간 계층 개입을 구분하는 데 도움이 됩니다. 전체 확인 절차는 프록시 경로·시스템 시간·인증서 신뢰 문제 해결을 참고하세요.

로그 확인 및 복구 전략

문제를 확인하는 동안 로그 수준은 보통 info면 충분합니다. debug는 많은 내용을 생성하므로 짧은 시간만 사용하세요. 설정 파싱 오류, DNS 조회, 규칙 매칭, 정책 그룹, 연결 대상과 하위 네트워크 오류에 집중합니다. 로그를 공유하기 전에 구독 URL, 노드 인증 정보, 기기 주소와 접속 기록을 삭제하세요. 오류 메시지의 timeout은 시간 초과 결과일 뿐 DNS·라우팅·서버 문제 중 무엇인지를 직접 의미하지 않습니다. connection refused는 대상이 명시적으로 거부했거나 해당 포트에서 수신 중이 아니라는 뜻이고, no such host는 조회 실패에 가깝습니다. permission denied는 시스템 권한을 확인해야 합니다.

여러 번 수정해 상태가 뒤섞였다면 먼저 필요한 로컬 규칙과 설정을 내보내고 시스템 프록시와 TUN을 끈 뒤 클라이언트를 종료하세요. 직접 연결이 복구되었는지 확인한 다음 다시 시작하고, 이미 정상 작동이 확인된 설정 하나만 가져오세요. 처음부터 모든 앱 데이터를 삭제하지 마세요. 로그·이전 설정과 설정 차이가 문제를 찾는 중요한 단서입니다. 기본 연결을 빠르게 다시 만들려면 빠른 시작 절차를 따라 단계별로 진행하세요. 클라이언트를 바꾸거나 설치 패키지를 다시 내려받아야 한다면 전체 플랫폼 다운로드 페이지에서 시스템과 아키텍처에 맞는 버전을 선택하세요.