Clash 전 플랫폼 설치·설정 가이드

PREPARE / INPUT CHECK

설치 전 공통 사전 준비

시스템 아키텍처, 설정 출처와 네트워크 진입점을 먼저 확인하면 잘못된 설치 파일, 사용할 수 없는 구독, 적용되지 않은 시스템 프록시를 하나의 문제로 혼동하지 않을 수 있습니다.

운영체제, 아키텍처와 클라이언트 역할 확인

다운로드하기 전에 운영체제 이름, 버전과 프로세서 아키텍처를 기록하세요. 일반적인 Windows 기기는 x64를 사용하며 일부 신형 기기는 ARM64를 사용합니다. macOS는 Intel과 Apple Silicon을 구분해야 하고, Android 설치 파일은 ARM64, ARM 또는 범용 아키텍처로 제공될 수 있습니다. Linux는 아키텍처뿐 아니라 deb, rpm과 압축 파일도 구분해야 합니다. 아키텍처가 맞지 않으면 설치 프로그램이 실행을 거부하거나 시스템에서 지원하지 않는다는 메시지가 나타나고, 실행 직후 종료되기도 합니다. 파일명에 ‘64’가 있다는 이유만으로 적합하다고 판단하지 말고 시스템 정보에서 프로세서 유형을 확인한 다음 다운로드 페이지에서 알맞은 항목을 선택하세요.

Clash 생태계는 일반적으로 ‘코어’와 ‘GUI 클라이언트’의 두 계층으로 구성됩니다. 코어는 YAML 설정 읽기, 연결 수립, 규칙 실행과 프록시 포트 제공을 담당하며, GUI 클라이언트는 구독 관리, 모드 전환, 시스템 프록시와 로그 표시를 담당합니다. 일반 데스크톱과 모바일 기기에는 GUI 클라이언트를 우선 사용하고, 서버나 라우터 또는 서비스 형태로 운영해야 하는 Linux 환경에서만 Mihomo 코어를 직접 배포하는 편이 적합합니다. 이 사이트는 모든 플랫폼에서 Clash Plus를 우선 추천합니다. Windows와 macOS에서는 Clash Verge Rev, FlClash도 선택할 수 있고, Android에서는 Clash Meta for Android, FlClash 또는 Surfboard를 사용할 수 있습니다. Clash for Windows와 ClashX Meta는 유지보수가 중단되었으므로 기존 환경 이전 용도로만 적합하며 새로운 장기 설정에는 권장하지 않습니다.

구독 또는 로컬 YAML 설정 준비

클라이언트 설치만 마쳤다고 연결을 사용할 수 있는 것은 아니며 설정도 가져와야 합니다. 일반적으로 구독 URL이나 로컬 YAML 파일을 사용합니다. 구독 URL은 설정 제공자가 생성하며 클라이언트는 이 주소에서 노드, 정책 그룹과 규칙을 가져옵니다. 로컬 파일은 오프라인 편집, 규칙 실험 또는 통제된 환경에서 고정 설정을 보관할 때 적합합니다. 가져오기 전에 주소가 온전한지, 복사 과정에서 공백이나 줄바꿈 또는 한글 문장부호가 붙지 않았는지 확인하세요. 구독 URL은 민감한 설정이므로 공개 스크린샷, 포럼 게시물, 공개 브라우저 북마크나 공유 문서에 올리지 마세요.

처음 테스트할 때는 구조가 단순하고 이전에 정상적으로 불러온 설정 하나를 남겨 두는 것이 좋습니다. 복잡한 설정에는 프록시 제공자, 규칙 제공자, 스크립트, 스니핑, DNS 재정의와 다단계 정책 그룹이 포함될 수 있으며, 원격 리소스 하나만 연결되지 않아도 불러오기에 영향을 줄 수 있습니다. 먼저 기본 설정으로 클라이언트, 시스템 권한과 프록시 진입점을 확인한 다음 복잡한 규칙을 하나씩 추가하면 모든 기능을 한 번에 가져오는 것보다 문제를 찾기 쉽습니다. 구독을 업데이트하기 전에는 현재 정상 작동하는 설정 이름도 기억해 두세요. 새 설정의 구문 분석이 실패하면 네트워크가 끊긴 상태에서 계속 수정하지 않고 즉시 이전 설정으로 돌아갈 수 있습니다.

시스템 프록시와 TUN의 범위 이해

시스템 프록시는 일반적으로 운영체제에 HTTP 및 SOCKS 프록시 주소를 기록합니다. 시스템 프록시 설정을 따르는 브라우저와 앱은 요청을 Clash로 보내므로 설정이 간단하고 켜고 끄기 쉽지만, 일부 명령줄 도구, 게임, 스토어 앱이나 자체 네트워크 스택을 관리하는 프로그램은 이를 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 더 많은 TCP, UDP 트래픽과 시스템 프록시를 읽지 않는 프로그램을 규칙 처리 과정으로 보냅니다. 적용 범위가 넓은 대신 더 높은 권한이 필요하며 다른 VPN, 가상 네트워크 어댑터, 엔드포인트 보안 프로그램이나 기업 네트워크 정책과 충돌하기 쉽습니다.

점검 항목	시스템 프록시	TUN 모드	최초 설정 권장 사항
필요 권한	시스템 프록시 설정 쓰기	가상 인터페이스 또는 서비스 생성	시스템 프록시부터 확인
적용 대상 앱	프록시 설정을 따르는 프로그램	더 많은 시스템 트래픽과 UDP	앱 요구 사항에 따라 확대
주요 충돌 원인	브라우저 확장 프로그램, 수동 프록시	다른 VPN, 가상 네트워크 어댑터, 방화벽	진입점은 한 번에 하나만 사용

설치 기록과 기준 상태 만들기

설치 전에 다른 프록시나 VPN 도구를 잠시 종료하고, 시스템에서 자주 쓰는 사이트에 직접 접속할 수 있는지 기록하세요. 설치 후에는 TUN을 바로 켜지 말고 설정 가져오기, 규칙 모드 선택, 시스템 프록시 활성화까지만 진행한 뒤 일반 웹페이지에 접속하면서 로그를 확인합니다. 그러면 클라이언트 실행, 설정 구문 분석, 프록시 포트 수신 대기, 시스템 프록시 기록과 규칙 매칭 여부를 분명한 기준으로 만들 수 있습니다. 한 단계를 마친 뒤 다음 단계로 넘어가면 이상이 생겼을 때 한 구간으로 범위를 좁힐 수 있습니다. 회사 기기, 학교 네트워크나 관리형 기기에서는 서비스 설치, VPN 구성 추가와 네트워크 설정 변경이 제한될 수 있으므로 현재 계정에 필요한 권한이 있는지 미리 확인하세요.

WINDOWS / DESKTOP

Windows: 설치, 시스템 프록시와 TUN

Windows에서 확인할 핵심 변수는 설치 파일 아키텍처, 네트워크 권한, 남아 있는 시스템 프록시 설정과 가상 네트워크 어댑터 서비스입니다.

설치 파일 선택과 최초 실행

Windows에 새로 설치할 때는 Clash Plus를 우선 선택하고, 익숙한 인터페이스에 따라 Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 사용할 수도 있습니다. Clash for Windows는 유지보수가 중단되었으므로 기존 사용자는 설정을 내보내거나 기록한 뒤 현재 유지보수되는 클라이언트로 이전해야 합니다. ‘설정 → 시스템 → 정보’를 열어 시스템 종류가 x64인지 ARM64인지 확인하세요. 현재 다운로드 페이지에 제공되는 세부 아키텍처는 카드 설명을 기준으로 판단하고, macOS 및 Linux 압축 파일이나 Mihomo 코어 파일을 Windows GUI 클라이언트로 착각하지 마세요.

설치 프로그램을 실행하면 Windows에서 사용자 계정 컨트롤 확인 창이 표시될 수 있습니다. 일반 앱 폴더에 설치한 뒤 클라이언트를 실행하고, 먼저 기본 화면이 정상적으로 열리는지 확인한 다음 방화벽 요청을 처리하세요. 일반적으로 개인 네트워크 액세스만 허용해도 가정이나 사무실 LAN에서 사용하기에 충분합니다. 공용 네트워크 허용 여부는 현재 기기가 연결된 환경에 따라 결정해야 합니다. 두 번 클릭해도 창이 나타나지 않으면 작업 관리자에서 프로세스가 이미 실행 중인지 확인하고 시스템 트레이도 살펴보세요. 일부 클라이언트는 기본적으로 트레이에 최소화됩니다. 그래도 화면이 나타나지 않으면 여러 클라이언트를 반복 설치하지 말고 보안 정책이 앱을 차단했는지 확인하세요.

구독 가져오기와 정책 선택

클라이언트의 설정, 구독 또는 Profiles 페이지에서 가져오기 항목을 찾아 전체 구독 URL을 붙여 넣고 다운로드하세요. 정상적으로 가져오면 보통 설정 이름, 업데이트 시간이나 정책 그룹 목록이 나타납니다. 구독 기록만 있고 정책이 하나도 없다면 원격 콘텐츠를 다운로드하지 못했거나, 반환된 내용이 Clash YAML이 아니거나, 설정 구문 분석에 실패했을 수 있습니다. 이때 로그에서 HTTP 상태, YAML 줄 번호와 provider 오류를 확인하세요. 설정 계층의 문제는 가상 네트워크 어댑터와 무관하므로 TUN부터 켜지 마세요.

설정을 활성화한 뒤 프록시 또는 정책 페이지로 이동하세요. 규칙 모드는 설정의 rules를 위에서 아래로 매칭하므로 일상적인 사용에 적합합니다. 글로벌 모드는 연결을 지정한 정책으로 보내므로 특정 노드의 작동 여부를 잠시 확인할 때 유용합니다. 직접 연결 모드는 프록시를 끈 상태에서 로컬 네트워크가 정상인지 확인하는 데 사용합니다. 처음에는 규칙 모드를 선택한 다음 주요 정책 그룹에서 작동하는 노드 하나를 직접 선택해 보세요. 자동 정책 그룹은 상태 확인이 끝나야 결과를 선택합니다. 확인 주소에 접속할 수 없으면 모든 항목이 시간 초과로 표시될 수 있지만, 이것이 모든 실제 연결을 사용할 수 없다는 뜻은 아닙니다. 브라우저 접속과 연결 로그를 함께 확인해 판단하세요.

시스템 프록시 활성화와 포트 확인

‘시스템 프록시’를 켜면 클라이언트가 로컬 루프백 주소와 수신 포트를 Windows 프록시 설정에 기록합니다. 이때 시스템의 프록시 설정 페이지를 열면 스크립트나 수동 프록시 상태가 바뀐 것을 확인할 수 있습니다. 브라우저로 사이트에 접속한 뒤 클라이언트 연결 목록에서 대상 도메인, 규칙 이름과 최종 정책을 찾으세요. 브라우저는 접속되지만 명령줄 도구는 접속되지 않는다면 해당 도구가 Windows 시스템 프록시를 읽지 않는 경우가 많습니다. PowerShell에서는 현재 세션에 환경 변수를 직접 지정할 수 있습니다. 포트는 클라이언트 화면에 표시된 실제 mixed port로 바꾸세요.

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

테스트가 끝나면 터미널 창을 닫는 것만으로 현재 세션의 변수가 제거됩니다. 장기 설정이 필요하다면 먼저 해당 도구가 지원하는 변수 범위를 확인해 더 이상 사용하지 않는 로컬 포트가 시스템 환경에 남지 않게 하세요. netstat -ano 또는 PowerShell의 네트워크 연결 명령으로 해당 포트가 수신 대기 중인지 확인할 수도 있습니다. 포트가 사용 중이면 클라이언트 로그에 보통 bind 또는 address in use가 표시됩니다. 점유 프로세스를 찾거나 설정 파일과 클라이언트 설정에서 포트를 동일하게 변경해야 하며, 화면에서 한 곳만 바꿔 설정 파일이 이전 포트를 계속 선언하게 두면 안 됩니다.

TUN 활성화와 Windows 고유 충돌 해결

TUN을 사용하려면 일반적으로 서비스를 설치하거나 관리자 권한으로 실행해야 합니다. 먼저 다른 VPN, 게임 가속 프로그램과 이전 Clash 클라이언트를 종료한 뒤 클라이언트 안내에 따라 서비스를 설치하고 TUN을 켜세요. 정상적으로 활성화되면 네트워크 어댑터 목록에 해당 가상 인터페이스가 나타나며, 연결 로그에도 시스템 프록시를 읽지 않는 앱의 트래픽이 더 많이 기록됩니다. 활성화한 뒤 시스템 전체가 오프라인이 되면 TUN을 먼저 끄고 기본 네트워크가 복구되는지 확인하세요. 그런 다음 DNS 모드, 기본 경로, 서비스 상태와 방화벽을 점검합니다. 오프라인 상태에서 네트워크 초기화, 드라이버 삭제와 설정 변경을 동시에 진행하면 비교할 기준을 잃게 되므로 피해야 합니다.

Windows가 절전 모드에서 깨어나거나 유선에서 Wi-Fi로 전환하거나 기업 VPN에 연결되면 경로와 DNS가 바뀔 수 있습니다. 절전 해제 후 네트워크가 되지 않는다면 시스템 프록시, TUN, 클라이언트를 차례로 끈 다음 다시 실행해 하나씩 활성화하세요. 시스템 프록시 스위치를 껐는데도 접속할 수 없다면 Windows 프록시 페이지에서 주소가 남아 있는지 확인하고, 필요하면 WinHTTP 프록시도 점검하세요. 단, 브라우저 프록시와 WinHTTP를 같은 종류로 혼동하면 안 됩니다. 클라이언트를 관리자 권한으로 실행하는 것과 시스템 서비스를 설치하는 것도 서로 다릅니다. 전자는 현재 프로세스의 권한만 높이고, 후자는 백그라운드 구성 요소가 가상 인터페이스를 계속 관리할 수 있게 합니다. 클라이언트가 제공하는 서비스 설치 절차를 우선 사용하세요.

MACOS / NETWORK SERVICE

macOS: 칩 아키텍처, 시스템 확장과 네트워크 서비스

macOS에서는 칩 아키텍처를 정확히 구분하고 앱 격리, 네트워크 확장 권한과 네트워크 서비스별 프록시 설정을 확인해야 합니다.

Apple Silicon과 Intel 구분

Apple 메뉴에서 ‘이 Mac에 관하여’를 눌러 칩 또는 프로세서 항목을 확인하세요. Apple 계열 칩이 표시되면 Apple Silicon 또는 ARM 아키텍처 설치 파일을, Intel이 표시되면 x64 설치 파일을 선택합니다. 새로 설치할 때는 Clash Plus를 우선 사용하고 Clash Verge Rev 또는 FlClash도 선택할 수 있습니다. ClashX Meta는 유지보수가 중단되었으므로 기존 설정 이전 용도로만 남겨 두는 경우가 많으며 새 환경의 기본 선택으로는 적합하지 않습니다. 아키텍처를 잘못 선택하면 앱이 열리지 않거나 호환 계층을 통해 실행되면서 리소스를 추가로 사용할 수 있으므로 처음부터 맞는 파일을 선택하세요.

GUI 클라이언트는 디스크 이미지나 압축 파일 형태로 제공되는 경우가 많습니다. 이미지를 연 뒤 앱을 ‘응용 프로그램’ 폴더로 드래그하고 그 폴더에서 실행하세요. 다운로드 폴더나 읽기 전용 이미지에서 계속 실행하지 마세요. 처음 실행할 때 출처 확인 메시지가 표시되면 시스템 설정의 ‘개인정보 보호 및 보안’에서 차단된 앱을 확인하고, 파일이 이 사이트의 다운로드 경로에서 받은 것인지 확인한 뒤 시스템 승인 절차를 진행하세요. 앱 하나를 승인하기 위해 시스템 보안 기능 전체를 끄지 마세요. 정상적인 승인 절차만으로 설치를 완료할 수 있고 이후 네트워크 확장과 백그라운드 항목도 관리하기 쉽습니다.

설정 가져오기와 시스템 프록시 권한 승인

클라이언트를 실행한 뒤 Profiles, 설정 또는 구독 영역으로 이동해 구독 URL을 붙여 넣고 업데이트하세요. macOS에서 주소의 특수 문자가 자동 변환되는 경우 먼저 일반 텍스트 편집기에 붙여 넣어 한 줄 전체를 확인한 뒤 클라이언트에 복사하는 것이 좋습니다. 설정을 정상적으로 다운로드했다면 활성 설정으로 선택하고 정책 그룹을 열어 노드와 DIRECT, REJECT 등의 정책이 표시되는지 확인하세요. YAML 구문 분석 실패는 보통 로그에 들여쓰기나 필드 유형이 표시됩니다. 원격 provider 실패는 일부 규칙이나 노드 그룹에만 영향을 줄 수 있으므로 기본 설정 불러오기와 추가 리소스 업데이트를 구분해야 합니다.

시스템 프록시를 켤 때 macOS에서 네트워크 설정 변경을 허용하도록 현재 사용자 암호나 생체 인증을 요구할 수 있습니다. 권한을 승인하면 프록시는 일반적으로 현재 활성 네트워크 서비스인 Wi-Fi나 이더넷에 기록됩니다. 네트워크 서비스를 전환했는데 새 서비스에 프록시 설정이 없으면 클라이언트의 스위치는 켜진 것으로 보여도 앱 트래픽이 들어오지 않을 수 있습니다. 이때 시스템 프록시를 껐다가 다시 켜 현재 네트워크에 맞게 다시 기록하세요. ‘시스템 설정 → 네트워크 → 현재 네트워크 → 세부사항 → 프록시’에서 웹 프록시와 보안 웹 프록시가 로컬 루프백 주소를 가리키는지도 확인할 수 있습니다.

터미널 프로그램과 로컬 네트워크 접속

터미널의 curl, 패키지 관리자와 개발 도구는 GUI 시스템 프록시를 따르지 않을 수 있습니다. 한 번 실행할 명령에만 변수를 지정할 수 있으며 실제 포트는 클라이언트에 표시된 값을 사용하세요.

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 https_proxy

변수를 shell 설정 파일에 쓰기 전에 장기간 적용할 필요가 있는지 확인하세요. 노트북이 현재 네트워크를 벗어난 뒤 로컬 Clash가 실행되지 않으면 영구 프록시 변수 때문에 터미널 요청이 계속 비어 있는 포트로 향하게 됩니다. 프로젝트나 터미널 세션별로 활성화하는 편이 더 안전합니다. LAN 공유도 신중하게 설정해야 합니다. 다른 기기의 연결이 꼭 필요할 때만 Allow LAN을 켜고 수신 주소, 방화벽과 신뢰할 네트워크 범위를 함께 고려하세요. 평소 이 Mac에서만 사용한다면 루프백 주소에서만 수신해 불필요한 LAN 진입점을 줄일 수 있습니다.

TUN, 네트워크 확장과 절전 복귀

TUN을 켜면 클라이언트에서 보조 서비스 설치나 VPN 구성 추가를 요청할 수 있습니다. 시스템 설정에 해당 네트워크 확장이 표시되어야 하며 메뉴 막대에도 VPN 상태가 나타날 수 있습니다. 처음 승인한 뒤 스위치가 즉시 꺼진다면 개인정보 보호 및 보안 페이지에 아직 승인할 항목이 있는지 확인한 다음 클라이언트를 다시 실행하세요. 회사에서 관리하는 Mac은 구성 프로파일로 네트워크 확장이 제한될 수 있으며 일반 계정에서 직접 해제할 수 없습니다. 허용 범위는 기기 관리자에게 문의하세요.

macOS에서 iCloud 비공개 릴레이, 기업 VPN, 다른 프록시 앱이나 네트워크 필터 확장을 동시에 사용하면 트래픽 경로가 서로 덮어쓸 수 있습니다. 문제를 해결할 때는 네트워크를 제어하는 도구 하나만 남기고 다른 확장은 끈 다음 시스템 프록시 모드부터 확인하세요. 절전 해제 후 도메인은 해석되지 않지만 IP로는 연결된다면 DNS와 TUN 인터페이스가 다시 생성되었는지 중점적으로 확인합니다. 모든 연결이 로그에 나타나지 않는다면 네트워크 서비스 전환과 시스템 프록시 기록을 점검하세요. 클라이언트를 종료하기 전에 시스템 프록시와 TUN을 끄면 비정상 종료 후에도 시스템이 로컬 포트를 계속 가리키는 상황을 줄일 수 있습니다.

앱에 ‘연결됨’이 표시되는 것은 로컬 구성 요소가 실행 중이라는 뜻일 뿐, 대상 연결이 반드시 예상한 정책을 거친다는 뜻은 아닙니다. Connections 또는 로그에서 접속한 도메인을 찾아 적용된 규칙과 정책 그룹을 확인하세요. 브라우저에 별도 프록시 확장 프로그램이 설치되어 있다면 시스템 설정을 덮어쓸 수 있으므로 기준 테스트를 할 때 잠시 비활성화해야 합니다. 규칙과 정책 그룹 원리는 정책 그룹 유형 상세 설명도 함께 읽어 보세요. 자동 선택 그룹의 상태 확인 결과를 시스템 네트워크 전체의 결론으로 오해하지 않는 데 도움이 됩니다.

ANDROID / VPN SERVICE

Android: VPN 권한, 백그라운드 실행과 앱별 라우팅

Android 클라이언트는 시스템 VPN 인터페이스로 트래픽을 처리하며 안정성은 시스템 절전, 백그라운드 제한과 제조사별 네트워크 정책에도 영향을 받습니다.

설치와 최초 VPN 권한 승인

Android에 새로 설치할 때는 Clash Plus를 우선 선택하고 Clash Meta for Android, FlClash 또는 Surfboard도 사용할 수 있습니다. 다운로드 전에 시스템 정보에서 Android 버전과 프로세서 아키텍처를 확인하세요. 다운로드 페이지에서 ARM64, ARM과 범용 파일을 제공한다면 최근 출시된 대부분의 기기는 ARM64를 사용하지만 반드시 기기 정보를 기준으로 선택해야 합니다. 브라우저에서 설치 파일을 받으면 현재 브라우저나 파일 관리자에서 앱 설치를 허용하라는 요청이 나타날 수 있습니다. 설치가 끝나면 해당 출처의 권한을 다시 해제해 임시 설치 권한이 계속 열려 있지 않게 하세요.

처음 연결을 켜면 Android에서 VPN 연결 확인 창이 표시됩니다. 이는 로컬 가상 네트워크 인터페이스를 만드는 표준 시스템 절차입니다. 승인하면 상태 표시줄에 보통 VPN 아이콘이 나타납니다. 기기에서 다른 VPN, 회사 업무 프로필 VPN, 광고 차단 도구나 Private DNS 앱을 사용 중이라면 시스템에서 하나의 앱만 인터페이스를 제어하도록 허용할 수 있습니다. 이때는 어떤 도구가 주요 트래픽 진입점을 담당할지 먼저 정해야 합니다. 여러 VPN 앱이 반복해서 연결을 빼앗도록 두면 스위치가 자동으로 꺼지거나 네트워크가 잠시 중단되고 DNS 경로가 서로 달라질 수 있습니다.

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

설정 관리 페이지에서 URL 또는 파일로 가져오세요. 클립보드에서 구독 URL을 붙여 넣은 뒤 주소 시작 부분, 경로와 쿼리 매개변수가 온전한지 확인합니다. 일부 키보드는 줄 끝에 공백을 추가하고 일부 메신저는 긴 주소를 잘라 내므로 요청이 실패할 수 있습니다. 정상적으로 가져온 다음에는 새 설정을 직접 선택해 현재 활성 항목으로 지정해야 합니다. 구독을 목록에만 저장하고 활성화하지 않는 것은 ‘설정은 보이지만 노드는 없는’ 문제의 흔한 원인입니다. 구독 업데이트는 되도록 네트워크가 안정적이고 VPN을 잠시 끈 상태에서 진행하세요. 이전 설정의 규칙이 구독 요청을 작동하지 않는 정책으로 보낼 수 있습니다.

노드와 정책 그룹이 나타나면 먼저 규칙 모드와 명확한 정책 하나를 선택한 다음 VPN을 시작하세요. 웹페이지에 접속한 뒤 로그를 열어 도메인이 규칙에 매칭되는지 확인합니다. Android 앱은 QUIC, HTTP/3 또는 자체 DNS를 사용할 수 있어 데스크톱 브라우저와 다르게 작동할 수 있습니다. 특정 앱만 실패한다면 먼저 시스템 브라우저로 기준 상태를 만든 뒤 앱별 설정에서 제외되었는지, IPv6만 사용하는지, 자체 보안 DNS가 활성화되어 있는지 확인하세요.

백그라운드 실행과 배터리 정책

모바일에서 가장 흔한 문제는 설정 구문 분석이 아니라 화면이 잠긴 뒤 시스템에서 클라이언트를 제한하는 것입니다. 시스템 배터리 설정에서 현재 Clash 클라이언트의 백그라운드 실행을 허용하고 필요한 자동 시작이나 백그라운드 활동도 허용하세요. 제조사에 따라 메뉴 이름은 ‘배터리 최적화’, ‘백그라운드 사용 제한’, ‘자동 시작 관리’ 또는 ‘앱 실행 관리’일 수 있습니다. 최근 앱 화면에서 앱 카드를 잠그는 것만으로는 시스템 수준의 백그라운드 권한을 대신할 수 없습니다. 이는 일반적으로 수동 정리 가능성을 낮출 뿐입니다. 데이터 절약 모드에서 클라이언트의 모바일 데이터 사용을 제한하지 않는지도 확인하세요.

화면을 잠근 지 몇 분 뒤 연결이 끊기고 잠금을 해제하면 복구된다면 절전 정책과 백그라운드 제한부터 확인하세요. Wi-Fi에서는 정상이고 모바일 네트워크에서 실패한다면 모바일 데이터 권한, IPv6와 통신사 네트워크 환경을 점검합니다. 모든 네트워크에서 일정 시간이 지나면 연결이 끊긴다면 구독의 노드 가용성과 상태 확인을 살펴보세요. 모바일에서 VPN을 계속 사용하면 일정한 백그라운드 활동이 발생합니다. 규칙 수, DNS 요청, 잦은 상태 확인과 많은 연결은 모두 배터리 사용량에 영향을 줍니다. 모바일 배터리 과소모 문제 해결을 참고해 불필요한 반복 테스트를 줄이고 안정적인 정책을 유지하며 백그라운드 깨우기를 점검하면 정상적인 소모와 비정상 반복 작업을 구분할 수 있습니다.

앱별 프록시, 우회와 LAN

Android 클라이언트는 일반적으로 앱별 프록시 기능을 제공하며 ‘선택한 앱만 프록시’ 또는 ‘선택한 앱 제외’를 사용할 수 있습니다. 목록을 만들기 전에 목적부터 명확히 하세요. 소수 앱만 Clash로 보내려면 포함 모드를 사용하고, 대부분의 앱에 규칙을 적용하되 은행 앱이나 LAN 도구만 직접 연결해야 한다면 제외 모드를 사용합니다. 두 모드의 의미는 반대이므로 전환한 뒤 목록을 다시 확인해야 합니다. 앱을 업데이트하거나 재설치하면 내부 식별자가 바뀔 수 있으므로 특정 앱이 갑자기 우회된다면 목록에 다시 들어가 확인하세요.

프린터, TV나 라우터 관리 페이지 같은 LAN 기기에 접속할 수 없다면 먼저 설정에서 LAN 주소가 DIRECT를 사용하는지 확인하고, 클라이언트에 LAN 우회 옵션이 있는지도 점검하세요. 일반적인 사설 주소는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이지만 실제 네트워크에서는 IPv6 로컬 주소를 사용할 수도 있습니다. LAN 기기 하나에 접속하려고 글로벌 직접 연결로 전환한 뒤 원래대로 돌리는 것을 잊지 마세요. 로그에서 대상 주소를 찾아 명확한 규칙을 추가하거나 LAN 우회 설정을 조정해야 합니다.

‘VPN에 연결되었지만 인터넷이 안 됨’ 증상이 나타나면 먼저 연결을 중지하고 휴대전화의 기본 네트워크가 정상인지 확인하세요. 그다음 클라이언트를 실행하고 시스템 브라우저만 테스트합니다. 로그에 요청이 전혀 없다면 VPN 권한과 앱별 제외 설정을 확인하세요. 요청은 있지만 DNS 오류가 표시되면 DNS 설정과 Private DNS를 점검하고, 요청이 프록시에 매칭된 뒤 시간 초과된다면 정책과 노드를 확인합니다. 재설치로는 구독, 백그라운드 정책이나 충돌하는 VPN 앱이 자동으로 해결되지 않으므로 계층별 점검이 더 효과적입니다.

IOS / NETWORK EXTENSION

iOS: Clash Plus, VPN 구성과 시스템 제한

iOS는 시스템 네트워크 확장으로 연결을 관리하므로 설치 경로, VPN 권한, 온디맨드 연결과 시스템 네트워크 서비스가 주요 점검 항목입니다.

App Store에서 Clash Plus 설치

iPhone과 iPad에서는 이 사이트의 다운로드 페이지에 있는 Clash Plus App Store 링크를 사용하세요. 클라이언트 공식 사이트는 clashplus.io입니다. 스토어 페이지를 연 뒤 시스템 절차에 따라 설치하고 홈 화면에서 실행하세요. iOS에서는 프로세서 아키텍처를 선택하거나 데스크톱용 형식의 파일을 직접 설치할 필요가 없습니다. 스토어 페이지가 열리지 않는다면 클라이언트 문제로 판단하기 전에 Apple ID, 네트워크와 시스템 스토어 서비스가 정상인지 확인하세요.

처음 연결할 때 시스템에서 VPN 구성 추가를 요청하며 기기 암호, 생체 인증 또는 시스템 확인을 요구합니다. 승인한 뒤에는 ‘설정 → 일반 → VPN 및 기기 관리’나 현재 iOS 버전의 VPN 페이지에서 구성을 확인할 수 있습니다. 이 권한은 시스템이 Clash Plus의 네트워크 확장 생성을 허용한다는 뜻일 뿐 구독이 불러와졌거나 정책을 사용할 수 있다는 의미는 아닙니다. 승인을 거부해도 클라이언트가 열리고 설정 목록이 보일 수 있지만 실제 네트워크는 제어할 수 없습니다. 연결 스위치로 돌아가 시스템 확인을 다시 표시하세요.

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

Clash Plus에서 설정 관리를 열고 URL로 구독을 가져오세요. 주소 전체를 정확히 복사하고 공개된 곳에는 게시하지 마세요. 가져온 뒤 설정이 목록에 나타나는지 확인하고 활성 설정으로 직접 선택합니다. 구독 다운로드에 실패하면 Safari에서 현재 네트워크로 구독 도메인에 접속할 수 있는지 먼저 확인하되, 구독 내용 자체를 공개해서는 안 됩니다. 다운로드는 성공했지만 정책 그룹이 없다면 클라이언트의 오류 정보를 확인하세요. YAML 구문 분석 실패, 원격 리소스 가져오기 실패와 빈 설정을 구분하는 것이 중요합니다.

규칙 모드를 선택한 뒤 주요 정책 그룹에서 노드 하나를 지정하고 연결을 켜세요. 최초 테스트는 Safari로 일반 웹페이지에 접속한 다음 클라이언트의 연결 기록을 확인합니다. 연결 기록에 도메인, 규칙과 정책이 표시되면 네트워크 확장에 트래픽이 들어온 것입니다. 기록이 비어 있다면 VPN이 실제로 연결되었는지, 다른 네트워크 확장이 제어 중인지, 온디맨드 연결 규칙에서 현재 네트워크를 제외했는지 확인하세요. 일부 앱은 기존 연결을 유지하므로 정책을 전환한 뒤 앱을 완전히 종료하고 다시 열어야 새 경로로 연결됩니다.

온디맨드 연결, 셀룰러 네트워크와 로컬 네트워크

온디맨드 연결은 네트워크가 바뀌거나 앱에서 요청할 때 VPN을 자동으로 시작하며 안정성이 검증된 설정에 적합합니다. 처음 설치하는 단계에서는 스위치를 수동으로 조작해 설정, 정책과 DNS가 정상인지 확인한 뒤 자동 기능을 켜는 것이 좋습니다. 그렇지 않으면 연결 자동 재시도가 실제 오류를 가릴 수 있습니다. 화면에 계속 연결 중이라고 표시되어 설정 구문 분석, 노드 시간 초과, 시스템 확장 시작 실패 중 어느 것이 원인인지 판단하기 어렵습니다. 온디맨드 연결을 활성화한 뒤에는 Wi-Fi와 셀룰러 네트워크를 각각 테스트하세요. 두 네트워크는 IPv6, DNS와 접근 정책이 다를 수 있습니다.

Wi-Fi에서는 작동하지만 셀룰러 네트워크에서는 작동하지 않는다면 Clash Plus의 셀룰러 데이터 사용이 허용되어 있는지 확인하고 저데이터 모드가 백그라운드 활동을 제한하지 않는지도 점검하세요. 셀룰러에서는 작동하지만 특정 Wi-Fi에서 작동하지 않는다면 해당 네트워크에 로그인 페이지가 필요하거나 VPN이 제한되어 있거나, LAN DNS와 설정이 충돌할 수 있습니다. 공용 Wi-Fi에 연결할 때는 VPN을 끈 상태에서 웹 인증을 먼저 마친 뒤 Clash Plus를 실행하세요. 인증 페이지는 보통 로컬 네트워크에 있으므로 처음부터 프록시 규칙이 처리하면 페이지가 정상적으로 나타나지 않을 수 있습니다.

가정 내 기기에 접속할 때 iOS에서 ‘로컬 네트워크’ 권한을 요청할 수 있습니다. 프린터, 미디어 기기와 LAN 서비스를 검색하거나 연결해야 한다면 해당 권한을 허용하고 사설 주소가 DIRECT를 사용하도록 규칙을 확인하세요. LAN 접속이 필요하지 않다면 인터넷 연결 문제를 해결하기 위해 권한 범위를 넓힐 필요는 없습니다. 권한 상태는 시스템 개인정보 보호 설정에서 따로 확인할 수 있으며, 변경한 뒤 관련 앱을 다시 실행하면 새 상태에 맞춰 연결을 다시 만드는 데 도움이 됩니다.

시스템 네트워크 서비스 간 관계 정리

iOS에서는 iCloud 비공개 릴레이, IP 주소 추적 제한, 기업 콘텐츠 필터나 다른 VPN 구성이 동시에 활성화될 수 있습니다. 모두 DNS와 연결 경로에 영향을 줄 수 있습니다. 문제가 생기면 변수 하나만 남긴 환경을 만드세요. 다른 네트워크 확장을 잠시 끄고 Clash Plus만 남긴 뒤 수동 정책 하나로 테스트합니다. 기본 연결이 복구되면 다른 기능을 하나씩 켜면서 어느 단계에서 변화가 생기는지 확인하세요. 상태 표시줄의 VPN 아이콘만 보고 어느 앱이 제어하는지 판단하지 말고 시스템 VPN 페이지에서 현재 연결 이름을 확인해야 합니다.

비행기 모드에서 복귀하거나 Wi-Fi와 셀룰러 네트워크를 전환한 뒤, 또는 기기가 오랫동안 잠겨 있었다면 기존 연결을 다시 만들어야 할 수 있습니다. 먼저 Clash Plus에서 연결을 끊었다가 다시 연결하세요. 그래도 인터넷이 되지 않으면 VPN을 끄고 기본 네트워크를 확인한 다음 클라이언트를 다시 실행합니다. 로그에 DNS 시간 초과가 표시되지만 프록시 연결은 정상이라면 설정의 DNS 서버가 현재 네트워크에 적합한지 확인하세요. 대상 정책이 시간 초과된다면 수동 노드로 전환해 비교합니다. Safari는 정상인데 특정 앱만 실패한다면 전체 설정을 삭제하지 말고 앱의 연결 캐시, 시스템 지역 서비스, 앱별 규칙이나 앱 자체 네트워크 구현을 먼저 살펴보세요.

LINUX / GUI OR CORE

Linux: GUI 클라이언트와 Mihomo 서비스 배포

데스크톱 Linux에서는 Clash Verge Rev 또는 FlClash를 사용할 수 있으며, 서버와 라우터 환경에는 Mihomo 코어 직접 실행이 적합합니다.

데스크톱 환경에 맞는 설치 형식 선택

Linux GUI 클라이언트는 다운로드 페이지 순서에 따라 Clash Verge Rev 또는 FlClash를 선택하세요. 설치 전에 uname -m을 실행해 아키텍처를 확인합니다. 일반적인 출력인 x86_64은 AMD64, aarch64는 ARM64에 해당합니다. Debian, Ubuntu와 그 파생 배포판은 보통 deb 패키지를 사용하고 Fedora, RHEL 계열은 rpm을 사용할 수 있습니다. 다른 배포판은 다운로드 페이지의 형식과 프로젝트 안내에 따라 선택하세요. 서버용 Mihomo 압축 파일을 GUI 데스크톱 클라이언트로 착각하지 마세요. 두 종류는 실행 방법, 설정 디렉터리와 시스템 프록시 관리 방식이 다릅니다.

deb 패키지는 시스템 소프트웨어 센터에서 설치하거나 터미널에서 로컬 설치 명령을 실행할 수 있습니다. 파일명은 실제로 다운로드한 파일로 바꾸세요.

sudo apt install ./clash-client-amd64.deb
uname -m
systemctl --user status

패키지 관리자는 의존성도 함께 처리하므로 저수준 압축 해제 명령을 직접 사용하는 것보다 일반적인 설치에 적합합니다. 처음 실행하면 데스크톱 환경에서 키링, 백그라운드 실행이나 네트워크 권한을 요청할 수 있습니다. 설정 가져오기와 로컬 프록시 테스트를 먼저 마친 다음 TUN을 활성화하세요. GNOME, KDE와 기타 데스크톱 환경은 시스템 프록시 지원 수준이 다르며 터미널 프로그램도 보통 데스크톱 프록시를 자동으로 읽지 않습니다. 따라서 환경 변수나 앱 자체 설정으로 확인해야 합니다.

데스크톱 프록시와 터미널 환경

GUI 클라이언트에서 시스템 프록시를 켠 뒤 데스크톱 네트워크 설정의 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:7890"
curl -I https://example.com
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

변수명의 대소문자 지원 여부는 도구마다 다릅니다. 소문자 형식을 읽는 프로그램도 있고 대문자 형식을 읽는 프로그램도 있습니다. 앱 동작을 모르는 상태에서 서로 다른 포트의 변수를 여러 세트 지정하지 마세요. 요청이 예상과 다른 프로토콜을 거칠 수 있습니다. 패키지 관리자, 컨테이너 서비스와 systemd 서비스도 대화형 shell의 환경 변수를 반드시 상속하는 것은 아닙니다. 해당 서비스나 도구 설정에 별도로 선언하고 필요하지 않을 때 제거하세요.

Mihomo 코어 직접 실행

서버, 보조 라우터와 데스크톱 환경이 없는 호스트에서는 Mihomo를 실행할 수 있습니다. 별도 사용자와 설정 디렉터리를 준비하고 실행 파일은 관리되는 경로에, 설정은 YAML 파일로 저장하세요. 처음에는 테스트 설정으로 포그라운드에서 실행해 구문 분석 결과를 확인하고 곧바로 백그라운드에 숨기지 마세요. 아래에는 일반적인 명령 형식을 제시하며 경로는 시스템 디렉터리에 맞게 조정할 수 있습니다.

mkdir -p "$HOME/.config/mihomo"
cp config.yaml "$HOME/.config/mihomo/config.yaml"
chmod 600 "$HOME/.config/mihomo/config.yaml"
mihomo -d "$HOME/.config/mihomo"

포그라운드 로그에는 설정 구문 분석, 수신 포트, 규칙 제공자와 DNS 초기화 상태가 표시됩니다. 오류가 없는 것을 확인한 뒤 systemd 서비스를 만드세요. 서비스에는 작업 디렉터리, 설정 디렉터리와 실행 사용자를 명확히 지정해 불필요한 높은 권한으로 계속 실행하지 않게 해야 합니다. TUN이 필요하다면 서비스 계정에 네트워크 인터페이스 생성과 경로 변경에 필요한 권한이 있어야 합니다. 모든 작업을 단순히 root에 맡기지 말고 배포판의 보안 모델에 맞춰 권한을 설정하세요.

[Unit]
Description=Mihomo Network Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

방화벽, 수신 주소와 DNS

이 호스트에서만 사용한다면 mixed-port, 제어 포트와 API는 루프백 주소에서 수신하게 해야 합니다. LAN에 프록시를 제공해야 할 때만 Allow LAN을 켜고 방화벽에서 허용할 출발지 범위를 지정하세요. 액세스 제어 없이 제어 인터페이스가 모든 주소에서 수신하게 하면 관리 영역의 노출 범위가 커집니다. 서버에서는 프록시 인바운드 포트, DNS 수신 포트와 외부 서비스 포트도 구분해야 합니다. ss -lntup으로 실제 수신 상태를 확인하고 포트 충돌이 없는지 점검하세요.

Linux의 DNS는 systemd-resolved, NetworkManager, 데스크톱 서비스나 컨테이너 네트워크에서 함께 관리할 수 있습니다. TUN을 켠 뒤 도메인은 실패하지만 IP에는 접속된다면 먼저 resolvectl status와 클라이언트 로그를 확인해 쿼리가 어느 DNS로 들어가는지 파악하세요. /etc/resolv.conf를 반복해서 덮어쓰는 방법은 네트워크 관리자가 파일을 다시 생성하므로 대개 잠시만 적용됩니다. DNS 담당 계층을 명확히 정하는 것이 올바른 방법입니다. Mihomo에서 가로채 처리하거나 시스템 리졸버가 처리한 뒤 규칙으로 보내되, 두 서비스가 같은 주소에서 동시에 수신하지 않게 하세요.

코어를 업그레이드하거나 설정을 교체할 때는 먼저 설정 테스트를 실행하고 현재 실행 가능한 파일을 보관하세요. 서비스 시작에 실패하면 journalctl -u mihomo로 로그를 확인하고 YAML 구문 분석, 권한, 디렉터리, 포트와 네트워크 권한을 중점적으로 점검합니다. 라우터 배포에는 포워딩, 정책 기반 라우팅과 LAN DNS가 관련됩니다. 먼저 Mihomo 라우터 배포 개요를 읽고 메인 라우터, 보조 라우터와 코어 직접 실행 방식의 트래픽 진입점을 파악한 뒤 운영 네트워크를 수정하세요.

CONFIG / RULE FLOW

공통 설정: 포트, 모드, DNS와 규칙 확인

플랫폼마다 화면은 다르지만 코어의 처리 과정은 같습니다. 트래픽이 수신 진입점으로 들어오면 도메인 해석과 규칙 매칭을 거쳐 정책 그룹의 실제 출구로 전달됩니다.

최소 설정 구조 이해

작동하는 설정에는 최소한 프록시 진입점, 실행 모드, 프록시 노드 또는 제공자, 정책 그룹과 규칙이 명확히 정의되어야 합니다. GUI 클라이언트는 일부 설정을 자체 데이터베이스에 저장할 수 있으므로 화면의 포트, TUN과 DNS 재정의가 구독 YAML에 모두 나타나지는 않을 수 있습니다. 문제를 해결할 때는 ‘현재 적용 중인 설정’의 출처부터 확인하세요. 구독 원문인지, 클라이언트 재정의인지, 병합 스크립트가 생성한 최종 설정인지 파악해야 합니다. 로컬로 다운로드한 원본 파일만 보면 실제 동작을 설명하지 못할 수 있습니다.

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

proxies:
  - name: example-proxy
    type: socks5
    server: 192.0.2.10
    port: 1080

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

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

예시의 주소는 문서 설명용이므로 실제 서비스에 그대로 사용할 수 없습니다. mixed-port는 HTTP와 SOCKS 연결을 모두 받아 데스크톱 앱을 설정하기 편리하며, mode: rule은 규칙에 따라 출구를 결정합니다. allow-lan: false는 이 기기에서만 사용한다는 뜻입니다. 규칙은 위에서 아래로 매칭되고 처음 일치하면 멈추므로 구체적인 도메인과 LAN 규칙은 마지막 MATCH보다 앞에 두어야 합니다. 수정 후에도 클라이언트가 이전 결과를 사용한다면 설정을 다시 불러오고 새 연결로 테스트하세요. 기존 장기 연결은 즉시 새 경로로 이동하지 않을 수 있습니다.

정책 그룹은 노드 목록의 다른 이름이 아닙니다

select 그룹은 사용자가 직접 선택하고, url-test는 상태 확인 결과에 따라 선택하며, fallback은 순서대로 첫 번째 사용 가능 항목을 사용합니다. load-balance는 여러 출구에 연결을 분산합니다. 자동 그룹에 표시되는 지연 시간은 특정 시점에 지정된 확인 요청으로 측정한 결과일 뿐 웹페이지, 다운로드나 영상의 전체 체감 품질과 같지 않습니다. 확인 주소에 접속할 수 없거나 노드에서 확인 요청을 제한하거나 기기의 백그라운드 활동이 제한되면 상태 확인 결과가 부정확해질 수 있습니다. Clash 지연 시간 테스트 원리를 참고해 수치 범위를 판단하고 중요한 작업 전에는 실제 접속 결과로 확인하세요.

정책 그룹은 서로 참조할 수도 있습니다. 예를 들어 ‘앱 정책’이 ‘자동 선택’을 가리키고 ‘자동 선택’이 다시 여러 노드를 포함할 수 있습니다. 로그에 최종 매칭된 그룹 이름만 표시된다면 그룹 내부에서 현재 선택된 항목도 확인해야 합니다. 상위 그룹을 바꿔도 변화가 없다면 하위 그룹에서 여전히 같은 노드를 선택하고 있을 수 있습니다. 자동 그룹이 자주 바뀐다면 확인 간격이 너무 짧거나 허용 편차가 너무 작거나 네트워크 변동이 원인일 수 있습니다. 설정의 목표는 모든 트래픽을 최대한 많은 자동 선택 계층에 통과시키는 것이 아니라 설명 가능하고 안정적인 경로를 만드는 것입니다.

DNS 모드와 도메인 해석 경로

DNS는 도메인이 먼저 어떤 주소로 해석될지 결정하며 도메인 기반 규칙의 정확한 매칭에도 영향을 줍니다. 시스템 프록시 모드에서는 일부 앱이 도메인을 프록시에 맡기고 다른 앱은 로컬에서 먼저 해석합니다. TUN 모드에서는 DNS 가로채기를 사용해 쿼리를 코어로 모을 수도 있습니다. 일반적인 fake-ip 모드는 도메인에 예약 주소를 할당하고 코어 내부에 매핑을 저장하므로 도메인 복원과 규칙 매칭이 쉽습니다. redir-host는 실제 주소를 먼저 얻은 뒤 처리하는 방식에 가깝습니다. LAN 서비스, 게임 플랫폼, 기기 검색과 일부 보안 프로그램은 fake-ip에 민감할 수 있습니다. DNS 기능 전체를 끄지 말고 필터 목록을 사용해 특정 도메인만 실제 주소로 해석하세요.

DNS 문제는 증상에 따라 판단해야 합니다. 도메인 접속은 실패하지만 IP로 직접 접속할 수 있다면 해석 계층을 중점적으로 확인하세요. 로그에 DNS 요청이 없다면 다른 앱이나 시스템 서비스가 쿼리를 처리했을 수 있습니다. 정상 주소가 반환되지만 연결이 시간 초과된다면 문제는 경로나 출구 계층으로 넘어간 것입니다. 암호화 DNS를 사용할 때는 해당 서버의 도메인을 어떻게 해석하는지도 고려해 ‘프록시에 필요한 DNS를 해석하려면 프록시가 필요한’ 순환 구조를 피해야 합니다. 현재 네트워크와 호환되는 기본 해석 경로를 최소 하나 남겨 두고 로그에서 쿼리의 실제 경로를 확인하는 것이 좋습니다.

로그로 반복 가능한 검증 수행

규칙을 확인할 때는 대상 도메인 하나를 정하고 로그를 지우거나 현재 위치를 기억한 뒤 새로 접속하세요. 출발 앱, 대상 도메인 또는 주소, 매칭된 규칙, 정책 그룹과 최종 노드를 기록합니다. 아무 기록도 없다면 트래픽이 Clash에 들어오지 않은 것이므로 시스템 프록시, VPN/TUN과 앱 자체 설정을 확인하세요. DIRECT에 매칭되었지만 프록시를 예상했다면 규칙 순서, 도메인 형식과 규칙 제공자 로드 여부를 점검합니다. 올바른 정책에 매칭되었는데 연결이 실패한다면 노드, DNS, IPv6와 대상 서비스를 확인하세요.

증상	우선 확인 항목	다음 단계
로그에 대상 요청이 없음	시스템 프록시, VPN, TUN, 앱별 설정	트래픽 진입점 확인
예상과 다른 규칙에 매칭	규칙 순서, 도메인, provider 상태	더 구체적인 규칙으로 재확인
올바르게 매칭되지만 시간 초과	정책 그룹의 현재 항목, 노드와 DNS	수동 노드로 전환해 비교
일부 앱만 실패	앱의 프록시 지원, QUIC, IPv6	시스템 브라우저와 비교

일상적으로는 로그 수준을 info로 유지하면 됩니다. 단기 문제를 분석할 때 상세도를 높일 수 있지만 완료 후에는 원래대로 돌려 장기간 많은 기록이 생성되지 않게 하세요. 로그를 공유하기 전에 구독 URL, 인증 정보, 노드 주소와 개인 도메인을 제거해야 합니다. 설정은 ‘DNS가 실패 원인인지 확인’처럼 명확한 목적에 따라 변경해야 하며 노드, 규칙과 네트워크 모드를 동시에 바꾸면 안 됩니다. 한 번에 변수 하나, 테스트 요청 하나만 사용하는 것이 이 매뉴얼에서 가장 중요한 실험 방법입니다.

DIAGNOSE / RECOVERY

설정 관련 자주 발생하는 문제와 계층별 해결

문제를 기본 네트워크, 클라이언트 프로세스, 설정 불러오기, 트래픽 진입점, 규칙·정책, 대상 연결의 여섯 계층으로 나누면 불필요한 재설치를 줄일 수 있습니다.

클라이언트 실행 후 인터넷이 전혀 되지 않음

첫 단계로 시스템 프록시와 TUN 또는 모바일 VPN을 끄고 기기의 기본 네트워크가 복구되는지 확인하세요. 껐는데도 접속할 수 없다면 시스템 프록시 설정이 남아 있거나 DNS가 복구되지 않았거나 네트워크 자체가 끊겼거나 다른 VPN이 실행 중일 수 있습니다. 데스크톱에서는 시스템 프록시 페이지가 여전히 127.0.0.1의 이전 포트를 가리키는지 확인하세요. 모바일에서는 상태 표시줄과 시스템 VPN 페이지를 확인하고, Linux에서는 환경 변수, 경로와 리졸버를 점검합니다. 기본 네트워크가 복구된 뒤에만 Clash를 다시 실행해 확인하세요.

두 번째 단계에서는 클라이언트만 실행하고 시스템 트래픽은 제어하지 않은 상태에서 설정을 정상적으로 불러오는지, 프록시 포트가 수신 대기 중인지 확인하세요. 세 번째 단계에서 시스템 프록시 또는 VPN을 켜고 시스템 브라우저로 대상에 접속하면서 로그를 확인합니다. 로그가 비어 있다면 진입점 문제이고, 로그는 있지만 DNS 오류가 있다면 도메인 해석을 점검해야 합니다. 정책 매칭 후 시간 초과가 발생한다면 수동 노드로 전환하세요. 이 세 단계로 ‘인터넷이 안 됨’이라는 모호한 결과를 명확한 계층으로 나눌 수 있습니다. 질문과 답변 형식으로 정리된 해결 방법은 자주 묻는 질문 페이지에서 더 확인할 수 있습니다.

구독 업데이트 실패 또는 가져온 뒤 노드가 없음

먼저 구독 URL 전체를 정확히 복사했는지, 현재 기본 네트워크에서 구독 서비스에 접속할 수 있는지 확인하세요. 클라이언트가 이전 설정을 사용 중이면 구독 업데이트 요청이 이전 규칙에 따라 작동하지 않는 노드로 전송될 수 있으므로 프록시 연결을 잠시 끊고 다시 시도합니다. HTTP 오류는 원격 요청에서 예상한 콘텐츠를 받지 못했다는 뜻이고, YAML 구문 분석 오류는 콘텐츠는 다운로드했지만 형식이나 필드가 설정 요구 사항과 맞지 않는다는 뜻입니다. provider 오류는 원격 노드 그룹이나 규칙 집합에만 영향을 줄 수 있습니다. 세 오류는 해결 방향이 다르므로 모두 ‘클라이언트 고장’으로 처리하면 안 됩니다.

가져온 뒤 노드가 없다면 해당 설정이 활성 항목으로 선택되었는지 확인하고 프록시 그룹이 비어 있는지 살펴보세요. 일부 구독은 기본 조각만 반환하므로 클라이언트에서 특정 처리 방식을 지원해야 합니다. 브라우저에서 열었을 때 YAML이 아니라 로그인 페이지나 안내 문구를 반환하는 주소도 있습니다. 웹페이지의 오류 내용을 설정 파일로 저장해 반복해서 가져오지 마세요. 이전 설정을 계속 사용할 수 있다면 복구 경로로 남겨 두고 설정 제공자에게 구독 상태를 문의하세요. 모든 설정을 자주 삭제하면 정상 작동하는 기준 상태까지 사라져 문제 해결이 더 어려워집니다.

시스템 프록시는 작동하지만 TUN이 시작되지 않음

시스템 프록시가 작동한다면 설정, 노드와 기본 규칙은 대체로 정상이며 문제 범위를 권한, 서비스, 가상 인터페이스, 경로나 DNS로 좁힐 수 있습니다. Windows에서는 클라이언트 서비스가 설치되었는지, 가상 네트워크 어댑터가 생성되었는지, 보안 프로그램이 차단하는지 확인하세요. macOS에서는 네트워크 확장과 VPN 구성 권한을, Linux에서는 실행 사용자의 네트워크 권한, 커널 모듈, 방화벽과 정책 기반 라우팅을 점검합니다. 모바일의 시스템 VPN은 자체가 주요 트래픽 진입점이므로 다른 VPN이 연결을 빼앗는지도 확인해야 합니다.

TUN을 켜자마자 인터넷이 끊기면 먼저 TUN을 꺼 시스템 프록시 기준 상태로 복구한 뒤 시작 단계의 첫 번째 오류를 확인하세요. 일반적인 원인에는 기본 경로가 생성되지 않음, DNS 수신 포트 충돌, 엄격한 라우팅과 로컬 네트워크의 비호환, IPv6 경로 이상이나 다른 가상 인터페이스의 높은 우선순위가 있습니다. TUN을 반드시 켜야 하는 성능 옵션으로 생각하지 마세요. 필요한 앱이 모두 시스템 프록시를 따른다면 시스템 프록시 모드만으로도 라우팅 규칙을 적용할 수 있습니다. 프록시 설정을 읽지 않는 프로그램, UDP 또는 더 넓은 트래픽을 꼭 제어해야 할 때만 TUN 권한과 호환성 문제를 해결하세요.

노드 지연 시간은 정상인데 웹페이지가 느림

지연 시간 테스트는 보통 짧은 요청이며 DNS, 연결 수립과 테스트 대상 중 일부만 측정합니다. 실제 웹페이지 속도에는 회선 혼잡, 패킷 손실, TLS 연결, 대상 사이트 위치, 동시 리소스와 전송 속도도 영향을 줍니다. 노드를 선택할 때 숫자 하나만 비교하지 말고 여러 차례 테스트한 안정성과 실제 사용 결과를 함께 확인하세요. 자동 정책 그룹이 자주 전환되면 장기 연결도 끊길 수 있습니다. 순간 최저 수치를 좇기보다 적절한 허용 편차와 확인 간격을 설정하는 것이 중요합니다.

특정 사이트만 느리다면 적용된 규칙과 정책을 확인해 부적절한 그룹에 배정되었는지 살펴보세요. 모든 사이트가 느리다면 DIRECT와 수동 노드를 각각 테스트해 로컬 네트워크와 프록시 출구를 구분합니다. 브라우저는 정상인데 영상이나 다운로드만 느리다면 앱의 UDP, QUIC 또는 다중 연결 전송 사용도 고려해야 합니다. 로그에 반복 재시도, DNS 시간 초과나 정책 전환이 많이 나타나면 클라이언트를 바꾸기 전에 이런 명확한 신호부터 해결하세요.

설정 변경 사항이 적용되지 않음

먼저 구독 캐시, 복사본이나 선택되지 않은 파일이 아니라 현재 활성 설정을 편집했는지 확인하세요. 구독 업데이트로 로컬 직접 수정 내용이 덮어써질 수 있으므로 장기적인 사용자 설정에는 클라이언트가 지원하는 재정의, 병합 또는 스크립트 기능을 사용해야 합니다. YAML을 저장한 뒤 다시 불러오고 로그에 구문 오류가 있는지 확인하세요. YAML은 들여쓰기에 민감하며 목록 항목, 콜론 뒤의 공백과 문자열 유형도 구문 분석에 영향을 줍니다. 규칙 이름은 정책 그룹 이름과 완전히 일치해야 하며 대소문자나 문자 차이가 있으면 불러오기에 실패합니다.

그다음 새 연결을 만드세요. 브라우저에서 이미 열린 페이지, 메신저의 장기 연결과 다운로드 작업은 이전 경로를 계속 사용할 수 있습니다. 모드를 바꿔도 기존 연결이 모두 자동으로 다시 만들어지지는 않습니다. 관련 앱을 종료하거나 연결이 끝난 뒤 다시 테스트하세요. DNS 캐시에도 이전 결과가 남을 수 있으므로 먼저 접속한 적 없는 도메인으로 확인한 다음 시스템 캐시를 지울 필요가 있는지 결정합니다. 변경 사항이 적용되었다는 근거는 스위치 위치가 아니라 로그에 나타난 새 규칙과 새 정책이어야 합니다.

작동하는 최소 상태로 복구

변경 사항이 너무 많아 판단하기 어렵다면 정해진 순서로 복구하세요. TUN과 시스템 프록시를 끄고 다른 네트워크 도구를 종료한 뒤 기본 네트워크를 확인합니다. Clash를 실행해 이전에 성공했던 단순한 설정을 불러오고 정책 하나를 수동으로 선택하세요. 시스템 프록시 또는 모바일 VPN을 켠 다음 시스템 브라우저에서 새 요청을 보내고 로그를 확인합니다. 기준 상태가 정상이라면 DNS 사용자 설정, 규칙 제공자, 자동 정책 그룹, 앱별 라우팅과 TUN을 순서대로 추가하세요. 항목 하나를 추가할 때마다 확인 결과를 남겨야 합니다.

그래도 재설치가 필요하다면 클라이언트 이름, 시스템 아키텍처, 설정 출처, 오류 문구와 이미 시도한 절차를 먼저 기록하세요. 제거하기 전에 시스템 프록시, TUN과 백그라운드 서비스를 꺼 시스템이 삭제된 로컬 포트를 계속 참조하지 않게 합니다. 재설치 후에는 이전 설정 전체를 바로 가져오지 말고 최소 설정부터 확인하세요. 최초 설치의 전체 점검 목록은 Clash 최초 설치 설정 방법도 참고할 수 있습니다. 이 복구 방식의 목적은 복잡한 기능을 피하는 것이 아니라 관찰할 수 있을 만큼 변수 수를 줄인 뒤 신뢰할 수 있는 환경을 하나씩 다시 만드는 것입니다.