Clash Meta 전체 플랫폼 설치·설정 완벽 가이드

CHAPTER 01 / PREPARATION

공통 준비: 클라이언트·구독·권한 범위

먼저 클라이언트, 코어, 구독을 구분하세요

Clash Meta의 실제 작동 흐름은 세 부분으로 나뉩니다. mihomo는 프로토콜 연결, 규칙 매칭, DNS 처리와 트래픽 전달을 담당하는 코어입니다. Clash Plus, Clash Verge Rev, FlClash 등은 코어를 관리하는 그래픽 클라이언트입니다. 구독은 서비스 제공자가 생성한 원격 설정으로, 보통 프록시 노드, 정책 그룹과 기본 규칙을 포함합니다. 클라이언트를 설치했다고 바로 사용할 수 있는 회선이 생기는 것은 아닙니다. 구독 링크도 설치 파일이 아니므로 두 가지를 각각 확보한 뒤 클라이언트에서 함께 구성해야 합니다.

클라이언트를 고를 때는 먼저 운영체제와 프로세서 아키텍처를 확인하세요. Windows의 일반적인 기기는 x64 설치 파일을 사용하며, ARM 프로세서 기기는 해당 빌드를 제공하는지 확인해야 합니다. macOS는 Intel과 Apple Silicon을 구분해야 합니다. Android 설치 파일은 arm64, arm 또는 범용 아키텍처로 나뉠 수 있습니다. 최신 기기는 보통 arm64를 사용하지만, 확인하기 어렵다면 다운로드 페이지에서 클라이언트가 제공하는 범용 빌드를 선택하세요. Linux는 배포판 패키지 형식, CPU 아키텍처, 데스크톱 환경 유무까지 확인해야 합니다.

그래픽 클라이언트는 일상적인 데스크톱과 모바일 환경에 적합합니다. mihomo 코어를 직접 사용하는 방식은 서버, 라우터, 컨테이너 또는 서비스 관리 스크립트를 직접 작성해야 하는 환경에 더 알맞습니다. 두 방식은 핵심 설정 의미가 비슷하지만, 그래픽 클라이언트는 시스템 프록시, TUN, 설정 오버라이드와 구독 업데이트를 별도 스위치로 제공할 수 있습니다. 문제를 해결할 때는 원인이 인터페이스 계층인지, 코어 계층인지, 상위 구독인지 먼저 구분해야 합니다. 실제 원인을 건드리지 않은 채 반복해서 재설치하는 일을 피할 수 있습니다.

가져오기 전에 구독 응답 내용을 확인하세요

구독 링크는 서비스 제공자의 관리 페이지에서 복사하고, 채팅창에서 줄바꿈된 주소를 임의로 잘라 사용하지 마세요. 링크에는 접근 인증 정보가 포함되는 경우가 많으므로 비공개 자료로 취급해야 하며, 공개 스크린샷이나 코드 저장소, 공유 문서에 넣지 마세요. 가져오기에 실패하면 먼저 시스템 브라우저에서 링크에 직접 접속해 보세요. YAML 텍스트가 표시되거나 설정 파일 다운로드가 시작되면 최소한 주소에는 접근할 수 있다는 뜻입니다. 로그인 페이지, 만료 안내, 접근 거부 또는 빈 응답이 표시되면 먼저 구독 측 문제를 해결해야 합니다.

같은 서비스가 Clash YAML, 범용 공유 링크와 다른 클라이언트 형식을 동시에 제공할 수 있습니다. mihomo 클라이언트에는 일반적으로 Clash 또는 mihomo 호환 설정이 필요합니다. 형식을 잘못 선택하면 클라이언트가 파싱 실패를 표시할 수 있고, 가져온 뒤 노드만 있고 정책 그룹은 없을 수도 있습니다. 형식을 바꾸기 전에 아직 사용할 수 있는 기존 설정을 삭제하지 마세요. 새 설정에 다른 이름을 지정해 노드 그룹, 규칙과 DNS 항목이 완전한지 확인한 다음 교체 여부를 결정하세요.

되돌릴 수 있는 설정 기준선 만들기

처음 실행한 뒤에는 기본 포트와 기본 작동 모드를 유지하고, 설정 하나만 가져온 다음 프록시 노드 하나를 선택해 브라우저 연결을 테스트하세요. 이 순서를 따르면 기준선을 만들 수 있습니다. 기본 상태에서 연결이 되었다면 이후 문제는 TUN, 오버라이드 규칙, DNS 또는 여러 설정의 동시 활성화에서 발생했을 가능성이 높습니다. 첫 테스트부터 시스템 프록시, TUN, LAN 공유와 사용자 지정 DNS를 모두 켜지 마세요. 문제가 생겼을 때 어느 계층에서 트래픽 경로가 바뀌었는지 판단하기 어려워집니다.

시스템 프록시와 TUN은 같은 진입점이 아닙니다. 시스템 프록시는 일반적으로 운영체제의 프록시 설정을 따르는 앱에만 영향을 주며, 흔히 HTTP 또는 SOCKS 포트를 사용합니다. TUN은 가상 네트워크 인터페이스를 만들어 시스템 프록시를 읽지 않는 프로그램까지 더 폭넓게 연결을 인계할 수 있습니다. 모바일 운영체제의 VPN 스위치는 보통 TUN과 비슷한 역할을 합니다. 두 방식은 서로 다른 상황에 사용할 수 있지만, 일반적인 데스크톱 브라우징은 먼저 시스템 프록시를 사용하고 게임, 명령줄 도구 또는 동작이 다른 앱에서 TUN을 고려하는 것이 좋습니다.

대상	주요 역할	우선 확인할 항목
그래픽 클라이언트	설정, 코어, 시스템 프록시와 인터페이스 상태 관리	시스템 아키텍처, 권한, 현재 설정
mihomo 코어	프로토콜 연결, 규칙, DNS와 트래픽 전달 실행	설정 문법, 수신 포트, 실행 로그
구독 설정	노드, 정책 그룹과 규칙 제공	링크 접근성, 형식, 업데이트 시간
시스템 네트워크 진입점	앱 트래픽을 클라이언트로 전달	시스템 프록시, VPN/TUN, 기타 네트워크 도구

CHAPTER 02 / WINDOWS

Windows: 설치·시스템 프록시·TUN 인계

설치 및 첫 실행

Windows 사용자는 Windows 다운로드 영역에서 Clash Plus를 선택하거나, 인터페이스 선호에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 사용할 수 있습니다. Clash for Windows는 유지 관리가 중단되었으며 보관용 선택지로만 안내합니다. 다운로드 전에 “설정 → 시스템 → 시스템 정보”에서 시스템 종류를 확인하세요. 일반적인 Intel 및 AMD PC는 보통 x64 빌드를 선택합니다. 설치 버전과 포터블 버전은 데이터 폴더 위치가 다를 수 있으므로 설정을 장기간 보존하려면 설치 후 포터블 폴더를 임의로 옮기지 마세요.

처음 실행할 때 Windows 보안 센터나 방화벽 확인 창이 나타나면 사용 범위에 맞게 권한을 부여하세요. 이 PC에서만 사용할 경우 프록시 기능을 위해 공용 네트워크 접근을 허용할 필요는 없습니다. LAN 기기가 이 PC의 포트에 연결해야 할 때만 해당 사설 네트워크 접근을 허용하는 것을 고려하세요. 클라이언트 창을 닫은 뒤에도 트레이에서 계속 실행될지는 설정에 따라 다릅니다. 실행 여부는 창이 사라졌는지가 아니라 작업 표시줄의 트레이 아이콘이나 작업 관리자를 확인해야 합니다.

설치 프로그램이 폴더에 파일을 쓸 수 없다면 먼저 다운로드 파일이 로컬에 완전히 저장되었는지 확인한 뒤, 사용자에게 쓰기 권한이 있는 위치에서 실행해 보세요. 관리자 권한은 드라이버 설치, 서비스 등록 또는 TUN 인터페이스 생성에 주로 필요합니다. 모든 문제의 기본 해결책으로 “항상 관리자 권한으로 실행”을 사용해서는 안 됩니다. 일반적인 시스템 프록시 모드에는 지속적인 관리자 권한이 필요하지 않으며, 과도한 권한은 프로그램과 브라우저의 실행 경계를 오히려 바꿀 수 있습니다.

구독 가져오기 및 설정 적용 확인

클라이언트의 설정, 구독 또는 Profiles 페이지에서 “URL에서 가져오기” 항목을 찾아 구독 주소를 붙여 넣고 알아보기 쉬운 이름을 지정하세요. 가져오기가 완료되면 해당 설정을 명시적으로 선택해야 합니다. 목록에 설정이 표시된다고 해서 이미 로드된 것은 아닙니다. 그런 다음 프록시 또는 Proxies 페이지에서 정책 그룹이 하나 이상 있는지 확인하고, 최종 출구 정책 그룹에서 노드를 선택하세요. 노드 목록만 있고 선택 그룹이 없다면 구독 형식이 완전하지 않거나 클라이언트가 올바른 설정을 로드하지 못했을 수 있습니다.

선택을 마친 뒤 먼저 시스템 프록시를 켜세요. Windows 시스템 프록시 설정에는 로컬 루프백 주소를 가리키는 프록시 서버가 표시되어야 하며, 포트는 클라이언트가 현재 수신 중인 값과 같아야 합니다. 구독 서버 주소를 Windows 시스템 프록시에 직접 입력하지 마세요. 시스템 프록시의 대상은 로컬 클라이언트이고, 클라이언트가 설정에 따라 원격 서버에 연결합니다. 테스트할 때는 새 브라우저 창을 열어 이전 경로의 연결 재사용을 피하세요. 클라이언트를 종료한 뒤 웹페이지에 접속할 수 없다면 시스템 프록시가 비정상적으로 남아 있는지 확인하세요.

포트에 자주 사용되는 필드는 port, socks-port, mixed-port입니다. 그래픽 클라이언트는 보통 mixed 포트를 사용해 HTTP와 SOCKS 요청을 함께 받습니다. 다른 프로그램이 포트를 사용 중이면 로그에 수신 실패가 기록됩니다. 클라이언트가 실행 중으로 표시되더라도 연결을 처리하지 못할 수 있습니다. 이때는 먼저 같은 종류의 프록시 프로그램을 종료하고 사용되지 않는 로컬 포트로 바꾼 다음, 시스템 프록시 대상이 자동으로 업데이트되었는지도 확인하세요.

TUN은 언제 켜야 하나요?

일부 게임 플랫폼, 명령줄 프로그램, 스토어 앱 또는 자체 네트워크 스택을 사용하는 소프트웨어는 Windows 시스템 프록시를 읽지 않습니다. 브라우저는 정상인데 특정 프로그램이 계속 직접 연결된다면 TUN을 활성화할 수 있습니다. 처음 켤 때는 가상 네트워크 어댑터나 서비스를 설치해야 할 수 있으므로 클라이언트가 명시적으로 요청하는 시스템 권한을 허용하세요. 활성화한 뒤에는 인터페이스가 성공적으로 생성되었는지 클라이언트 로그와 시스템 라우팅 테이블의 해당 경로로 확인해야 하며, 인터페이스 스위치 색상만 보아서는 안 됩니다.

TUN은 다른 VPN, 가상 머신 네트워크 어댑터, 네트워크 가속기와 기업 보안 소프트웨어와 함께 라우팅을 변경할 수 있습니다. 테스트할 때는 트래픽을 인계하는 도구를 하나만 남기고, 기본 연결을 확인한 뒤 하나씩 다시 활성화하세요. TUN을 켠 뒤 LAN 공유, 프린터 또는 회사 인트라넷이 작동하지 않으면 규칙에서 사설 주소를 DIRECT로 유지하는지 확인하고, 우회 목록에 실제 사용하는 내부 네트워크 대역이 포함되어 있는지 점검하세요. TUN을 끈 뒤에는 인터페이스와 기존 연결이 해제될 때까지 기다렸다가 다시 테스트해야 합니다.

netsh winhttp show proxy
ipconfig /flushdns
netstat -ano | findstr LISTENING

CHAPTER 03 / MACOS

macOS: 아키텍처 선택·네트워크 서비스·시스템 확장

Apple Silicon 또는 Intel 빌드 선택

macOS에서 다운로드하기 전에 “이 Mac에 관하여”를 열어 칩 정보를 확인하세요. Apple 칩으로 표시되면 Apple Silicon 또는 arm64 빌드를 선택하고, Intel 프로세서로 표시되면 x64 빌드를 선택합니다. macOS 다운로드 영역에서는 Clash Plus를 우선 선택할 수 있으며, Clash Verge Rev와 FlClash도 사용할 수 있습니다. ClashX Meta는 유지 관리가 중단되었으므로 기존 설정을 당분간 유지해야 하는 환경에 적합합니다. 아키텍처를 잘못 고르면 앱이 실행되지 않거나 변환 계층을 통해 실행되어 동작 차이가 생길 수 있습니다.

다운로드한 앱을 “응용 프로그램” 폴더로 이동한 뒤 해당 폴더에서 실행하세요. 다운로드 이미지나 임시 폴더에서 직접 실행하면 업데이트, 데이터 폴더와 권한 상태가 불안정해질 수 있습니다. 시스템이 인터넷에서 받은 앱을 처음 열 때 보안 확인 창을 표시하면, 파일 출처가 이 사이트의 다운로드 경로가 안내하는 해당 클라이언트인지 확인하세요. 시스템이 실행을 차단하면 “시스템 설정 → 개인정보 보호 및 보안”에서 차단 기록을 확인하고 시스템이 제공하는 명확한 경로를 통해 승인하세요.

클라이언트 데이터 폴더는 보통 사용자 라이브러리 영역에 있으며, 앱 본체를 삭제해도 구독과 설정이 함께 삭제되지는 않습니다. 클라이언트를 바꾸기 전 구독 출처, 현재 정책과 사용자 지정 오버라이드를 기록한 뒤 기존 클라이언트를 종료하세요. 두 클라이언트가 동시에 시스템 프록시를 설정하지 않도록 해야 합니다. 나중에 실행된 프로그램이 프록시 포트를 덮어쓸 수 있고, 종료할 때 이미 작동하지 않는 다른 값으로 복원할 수도 있습니다.

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

macOS의 시스템 프록시는 네트워크 서비스별로 저장되므로 Wi-Fi, 유선 네트워크와 기타 인터페이스가 각각 설정을 유지할 수 있습니다. 클라이언트에서 시스템 프록시를 켜면 현재 서비스에 웹 프록시, 보안 웹 프록시와 SOCKS 프록시가 설정되는 경우가 많습니다. Wi-Fi에서 유선 연결로 전환한 뒤 상태가 이상하면 새 네트워크 서비스도 클라이언트가 인계했는지 확인하세요. 기업 네트워크의 자동 프록시 구성 파일이 수동 프록시와 함께 존재할 수도 있으므로 어느 설정을 적용할지 먼저 명확히 해야 합니다.

시스템 네트워크 세부 정보에서 프록시 상태를 확인하거나 명령으로 현재 설정을 읽을 수 있습니다. 프록시 서버는 127.0.0.1 또는 로컬 루프백 주소여야 하며, 포트는 클라이언트와 같아야 합니다. 클라이언트를 종료한 뒤 네트워크가 끊기면 클라이언트를 다시 열어 시스템 프록시를 끄거나 시스템 설정에서 남은 항목을 정리하세요. 앱만 삭제하고 시스템 프록시를 복구하지 않으면 브라우저가 더 이상 수신하는 프로그램이 없는 로컬 포트로 계속 요청을 보낼 수 있습니다.

scutil --proxy
networksetup -listallnetworkservices
lsof -nP -iTCP -sTCP:LISTEN

터미널의 curl, 패키지 관리자와 개발 도구가 그래픽 시스템 프록시를 완전히 따르지 않을 수 있습니다. 임시 테스트가 필요하면 현재 터미널 세션에만 프록시 환경 변수를 설정하고 테스트가 끝난 뒤 삭제하세요. 포트는 클라이언트의 실제 mixed 포트로 바꿔야 하며, 예시 값을 고정값으로 간주하지 마세요.

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

TUN·시스템 확장·로컬 네트워크

시스템 프록시를 읽지 않는 앱까지 인계해야 한다면 클라이언트에서 TUN을 활성화할 수 있습니다. macOS에서는 관리자 인증 정보 입력, 네트워크 확장 허용 또는 VPN 구성 추가가 필요할 수 있습니다. 권한은 시스템 팝업에 표시된 대상별로 필요한 항목만 확인하세요. 이전에 거부했다면 개인정보 보호 및 보안, 네트워크 확장 또는 VPN 설정에서 다시 확인할 수 있습니다. 스위치는 켜졌지만 인터페이스 생성에 실패하면 로그에 권한, 서비스 또는 라우팅 오류가 기록되는 경우가 많습니다.

macOS에서 기업 VPN, 컨테이너 네트워크와 가상 머신 소프트웨어를 동시에 실행하면 여러 가상 인터페이스가 기본 경로 또는 DNS를 두고 경쟁할 수 있습니다. 다른 네트워크 인계 도구를 먼저 끄고 Clash만 실행했을 때의 결과를 확인한 뒤 필요한 소프트웨어를 다시 켜세요. 회사 인트라넷이 지정 DNS나 검색 도메인에 의존한다면 TUN의 DNS 인계가 해석 경로를 바꿀 수 있습니다. 내부 도메인과 네트워크 대역을 DIRECT 규칙에 추가하고, 해당 조회가 내부 이름을 해석할 수 있는 서버를 사용하도록 하세요.

LAN 접근에 문제가 생겼다고 모든 사설 주소를 프록시로 보내지는 마세요. 가정용 라우터, 프린터, 파일 공유와 개발 장비는 보통 직접 연결해야 합니다. 설정의 allow-lan은 다른 기기가 이 컴퓨터의 프록시 포트에 연결할 수 있는지를 제어하며, 이 컴퓨터가 LAN에 접근할 수 있는지를 결정하지는 않습니다. LAN의 직접 연결 여부는 주로 규칙과 라우팅이 함께 결정합니다. 프록시를 공유해야 할 때만 LAN 수신을 켜고, 시스템 방화벽으로 네트워크 범위를 제한하세요.

CHAPTER 04 / ANDROID

Android: 앱 설치·VPN 인계·백그라운드 실행

설치 및 구독 가져오기

Android에서는 Android 다운로드 영역에서 Clash Plus를 우선 선택하거나 Clash Meta for Android, FlClash, Surfboard를 사용할 수 있습니다. 다운로드 패키지가 아키텍처별로 나뉜다면 최신 주류 기기는 보통 arm64를 사용하고, 구형 기기는 arm 빌드가 필요할 수 있습니다. 아키텍처를 확인하기 어렵다면 클라이언트가 제공하는 범용 패키지를 우선 선택하세요. 설치 시스템에서 브라우저나 파일 관리자가 앱을 설치하도록 허용해야 할 경우, 이번에 사용할 출처에만 권한을 부여하고 설치 후 필요에 따라 끄세요.

처음 실행한 뒤 설정 페이지에서 URL에서 가져오기를 선택하고 구독 링크를 붙여 넣어 파싱이 끝날 때까지 기다리세요. 모바일 네트워크는 첫 요청 중 잠시 전환될 수 있으므로 가져오기에 실패하면 Wi-Fi와 모바일 데이터에서 각각 테스트해야 합니다. 설정 다운로드가 성공해도 활성 설정으로 지정한 뒤 프록시 그룹에서 노드를 선택해야 합니다. 설정 이름만 보인다고 VPN이 연결된 것은 아닙니다. 상태 표시줄에 VPN 아이콘이 나타나고 클라이언트 로그가 연결을 처리하기 시작해야 실제 트래픽 인계가 이루어진 것입니다.

QR 코드로 가져올 때는 QR 코드의 내용이 단일 노드 공유 링크가 아니라 실제 구독 주소인지 확인하세요. 단일 노드 링크는 클라이언트가 인식할 수 있지만 일반적으로 전체 규칙과 정책 그룹을 포함하지 않습니다. 스캔에는 카메라 권한이 필요하고, 앨범에서 인식하려면 사진 접근 권한이 필요합니다. 이러한 권한을 제공하고 싶지 않다면 URL을 직접 복사하는 편이 더 명확합니다. 가져온 뒤에는 구독 QR 코드가 포함된 임시 스크린샷을 삭제해 사진 동기화에 오래 남지 않도록 하세요.

Android VPN과 앱별 트래픽 분류

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 인계합니다. 처음 연결할 때 시스템 VPN 권한 창이 표시되며, 승인해야 클라이언트가 인터페이스를 만들 수 있습니다. 시스템에서는 일반적으로 한 번에 하나의 일반 VPN만 활성화할 수 있으므로 다른 VPN, 필터링 도구 또는 로컬 VPN 인터페이스를 사용하는 방화벽은 연결이 끊깁니다. 연결 버튼이 계속 중지 상태로 돌아가면 다른 앱이 VPN 권한을 계속 사용하려는지 먼저 확인하세요.

일부 클라이언트는 앱별 프록시 또는 우회 목록을 제공합니다. 규칙 모드는 도메인, IP와 규칙 집합에 따라 출구를 선택하는 기능이고, 앱별 분류는 어떤 앱이 VPN에 들어갈지를 정하는 기능입니다. 두 기능은 서로 다른 계층에 있습니다. 특정 앱을 우회하도록 설정하면 해당 연결은 mihomo로 들어가지 않으므로 이후 도메인 규칙으로 처리할 수 없습니다. 특정 앱이 작동하지 않을 때는 먼저 앱별 분류 목록을 확인하고, 다음으로 규칙 매칭을 살펴본 뒤, 선택한 노드가 해당 앱의 프로토콜과 네트워크 환경을 지원하는지 확인하세요.

LAN 기기 검색, 화면 공유와 인쇄는 멀티캐스트 또는 로컬 네트워크 대역에 의존하므로 VPN 인계 후 시스템 제한의 영향을 받을 수 있습니다. 먼저 사설 주소가 DIRECT를 사용하는지 확인하고, 클라이언트가 지원한다면 LAN 접근을 허용하세요. 규칙이 올바르더라도 일부 앱은 Android VPN 상태에 따라 검색 동작을 바꿀 수 있습니다. 이때 VPN을 일시적으로 끊고 비교 테스트해 규칙 오류인지 앱 자체의 가상 네트워크 제한인지 구분하세요.

백그라운드·배터리 절약·네트워크 전환

Android 제조사의 배터리 절약 정책은 화면이 꺼진 뒤 클라이언트 백그라운드 프로세스를 종료할 수 있습니다. 연결 직후에는 작동하지만 잠시 화면을 잠그면 VPN 아이콘이 사라지거나 네트워크가 직접 연결로 돌아가는 것이 일반적인 증상입니다. 시스템 앱 설정에서 백그라운드 활동을 허용하고 배터리 정책을 제한 없음 또는 이에 준하는 옵션으로 바꾸세요. 시스템 기능에 따라 최근 앱에서 클라이언트를 잠글 수도 있습니다. 설정 이름은 시스템마다 다르지만, 화면이 꺼지거나 네트워크가 전환된 뒤에도 VPN 서비스가 유지되는지가 판단 기준입니다.

Wi-Fi에서 모바일 데이터로 전환하면 기존 TCP 연결은 이전 네트워크 경로를 그대로 사용할 수 없으므로 잠시 끊기는 것은 정상적인 재연결 과정입니다. 오랫동안 복구되지 않으면 비행기 모드를 반복해서 전환하지 말고 클라이언트에서 다시 연결하세요. “VPN 항상 사용”을 켜면 시스템이 VPN을 거치지 않은 연결 차단도 함께 활성화할 수 있습니다. 클라이언트가 정상적으로 시작되지 않으면 모든 네트워크가 차단될 수 있으므로, 이런 시스템 정책을 켜기 전에 재부팅 후 클라이언트가 안정적으로 자동 시작되는지 확인하세요.

모바일에서 DNS 문제는 일부 앱이 IP로는 접속되지만 도메인은 실패하거나, 같은 사이트의 결과가 Wi-Fi와 모바일 데이터에서 다르게 나타나는 방식으로 드러납니다. 먼저 비공개 DNS와 브라우저 보안 DNS 등 추가 변수를 끄고 비교한 뒤 클라이언트의 DNS 모드를 확인하세요. 충돌 원인을 확인한 다음 어느 계층을 유지할지 결정해야 합니다. 시스템 비공개 DNS, 앱 내부 DNS와 여러 필터링 도구가 모두 조회를 동시에 바꾸도록 장기간 중첩해서는 안 됩니다.

CHAPTER 05 / IOS

iOS: Clash Plus·VPN 구성·주문형 연결

설치 및 설정 진입점

iPhone과 iPad에서는 iOS 다운로드 영역에서 Clash Plus App Store 페이지로 이동할 수 있으며, 클라이언트 관련 정보는 공식 웹사이트 clashplus.io에서도 확인할 수 있습니다. 설치가 끝나면 먼저 시스템 설정에서 기기 날짜, 네트워크와 App Store 로그인 상태가 정상인지 확인하세요. iOS의 네트워크 인계는 시스템 VPN 프레임워크가 관리하므로 클라이언트가 시스템 승인 없이 다른 앱의 연결을 직접 변경할 수는 없습니다.

Clash Plus를 연 뒤 설정 페이지에서 구독 가져오기를 선택하고 서비스 제공자가 제공한 Clash 호환 링크를 붙여 넣으세요. 클립보드에서 링크를 입력하면 시스템이 붙여넣기 허용 여부를 물을 수 있습니다. 거부한 경우 입력란으로 다시 들어가 직접 붙여 넣을 수 있습니다. 가져온 뒤 정책 그룹과 노드가 나타나는지 확인하고 해당 설정을 현재 설정으로 지정하세요. 구독 목록의 업데이트 시간은 최근 요청 결과만 나타내며 노드 연결성이 검증되었다는 뜻은 아닙니다.

처음 연결할 때 iOS는 VPN 구성을 추가하도록 요청하며 기기 잠금 암호나 생체 인증으로 확인해야 합니다. 이 과정은 시스템에서 처리되고, 완료되면 상태 표시줄이나 제어 센터에서 VPN 상태를 확인할 수 있습니다. 시스템 설정에 다른 VPN이 이미 있으면 Clash Plus를 시작할 때 현재 구성이 전환되는 경우가 많습니다. 기업 관리 기기는 관리 정책에 따라 새 VPN 추가가 제한될 수 있으며, 이런 제한은 기기 관리자에게 처리해야 합니다. 앱을 반복해서 재설치해도 시스템 정책은 바뀌지 않습니다.

규칙 모드·정책 그룹·주문형 연결

일상적인 사용에서는 먼저 규칙 모드를 유지하는 것이 좋습니다. 규칙 모드는 설정의 도메인, IP, 규칙 집합과 최종 MATCH 규칙에 따라 DIRECT 또는 프록시 정책을 결정합니다. 전역 모드는 연결을 하나의 프록시 그룹으로 집중시키므로 노드를 임시로 검증할 때 적합하지만, 모든 문제를 영구적으로 우회하는 방법으로는 적절하지 않습니다. 규칙 모드에서 특정 사이트에 문제가 있지만 전역 모드에서는 정상이라면 연결 로그에서 해당 연결의 매칭 규칙을 확인해야 하며, 단순히 노드가 고장 났다고 판단해서는 안 됩니다.

정책 그룹에는 자동 선택, 장애 조치, 수동 선택과 직접 연결이 포함될 수 있습니다. 자동 선택 결과는 구독이 정의한 테스트 주소와 간격에 따라 달라지며, 언제나 모든 업무에 적합하다는 뜻은 아닙니다. 안정성이 중요하다면 수동 그룹에서 노드 하나를 고정해 자동 전환 변수를 제거하세요. 연결이 안정적임을 확인한 뒤 자동 정책으로 돌아가면 됩니다. 노드 전환은 새로 생성되는 연결에만 영향을 주며 기존 세션은 이전 경로를 계속 사용할 수 있으므로, 테스트할 때 대상 앱을 완전히 종료한 뒤 다시 여세요.

주문형 연결은 특정 네트워크 조건에서 VPN을 자동으로 활성화할 수 있지만, 규칙 범위가 너무 넓으면 집에 돌아오거나 회사에 들어갈 때, 또는 셀룰러 네트워크로 전환할 때 계속 재연결될 수 있습니다. 처음 설정할 때는 수동 연결을 사용하고 구독과 규칙이 안정적인지 확인한 뒤 신뢰할 수 있는 Wi-Fi, 셀룰러 네트워크 등의 조건에 따라 주문형 정책을 구성하세요. 설정 후에는 화면 잠금, 잠금 해제, 비행기 모드 복구와 네트워크 전환을 실제로 테스트해야 하며 스위치 상태만으로 판단해서는 안 됩니다.

iOS의 DNS와 LAN 권한

iOS는 앱의 로컬 네트워크 접근을 제한합니다. NAS, 화면 공유 기기 또는 LAN 제어 페이지에 접근해야 한다면 시스템 개인정보 설정에서 클라이언트 또는 관련 앱의 로컬 네트워크 사용을 허용하고, 설정에서 사설 주소가 DIRECT를 사용하도록 해야 합니다. 클라이언트에 권한이 있다고 해서 다른 앱의 권한까지 자동으로 부여되는 것은 아닙니다. 실제 접근 여부는 대상 앱과 시스템 네트워크 정책에도 달려 있습니다.

fake-ip 모드에서는 DNS가 반환한 주소를 코어가 도메인에 매핑한 뒤 규칙에 따라 처리합니다. 대부분의 일반 웹페이지에는 적합하지만 LAN 검색, 특수 도메인 해석 또는 IP를 직접 검증하는 앱은 fake-ip 필터에 추가해야 할 수 있습니다. 필터링은 해당 도메인이 실제 해석 결과를 받는다는 뜻이지 자동으로 직접 연결된다는 뜻은 아닙니다. 최종 출구는 여전히 rules가 결정합니다. 수정 후에는 설정을 다시 로드하고 새 연결을 만들어야 하며, 기존 DNS 캐시는 설정 문자가 바뀌었다고 즉시 사라지지 않습니다.

연결은 정상으로 표시되지만 웹페이지가 열리지 않으면 먼저 Safari에서 일반 HTTP 페이지를 열어 호텔, 공항 또는 학교 네트워크의 인증 페이지가 있는지 확인하세요. 인증을 완료하기 전에는 VPN이 유효한 외부 연결을 만들지 못할 수 있습니다. 인증 후 연결을 다시 시작하고 로그에서 DNS 시간 초과, 라우팅 실패 또는 노드 핸드셰이크 오류를 확인하세요. 셀룰러 네트워크는 정상인데 특정 Wi-Fi만 실패한다면 곧바로 구독을 바꾸기보다 해당 네트워크의 인증, DNS와 IPv6 조건을 먼저 처리하세요.

CHAPTER 06 / LINUX

Linux: 데스크톱 클라이언트·mihomo 서비스·환경 변수

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

데스크톱 환경이 있는 Linux 사용자는 Linux 다운로드 영역에서 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 다운로드 전에 uname -m으로 아키텍처를 확인하세요. 일반적인 데스크톱 컴퓨터는 대부분 x86_64이고 ARM 기기는 aarch64로 표시될 수 있습니다. 배포판의 패키지 형식도 확인해야 합니다. Debian과 Ubuntu 계열은 보통 deb를 사용하며, 다른 배포판은 명확히 지원되는 형식을 선택하거나 기기에 맞는 설치 방법을 사용하세요.

그래픽 클라이언트를 실행한 뒤 구독 가져오기, 정책 그룹 선택과 시스템 프록시의 작동 방식은 다른 데스크톱 플랫폼과 비슷합니다. 주요 차이는 데스크톱 환경에 있습니다. GNOME, KDE와 경량 창 관리자는 시스템 프록시 구현이 서로 다르고, 일부 명령줄 프로그램은 데스크톱 프록시를 완전히 무시합니다. 먼저 클라이언트에서 mixed 포트가 수신 중인지 확인한 다음 브라우저, 터미널과 프록시가 필요한 앱을 각각 테스트하세요. 특정 브라우저 하나의 결과를 시스템 전체의 결과로 간주하지 마세요.

패키지를 설치한 뒤 앱이 실행되지 않으면 터미널에서 프로그램을 실행해 누락된 의존성, 권한 또는 그래픽 세션 관련 오류를 확인할 수 있습니다. Wayland와 X11에서는 트레이 아이콘, 창 배율과 자동 시작 동작이 다를 수 있지만 이런 인터페이스 문제는 코어 실행에 영향을 주지 않을 수도 있습니다. 수신 포트, 프로세스 목록과 로그로 프록시 서비스가 작동하는지 확인한 뒤 데스크톱 통합 문제를 별도로 처리하세요.

mihomo 코어 직접 실행

서버, 라우터 또는 데스크톱 환경이 없는 시스템에서는 보통 mihomo를 직접 실행합니다. 다운로드 페이지의 코어 영역은 아키텍처별 빌드를 제공하므로 반드시 uname -m 결과에 맞게 선택하세요. 설정 파일은 권한이 제한된 폴더에 저장해야 합니다. 구독을 펼친 뒤 인증 정보가 포함될 수 있기 때문입니다. 처음에는 포그라운드에서 설정을 로드해 문법 검사, 포트 수신과 규칙 로드가 성공하는지 확인한 다음 systemd 서비스를 작성하세요. 첫 오류를 보지 못한 채 서비스가 반복 재시작하는 상황을 피할 수 있습니다.

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

ss -lntp
journalctl --user -u mihomo --no-pager -n 100

systemd 사용자 서비스를 사용할 때는 작업 디렉터리, 실행 파일 경로와 설정 디렉터리를 모두 절대 경로로 작성해야 합니다. 서비스 계정에는 설정을 읽고 캐시 디렉터리에 쓸 권한이 있어야 합니다. 낮은 번호의 포트에 바인딩하거나 라우팅을 변경하거나 TUN을 생성해야 한다면 시스템 서비스를 사용하고 필요한 권한만 명시적으로 부여하세요. 권한 설정을 생략하려고 관련 없는 디렉터리를 모든 사용자가 계속 쓸 수 있게 두어서는 안 됩니다.

[Unit]
Description=mihomo proxy core
After=network-online.target

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

[Install]
WantedBy=multi-user.target

터미널 프록시·TUN·방화벽

명령줄 도구를 연결하는 가장 명확한 방법은 현재 세션에 환경 변수를 설정하는 것입니다. HTTP 도구는 보통 http_proxy와 https_proxy를 읽고, SOCKS가 필요하면 도구의 지원 여부에 따라 all_proxy를 사용할 수 있습니다. 환경 변수의 대소문자 구분 방식은 프로그램마다 다르므로 스크립트에서는 필요한 형식을 명시적으로 설정하는 편이 좋습니다. 프록시 변수를 모든 시스템 서비스의 전역 환경에 영구적으로 넣지 마세요. 소프트웨어 업데이트, 내부 네트워크 접근과 로컬 관리 작업까지 의도치 않게 프록시를 거칠 수 있습니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890

curl -I https://example.com
env | grep -i proxy

Linux TUN은 커널 TUN 장치, 라우팅 권한과 방화벽 규칙이 함께 필요합니다. 컨테이너 환경에서는 /dev/net/tun과 네트워크 관리 권한을 열어야 할 수도 있습니다. 활성화하기 전에 현재 기본 경로, 정책 라우팅과 DNS 설정을 기록해 두면 문제 발생 시 되돌릴 수 있습니다. nftables, iptables, firewalld 또는 배포판 네트워크 관리자를 사용할 때는 여러 도구가 같은 전달 규칙을 동시에 관리하지 않도록 하세요.

서버에서 allow-lan을 켜거나 모든 주소에서 수신하도록 설정하면 프록시 포트가 네트워크 인터페이스에 노출됩니다. 다른 기기의 접속이 명확히 필요할 때만 이렇게 설정하고, 호스트 방화벽으로 출발지 주소를 제한하세요. 로컬 프록시로만 사용할 때는 127.0.0.1에서 수신하면 됩니다. 포트를 확인할 때는 수신 주소도 함께 보세요. 포트가 존재한다고 접근 범위가 올바른 것은 아닙니다. 루프백 주소 수신과 모든 인터페이스 수신은 경계가 완전히 다릅니다.

DNS를 systemd-resolved, NetworkManager, 컨테이너 런타임 또는 수동 resolv.conf가 관리하면 TUN 인계 결과가 서로 덮어써질 수 있습니다. 먼저 resolvectl status에서 각 인터페이스의 DNS를 확인한 뒤 조회가 mihomo로 들어가는지 판단하세요. 컨테이너 안에서만 해석이 실패한다면 호스트, 컨테이너 DNS와 전달 규칙을 각각 점검해야 하며 호스트 브라우저의 프록시 설정만 바꿔서는 안 됩니다.

CHAPTER 07 / CONFIGURATION

공통 설정: 포트·DNS·규칙·구독 업데이트

읽기 쉬운 최소 설정과 수신 범위

그래픽 클라이언트는 보통 구독에서 설정을 생성하므로 사용자가 YAML을 처음부터 작성할 필요는 없습니다. 하지만 주요 필드를 이해하면 인터페이스 스위치가 실제로 무엇을 바꾸는지 판단하는 데 도움이 됩니다. 아래 예시는 로컬 mixed 포트, 규칙 모드, 로그 수준, 제어 인터페이스와 DNS의 기본 관계를 보여 줍니다. 완전한 구독 설정이 아니므로 proxies와 proxy-groups가 없으면 사용할 수 있는 회선이 자동으로 생기지 않습니다. 실제 사용에서는 구독이 노드를 제공해야 하며, 구조를 유지한 채 오버라이드해야 합니다.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-port는 HTTP와 SOCKS 연결을 동시에 받아 데스크톱 시스템 프록시와 명령줄 도구가 하나의 진입점을 함께 사용할 수 있게 합니다. allow-lan: false를 루프백 바인딩과 함께 사용하면 로컬 접근만 허용됩니다. 같은 LAN의 휴대폰이나 다른 기기가 이 포트를 사용해야 한다면 수신 주소, 방화벽과 접근 규칙을 모두 조정해야 합니다. 스위치 하나만 바꾸면 여전히 연결되지 않을 수도 있고, 반대로 노출 범위가 의도치 않게 커질 수도 있습니다.

external-controller는 관리 인터페이스이며 일반 프록시 포트가 아닙니다. 그래픽 클라이언트가 이를 통해 연결 정보를 읽고 정책을 전환할 수 있습니다. LAN에 직접 노출할 때는 인증을 설정하고 접근 출처를 제한해야 하며, 로컬 클라이언트는 루프백에서 수신하도록 유지해야 합니다. 포트가 충돌하더라도 제어 인터페이스를 함부로 삭제하지 마세요. 인터페이스가 코어와 통신하지 못할 수 있습니다. 먼저 충돌한 포트가 mixed, DNS 또는 controller 중 무엇인지 판단하세요.

DNS 모드와 fake-ip 필터

DNS는 도메인을 어떻게 해석할지 결정하고 도메인 규칙에 필요한 식별 정보도 제공합니다. fake-ip 모드는 먼저 예약 주소를 반환한 뒤 코어가 연결을 원래 도메인에 매핑하므로, 앱이 IP 연결만 시작하더라도 도메인 규칙 정보를 유지할 수 있습니다. redir-host는 전통적인 해석 흐름에 더 가깝고 일부 특수 프로그램과의 호환성이 직접적일 수 있지만 도메인 매핑과 캐시 동작은 다릅니다. 모드 선택은 “속도”라는 추상적인 기준보다 실제 앱 동작을 바탕으로 판단해야 합니다.

LAN 도메인, 연결성 확인 도메인, 시간 동기화와 반환 주소에 특별한 요구가 있는 일부 앱은 fake-ip-filter에 추가해야 할 수 있습니다. 필터링은 해당 도메인이 실제 해석 결과를 받는다는 뜻이지 자동으로 직접 연결된다는 뜻은 아닙니다. 최종 출구는 여전히 rules가 결정합니다. 수정 후에는 시스템 DNS 캐시를 지우고 설정을 다시 로드한 뒤 연결을 재생성하세요. 웹페이지만 새로 고치면 브라우저 내부 캐시가 계속 사용되어 설정이 적용되지 않은 것처럼 보일 수 있습니다.

시스템 암호화 DNS, 브라우저 자체 DNS와 클라이언트 DNS를 동시에 사용하면 조회가 예상한 진입점을 우회할 수 있습니다. 문제 해결 단계에서는 추가 계층을 잠시 끄고 mihomo DNS만 남긴 뒤 로그에서 도메인과 규칙 매칭이 보이는지 확인하세요. 기본 경로가 정상임을 확인한 다음 필요한 보안 DNS 설정을 하나씩 다시 활성화하세요. 누출 점검과 설정 검증은 Clash DNS 누출 검사 및 누출 방지 설정 실전 가이드에서 계속 확인할 수 있습니다.

규칙 순서와 정책 그룹

규칙은 위에서 아래 순서로 매칭되며, 첫 번째로 일치한 뒤에는 계속 진행하지 않습니다. 구체적인 도메인, 프로세스 또는 규칙 집합은 보통 앞에 배치하고, 범위가 넓은 GEOIP, GEOSET과 최종 MATCH는 뒤에 둡니다. MATCH를 앞에 배치하면 이후 규칙은 영원히 실행되지 않습니다. 규칙을 수정한 뒤에는 연결 로그에서 “요청 도메인—매칭 규칙—대상 정책” 세 가지를 확인해야 하며, 최종 웹페이지가 열리는지만 보아서는 안 됩니다.

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

RULE-SET은 독립적인 규칙 집합을 참조해 업데이트와 재사용을 쉽게 합니다. 규칙 제공자의 다운로드가 실패해도 기존 캐시로 계속 작동할 수 있지만, 새로 설치하거나 캐시를 삭제하면 문제가 드러납니다. provider 주소의 접근 가능 여부, behavior 유형과 규칙 내용의 일치 여부, 정책 이름의 실제 존재 여부를 확인하세요. 존재하지 않는 정책 그룹에 규칙이 매칭되면 설정 로드 단계에서 오류가 발생하는 경우가 많습니다.

정책 그룹 이름은 구독이 결정하므로 예시에 나온 PROXY가 모든 설정에 고정으로 존재하는 것은 아닙니다. 오버라이드 규칙을 작성할 때는 현재 설정에 있는 실제 그룹 이름을 사용해야 합니다. 전역 모드는 대부분의 규칙 판단을 건너뛰고 트래픽을 지정된 전역 그룹으로 전달하며, 직접 연결 모드는 프록시 출구를 건너뜁니다. 세 모드의 차이는 규칙·전역·직접 연결 모드 설명에서 확인할 수 있습니다.

구독 업데이트와 오버라이드의 관계

구독 업데이트는 보통 원격 설정을 다시 다운로드해 교체합니다. 구독에서 생성된 YAML을 직접 편집하면 다음 업데이트에서 수정 내용이 덮어써질 수 있습니다. 오버라이드, 스크립트 또는 Mixin을 지원하는 클라이언트라면 로컬 포트, DNS와 추가 규칙을 전용 오버라이드 계층에 넣으세요. 지원하지 않는 경우에는 수정 기록을 남기고 업데이트 후 다시 확인해야 합니다. 한 가지 수정을 지키기 위해 업데이트를 영구적으로 끄지 마세요. 노드, 정책과 규칙의 정상적인 변경까지 놓치게 됩니다.

자동 업데이트 간격은 너무 짧아 빈번하게 요청하지도, 너무 길어 서비스 제공자의 조정을 제때 받지 못하지도 않게 설정하세요. 업데이트에 실패하면 HTTP 요청 실패, 반환 내용 변경, 파싱 오류와 프록시 루프를 구분해야 합니다. 클라이언트가 현재 프록시를 통해 구독을 요청하는데 구독 도메인이 잘못된 규칙으로 사용할 수 없는 노드에 전달되면 업데이트 루프가 생길 수 있습니다. 자세한 절차는 구독 업데이트 실패 점검 및 자동 업데이트 설정에서 확인하세요.

CHAPTER 08 / TROUBLESHOOTING

설정 문제 해결: 트래픽 경로를 따라 단계별로 확인하기

클라이언트는 실행되지만 네트워크가 연결되지 않음

문제 해결 순서는 실제 트래픽 경로를 따라야 합니다. 대상 앱이 요청을 로컬 프록시에 전달하는지, 로컬 포트가 수신 중인지, 코어가 현재 설정을 로드했는지, 규칙이 연결을 예상한 정책으로 전달하는지, 노드가 원격 연결을 만들 수 있는지, DNS가 사용 가능한 결과를 반환하는지를 차례로 확인하세요. 클라이언트 화면에 “실행 중”이라고 표시되는 것은 프로세스가 존재한다는 뜻일 뿐이며, 위 각 단계가 성공했다는 의미는 아닙니다.

먼저 TUN을 끄고 시스템 프록시만 유지한 상태에서 브라우저로 일반 사이트에 접속하세요. 브라우저도 실패하면 시스템 프록시 주소가 로컬 컴퓨터인지, 포트가 클라이언트와 일치하는지 확인하고 로그에 연결 기록이 있는지 살펴보세요. 로그가 전혀 없다면 트래픽이 클라이언트로 들어오지 않은 경우가 많습니다. 요청은 있지만 즉시 거부되면 포트 오류나 코어 미실행일 수 있습니다. 규칙 매칭은 되지만 원격 핸드셰이크가 실패하면 노드와 네트워크 조건을 계속 확인하세요.

시스템 프록시를 끈 뒤에도 웹페이지에 접속할 수 없다면 남은 프록시 설정, DNS 캐시 또는 다른 VPN 라우팅이 원인일 수 있습니다. Windows에서는 시스템 프록시, macOS에서는 현재 네트워크 서비스, 모바일 시스템에서는 VPN 상태, Linux에서는 환경 변수와 기본 경로를 확인하세요. 기기를 재시작하면 일부 임시 상태를 정리할 수 있지만, 재시작 전에 설정과 로그를 기록해야 합니다. 그렇지 않으면 문제가 재현된 뒤에도 어느 계층이 바뀌었는지 알 수 없습니다.

구독을 업데이트할 수 없거나 파싱에 실패함

구독 업데이트가 실패하면 먼저 브라우저에서 원래 링크를 열어 응답 상태를 확인하세요. 링크에 접근할 수 없거나 만료되었거나 로그인 페이지가 반환되면 서비스 제공자 측에서 주소를 갱신해야 합니다. 브라우저에서는 열리지만 클라이언트에서 실패한다면 클라이언트의 네트워크 권한, 현재 프록시 규칙과 시스템 시간을 확인하세요. 인증서 연결은 정확한 시간에 의존하므로 기기 시간이 크게 어긋나면 네트워크 문제처럼 보이는 보안 연결 오류가 발생할 수 있습니다.

파싱 실패는 대개 반환 내용이 호환되는 YAML이 아니거나, 현재 클라이언트가 필드 구조를 인식하지 못하거나, 웹 인증 및 오류 페이지가 원래 내용을 대신했다는 뜻입니다. HTTP 상태 코드만 보지 마세요. 성공 응답이어도 HTML일 수 있습니다. 반환 내용을 로컬에 저장해 시작 부분이 설정 필드인지 확인하고 들여쓰기와 인코딩도 점검하세요. 전체 판단 절차는 구독 만료 및 파싱 실패 자가 점검 목록을 참고하세요.

가져온 뒤 노드가 비어 있다면 먼저 Clash 또는 mihomo 형식을 선택했는지 확인하세요. 다른 도구 전용 구독이 아닐 수 있습니다. 노드는 있지만 정책 그룹이 비어 있다면 설정 변환 과정에서 proxy-groups가 빠졌을 가능성이 있습니다. 많은 노드를 새 파일에 하나씩 수동으로 복사하지 말고 구독 출처에서 올바른 형식을 다시 받으세요. 복사 과정에서 인증 필드와 프로토콜 매개변수가 손상되는 것을 피할 수 있습니다.

일부 웹사이트나 앱만 실패함

일부 웹사이트가 실패하면 먼저 연결 로그에서 도메인, 매칭 규칙과 정책을 확인하세요. DIRECT로 잘못 매칭되었다면 구체적인 규칙을 더 넓은 규칙보다 앞에 배치해 조정하세요. 이미 프록시에 들어갔는데 실패한다면 검증된 노드 하나를 고정해 자동 정책 전환을 배제하고 다시 시도하세요. 브라우저는 정상인데 특정 앱만 실패하면 해당 앱이 시스템 프록시를 읽는지 확인하고, 필요하면 TUN 또는 모바일 앱별 분류를 테스트하세요.

웹사이트는 열리지만 이미지, 로그인 또는 동영상이 실패하는 경우는 주 도메인과 리소스 도메인이 서로 다른 정책에 매칭되었기 때문일 수 있습니다. 개발자 도구나 연결 목록에서 부속 도메인을 확인한 뒤 같은 정책을 사용해야 하는지 판단하세요. 너무 넓은 DOMAIN-KEYWORD 규칙 하나로 비슷한 이름을 모두 덮지 마세요. 관련 없는 서비스까지 바뀔 수 있습니다. 유지 관리가 잘 되는 규칙 집합을 사용하거나 명확한 도메인 접미사에 규칙을 추가하는 편이 안전합니다.

노드를 바꾼 뒤에도 문제가 잠시 지속된다면 DNS, HTTP/2, QUIC 또는 앱 세션 캐시 때문일 수 있습니다. 대상 앱을 완전히 종료하고 필요한 캐시를 정리한 뒤 새 연결을 만들어 다시 테스트하세요. 브라우저 시크릿 창은 일부 캐시만 줄일 뿐 시스템 DNS 갱신을 대신하지 않습니다. 비교 테스트에서는 한 번에 변수 하나만 바꾸고 모드, 노드, 네트워크와 매칭 규칙을 기록하세요.

DNS·포트·TUN 충돌

DNS 문제의 전형적인 증상은 IP에는 접근할 수 있지만 도메인은 실패하거나, 로그에 조회 시간 초과가 계속 나타나거나, 같은 도메인이 앱마다 서로 다른 결과를 내는 것입니다. 먼저 로컬 DNS 수신 포트가 사용 중인지 확인한 다음 브라우저 자체 DNS와 시스템의 추가 DNS 도구를 꺼서 비교하세요. fake-ip 모드에서 예약 주소가 보이는 것은 설계에 따른 동작이므로 해당 주소 자체를 원격 서버 장애로 오해하지 마세요.

포트 충돌은 프록시 또는 제어 인터페이스의 수신을 막을 수 있습니다. 로그의 bind, address already in use 등의 정보를 확인한 뒤 시스템 도구로 포트를 사용하는 프로세스를 찾으세요. 포트를 바꾸면 시스템 프록시, 터미널 환경 변수, 브라우저 확장 프로그램과 LAN 기기도 모두 함께 업데이트해야 합니다. 클라이언트 필드만 바꾸고 기존 시스템 프록시를 그대로 두면 “코어는 정상 실행되지만 요청이 들어오지 않는” 상태가 됩니다.

TUN을 켠 뒤 전체 네트워크가 끊기면 먼저 TUN을 끄고 기준선으로 돌아간 다음 가상 인터페이스 권한, 기본 경로, DNS 가로채기와 다른 VPN을 확인하세요. 데스크톱 가상 머신, 컨테이너, 게임 가속기와 기업 네트워크 소프트웨어가 네트워크 필터 드라이버를 설치했을 수 있습니다. 충돌하는 도구를 순서대로 비활성화하고 한 번에 하나씩만 복구하세요. 문제가 절전 모드 해제 후에만 나타난다면 TUN 인터페이스를 다시 만들고 남은 라우팅이 있는지 확인하세요.

로그 읽는 법과 되돌려야 할 때

일상적인 문제 해결에는 info 수준이면 충분합니다. debug 로그는 짧은 시간 동안 세부 정보를 수집해야 할 때만 켜세요. 연결 기록이 대량으로 생성되기 때문입니다. 설정 로드 오류, 수신 실패, DNS 시간 초과, 규칙 매칭, 원격 핸드셰이크와 라우팅 생성 정보를 중점적으로 확인하세요. 로그를 공유하기 전에는 구독 주소, 인증 필드, 노드 인증 정보와 공개하고 싶지 않은 접근 도메인을 제거하세요.

여러 수정 사항이 겹쳐 원인을 판단할 수 없다면 최소 상태로 되돌리세요. TUN과 오버라이드를 비활성화하고 원본 구독 하나만 로드한 뒤 기본 로컬 포트를 사용하고 노드 하나를 고정해 시스템 프록시로 브라우저를 테스트합니다. 기준선이 복구되면 “사용자 지정 DNS—추가 규칙—TUN—LAN 공유” 순서로 하나씩 다시 추가하세요. 특정 단계에서 바로 문제가 재현되면 조사 범위를 해당 계층으로 좁힐 수 있습니다.

원본 구독이 여러 네트워크와 여러 클라이언트에서 모두 연결되지 않지만 링크 반환 내용은 정상이라면 구독 서비스 제공자에게 노드 상태를 확인해야 합니다. 같은 구독이 다른 기기에서는 작동한다면 먼저 로컬 권한, 포트, DNS와 라우팅을 확인하세요. 클라이언트 재설치는 프로그램 파일이나 시스템 통합이 손상된 경우에만 적합하며, 구독 형식, 규칙 논리와 원격 노드 상태를 자동으로 고쳐 주지는 않습니다.

증상	첫 번째 확인 지점	다음 단계
클라이언트는 실행 중이지만 로그에 요청이 없음	시스템 프록시, VPN/TUN, 앱 프록시 설정	로컬 주소와 mixed 포트 확인
모든 노드 연결 실패	현재 네트워크, 시스템 시간, 구독 상태	네트워크를 바꾸고 핸드셰이크 로그 확인
일부 도메인만 실패	규칙 매칭과 DNS 결과	노드를 고정하고 부속 도메인 확인
TUN 활성화 후 네트워크 끊김	가상 인터페이스, 라우팅, 다른 VPN	TUN을 끄고 시스템 프록시 기준선으로 복귀
구독은 성공적으로 반환되지만 파싱할 수 없음	반환 내용과 구독 형식	로그인 페이지나 오류 페이지가 아닌지 확인

문제 해결이 끝나면 최종적으로 작동한 클라이언트, 설정 이름, 프록시 모드, DNS 선택과 필요한 오버라이드를 로컬에 기록하세요. 이후 업데이트는 이 기준선과 비교하면 되므로 전체 트래픽 경로를 다시 추측할 필요가 없습니다. 재설치하거나 플랫폼을 바꿔야 할 때는 클라이언트 다운로드 페이지로 돌아가 시스템 아키텍처와 사용 가능한 클라이언트를 확인하세요.