Clash 전체 플랫폼 설치 및 설정 가이드

설치 전 공통 준비 사항

플랫폼, 아키텍처, 클라이언트 유형 먼저 확인

Clash는 단일 설치 패키지가 아니라 프록시 코어, 그래픽 클라이언트, 설정 파일, 라우팅 데이터로 구성된 도구 모음입니다. 일반 데스크톱 및 모바일 기기 사용자는 보통 그래픽 클라이언트가 필요하며, 서버·소프트 라우터·컨테이너 환경에서는 Mihomo 코어를 직접 실행합니다. 그래픽 클라이언트는 구독 관리, 정책 전환, 로그 확인, 시스템 권한 처리를 담당하고, 코어는 설정 해석, 로컬 포트 수신, 규칙 매칭, 연결 전달을 담당합니다. 다운로드 전에 두 소프트웨어 유형을 구분하면 명령줄 인터페이스만 제공되는 코어를 데스크톱 프로그램으로 잘못 설치하는 일을 피할 수 있습니다.

플랫폼은 Windows, macOS, Linux라는 이름만 확인해서는 부족하며 프로세서 아키텍처도 확인해야 합니다. 대부분의 일반 Windows PC는 x64를 사용하고, Qualcomm 등 ARM 프로세서를 탑재한 기기만 ARM64가 필요합니다. Apple Silicon Mac은 macOS ARM64 설치 패키지를, Intel Mac은 x64 설치 패키지를 사용합니다. Android 설치 패키지는 보통 arm64, arm, universal 세 종류이며 최근 기기는 대체로 arm64를 우선 선택합니다. 확실하지 않다면 universal을 선택할 수 있습니다. Linux에서는 배포판의 패키지 형식도 확인해야 합니다. Debian, Ubuntu 및 파생 시스템은 보통 deb를 사용하고, Fedora, openSUSE 등은 보통 rpm을 사용합니다.

구독 주소와 기본 네트워크 준비

클라이언트 자체에는 사용할 수 있는 프록시 노드가 포함되어 있지 않습니다. 처음 설정하기 전에 서비스 제공업체가 생성한 Clash 또는 Mihomo 호환 구독 주소나 구조가 완전한 YAML 설정 파일을 준비해야 합니다. 구독 주소에는 보통 인증 정보가 포함되므로 비밀번호처럼 보관하고 스크린샷, 공개 로그, 명령 기록, 공개 코드 저장소에 노출하지 마세요. 제공업체가 여러 형식을 제공한다면 Clash, Mihomo 또는 Meta로 명확히 표시된 형식을 우선 선택하세요. 일반 공유 링크를 가져올 수 있는지는 클라이언트에 형식 변환 기능이 내장되어 있는지에 따라 달라집니다.

가져오기 전에 현재 네트워크에서 구독 주소에 접속할 수 있는지 확인하세요. 브라우저에서 열리지 않으면 클라이언트도 업데이트를 완료하기 어렵습니다. 인증이 필요한 구독이 웹페이지가 아닌 YAML 텍스트를 반환하는 것은 정상입니다. 로그인 페이지, HTML 오류 페이지 또는 빈 응답이 반환된다면 주소, 권한 또는 네트워크 환경에 문제가 있다는 뜻입니다. 회사·학교·공용 네트워크는 특정 연결을 제한할 수 있으므로 처음 설치할 때는 안정적인 가정용 네트워크나 모바일 핫스팟을 사용한 뒤 대상 네트워크로 옮겨 테스트하는 것이 좋습니다.

설정, 구독, 오버라이드 구분

구독은 원격 설정의 원본이고, 설정 파일은 클라이언트가 실제로 불러오는 내용이며, 오버라이드는 원격 구독을 수정하지 않고 로컬 필드를 조정하는 기능입니다. 많은 그래픽 클라이언트가 구독을 캐시하므로 가져오기에 성공했다고 해서 시작할 때마다 원격 서버에 실시간 요청을 보내는 것은 아닙니다. 보통 업데이트 버튼을 눌러야 다시 가져옵니다. 구독 캐시의 YAML을 수정하면 다음 업데이트에서 덮어써질 수 있습니다. 포트, DNS, 규칙을 장기간 유지해야 한다면 클라이언트의 오버라이드, 병합 설정 또는 스크립트 기능을 사용하고 수정 전에 원본 설정을 내보내세요.

최소 설정에는 수신 포트, 프록시 노드 또는 프록시 제공자, 정책 그룹, 규칙이 필요합니다. 필드 사이에는 참조 관계가 있습니다. 규칙은 정책 그룹을 가리키고, 정책 그룹은 다시 실제 노드를 선택합니다. 이름 하나라도 일치하지 않으면 로드에 실패합니다. YAML을 직접 관리하려면 먼저 Clash 설정 파일 구조 해설을 읽고 계층을 이해한 뒤 수정하세요. YAML은 공백 들여쓰기를 사용하며 탭을 섞어 쓸 수 없습니다. 같은 목록의 항목은 들여쓰기 수준을 동일하게 유지해야 합니다.

되돌릴 수 있는 초기 상태 기록

설치 전에 시스템의 기존 프록시 설정, DNS 설정, VPN 소프트웨어 상태를 기록하세요. Windows에서는 “설정 → 네트워크 및 인터넷 → 프록시”, macOS에서는 현재 네트워크 서비스의 “세부사항 → 프록시”에서 확인할 수 있으며, 모바일 기기에서는 기존 VPN 설정이 있는지 확인합니다. Clash를 다른 VPN, 네트워크 필터, 패킷 캡처 도구, 자녀 보호 기능 또는 기업 보안 소프트웨어와 동시에 실행하면 라우팅 테이블, 가상 네트워크 어댑터, 시스템 프록시를 서로 차지하려 할 수 있습니다. 처음 문제를 진단할 때는 네트워크를 제어하는 도구를 하나만 남기고, 연결이 안정된 뒤 다른 소프트웨어를 하나씩 다시 활성화하세요.

다운로드 경로는 클라이언트 페이지에 모아 두었습니다. Clash Plus는 Windows, macOS, Android, iOS용 권장 그래픽 클라이언트이며, Linux 데스크톱에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 서버와 라우터 환경에서는 Mihomo 코어를 고려하세요. 유지보수가 중단된 Clash for Windows와 ClashX Meta는 기존 환경을 이전하거나 오래된 설정과의 호환이 필요한 경우에만 적합하며, 새로 장기간 배포하는 용도로는 권장하지 않습니다.

Windows 다운로드, 설치 및 시스템 연결

설치 패키지 다운로드 및 최초 실행

Windows 일반 사용자는 Clash Plus를 우선 선택하고, 인터페이스 취향에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 사용할 수도 있습니다. Windows 다운로드 영역에서 기기 아키텍처를 먼저 확인한 뒤 전체 설치 패키지를 다운로드하세요. 대부분의 Intel 및 AMD PC는 x64를 사용합니다. 시스템 정보에 ARM64가 명확히 표시되는 기기만 ARM 버전을 선택하세요. 설치 경로는 기본값을 사용하는 것이 좋으며, 프로그램 폴더를 자주 동기화되는 클라우드 드라이브, 임시 폴더 또는 권한이 엄격한 디렉터리에 두지 마세요.

설치 중 사용자 계정 컨트롤 창이 나타나면 작업 출처를 확인한 뒤 설치를 허용하세요. 처음 실행할 때 Windows 방화벽이 클라이언트 통신 허용 여부를 물을 수 있습니다. 신뢰할 수 있는 네트워크에서만 실행한다면 필요에 따라 권한을 부여하세요. 거부해도 일반적으로 루프백 주소를 통한 로컬 프록시 포트 접근에는 영향이 없지만, LAN 공유·외부 제어·일부 TUN 기능은 제한될 수 있습니다. 설치 후에는 클라이언트의 기본 화면을 먼저 열고, 설정과 연결 방식이 정상인지 확인하기 전에는 시작 시 자동 실행을 켜지 마세요.

구독 가져오기 및 설정 상태 확인

설정 또는 구독 페이지에서 URL 가져오기를 선택하고 구독 주소를 붙여 넣어 저장하세요. 클라이언트가 가져오기를 완료하면 설정 이름, 정책 그룹, 노드 목록이 표시되어야 합니다. 빈 설정 하나만 나타나거나 가져오기 버튼이 반응하지 않으면 로그에서 HTTP 상태, 시간 초과, 인증서 오류, YAML 파싱 정보를 확인하세요. 로컬 파일을 가져올 때는 브라우저가 저장한 HTML 페이지가 아니라 완전한 YAML 파일을 선택해야 합니다. 설정이 성공적으로 로드되면 현재 사용 설정으로 지정한 뒤 프록시 그룹 페이지에서 정책을 선택하세요.

첫 테스트에서는 주요 정책 그룹을 자동 선택이나 부하 분산이 아닌 명확한 노드 하나로 지정하는 것이 좋습니다. 연결 문제가 생겼을 때 상태 확인과 정책 그룹 전환이라는 변수를 제거할 수 있기 때문입니다. 클라이언트가 제공하는 지연 시간 테스트는 테스트 주소의 연결 상태만 보여 주며 모든 웹사이트의 실제 사용 가능성을 의미하지 않습니다. 테스트 후 로그를 열고 일반 웹페이지에 접속하면서 규칙 매칭과 연결 기록이 나타나는지 확인하세요.

시스템 프록시 활성화와 포트의 관계

Windows 시스템 프록시는 브라우저, 메신저, WinINET 또는 시스템 프록시 설정을 따르는 대부분의 데스크톱 앱에 적합합니다. 클라이언트에서 “시스템 프록시”를 켜면 시스템은 보통 HTTP 및 HTTPS 프록시를 로컬 수신 주소로 지정합니다. 일반적인 수신 주소는 127.0.0.1이며 포트는 설정의 mixed-port, port 또는 클라이언트 설정에서 가져옵니다. 시스템 프록시는 로컬 포트를 가리키는 설정일 뿐이며, 실제 규칙 매칭은 Clash 코어가 수행합니다.

브라우저는 접속되는데 명령줄 도구가 실패한다면 대개 노드 문제가 아니라 해당 프로그램이 Windows 시스템 프록시를 읽지 않는 경우입니다. PowerShell, Git, 패키지 관리자, 개발 도구는 별도로 프록시 환경 변수나 프로그램 내부 프록시를 설정해야 할 수 있습니다. 반대로 브라우저 확장 프로그램이 독립 프록시를 설정하면 시스템 설정을 우회할 수도 있습니다. 문제를 확인할 때는 먼저 브라우저 프록시 확장을 끄고 시스템 프록시 주소가 클라이언트의 실제 수신 포트와 일치하는지 확인하세요.

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe https://example.com

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

위 PowerShell 설정은 현재 터미널 세션에서만 유효하며, 포트는 클라이언트에 표시된 실제 혼합 프록시 포트로 바꿔야 합니다. 단기 테스트에는 세션 수준 변수를 사용하는 편이 안전합니다. 창을 닫으면 다른 프로그램에 계속 영향을 주지 않습니다. Git에 별도로 설정하려면 Git 자체 설정 항목을 사용하고 필요 없을 때 삭제하세요. 클라이언트를 종료한 뒤에도 명령이 작동하지 않는 로컬 포트를 가리키는 일을 막을 수 있습니다.

TUN 모드, 서비스 모드 및 권한

시스템 프록시를 읽지 않는 앱, 일부 스토어 앱, UDP를 처리해야 하는 프로그램은 TUN 모드를 사용할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 조정하므로 보통 관리자 권한이나 서비스 구성 요소 설치가 필요합니다. 일부 클라이언트는 “서비스 모드”를 제공하여 백그라운드 서비스가 실행 때마다 관리자 권한을 요청하는 작업을 대신 처리합니다. 서비스를 설치한 뒤 클라이언트를 다시 시작하고 서비스 상태가 정상인지 확인한 다음 TUN을 켜세요. 가상 어댑터 생성에 실패하면 다른 VPN, 가상 머신 네트워크 구성 요소, 이전 네트워크 필터 드라이버가 동시에 실행 중인지 확인하세요.

TUN을 켰다고 해서 모든 연결이 반드시 프록시를 거치는 것은 아닙니다. 규칙 모드는 도메인, IP, 프로세스 또는 규칙 데이터에 따라 직접 연결, 프록시, 차단을 결정합니다. LAN 프린터, NAS, 원격 데스크톱에 접근할 수 없다면 바로 전역 모드로 전환하기보다 사설 주소 규칙과 라우팅 제외 설정을 확인하세요. 일반적인 사설 네트워크 대역은 직접 연결을 유지해야 하며, 기업 환경에서는 별도의 내부 네트워크 대역을 추가로 직접 연결 규칙에 넣어야 할 수 있습니다.

시작 시 실행, 절전 모드 복귀 및 종료 순서

구독 업데이트, 시스템 프록시, TUN이 모두 정상 작동하는 것을 확인한 뒤 시작 시 자동 실행을 활성화하세요. 클라이언트에 “자동 실행”, “시작 후 시스템 프록시 활성화”, “시작 후 TUN 활성화” 같은 독립 옵션이 있다면 단계적으로 켜는 것이 좋습니다. 먼저 클라이언트만 시스템과 함께 시작하도록 한 뒤 한 번 재부팅해 보고, 그 다음 자동 프록시를 활성화하세요. 서비스가 준비되기 전에 시스템이 트래픽을 로컬 포트로 보내 로그인 직후 잠시 인터넷이 끊기는 일을 피할 수 있습니다.

Windows가 절전 모드에서 복귀하거나 네트워크가 전환되면 기존 연결과 DNS 캐시가 남아 있을 수 있습니다. 복귀 후 접속할 수 없다면 먼저 시스템 프록시 또는 TUN을 끄고 클라이언트가 네트워크 상태를 다시 가져올 때까지 기다린 뒤 다시 켜세요. 클라이언트를 종료할 때는 화면의 종료 명령을 사용해 시스템 프록시를 복원하세요. 작업 관리자에서 프로세스를 강제 종료하면 프록시 주소가 남을 수 있습니다. “클라이언트 종료 후 모든 웹페이지가 열리지 않는” 경우 시스템 프록시 설정에서 수동 프록시를 끈 뒤 클라이언트를 다시 시작하세요.

macOS 설치, 권한 승인 및 네트워크 확장

Apple Silicon 또는 Intel 설치 패키지 선택

macOS에서는 먼저 프로세서 아키텍처를 구분해야 합니다. 화면 왼쪽 상단의 Apple 메뉴에서 “이 Mac에 관하여”를 열고 칩에 Apple M 시리즈가 표시되면 Apple Silicon 또는 ARM64 설치 패키지를 선택하세요. 프로세서가 Intel로 표시되면 x64 설치 패키지를 선택합니다. Clash Plus를 우선 권장하며 Clash Verge Rev 또는 FlClash도 사용할 수 있습니다. 다운로드 경로는 macOS 클라이언트 영역에 있습니다. 아키텍처를 잘못 선택하면 앱이 실행되지 않거나 변환 계층을 통해 실행되어 호환성 문제가 생길 수 있습니다.

일반적인 설치 방법은 디스크 이미지를 열고 앱을 “응용 프로그램” 폴더로 드래그한 뒤 해당 폴더에서 실행하는 것입니다. 디스크 이미지에서 직접 장기간 실행하지 마세요. 마운트 경로가 바뀌어 로그인 항목, 업데이트, 권한 기록이 불안정해질 수 있습니다. 처음 실행할 때 시스템이 차단하면 “시스템 설정 → 개인정보 보호 및 보안”에서 앱 이름을 확인한 뒤 열기를 허용하세요. 앱 위치를 반복해서 옮기지 마세요. macOS는 경로가 다른 앱을 서로 다른 권한 대상으로 인식합니다.

구독 가져오기 및 필요한 권한 허용

클라이언트 설정 페이지에서 원격 구독을 추가하고 업데이트가 완료되면 활성 설정으로 지정하세요. 이어서 정책 그룹에서 노드를 선택하고 로그나 웹페이지 접속으로 연결을 확인합니다. 프록시, TUN, 네트워크 확장을 처음 활성화할 때 시스템이 관리자 암호를 요구하거나 VPN 설정 추가를 허용할지 물을 수 있습니다. 권한 창은 운영체제에서 표시되므로 완료 후 클라이언트로 돌아가 스위치 상태를 확인하세요. 시스템 팝업이 사라졌는지만 확인해서는 안 됩니다.

클라이언트가 메뉴 막대 아이콘을 제공한다면 메뉴 막대에서 시스템 프록시와 모드를 빠르게 전환할 수 있지만, 복잡한 설정은 기본 화면에서 처리해야 합니다. 메뉴 막대 아이콘이 사라졌다고 프로세스가 종료된 것은 아닙니다. 시스템에 접혀 있거나 앱이 백그라운드 전용으로 설정되었을 수 있습니다. “활성 상태 보기”에서 프로세스 상태를 확인하는 것이 여러 인스턴스를 반복 실행하는 것보다 안전합니다. 여러 인스턴스가 같은 포트를 동시에 수신하면 나중에 시작된 코어에서 포트 사용 중 오류가 발생합니다.

시스템 프록시와 네트워크 서비스별 설정

macOS는 네트워크 서비스별로 프록시 설정을 저장하므로 Wi-Fi, 이더넷, 개인용 핫스팟에 각각 별도 설정이 있을 수 있습니다. 클라이언트가 시스템 프록시를 켤 때는 보통 현재 활성 서비스만 수정하지만, 네트워크를 바꾸면 시스템이 다른 프록시 상태를 복원할 수 있습니다. Wi-Fi에서는 정상인데 유선 연결 후 실패한다면 클라이언트를 재시작하기보다 “시스템 설정 → 네트워크”에서 현재 서비스를 확인하세요. 기업 설정 프로파일이 프록시를 잠글 수도 있으며, 이 경우 일반 앱으로 덮어쓸 수 없으므로 기기 관리 정책을 따라야 합니다.

시스템 프록시는 주로 CFNetwork 또는 시스템 네트워크 설정을 따르는 앱에 영향을 줍니다. 터미널의 curl, SSH, Homebrew, 일부 개발 도구는 그래픽 인터페이스의 프록시 설정을 자동으로 사용하지 않습니다. 현재 터미널에서 환경 변수를 임시로 내보내 다음과 같이 확인할 수 있습니다:

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
curl -I https://example.com

unset HTTP_PROXY
unset HTTPS_PROXY

포트는 클라이언트의 현재 혼합 포트와 일치해야 합니다. 터미널 테스트는 성공하지만 그래픽 앱이 실패하면 앱이 독립 네트워크 확장을 사용하는지, 이전 DNS를 캐시하는지, 시스템 프록시를 명시적으로 비활성화했는지 확인하세요. 그래픽 앱은 정상인데 터미널이 실패하면 환경 변수, Shell 시작 파일, 프로그램 자체의 프록시 설정을 우선 확인합니다.

TUN, DNS 및 다른 네트워크 확장 충돌

TUN은 더 많은 앱과 UDP 트래픽을 연결해야 하는 환경에 적합합니다. 활성화하면 클라이언트가 네트워크 확장을 설치하거나 호출하고 시스템 라우팅을 수정합니다. macOS에서는 방화벽, 콘텐츠 필터, 기업 VPN, 가상 머신 브리지, 다른 프록시 프로그램이 동시에 실행될 수 있으며, 이 구성 요소들의 처리 순서가 연결에 영향을 줍니다. 처음 TUN을 켜기 전에 다른 네트워크 제어 도구를 잠시 종료하고 “시스템 설정 → 네트워크 → VPN 및 필터”에서 중복 활성화된 설정이 없는지 확인하세요.

TUN을 켠 뒤 IP 주소에는 접속되지만 도메인을 해석하지 못한다면 클라이언트 로그의 DNS 요청을 확인하고 현재 네트워크에서 설정된 DNS 서버에 접근할 수 있는지 확인하세요. LAN 도메인이 라우터나 회사 내부 DNS에 의존한다면 모든 조회를 공용 DNS로 보내면 내부 이름이 작동하지 않을 수 있습니다. 내부 도메인에는 별도의 nameserver-policy를 설정하거나 해당 도메인과 사설 주소가 로컬 해석을 사용하도록 구성할 수 있습니다.

로그인 항목, 종료 및 시스템 업데이트 후 확인

시작 시 자동 실행이 필요하다면 클라이언트 자체의 로그인 시 실행 옵션을 사용하고 “시스템 설정 → 일반 → 로그인 항목”에서 상태를 확인하세요. 여러 도구로 시작 항목을 중복 등록하지 마세요. 인스턴스가 두 개 실행될 수 있습니다. 시스템 업데이트 후 네트워크 확장이 작동하지 않으면 앱 권한과 백그라운드 항목이 계속 허용되어 있는지 확인한 뒤 서비스 구성 요소를 다시 설치하세요. 앱을 바로 삭제해도 시스템 프록시가 항상 지워지는 것은 아니므로 제거 전에 시스템 프록시와 TUN을 끄고 클라이언트에서 정상적으로 종료하세요.

Android 설치, VPN 권한 및 백그라운드 실행

설치 패키지 선택 및 설치 완료

Android에서는 Clash Plus를 우선 선택하고 Clash Meta for Android, FlClash, Surfboard를 사용할 수도 있습니다. Android 다운로드 영역에서 기기 아키텍처에 맞는 설치 패키지를 우선 선택하세요. 최근 출시된 대부분의 스마트폰과 태블릿은 arm64를 사용하며, 오래된 기기는 arm을 사용할 수 있습니다. 확인할 수 없다면 universal을 선택할 수 있지만 파일 크기가 대체로 더 큽니다. 아키텍처가 맞지 않으면 시스템에서 설치할 수 없다고 표시하거나 설치 후 실행에 실패합니다.

브라우저로 앱 설치 패키지를 다운로드하면 Android에서 현재 브라우저나 파일 관리 앱에 “알 수 없는 앱 설치 허용” 권한을 요구할 수 있습니다. 이 권한은 지정한 앱이 설치를 시작하도록 허용하는 것일 뿐 모든 출처를 영구적으로 허용하는 것은 아닙니다. 설치가 끝나면 필요에 따라 해당 출처의 권한을 끄세요. 기존 앱과 충돌한다는 메시지가 나타나면 서명이 다르거나 이전 앱이 같은 패키지 이름을 사용하고 있을 가능성이 큽니다. 먼저 기존 클라이언트 설정을 내보낸 뒤 삭제 여부를 결정하여 구독과 오버라이드 규칙을 함께 잃지 않도록 하세요.

구독 가져오기 및 VPN 연결 생성

클라이언트를 연 뒤 설정 페이지에서 URL로 구독을 가져오고 업데이트가 완료되면 해당 설정을 선택하세요. 프록시 또는 정책 페이지에서 주요 정책 그룹에 노드를 지정합니다. 홈 화면으로 돌아가 시작을 누르면 Android에서 VPN 연결 요청이 표시되며, 승인 후 상태 표시줄에 보통 VPN 아이콘이 나타납니다. 이 권한은 로컬 가상 네트워크 인터페이스를 만들어 앱 트래픽을 Clash 코어로 보내는 데 사용됩니다. 사용할 수 있는 노드를 이미 선택했다는 뜻은 아니며, 접속 가능 여부는 설정·정책·DNS에 달려 있습니다.

시작을 누른 직후 중지된다면 먼저 클라이언트 로그를 확인하세요. 흔한 원인은 설정 파싱 실패, 로컬 포트 충돌, 다른 앱이 VPN 권한을 사용 중인 경우, 시스템이 백그라운드 시작을 허용하지 않는 경우입니다. Android에서는 일반 VPN 연결 하나만 허용되는 경우가 많아 다른 VPN, 광고 차단기, 기업 보안 클라이언트, 일부 방화벽이 Clash와 서로 연결을 대체할 수 있습니다. 테스트할 때는 다른 VPN을 끈 뒤 다시 권한을 승인하세요.

앱별 프록시, 우회 및 로컬 네트워크

Android 클라이언트는 보통 앱별 프록시를 지원합니다. 지정한 앱만 프록시를 사용하게 하거나 특정 앱을 VPN에서 우회시킬 수 있습니다. 지정 앱만 프록시하는 방식은 어떤 앱을 연결해야 하는지 명확한 경우에 적합하고, 우회 방식은 대부분의 앱을 기본적으로 연결하되 은행 앱, LAN 도구, 기업 앱만 제외할 때 적합합니다. 시스템 구성 요소 사이에는 호출 관계가 있으므로 앱이 시스템 다운로드 관리자, WebView, 외부 브라우저를 통해 요청을 완료할 수 있습니다. 앱별 목록이 너무 좁으면 메인 화면은 정상인데 로그인이나 다운로드만 실패할 수 있습니다.

라우터, 화면 공유 기기, 프린터, NAS에 접근하려면 LAN 연결을 허용하고 사설 주소가 직접 연결되도록 해야 합니다. 일부 Android 시스템에는 “VPN을 사용하지 않는 연결 차단” 옵션이 있습니다. 이를 켜면 VPN에 들어가지 않은 모든 트래픽이 시스템에서 버려져 앱별 우회나 LAN 접근과 충돌할 수 있습니다. 해당 시스템 옵션을 켠 뒤에만 문제가 생긴다면 먼저 끄고 확인한 뒤 Clash의 라우팅과 우회 규칙을 조정하세요.

절전 설정 및 백그라운드 유지

모바일 운영체제는 화면이 꺼지거나 배터리가 부족하거나 앱이 오랫동안 백그라운드에 있으면 앱을 제한합니다. 보통 시작 직후에는 정상인데 화면을 잠근 뒤 연결이 끊기고 클라이언트를 다시 열면 복구됩니다. 시스템 배터리 설정에서 클라이언트를 제한 없음으로 지정하고 백그라운드 실행을 허용하세요. 제조업체의 자동 시작 관리에서도 실행을 허용해야 합니다. 브랜드마다 설정 이름은 다르지만 기준은 같습니다. 화면이 꺼진 뒤에도 클라이언트 프로세스와 VPN 서비스가 정리되지 않아야 합니다.

TUN/VPN을 계속 실행하면 일정 수준의 배터리를 더 사용하며, 실제 소모량은 네트워크 품질, DNS 요청, 상태 확인 빈도, 활성 연결 수에 따라 달라집니다. 연결 유지를 위해 중복 예약 업데이트나 고빈도 속도 측정을 여러 개 동시에 켜지 마세요. 구독 업데이트는 실제 필요에 맞는 주기로 설정하고, 정책 그룹 상태 확인도 많은 노드를 지나치게 자주 탐색할 필요가 없습니다. 배터리 소모가 비정상적으로 늘면 Android 배터리 통계와 클라이언트 로그를 먼저 확인하여 지속적인 네트워크 활동인지 VPN이 반복 재시작되는지 구분하세요.

모바일 네트워크, Wi-Fi 및 비공개 DNS

Wi-Fi에서 모바일 네트워크로 전환하면 기존 TCP 및 UDP 연결이 끊기고 클라이언트가 채널을 다시 만들어야 합니다. 잠시 기다려도 복구되지 않으면 구독을 반복해서 다시 가져오기보다 VPN을 중지한 뒤 다시 시작하세요. Android의 “비공개 DNS”는 암호화 DNS를 사용하므로 Clash의 DNS 연결과 처리 순서가 달라질 수 있습니다. 일부 도메인만 해석되지 않는다면 먼저 비공개 DNS를 자동으로 바꿔 비교 테스트한 뒤, 현재 설정에 따라 시스템과 Clash 중 한 곳에서 DNS를 통합 처리하도록 결정하세요.

iOS 설치, VPN 설정 및 주문형 연결

App Store에서 Clash Plus 설치

iPhone과 iPad에서는 Clash Plus를 사용합니다. 다운로드 페이지에 App Store 경로가 제공되며, 앱 정보를 확인할 수 있도록 공식 웹사이트 clashplus.io도 안내합니다. 설치가 끝나면 앱을 먼저 열고 시스템 권한 안내를 읽은 뒤 설정 페이지로 이동하세요. iOS의 네트워크 연결은 시스템 Network Extension에 의존합니다. 앱에서 처음 프록시를 시작할 때 VPN 설정 추가를 요청하며 기기 암호, Face ID, Touch ID로 확인해야 합니다.

시스템 설정의 VPN 상태는 네트워크 확장이 생성되었는지만 보여 주며 설정에 있는 노드를 사용할 수 있다는 뜻은 아닙니다. 설치 후 구독 가져오기, 설정 선택, 정책 그룹 선택, 연결 테스트를 순서대로 완료하세요. VPN만 승인하고 유효한 설정을 로드하지 않으면 앱이 연결 직후 끊기거나 연결 상태만 유지한 채 전달할 정책이 없을 수 있습니다.

구독 가져오기 및 설정 업데이트

설정 페이지에서 URL로 추가를 선택하고 Clash 또는 Mihomo 호환 구독 주소를 붙여 넣으세요. 업데이트에 성공하면 설정에 프록시 그룹과 규칙이 있는지 확인한 뒤 현재 설정으로 지정합니다. iOS에서 클립보드 접근 알림이 나타날 수 있는데, 구독 주소를 붙여 넣을 때 발생하는 시스템 동작입니다. 가져오기가 끝나면 클립보드에 주소를 계속 보관할 필요는 없습니다. Safari에서 구독 링크를 눌러 앱으로 이동한 경우 실제로 열린 앱과 설정 이름을 확인하여 같은 구독을 중복 가져오지 않도록 하세요.

구독 업데이트에 실패하면 먼저 Safari에서 같은 주소를 열어 보세요. 브라우저에서도 열리지 않는다면 네트워크, 주소 유효성, 서비스 상태를 확인합니다. 브라우저에서는 열리지만 앱에서 실패한다면 URL에 이스케이프된 문자가 포함되었는지, 추가 요청 헤더가 필요한지, 클라이언트 로그의 상태 코드를 확인하세요. 기존 설정을 업데이트하기 전에 중요한 오버라이드를 내보내세요. 원격 업데이트가 구독으로 생성된 노드와 정책 그룹을 바꿀 수 있습니다.

정책 모드, LAN 및 셀룰러 네트워크

처음 연결할 때는 규칙 모드를 사용하고 주요 정책 그룹에 명확한 노드 하나를 지정하는 것이 좋습니다. 전역 모드는 원래 직접 연결해야 하는 시스템 서비스와 로컬 연결까지 하나의 정책에 넘길 수 있으므로 장기적인 문제 해결 방식으로 적합하지 않습니다. 규칙 모드에서는 도메인과 주소를 순서대로 매칭하고 매칭되지 않은 연결은 최종 규칙이 처리합니다. 가정용 기기에 접근해야 한다면 사설 주소, LAN 도메인, Bonjour 관련 트래픽이 잘못 프록시되지 않도록 하세요.

Wi-Fi에서 셀룰러 네트워크로 전환하면 시스템이 기본 연결을 다시 만듭니다. 네트워크 확장은 보통 자동으로 복구되지만 장시간 연결은 앱이 다시 요청해야 할 수 있습니다. 상태 표시줄에 VPN이 계속 표시되는데 네트워크를 사용할 수 없다면 Clash Plus에서 연결을 중지하고 시스템 VPN 아이콘이 사라질 때까지 기다린 뒤 다시 시작하세요. 비행기 모드를 반복해서 켜고 끄면 설정 문제를 가릴 수 있어 네트워크 전환, DNS, 노드 중 어느 것이 원인인지 판단하기 어렵습니다.

주문형 연결 및 백그라운드 제한

주문형 연결은 네트워크 변화에 따라 VPN을 자동으로 만들 수 있어 설정이 안정된 기기에 적합합니다. 처음 설치할 때는 잘못된 설정이 네트워크 전환마다 자동으로 복구될 수 있으므로 바로 활성화하지 않는 것이 좋습니다. 먼저 수동 연결로 Wi-Fi, 셀룰러 네트워크, 화면 잠금, 깨우기 테스트를 완료한 뒤 필요에 따라 주문형 규칙을 켜세요. 가정용 Wi-Fi, 회사 Wi-Fi, 모바일 네트워크를 서로 다르게 처리해야 한다면 하나의 광범위한 규칙에 의존하지 말고 네트워크 조건을 명확히 설정하세요.

iOS의 백그라운드 동작은 시스템이 통합 관리하므로 앱 화면을 계속 열어 두는 것만으로 모든 연결 끊김을 해결할 수 없습니다. 안정성은 네트워크 확장 상태, 시스템 리소스, 설정 복잡도, 네트워크 전환에 좌우됩니다. 빈번한 상태 확인은 백그라운드 활동을 늘리고, 복잡한 스크립트와 지나치게 큰 규칙 데이터는 설정 로드 시간을 늘릴 수 있습니다. 시스템이 연결을 종료한다면 불필요한 탐색을 줄이고 로그에서 메모리, 설정 파싱, 네트워크 변화 기록을 먼저 확인하세요.

다른 VPN 설정과의 관계

기기에는 여러 VPN 설정을 저장할 수 있지만 같은 시점에는 보통 하나의 주요 터널만 활성화됩니다. 기업 기기 관리, 콘텐츠 필터, DNS 앱, 다른 프록시 도구가 네트워크 확장 기능을 차지할 수 있습니다. Clash Plus가 시작되지 않으면 “설정 → 일반 → VPN 및 기기 관리”에서 현재 설정을 확인하되 기업 관리 항목을 함부로 삭제하지 마세요. 개인 기기라면 다른 VPN을 먼저 비활성화해 비교하고, 관리 기기라면 조직 정책을 따라야 합니다.

Linux 데스크톱, 명령줄 및 서비스 배포

데스크톱 클라이언트 패키지 형식 선택

Linux 데스크톱 사용자는 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. Debian, Ubuntu, Linux Mint 및 파생 시스템은 보통 deb 설치 패키지를 사용하고, Fedora, Rocky Linux, openSUSE 환경은 배포판이 지원하는 rpm을 선택합니다. 일부 클라이언트는 독립 실행 형식도 제공할 수 있습니다. Linux 다운로드 영역으로 이동하기 전에 uname -m을 실행해 아키텍처를 확인하세요. x86_64 출력은 보통 AMD64에 해당하고 aarch64 출력은 ARM64에 해당합니다.

uname -m
cat /etc/os-release

sudo apt install ./clash-client-amd64.deb
# rpm 계열 배포판을 사용하는 경우 해당 패키지 관리자로 rpm 파일을 설치하세요

예시의 파일 이름은 실제로 다운로드한 파일로 바꿔야 합니다. 로컬 패키지는 직접 압축을 풀어 복사하는 것보다 패키지 관리자로 설치하는 편이 데스크톱 항목과 의존성을 처리하기 쉽습니다. 설치 후 메뉴 아이콘이 나타나지 않으면 터미널에서 한 번 실행해 오류 출력을 확인하세요. Wayland와 X11 환경은 트레이 아이콘, 권한 알림, 자동 실행 방식이 다를 수 있습니다. 트레이가 보이지 않는다고 코어가 실행되지 않는 것은 아니므로 프로세스, 포트, 로그를 함께 확인해야 합니다.

설정 가져오기 및 데스크톱 시스템 프록시

그래픽 클라이언트의 구독 가져오기 절차는 다른 데스크톱 플랫폼과 비슷합니다. 원격 URL 추가, 설정 업데이트, 현재 설정 지정, 정책 선택 후 시스템 프록시를 켭니다. Linux의 시스템 프록시는 전 시스템에서 공유하는 단일 인터페이스가 아닙니다. GNOME, KDE, 브라우저, 터미널, 백그라운드 서비스가 서로 다른 설정을 읽을 수 있습니다. 데스크톱 스위치는 데스크톱 환경의 프록시 설정을 따르는 앱에 주로 영향을 주며, 명령줄 프로그램과 systemd 서비스는 보통 자동으로 읽지 않습니다.

터미널 테스트에서는 환경 변수를 임시로 설정할 수 있습니다. 대문자와 소문자 변수명을 함께 지정하면 더 많은 도구와 호환되지만, 장기 설정 전에 프로그램의 동작을 확인하세요. 프록시 변수를 모든 사용자의 전역 환경에 직접 기록하지 마세요. 클라이언트가 실행되지 않을 때 많은 명령이 실패할 수 있습니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$https_proxy

curl -I https://example.com

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY

SSH는 HTTP 프록시 변수를 설정했다고 해서 자동으로 Clash를 통과하지 않습니다. Git의 HTTPS 원격 저장소는 환경 변수를 읽을 수 있지만 SSH 원격 저장소는 별도의 ProxyCommand 또는 TUN 라우팅이 필요합니다. 패키지 관리자도 자체 프록시 설정 파일을 사용할 수 있습니다. 문제를 확인할 때는 앱별로 하나씩 점검하고 “브라우저가 정상”이라는 이유로 모든 Linux 프로세스가 연결되었다고 판단하지 마세요.

TUN 권한, 라우팅 및 DNS

Linux TUN은 /dev/net/tun에 접근하고 라우팅, 정책 라우팅 또는 방화벽 규칙을 수정해야 합니다. 그래픽 클라이언트는 권한 도우미를 통해 작업할 수 있으며, 명령줄 코어는 적절한 capability가 필요하거나 관리되는 서비스로 시작해야 합니다. 전체 데스크톱 클라이언트를 장기간 root로 실행하는 것은 바람직하지 않습니다. 클라이언트가 제공하는 서비스 모드를 우선 사용하거나 코어에 최소한의 필수 권한만 부여하세요.

컨테이너, 가상 머신, Docker 브리지, 로컬 Kubernetes는 추가 네트워크 대역을 만들 수 있습니다. 자동 라우팅을 활성화했는데 이 대역이 올바르게 제외되지 않으면 컨테이너에서 호스트로의 접근, 이미지 다운로드, 클러스터 내부 통신이 비정상적으로 작동할 수 있습니다. TUN을 켜기 전에 ip route를 기록하고 문제가 생긴 뒤 라우팅 테이블을 비교하세요. LAN, 컨테이너 네트워크 대역, VPN 전용 대역은 실제 환경에 맞춰 직접 연결 또는 제외로 설정해야 합니다.

ip route
ip rule
ss -lntup | grep -E '7890|9090'
resolvectl status

배포판에 따라 systemd-resolved, NetworkManager, 기존 resolv.conf 또는 다른 DNS 관리 방식을 사용할 수 있습니다. Clash의 DNS 연결은 현재 해석 체인과 함께 작동해야 합니다. 시스템의 /etc/resolv.conf가 로컬 stub을 가리키는데 Clash가 같은 주소로 쿼리를 되돌리면 순환이 발생할 수 있습니다. 로그에 DNS 시간 초과, CPU 사용량 증가, 반복 요청이 계속 나타난다면 최종적으로 접근 가능한 실제 DNS를 가리키도록 상위 nameserver를 설정했는지 확인하세요.

Mihomo 코어의 서비스 실행

데스크톱 환경이 없는 서버나 라우터에서는 Mihomo 코어를 직접 실행할 수 있습니다. 설정 디렉터리에는 기본 설정과 필요한 라우팅 데이터가 포함되어야 하며 실행 사용자가 이를 읽을 권한을 가져야 합니다. 시작하기 전에 코어의 설정 검사 기능으로 YAML 파싱 가능 여부를 확인한 뒤 systemd에 맡기세요. 서비스에는 명확한 작업 디렉터리, 설정 경로, 재시작 정책, 로그 출력을 지정하고 임시 디렉터리에서 시작하지 않도록 합니다.

mihomo -t -d /etc/mihomo
mihomo -d /etc/mihomo

서비스로 배포할 때 제어 포트와 프록시 포트를 기본적으로 모든 네트워크 인터페이스에 공개하지 마세요. 로컬에서만 사용할 경우 루프백 주소에 수신하도록 유지하고, LAN 기기에서 사용해야 할 때만 allow-lan, 수신 주소, 방화벽, 제어 인터페이스 인증을 설정하세요. 원격 제어 인터페이스를 공개한다면 출처를 제한하고 접근 키를 설정해야 합니다. 설정을 변경한 뒤에는 먼저 검사하고 서비스를 다시 로드하며, 빠르게 되돌릴 수 있도록 이전에 시작 가능했던 설정을 보관하세요.

자동 시작과 그래픽 세션의 차이

데스크톱 클라이언트의 자동 시작은 보통 사용자 그래픽 세션에 의존하고, systemd 시스템 서비스는 시스템 부팅 단계에서 실행됩니다. 같은 코어 인스턴스를 두 방식으로 동시에 시작하지 마세요. 포트와 설정 디렉터리를 서로 차지하려 합니다. 데스크톱 프록시만 필요하다면 클라이언트의 로그인 시 실행을 사용하세요. 전체 호스트나 LAN에 안정적인 서비스를 제공하려면 독립 코어 서비스를 사용하고 그래픽 인터페이스는 제어용으로만 두세요. 업그레이드 전 서비스를 중지하고 설정을 백업한 뒤, 업그레이드 후에는 먼저 전면 실행으로 호환성을 테스트하고 자동 시작을 복원하세요.

시스템 프록시, 규칙 모드, 전역 모드 및 TUN

네 가지 개념의 역할

시스템 프록시, TUN, 규칙 모드, 전역 모드는 같은 계층에 있지 않습니다. 시스템 프록시와 TUN은 “어떤 트래픽이 Clash로 들어오는지”를 결정하고, 규칙 모드와 전역 모드는 “들어온 뒤 어떻게 처리하는지”를 결정합니다. 시스템 프록시는 운영체제의 프록시 설정으로 프록시를 지원하는 앱을 로컬 수신 포트로 보냅니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 연결을 가로챕니다. 트래픽이 코어에 들어오면 규칙 모드는 규칙 목록에 따라 직접 연결, 프록시, 차단을 선택하고, 전역 모드는 대부분의 연결을 지정된 하나의 정책으로 보냅니다.

이 두 계층을 이해하면 흔한 오판을 피할 수 있습니다. 브라우저의 트래픽 로그가 없다면 연결이 Clash에 들어오지 않았을 가능성이 있으므로 시스템 프록시나 TUN을 확인해야 합니다. 로그에 연결이 있지만 결과가 예상과 다르면 규칙, 정책 그룹, 노드를 확인하세요. 전역 모드로 전환해도 이미 코어에 들어온 트래픽의 처리 방식만 바뀔 뿐, 시스템 프록시를 전혀 읽지 않는 프로그램이 갑자기 연결되는 것은 아닙니다.

규칙은 왜 순서대로 매칭되는가

Clash 규칙은 보통 위에서 아래로 검사하며 첫 번째 규칙이 일치하면 이후 매칭을 중단합니다. 따라서 구체적인 규칙을 광범위한 규칙보다 앞에 배치하고 마지막에는 MATCH를 기본 규칙으로 사용하세요. 도메인 규칙, 규칙 데이터, IP 대역, 프로세스 규칙을 함께 사용할 수 있지만 DNS 해석 여부와 IP 매칭 생략 여부가 성능과 결과에 영향을 줍니다. 특정 웹사이트가 잘못된 정책을 사용하는 것을 발견하면 로그에서 도메인, 대상 주소, 매칭 규칙을 확인한 뒤 설정으로 돌아가 원인을 찾으세요. 중복 규칙을 무작정 추가하지 마세요.

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

예시에서는 더 구체적인 도메인 접미사 규칙이 키워드 규칙보다 앞에 있고, 사설 주소는 명시적으로 직접 연결되며, 마지막에는 MATCH가 PROXY 정책 그룹으로 전달됩니다. 실제 설정의 정책 그룹 이름은 proxy-groups 정의와 완전히 일치해야 합니다. no-resolve는 해당 IP 규칙을 매칭할 때 도메인에 대한 추가 해석을 실행하지 않는다는 뜻이며, 전체 DNS 모듈을 끈다는 의미는 아닙니다.

정책 그룹은 노드 목록과 같은 개념이 아닙니다

노드는 구체적인 연결 매개변수를 설명하고, 정책 그룹은 여러 노드나 다른 정책 중에서 선택합니다. select 그룹은 사용자가 직접 선택하고, url-test 그룹은 테스트 결과에 따라 선택하며, fallback 그룹은 사용 가능한 항목으로 순서대로 대체하고, load-balance 그룹은 알고리즘에 따라 연결을 분배합니다. 일상적인 문제 해결에서는 자동 정책이 상태 확인에 따라 결과를 바꾸지 않도록 select로 노드 하나를 고정하세요. 고정 노드가 안정된 뒤 자동 그룹의 테스트 주소, 간격, 허용 오차가 적절한지 확인합니다.

정책 그룹은 다른 정책 그룹을 참조할 수 있습니다. 흔한 구조에서는 업무 규칙이 “해외 웹사이트”, “스트리밍”, “다운로드” 같은 업무 그룹을 가리키고, 업무 그룹이 다시 지역 그룹을 참조하며, 지역 그룹이 최종적으로 노드를 선택합니다. 계층이 너무 깊으면 화면에서 선택한 항목이 최종 노드가 아닐 수 있습니다. 문제를 해결할 때는 참조 체인을 단계별로 펼쳐 모든 그룹에 사용할 수 있는 출구가 있는지 확인하세요. 프로젝트와 코어의 관계는 Clash 오픈 소스 생태계 프로젝트 관계에서 확인할 수 있습니다.

DNS 연결, Fake IP 및 실제 주소

DNS 모듈은 도메인을 주소로 변환할 뿐 아니라 규칙 판단과 트래픽 매핑에도 관여할 수 있습니다. Fake IP 모드에서는 먼저 예약 주소를 반환하고 코어가 매핑을 통해 원래 도메인을 복원하므로 규칙 매칭이 편리하고 앱이 자체적으로 우회하는 일을 줄일 수 있습니다. 일부 LAN 검색, 하드코딩된 DNS, 특수 검증, 반환 주소를 직접 기록하는 앱은 Fake IP와 호환되지 않을 수 있으므로 필터 목록에 추가하거나 redir-host로 바꿔 비교하세요.

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

이 조각은 필드 구조만 보여 주며 노드, 정책 그룹, 규칙이 포함되어 있지 않으므로 독립적으로 연결할 수 있는 완전한 설정이 아닙니다. 수신 주소를 로컬로 제한하여 단일 기기에서 필드를 이해하는 데 적합합니다. 실제 사용에서는 네트워크 접근성, 개인정보 보호 요구, 내부 DNS 필요에 따라 상위 DNS를 선택하고 기계적으로 복사하지 마세요. 네트워크가 IPv6를 지원하지 않는데 설정이 IPv6 주소를 우선 반환하면 도메인은 해석되지만 연결이 시간 초과될 수 있습니다. 이때 시스템 네트워크, DNS 응답, Clash의 IPv6 설정을 함께 확인하세요.

일상 실행 방식 선택

데스크톱 업무 환경에서는 먼저 규칙 모드와 시스템 프록시를 사용하세요. 범위가 명확하고 종료 후 복구하기 쉽습니다. 명령줄, UDP, 프록시를 따르지 않는 앱까지 처리해야 한다면 규칙 모드와 TUN을 함께 사용하세요. 모바일 기기는 보통 시스템 VPN 인터페이스로 트래픽을 연결하므로 본질적으로 TUN에 가깝지만, 출구는 여전히 규칙이 결정합니다. 전역 모드는 “현재 노드가 연결을 만들 수 있는지” 판단하는 데 적합하며 모든 문제의 최종 해결책으로 사용하기에는 적합하지 않습니다.

설정 유지 관리 및 일반적인 문제 해결

먼저 문제가 발생한 계층을 판단하세요

효율적인 문제 해결은 계층별로 범위를 좁혀야 합니다. 첫 번째 계층은 클라이언트 실행 여부, 코어 시작 여부, 포트 수신 여부입니다. 두 번째는 트래픽이 Clash로 들어오는지 여부입니다. 세 번째는 규칙이 예상 정책과 매칭되는지 여부입니다. 네 번째는 선택한 노드에 연결할 수 있는지 여부입니다. 다섯 번째는 대상 웹사이트, DNS, 앱 프로토콜에 추가 제한이 있는지 여부입니다. 웹페이지가 열리지 않는다고 클라이언트, 구독, DNS, 모드를 동시에 바꾸지 마세요. 복구되더라도 실제 원인을 알 수 없습니다.

클라이언트 홈 화면에 활성 설정이 표시되는지 먼저 확인한 다음 로그를 확인하세요. 접속 기록이 전혀 없다면 시스템 프록시, TUN, VPN 권한, 앱별 프록시를 중점적으로 확인합니다. 연결 기록은 있지만 규칙이 잘못된 것으로 표시되면 규칙 순서와 정책 그룹을 확인하세요. 연결 기록이 있고 올바른 노드와 매칭되지만 연결 시간 초과가 발생하면 다른 노드와 네트워크를 테스트합니다. 특정 도메인만 실패할 때는 DNS, 도메인 규칙, 대상 서비스 상태를 확인하세요.

구독 업데이트 실패 및 설정 로드 실패

구독 업데이트 실패는 보통 네트워크 오류, HTTP 오류, 콘텐츠 파싱 오류로 나뉩니다. 시간 초과나 연결 거부는 주소에 접근할 수 없다는 뜻이고, 인증 실패나 권한 오류는 구독 상태를 확인해야 합니다. YAML 대신 HTML이 반환되는 경우는 로그인 페이지, 게이트웨이 차단, 잘못된 리디렉션에서 흔히 발생합니다. 브라우저에서 열린다고 클라이언트의 요청 조건까지 완전히 같다는 뜻은 아니지만, 주소 오탈자와 기본 네트워크 문제를 먼저 배제할 수 있습니다. 주소를 복사할 때 앞뒤 공백, 줄바꿈, 메신저가 추가한 이스케이프 문자가 포함되지 않았는지 확인하세요.

설정 파싱 오류는 보통 로그에 줄 번호나 필드명이 표시됩니다. YAML에서 가장 흔한 문제는 들여쓰기 계층 오류, 콜론 뒤 공백 누락, 같은 키의 중복 정의, 목록 기호 위치 오류, 존재하지 않는 정책 그룹 참조입니다. 오류가 발생하면 오류가 표시된 줄에서 위쪽으로 소속 구조를 확인하세요. 실제 들여쓰기 문제는 몇 줄 앞에 있을 수 있습니다. 최근 정상 설정으로 되돌린 뒤 변경 사항을 작은 단위로 나누어 하나씩 추가하는 것도 좋습니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,PROXY

이 구조에서 rules가 참조하는 PROXY는 정책 그룹 이름과 일치합니다. 이름을 다른 문자열로 바꾸면 규칙도 함께 수정해야 합니다. YAML에서 특수 문자가 포함된 이름은 따옴표로 감쌀 수 있지만 같은 참조는 계속 완전히 일치해야 합니다. 필드에 대한 자세한 설명은 설정 파일 구조 해설에서 확인하세요.

포트 사용 중 및 코어 시작 실패

코어가 시작되면 혼합 프록시, HTTP, SOCKS, DNS, 제어 포트를 수신합니다. 다른 Clash 인스턴스, 이전 프로세스, 다른 프록시 프로그램이 같은 포트를 이미 사용하고 있으면 새 인스턴스가 시작되지 않습니다. Windows에서는 리소스 모니터나 명령줄로 수신 포트를 확인하고, macOS와 Linux에서는 lsof 또는 ss를 사용할 수 있습니다. 사용 중인 포트를 찾으면 먼저 프로세스의 신원을 확인하고 모르는 시스템 서비스를 바로 종료하지 마세요. 이전 클라이언트를 닫거나 현재 설정에 사용되지 않은 포트를 지정하세요.

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

포트가 사용 중이 아닌데도 코어가 시작되지 않으면 설정 파일 권한, 작업 디렉터리, 규칙 데이터 존재 여부, 클라이언트가 호출하는 코어 경로가 유효한지 확인하세요. 보안 소프트웨어가 코어 파일을 격리하거나 시스템 업데이트로 서비스 권한이 바뀌거나 앱 위치가 변경되어도 같은 현상이 발생할 수 있습니다. 그래픽 인터페이스에 “시작 실패”만 표시되면 상세 로그를 열거나 터미널에서 클라이언트를 시작해 전체 오류를 확인하세요.

브라우저는 정상인데 터미널 또는 앱이 실패하는 경우

브라우저가 정상이라는 것은 노드와 적어도 하나의 프록시 진입점이 작동한다는 뜻이지만 터미널까지 연결되었다는 의미는 아닙니다. 터미널 프로그램은 시스템 프록시를 읽지 않을 수 있어 환경 변수나 프로그램 수준 설정이 필요합니다. 게임과 일부 스토어 앱은 UDP나 직접 소켓을 사용할 수 있으므로 TUN이 필요할 수 있습니다. 또한 브라우저에 독립 프록시 확장 프로그램이 설치되어 있다면 Clash의 시스템 프록시를 사용하지 않을 수도 있습니다. 각 테스트 요청이 로그에 나타나는지 비교해 확인하세요.

터미널 시작 파일에 이전 프록시 변수가 남아 있는지 확인하세요. 변수가 이미 종료한 클라이언트 포트를 가리키면 명령이 계속 실패합니다. Windows에서는 PowerShell 환경 변수를, macOS와 Linux에서는 Shell 설정 파일과 현재 세션을 확인하세요. Git, npm, 패키지 관리자에도 자체 프록시 항목이 남아 있을 수 있습니다. 자세한 분기는 시스템 프록시가 적용되지 않을 때의 문제 해결에서 확인하세요.

IP에는 접속되지만 도메인은 실패하는 경우

이 현상은 보통 DNS 문제를 가리킵니다. 먼저 Clash DNS가 활성화되어 있는지, 수신 포트가 사용 중인지, 상위 서버에 접근할 수 있는지 확인하세요. TUN 모드에서는 DNS 가로채기가 작동하는지와 시스템 조회가 순환을 만드는지도 확인해야 합니다. 내부 도메인만 실패한다면 공용 DNS가 회사나 가정 내부의 레코드를 알지 못하는 것입니다. 해당 도메인은 로컬 해석을 유지하도록 설정하세요. 일부 앱만 실패한다면 Fake IP 호환성과 필터 규칙을 확인합니다.

시스템 DNS 캐시 삭제는 오래된 레코드만 처리할 뿐 잘못된 상위 DNS나 규칙을 수정하지 못합니다. 캐시를 반복해서 새로 고치는 것을 주요 해결책으로 삼지 마세요. 비교 테스트에서는 Clash DNS를 잠시 꺼서 시스템의 기존 해석을 사용할 수 있습니다. 즉시 정상으로 돌아온다면 enhanced-mode, nameserver, fallback, nameserver-policy, IPv6를 하나씩 확인하세요. 꺼도 계속 실패하면 시스템 네트워크나 라우터 DNS를 점검해야 합니다.

TUN을 켠 뒤 LAN 또는 전체 네트워크가 끊기는 경우

먼저 TUN을 끄고 시스템 프록시 모드가 정상인지 확인하세요. 끈 뒤 복구된다면 노드와 기본 설정은 대체로 정상이고 문제는 라우팅, 가상 네트워크 어댑터, DNS, 권한에 집중됩니다. 다른 VPN, 가상 머신, 컨테이너 네트워크, 기업 필터가 있는지 확인하세요. 사설 주소는 직접 연결하고 특수한 내부 네트워크 대역은 제외 목록에 추가해야 합니다. Windows에서는 서비스 모드와 가상 어댑터를, macOS에서는 VPN 및 필터를, Linux에서는 라우팅 테이블·정책 라우팅·방화벽을 중점적으로 확인하세요.

TUN 실패 후에도 시스템 네트워크를 사용할 수 없다면 클라이언트를 정상적으로 종료한 뒤 남은 라우팅, 시스템 프록시, DNS를 확인하세요. 모바일 기기에서는 VPN을 중지하고 시스템 아이콘이 사라질 때까지 기다린 후 네트워크를 다시 연결하세요. 데스크톱 시스템에서는 가상 네트워크 어댑터를 첫 단계에서 바로 삭제하지 마세요. 클라이언트 서비스가 다시 만들 수 있고 다른 소프트웨어의 어댑터까지 삭제해 문제를 키울 수 있습니다. 먼저 클라이언트에서 기능을 끈 뒤 해당 서비스 구성 요소를 제거하세요.

구독 업데이트 후 기존 선택이 사라지는 경우

구독 제공업체가 노드 이름, 정책 그룹, 규칙 구조를 변경할 수 있습니다. 클라이언트에 저장된 선택은 보통 이름으로 연결되므로 이름이 바뀌면 기본 항목으로 돌아갑니다. 로컬 오버라이드를 사용한다면 이전 그룹 이름을 참조하여 무효화될 수도 있습니다. 업데이트 후 정책 그룹이 여전히 존재하는지 확인하고 오버라이드 로그를 점검하세요. 구독 캐시를 직접 장기간 수정하지 마세요. 다음 업데이트에서 덮어써집니다.

클라이언트를 이전할 때는 구독 주소, 로컬 설정, 오버라이드 스크립트, 사용자 선택을 각각 백업하세요. 클라이언트마다 설정 디렉터리, 스크립트 기능, 정책 저장 방식이 다르므로 이전 프로그램 폴더 전체를 복사하는 것만으로는 충분하지 않습니다. 이전 클라이언트의 마이그레이션 절차는 클라이언트 지원 종료 후 설정 보존 및 대체 소프트웨어 선택에서 확인할 수 있습니다.

유지 관리 가능한 설정 업데이트 절차 만들기

안정적인 설정은 최근 정상 백업을 하나 보관하고 로컬 변경 사항을 설명 가능한 범위로 제한해야 합니다. 구독을 업데이트하기 전에 현재 정책과 중요한 오버라이드를 기록하고, 업데이트 후 설정 로드, DNS, 직접 연결 사이트, 프록시 사이트, LAN을 순서대로 테스트하세요. 라우팅 데이터 업데이트와 클라이언트 업데이트는 분리해서 진행해야 문제가 생겼을 때 원인을 쉽게 판단할 수 있습니다. GeoIP와 GeoSite의 용도, 참조, 로드 문제는 GeoIP 및 GeoSite 사용 방법에서 확인하세요.

문제 해결 중에는 연결과 규칙 정보를 볼 수 있는 수준으로 로그를 설정하고 문제가 해결되면 일반 수준으로 되돌리세요. 장기간 많은 파일이 생성되는 것을 막을 수 있습니다. 로그를 공유할 때는 구독 주소, 제어 키, 노드 인증 정보, 개인 도메인 기록을 삭제하세요. 원인을 계속 확인해야 하지만 분류하기 어렵다면 자주 묻는 질문에서 기본 개념, 설치 및 설정, 사용 팁, 문제 해결 항목을 순서대로 검색하세요.

모든 플랫폼에서 핵심 판단 순서는 같습니다. 먼저 소프트웨어와 설정이 실행 중인지 확인하고, 다음으로 트래픽이 들어오는지 확인한 뒤 규칙·정책·노드를 점검하고 마지막으로 DNS와 플랫폼 권한을 처리합니다. 이 순서로 증거를 남기고 변수를 줄이는 편이 반복해서 재설치하는 것보다 안정적인 결과를 얻기 쉽습니다. 클라이언트나 설치 패키지를 다시 선택해야 한다면 Clash 클라이언트 다운로드 페이지로 돌아가 이 페이지의 해당 플랫폼 장에 따라 권한과 연결 설정을 다시 완료하세요.