시작하기 전에
공통 준비: 클라이언트, 구독과 프록시 모드
기본 연결만 한 번 설정하면 된다면 분량이 짧은 빠른 시작 가이드부터 확인하세요. 이 페이지는 체계적인 참고 자료로, 각 플랫폼의 다운로드와 설치부터 구독, 시스템 프록시, TUN, 권한과 플랫폼 제한까지 다룹니다. 특정 문제가 생겼다면 처음부터 읽지 말고 위 목차에서 해당 장으로 바로 이동하면 됩니다. 모든 클라이언트는 다운로드 센터에서 플랫폼에 맞게 선택하며, 데스크톱과 모바일 모두 Clash Plus를 우선 고려하세요. 다른 선택지와 유지 관리 상태는 다운로드 페이지의 최신 목록을 기준으로 합니다.
클라이언트, 코어와 설정 파일의 차이
Clash를 사용할 때는 서로 독립적인 세 부분을 이해해야 합니다. 클라이언트는 창, 메뉴, 스위치와 구독 관리를 제공하고, mihomo 같은 코어는 포트 수신, DNS 해석, 규칙 매칭과 연결 수립을 담당합니다. 설정 파일에는 프록시 정보, 정책 그룹, 규칙, DNS와 TUN 매개변수가 저장됩니다. 인터페이스 클라이언트를 바꿔도 구독이 바뀌는 것은 아니며, 호환 설정을 같은 방식으로 가져오면 일반적으로 규칙 결과도 동일합니다. 반대로 클라이언트 창은 정상적으로 열려도 코어가 시작되지 않았다면 시스템 프록시가 설정되어 있어도 실제 트래픽 전달은 이루어지지 않습니다.
구독 링크는 보통 서비스 제공자가 생성합니다. 클라이언트가 링크를 가져오면 YAML 설정 또는 변환된 설정 내용을 다운로드합니다. 가져오기에 성공했다는 것은 형식을 읽을 수 있다는 뜻일 뿐, 포함된 프록시 서버에 연결할 수 있다는 의미는 아닙니다. 변수를 줄이려면 처음 설정할 때 구독의 기본 규칙을 그대로 유지하고, 많은 사용자 규칙을 한꺼번에 추가하거나 DNS를 덮어쓰거나 수신 포트를 바꾸지 않는 것이 좋습니다. 기본 연결이 안정된 뒤 개인 설정을 하나씩 추가하고 한 번에 한 부분만 변경하면 문제 발생 시 되돌리기 쉽습니다.
구독 가져오기 전 확인 사항
링크를 복사할 때 앞뒤 공백, 줄바꿈 또는 메신저가 덧붙인 문장부호가 포함되지 않았는지 확인하세요. 링크는 개인 설정에 접근하는 정보이므로 공개 페이지나 스크린샷에 올리지 않는 것이 좋습니다. 서비스 제공자가 ‘원클릭 가져오기’와 일반 구독 주소를 모두 제공한다면 클라이언트가 명확히 지원하는 방식을 우선 사용하세요. 일반 주소는 ‘구독’, ‘설정’ 또는 ‘Profiles’ 페이지에 붙여 넣습니다. 가져오기가 끝나면 먼저 설정 이름, 정책 그룹과 규칙이 표시되는지 확인한 뒤 해당 설정을 현재 설정으로 지정하세요. 주소만 클라이언트에 저장하고 설정을 활성화하지 않는 것은 새로 설치한 뒤 가장 흔히 놓치는 부분입니다.
시스템 프록시와 TUN 선택
시스템 프록시는 브라우저, 데스크톱 메신저와 운영체제 프록시 설정을 읽는 앱에 적합합니다. 클라이언트는 보통 HTTP와 SOCKS 수신 주소를 설정하며, 흔히 사용하는 로컬 주소는 127.0.0.1입니다. 포트는 설정의 mixed-port, port 또는 socks-port 값으로 결정됩니다. 권한 요구가 낮고 켜고 끄기 쉽다는 장점이 있지만, 일부 게임, 명령줄 프로그램, 스토어 앱과 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시를 무시할 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 시스템 트래픽을 가로채므로 시스템 프록시를 읽지 못하는 프로그램에도 적합하며, 더 많은 TCP, UDP와 DNS 요청을 통합 처리할 수 있습니다. 대신 높은 시스템 권한이 필요하고 다른 VPN, 가상 머신, 컨테이너 네트워크, 보안 소프트웨어 또는 기업용 네트워크 구성 요소와 충돌할 수 있습니다. 처음 사용할 때는 먼저 시스템 프록시를 확인한 뒤 실제 필요에 따라 TUN을 켜고, 여러 트래픽 가로채기 도구를 동시에 활성화하지 않는 것이 좋습니다. 모바일의 VPN 스위치는 작동 방식이 TUN에 더 가깝고, 시스템상 이런 네트워크 확장은 보통 하나만 활성 상태로 둘 수 있습니다.
| 작동 방식 | 적합한 상황 | 확인할 사항 |
|---|---|---|
| 시스템 프록시 | 브라우저, 일반 데스크톱 앱, 일상적인 규칙 설정 | 앱이 시스템 프록시를 읽는지, 종료할 때 설정을 복원하는지 |
| TUN 또는 모바일 VPN | 게임, 명령줄, UDP, 시스템 프록시를 무시하는 앱 | 관리자 권한, 라우팅 충돌, DNS 가로채기와 다른 VPN |
| 앱 내 프록시 | 특정 도구 하나만 로컬 SOCKS 또는 HTTP 포트를 사용하도록 할 때 | 프록시 프로토콜, 수신 주소와 포트가 클라이언트 설정과 일치해야 함 |
재현 가능한 확인 절차 만들기
모든 플랫폼에서 같은 순서로 확인할 수 있습니다. 먼저 클라이언트 코어가 실행 중인지 확인하고, 현재 설정이 실제로 선택되어 있는지 확인합니다. 그다음 프록시 모드가 규칙, 글로벌 또는 직접 연결 중 무엇인지 확인하고, 대상 요청이 연결 기록에서 어떤 규칙과 정책 그룹에 매칭되었는지 살펴봅니다. 마지막으로 프록시 서버 자체의 사용 가능 여부를 판단하세요. 웹페이지가 열리는지만 보면 DNS, 규칙, 프록시 서버와 시스템 가로채기 중 어느 단계에 문제가 있는지 구분하기 어렵습니다. 연결 기록과 로그가 더 신뢰할 수 있는 근거를 제공하며, 관련 오류 필드는 Clash 로그 오류 확인 방법에서 계속 확인할 수 있습니다.
데스크톱 플랫폼
Windows: 설치, 구독과 시스템 네트워크 가로채기
Windows에서는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu와 보관용 Clash for Windows를 선택할 수 있습니다. 새로 설정할 때는 계속 유지 관리되고 mihomo를 지원하는 클라이언트를 우선 사용하세요. 다운로드 전 ‘설정 → 시스템 → 시스템 정보’에서 기기 아키텍처를 확인합니다. 대부분의 일반 PC는 x64를 사용하며, ARM 프로세서를 탑재한 기기만 ARM 버전이 필요합니다. 설치 패키지와 포터블 압축 파일은 사용 방식이 다릅니다. 설치 패키지는 프로그램 폴더와 바로가기를 만들고, 포터블 버전은 고정된 폴더에 완전히 압축을 푼 뒤 실행해야 합니다. 압축 프로그램의 미리보기 창에서 바로 실행하지 마세요.
설치 및 첫 실행
Windows 다운로드 영역에서 설치 파일을 받은 뒤 먼저 기존 Clash 클라이언트를 종료해 같은 수신 포트를 두 프로그램이 사용하지 않도록 합니다. 설치 마법사를 완료한 다음 클라이언트를 실행하세요. Windows 방화벽 알림이 표시되면 LAN 공유가 실제로 필요한 경우에만 해당 네트워크 유형을 허용합니다. 단일 기기에서 사용할 때는 코어의 수신 주소를 로컬 루프백 주소로 유지하면 되며, ‘연결되게 하려고’ 모든 네트워크 인터페이스를 열 필요는 없습니다. 프로그램은 열리지만 코어가 시작되지 않는다면 기존 클라이언트가 트레이에서 실행 중인지 확인한 뒤 포트 사용 현황과 코어 로그를 살펴보세요.
포터블 버전을 임시 다운로드 폴더, 동기화 드라이브의 충돌 폴더 또는 권한이 엄격하게 제한된 위치에 두지 마세요. 클라이언트는 보통 자체 데이터 폴더에 설정, 캐시와 로그를 기록해야 합니다. 경로에 쓰기 권한이 없으면 설정을 가져온 뒤 사라지거나 업데이트가 실패하고, 실행할 때마다 초기 상태로 돌아가는 현상이 나타날 수 있습니다. 처음 실행한 뒤 클라이언트 설정에서 데이터 폴더 위치를 확인하고, 장기간 사용할 설정은 직접 관리할 수 있는 위치에 백업하세요.
구독 가져오기 및 정책 선택
‘설정’ 또는 ‘구독’ 페이지에서 URL 가져오기를 선택하고 구독 주소를 붙여 넣은 뒤 다운로드가 완료될 때까지 기다립니다. 새 설정이 나타나면 활성화하거나 현재 설정으로 지정하세요. 이어서 ‘프록시’ 페이지에서 모드를 ‘규칙’으로 설정합니다. 규칙 모드는 설정에 있는 규칙을 위에서부터 매칭하고, 처음 일치하는 규칙에서 멈춥니다. 정책 그룹은 매칭 후 실제로 사용할 출구를 결정합니다. 처음 확인할 때 모드를 ‘직접 연결’로 잘못 설정하지 말고, 영향을 이해하지 못한 상태에서 ‘글로벌’을 장기간 사용하지도 마세요. 규칙 모드는 LAN 직접 연결, 자주 사용하는 중국 본토 서비스 직접 연결과 지정 대상 프록시를 함께 유지할 수 있어 일상 사용에 적합한 기본 선택입니다.
정책 그룹이 수동 선택 방식이라면 그룹 안에서 사용할 수 있는 항목을 명확히 선택해야 합니다. 자동 테스트, 장애 조치 또는 부하 분산 방식이라면 설정에 정의된 탐색 및 전환 로직이 처리합니다. 클라이언트에 표시되는 테스트 결과는 지정한 테스트 주소에 연결한 결과일 뿐, 다운로드 속도나 모든 웹사이트의 실제 사용 경험과 같지는 않습니다. 이 차이는 노드 지연 시간 테스트 원리에서 확인할 수 있습니다.
시스템 프록시 활성화
코어가 실행 중인지 확인한 뒤 ‘시스템 프록시’를 켜세요. 이 작업은 Windows 프록시 설정을 클라이언트의 로컬 포트로 지정합니다. 브라우저로 대상 웹사이트에 접속하면서 클라이언트 연결 페이지에 해당 도메인, 매칭된 규칙과 정책 그룹이 표시되는지 확인하세요. 브라우저는 되지만 특정 명령줄 프로그램이 작동하지 않는다면 구독 문제가 아니라 해당 프로그램이 Windows 시스템 프록시를 읽지 않는 경우가 많습니다. 해당 프로그램에 HTTP_PROXY, HTTPS_PROXY 또는 SOCKS 주소를 별도로 설정하거나 필요에 따라 TUN을 사용할 수 있습니다.
set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
curl https://example.com위 예시는 현재 명령 프롬프트 창에서만 적용되며, 포트는 클라이언트에 실제로 표시되는 mixed 포트로 바꿔야 합니다. PowerShell, Git, 패키지 관리자와 개발 도구에는 각각 독립적인 프록시 설정이 있을 수 있으므로 브라우저가 된다고 모든 프로그램이 자동으로 따라온다고 가정하지 마세요. 문제를 확인할 때는 먼저 도구 자체의 설정을 확인한 뒤 환경 변수나 TUN이 필요한지 판단합니다.
TUN 모드 및 권한
게임, 스토어 앱, UDP 또는 시스템 프록시를 읽지 않는 소프트웨어까지 가로채야 한다면 다른 VPN 도구를 끄고 관리자 권한으로 클라이언트를 실행한 다음 TUN을 켤 수 있습니다. 처음 활성화할 때 가상 네트워크 어댑터나 네트워크 구성 요소 설치가 진행될 수 있으며, 완료 후 기본 라우팅과 DNS를 클라이언트가 인계했는지 확인해야 합니다. TUN을 켠 뒤 시스템 전체의 인터넷이 끊기면 먼저 TUN을 끄고 가상 머신 브리지, 컨테이너 네트워크, 가속기 또는 보안 소프트웨어의 네트워크 필터 모듈이 동시에 실행 중인지 확인하세요. 문제가 있는 상태에서 여러 가로채기 도구를 반복해서 전환하면 라우팅 테이블과 DNS 상태를 더 파악하기 어려워집니다.
Windows 특유의 문제
절전 모드에서 복귀한 뒤 연결이 끊기면 바로 클라이언트를 재설치하기보다 먼저 구독 상태를 새로 고친 다음 코어를 재시작해 보세요. 시스템 시간이 맞지 않으면 TLS 연결에 영향을 줄 수 있으므로 자동 시간 동기화가 정상인지 확인합니다. LAN 공유가 필요하면 설정에서 ‘LAN 연결 허용’을 켜고 수신 주소를 클라이언트가 허용하는 LAN 주소로 변경한 뒤 방화벽에서는 필요한 포트만 허용하세요. 다른 기기에서는 이 컴퓨터의 LAN 주소를 입력해야 하며 127.0.0.1을 입력하면 안 됩니다. 공유가 끝나면 신뢰할 수 없는 네트워크에 프록시 포트가 노출되지 않도록 즉시 닫으세요.
데스크톱 플랫폼
macOS: 칩 아키텍처, 시스템 프록시와 네트워크 확장
macOS에서 다운로드하기 전에 먼저 칩 아키텍처를 확인하세요. 왼쪽 상단 Apple 메뉴의 ‘이 Mac에 관하여’를 열어 Apple 칩으로 표시되면 Apple Silicon 또는 ARM 빌드를, Intel 프로세서로 표시되면 x64 빌드를 선택합니다. 선택 가능한 클라이언트는 Clash Plus, Clash Verge Rev, FlClash와 보관 상태인 ClashX Meta입니다. 새로 설치할 때는 계속 유지 관리되는 클라이언트를 우선하고, macOS 다운로드 영역에서 칩에 맞는 파일을 받으세요. 아키텍처를 잘못 선택하면 앱이 열리지 않거나 별도의 변환 계층이 필요할 수 있습니다.
앱 설치 및 첫 권한 승인
일반적인 설치 방법은 디스크 이미지를 연 뒤 앱을 ‘응용 프로그램’ 폴더로 드래그하고 해당 폴더에서 실행하는 것입니다. 디스크 이미지에서 직접 장기간 실행하지 마세요. 앱 업데이트, 보조 구성 요소와 데이터 폴더가 예상대로 기록되지 않을 수 있습니다. 처음 열 때 시스템 확인 창이 나타나면 앱 출처와 다운로드 경로를 확인한 뒤 시스템이 제공하는 보안 절차를 따르세요. 시스템 프록시, 네트워크 확장 또는 TUN을 사용할 때 macOS에서 관리자 인증 정보를 요구할 수 있으며, 이는 시스템 네트워크 설정을 변경하는 데 필요한 권한입니다.
시작한 뒤 시스템 프록시와 TUN을 동시에 켜지 마세요. 설정 페이지에서 구독 URL로 설정을 가져오고 정책 그룹과 규칙이 로드될 때까지 기다린 뒤 현재 설정으로 지정하고 규칙 모드를 선택합니다. 가져온 뒤 설정 항목 하나만 보이고 정책 그룹이 보이지 않는다면 설정 다운로드가 잘못되었거나 구독 변환 결과가 호환되지 않거나 기존 설정이 계속 선택된 상태일 수 있습니다. 이때는 설정 업데이트 시간과 클라이언트 로그를 확인하고 업데이트 버튼만 반복해서 누르지 마세요.
시스템 프록시의 적용 범위
macOS 시스템 프록시는 현재 네트워크 서비스의 HTTP, HTTPS 또는 SOCKS 설정에 기록됩니다. 브라우저와 시스템 네트워크 프레임워크를 따르는 대부분의 앱은 이 값을 읽지만 터미널 명령, 일부 개발 도구와 자체 네트워크 스택을 사용하는 앱은 따르지 않을 수 있습니다. 시스템 프록시를 켠 뒤 ‘시스템 설정 → 네트워크 → 현재 네트워크 → 세부사항 → 프록시’에서 해당 항목이 로컬 포트를 가리키는지 확인할 수 있습니다. 일반적으로 이 값을 직접 수정할 필요는 없으며, 프록시를 끌 때 클라이언트가 복원해야 합니다.
터미널 도구가 필요로 할 때는 현재 세션에만 환경 변수를 설정할 수 있습니다. 포트는 클라이언트에 표시되는 실제 mixed 포트를 사용하며, 터미널을 종료하면 설정이 자동으로 사라집니다:
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
curl https://example.comGit, Homebrew 또는 다른 도구에 독립적인 프록시 주소가 저장되어 있다면 내부 설정도 확인해야 합니다. 기존 주소가 현재 환경 변수보다 우선해 ‘브라우저는 정상인데 터미널은 계속 실패하는’ 현상이 생길 수 있습니다. 문제를 확인할 때 env | grep -i proxy로 현재 환경을 확인하고, 특정 도구에 추가 매개변수가 저장되어 있는지도 살펴보세요.
TUN, 네트워크 확장과 DNS
시스템 프록시를 읽지 않는 앱에는 클라이언트가 제공하는 TUN 또는 네트워크 확장 모드를 사용할 수 있습니다. 처음 활성화할 때는 보통 시스템 승인이 필요하며, 일부 클라이언트는 백그라운드에서 라우팅을 조정하기 위해 보조 서비스를 설치합니다. 승인 후 스위치가 즉시 다시 꺼진다면 시스템 설정의 네트워크 확장 허용 여부, 클라이언트 로그와 보조 서비스 상태를 확인하세요. 기업용 기기는 구성 프로파일의 제한을 받을 수 있어 일반 사용자 권한으로 조직 정책을 덮어쓸 수 없습니다. 이때는 반복 설치하지 말고 기기 관리 규정을 따라야 합니다.
macOS에서 여러 VPN, 필터, 콘텐츠 검사 도구 또는 가상 네트워크 어댑터를 동시에 실행하면 라우팅 우선순위가 충돌할 수 있습니다. 연결은 수립되지만 트래픽이 흐르지 않거나, 특정 도메인이 잘못된 주소로 해석되거나, LAN 기기에 접근할 수 없거나, 절전 후 인터넷이 끊기는 현상이 나타날 수 있습니다. 먼저 다른 네트워크 가로채기 도구를 끄고 Clash만 남긴 뒤 코어를 재시작하고 DNS를 확인하세요. 단독 실행이 정상임을 확인한 다음 다른 소프트웨어를 하나씩 다시 켜면 충돌 지점을 찾을 수 있습니다.
절전, 네트워크 전환과 로컬 서비스
Mac이 절전에서 복귀하거나 무선 네트워크, 유선 네트워크와 모바일 핫스팟 사이를 전환하면 로컬 IP, 기본 라우팅과 DNS가 바뀔 수 있습니다. 연결이 이전 상태에 멈춰 있으면 먼저 코어를 일시 중지했다가 다시 시작하고, 필요하면 시스템 프록시를 껐다가 다시 켜세요. 로컬 개발 서비스를 실행할 때 localhost, 127.0.0.1과 LAN 대역은 보통 직접 연결해야 합니다. 사용자 규칙이 이 주소를 너무 일찍 프록시로 보내면 로컬 페이지, 데이터베이스 또는 LAN 기기에 접근할 수 없습니다. LAN 직접 연결 규칙을 일반 프록시 규칙보다 앞에 배치하세요.
메뉴 막대 아이콘을 종료한 뒤 모든 웹페이지가 열리지 않는다면 시스템 프록시가 복원되지 않았을 가능성이 큽니다. 클라이언트를 다시 실행해 시스템 프록시를 끄거나 현재 네트워크 서비스의 프록시 설정에서 해당 항목을 해제하세요. 특정 브라우저만 문제가 있다면 브라우저 확장 프로그램이나 브라우저 자체의 프록시 설정을 확인합니다. 시스템 계층과 앱 계층에 서로 다른 로컬 포트를 동시에 저장하지 마세요. 포트를 업데이트한 뒤 이전 값이 남기 쉽습니다.
모바일 플랫폼
Android: 앱 설치, VPN 권한과 백그라운드 실행
Android에서는 Clash Plus, Clash Meta for Android, FlClash와 Surfboard를 선택할 수 있습니다. 설치 전 Android 다운로드 영역에서 클라이언트를 선택하세요. 설치 패키지는 ARM64, ARM 또는 범용 아키텍처로 나뉠 수 있으며, 최근 출시된 스마트폰과 태블릿 대부분은 ARM64를 사용합니다. 오래된 기기에서만 다른 아키텍처가 필요할 수 있습니다. 확실하지 않다면 다운로드 페이지의 범용 빌드를 우선 선택하거나 시스템 정보 도구에서 ABI를 확인하세요. 아키텍처가 맞지 않으면 보통 구독이나 네트워크 문제가 아니라 설치 단계에서 설치할 수 없다는 메시지가 표시됩니다.
설치 및 VPN 권한 승인
다운로드가 완료되면 Android의 설치 절차에 따라 파일을 엽니다. 시스템에서 현재 브라우저나 파일 관리자에 한 번 설치 권한을 부여하라고 요청할 수 있으며, 완료 후에는 개인 보안 기준에 따라 이 권한을 다시 끌 수 있습니다. 클라이언트를 처음 실행하고 연결을 시작하면 Android가 VPN 연결 요청을 표시합니다. 승인하면 상태 표시줄에 보통 VPN 아이콘이 나타납니다. Android는 일반적으로 한 번에 하나의 VPN 서비스만 실행할 수 있으므로 다른 VPN, 기업용 터널, 방화벽 또는 로컬 필터 앱이 중지되거나 반대로 Clash의 연결을 막을 수 있습니다.
모바일에는 데스크톱 시스템 프록시와 같은 전역 스위치가 없으며, 클라이언트는 보통 Android VPN API로 가상 인터페이스를 만듭니다. 시작 버튼에 연결됨으로 표시된다는 것은 인터페이스가 만들어졌다는 뜻일 뿐입니다. 현재 설정, 규칙 모드와 정책 그룹도 확인해야 합니다. 설정 페이지에서 URL로 새 구독을 만들고 업데이트한 뒤 해당 설정을 선택하세요. 구독을 다운로드하려면 이미 사용할 수 있는 네트워크 경로가 필요한 경우, 먼저 연결 가능한 환경에서 최초 가져오기를 완료한 다음 프록시를 시작합니다.
앱별 프록시와 우회 설정
Android 클라이언트는 앱별 프록시를 제공하는 경우가 많으며, ‘선택한 앱만 프록시’ 또는 ‘선택한 앱 우회’를 선택할 수 있습니다. 두 모드는 의미가 서로 반대이므로 전환할 때 목록을 다시 확인하세요. 브라우저만 프록시로 보내는 방식은 테스트에 적합하지만, 브라우저가 외부 앱을 호출할 때 경로가 달라질 수 있습니다. 은행 앱, LAN 제어 앱 또는 VPN에 민감한 앱을 우회할 때는 우회된 앱이 현재 네트워크를 직접 사용한다는 점을 이해해야 합니다. 시스템에서 ‘VPN 항상 켜기’ 또는 ‘VPN을 사용하지 않는 연결 차단’을 활성화했다면 우회 동작도 시스템 정책의 영향을 받습니다.
규칙 모드와 앱별 프록시는 서로 다른 두 단계의 판단입니다. 앱이 먼저 VPN에 들어갈지 결정하고, VPN에 들어온 뒤 Clash 규칙이 DIRECT, PROXY 또는 REJECT를 결정합니다. 특정 앱을 우회 목록에 넣으면 Clash의 도메인 규칙을 바꿔도 해당 앱에는 영향을 주지 않습니다. ‘규칙이 왜 적용되지 않지?’라는 문제를 확인할 때는 먼저 해당 앱의 트래픽이 클라이언트 연결 기록에 들어오는지 확인한 다음 규칙 순서를 살펴보세요.
백그라운드 제한과 배터리 절전 정책
일부 Android 시스템은 화면 잠금, 작업 정리 또는 절전 모드에서 VPN 클라이언트를 제한합니다. 처음에는 작동하지만 잠시 화면을 잠그면 연결이 사라지고 앱을 다시 열면 복구되는 식입니다. 시스템의 배터리 및 백그라운드 관리에서 클라이언트의 지속 실행을 허용하고 자동 정리 목록에 넣지 마세요. 제조사마다 메뉴 이름은 다르지만 목표는 같습니다. 포그라운드 VPN 서비스를 유지하고, 백그라운드 네트워크를 허용하며, 화면이 꺼진 뒤 프로세스를 강제 종료하지 않도록 설정합니다.
구독 자동 업데이트도 백그라운드 네트워크에 의존합니다. 앱을 열 때만 업데이트된다면 클라이언트의 업데이트 주기, 백그라운드 데이터 권한과 절전 제한을 확인하세요. 업데이트가 실패했을 때는 마지막으로 성공한 설정을 유지하는 편이 삭제 후 다시 가져오는 것보다 안전합니다. 사용할 수 있는 설정을 유일하게 삭제하면 구독을 다시 가져오는 네트워크 경로를 잃을 수 있습니다.
DNS, IPv6와 핫스팟 공유
Android의 비공개 DNS, 클라이언트 내장 DNS와 통신사 DNS가 동시에 해석에 관여할 수 있습니다. 일부 도메인만 실패한다면 비공개 DNS를 잠시 끄고 비교한 뒤 설정의 enhanced-mode, 상위 리졸버와 Fake-IP 제외 항목을 확인하세요. IPv6, 비공개 DNS, TUN 스택과 규칙을 한꺼번에 크게 바꾸지 마세요. 어떤 변경이 영향을 주었는지 판단할 수 없게 됩니다. IPv6 네트워크에서 ‘어떤 앱은 정상이고 어떤 앱은 시간 초과’가 발생하면 클라이언트가 IPv6를 가로채는지와 설정에 관련 규칙이 있는지 확인합니다.
휴대폰에서 핫스팟을 켜도 핫스팟에 연결된 기기가 휴대폰의 VPN을 자동으로 사용하는 것은 아닙니다. 공유 여부는 Android 시스템 구현, 클라이언트 기능과 라우팅 권한에 따라 달라지므로 휴대폰 자체 접속이 정상이라는 이유만으로 핫스팟 기기도 규칙 설정된다고 판단할 수 없습니다. 안정적인 공유가 필요하면 각 기기에 클라이언트를 따로 설치하거나 투명 프록시를 명확히 지원하는 게이트웨이 방식을 사용하세요. LAN 접근이 실패하면 사설 주소 대역을 직접 연결로 유지하는 규칙인지도 확인해야 합니다.
모바일 플랫폼
iOS: App Store 설치, 구독 가져오기와 필요 시 연결
iPhone과 iPad에서는 iOS 다운로드 영역을 통해 Clash Plus의 App Store 페이지로 이동할 수 있으며, 클라이언트 공식 사이트는 clashplus.io입니다. 설치 후 처음 연결할 때 VPN 설정 추가를 요청합니다. 시스템에서 승인해야 클라이언트가 네트워크 확장을 만들 수 있습니다. iOS는 일반적으로 한 번에 하나의 활성 VPN만 유지하므로 기존 기업용 VPN, 개인 VPN 또는 콘텐츠 필터 도구가 서로 대체될 수 있습니다.
구독 가져오기 및 설정 활성화
구독 주소를 복사한 뒤 클라이언트의 설정 또는 구독 페이지에서 URL로 추가를 선택합니다. 붙여 넣을 때 메신저의 줄임표, 공백 또는 줄바꿈이 함께 들어가지 않았는지 확인하세요. 저장 후 업데이트를 실행하고 설정에 정책 그룹과 규칙이 표시되는지 확인한 다음 현재 설정으로 지정합니다. 일부 구독 링크는 Safari에서 클라이언트를 바로 호출할 수 있지만, 전체 주소를 확인하려면 직접 붙여 넣는 편이 더 편리합니다. 이동 후 클라이언트에 새 설정이 추가되지 않았다면 앱 안에서 URL 가져오기를 사용하고 형식 오류나 네트워크 오류가 표시되었는지 확인하세요.
연결을 시작한 뒤 먼저 규칙 모드를 선택할 수 있습니다. Safari를 열어 테스트하면서 클라이언트 연결 기록도 확인하세요. 웹페이지가 예상한 정책을 사용하지 않는다면 정책 그룹을 반복해서 바꾸기보다 먼저 어떤 규칙에 도메인이 매칭되었는지 확인합니다. Clash 규칙은 설정 순서에 따라 위에서 아래로 판단하며 처음 매칭된 규칙에서 멈춥니다. 뒤에 있는 규칙은 이미 결정된 결과를 덮어쓰지 않습니다. DOMAIN, IP-CIDR, GEOSITE와 MATCH의 차이를 이해하려면 Clash 사용자 규칙과 매칭 순서를 참고하세요.
필요 시 연결과 시스템 네트워크 전환
필요 시 연결을 지원하는 클라이언트는 셀룰러 네트워크나 지정한 무선 네트워크에서 자동으로 VPN을 시작할 수 있습니다. 설정하기 전에 먼저 수동으로 연결해 설정이 안정적인지 확인한 뒤 조건을 조금씩 추가하세요. 조건이 너무 넓으면 가정 내 LAN에서도 계속 트래픽을 가로챌 수 있고, 조건이 서로 충돌하면 연결과 해제가 반복됩니다. 신뢰할 수 있는 특정 무선 네트워크에서는 자동 연결을 원하지 않는다면 매번 수동으로 끄기보다 클라이언트가 제공하는 네트워크 예외를 사용하세요.
무선 네트워크에서 셀룰러 네트워크로 전환하면 iOS가 하위 인터페이스를 다시 만들기 때문에 기존 연결이 잠시 멈추는 것은 흔한 현상입니다. 오래 복구되지 않으면 VPN 설정을 삭제하지 말고 클라이언트에서 중지한 뒤 다시 시작해 보세요. 비행기 모드, 저데이터 모드와 시스템 수준의 네트워크 제한도 백그라운드 연결에 영향을 줍니다. 문제를 판단할 때는 먼저 일반 네트워크 자체가 정상인지 확인한 다음 클라이언트를 시작해 통신사나 무선 네트워크 문제를 구독 문제로 오해하지 않도록 합니다.
DNS 및 LAN 접근
iOS에서는 네트워크 확장이 DNS 요청을 가로챌 수 있으며, 구체적인 동작은 클라이언트 구현과 설정에 따라 달라집니다. Fake-IP 모드는 먼저 예약 주소를 반환하고 연결 단계에서 매핑을 바탕으로 도메인을 복원하므로 규칙 매칭에 유리합니다. 일부 LAN 기기, 프린터, 화면 미러링 서비스 또는 실제 주소에 의존하는 특수 앱과의 호환성 문제는 이때 발생할 수 있습니다. 해당 도메인을 Fake-IP 제외 목록에 추가하거나 LAN 도메인에 직접 연결용 DNS를 설정하세요. 변경 전 원래 설정을 기록하고 문제가 명확한 도메인에만 예외를 추가합니다.
가정용 라우터, 네트워크 저장 장치 또는 화면 미러링 기기에 접근할 때는 사설 주소 대역과 로컬 도메인이 직접 연결되도록 해야 합니다. 대표적인 사설 대역은 10.0.0.0/8, 172.16.0.0/12과 192.168.0.0/16입니다. 설정 앞부분의 일반 규칙이 이 주소를 프록시로 보내면 로컬 기기에서 시간 초과가 발생합니다. 규칙을 조정한 뒤 연결을 다시 수립해 DNS 매핑과 기존 세션을 함께 갱신하세요.
백그라운드 동작과 시스템 제한
iOS는 백그라운드 작업을 통합 관리하며, 클라이언트 화면을 닫았다고 이미 연결된 VPN 네트워크 확장이 중지되는 것은 아닙니다. 계속 실행 중인지 여부는 시스템 상태 표시줄, 제어 센터와 클라이언트 연결 상태를 기준으로 확인하세요. 반대로 앱 전환기에서 화면을 밀어 종료해도 시스템이 네트워크 확장을 유지할 수 있습니다. 중지하려면 클라이언트 안에서 끄거나 시스템 VPN 설정에서 연결을 해제해야 합니다. 이렇게 하면 ‘앱은 닫혔는데 네트워크는 계속 프록시를 사용한다’고 잘못 판단하는 일을 줄일 수 있습니다.
연결 스위치를 켜자마자 자동으로 꺼진다면 VPN 승인이 완료되지 않았거나, 다른 네트워크 확장이 선점했거나, 설정에서 코어를 시작하지 못했거나, 시스템 네트워크를 일시적으로 사용할 수 없는 경우가 흔합니다. 승인, 다른 VPN, 현재 설정과 로그를 순서대로 확인하세요. 모든 설정을 먼저 삭제하지 마세요. 시작 오류 로그가 DNS, 규칙 또는 설정 형식 문제를 직접 가리키는 경우가 많습니다. 더 자세한 iOS 사용 경로는 iPhone 구독 가져오기 단계에서도 확인할 수 있습니다.
데스크톱 및 서버
Linux: 그래픽 클라이언트, mihomo 코어와 서비스 관리
Linux 데스크톱에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있으며, 서버·라우터·GUI가 없는 환경에는 mihomo 코어를 직접 실행하는 방식이 더 적합합니다. 그래픽 클라이언트는 Linux 다운로드 영역에서 배포판에 맞는 설치 패키지를 받을 수 있습니다. 선택 전 CPU 아키텍처와 패키지 형식을 확인하세요. Debian, Ubuntu와 파생 배포판은 보통 deb를 사용하지만 다른 배포판은 다른 패키지 관리 방식을 사용할 수 있습니다. 코어 압축 파일도 AMD64, ARM64, ARMv7과 MIPS 등으로 나뉘며, 아키텍처가 틀리면 실행 파일이 바로 실행되지 않습니다.
데스크톱 클라이언트 설치
deb 패키지는 시스템 소프트웨어 센터로 설치하거나 터미널에서 패키지 관리 명령을 실행할 수 있습니다. 파일명은 실제로 다운로드된 파일을 기준으로 합니다:
sudo apt install ./clash-client-amd64.deb설치가 끝나면 앱 메뉴에서 실행하고 구독을 가져온 뒤 규칙 모드를 선택하세요. Linux 데스크톱 환경의 시스템 프록시 처리는 완전히 통일되어 있지 않습니다. GNOME, KDE, 브라우저, 터미널 도구와 샌드박스 앱이 서로 다른 설정을 읽을 수 있습니다. 클라이언트에 ‘시스템 프록시가 켜짐’으로 표시되어도 데스크톱 네트워크 설정에 값이 기록되었는지 확인하고 브라우저와 명령줄을 각각 테스트해야 합니다. Flatpak, 컨테이너 또는 원격 개발 환경에는 독립적인 네트워크 네임스페이스가 있을 수 있어 호스트의 프록시를 자동으로 상속하지 않습니다.
mihomo 직접 실행
GUI가 없는 환경에서는 먼저 mihomo 전용 폴더를 만들고 실행 파일과 config.yaml을 넣습니다. 실행 권한을 부여한 뒤 -d로 작업 디렉터리를 지정하세요. 아래 경로는 이해하기 쉬운 예시일 뿐이며 실제 시스템에 맞게 바꿀 수 있습니다:
sudo mkdir -p /etc/mihomo
sudo cp mihomo /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo
sudo cp config.yaml /etc/mihomo/config.yaml
mihomo -d /etc/mihomo처음 확인할 때는 포그라운드 실행이 적합합니다. 설정 구문 오류가 터미널에 바로 출력되기 때문입니다. 설정을 불러올 수 있고 포트가 수신 중이며 규칙과 DNS가 정상임을 확인한 뒤 서비스 관리자로 넘기세요. 처음부터 백그라운드에서 실행하면 시작 실패 원인을 로그로 간접적으로만 판단해야 합니다. 설정에서 참조하는 규칙 세트, Geo 데이터 파일과 상대 경로는 작업 디렉터리를 기준으로 하므로 실행 사용자에게 읽기 권한이 있는지 확인합니다.
systemd로 서비스 관리
장기간 실행해야 한다면 systemd 서비스를 만들 수 있습니다. 서비스 계정은 설정을 읽고 캐시에 기록할 권한을 가져야 하며, TUN을 활성화할 경우 필요한 네트워크 권한도 필요합니다. 최소 서비스 예시는 다음과 같습니다:
[Unit]
Description=mihomo service
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.target시스템 서비스 파일로 저장한 뒤 설정을 다시 불러오고 서비스를 시작합니다. systemctl status로 상태를 확인하고 journalctl로 로그를 확인하세요. 코어를 업데이트할 때는 먼저 서비스를 중지하고 파일을 교체한 뒤 다시 시작해 실행 중인 프로세스와 디스크 파일 상태가 어긋나지 않도록 합니다. 구독 업데이트도 완성된 설정을 먼저 생성하고 구문 검사를 마친 뒤 현재 파일을 교체해야 합니다. 잘못된 HTML 페이지나 불완전한 내용을 다운로드해 서비스가 종료되는 일을 막을 수 있습니다.
프록시 환경 변수와 서비스 적용 범위
데스크톱 시스템 프록시는 모든 Shell, SSH 세션, Docker 빌드 또는 systemd 서비스에 자동으로 적용되지 않습니다. 임시 명령에는 환경 변수를 사용할 수 있습니다:
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"socks5h는 도메인 해석을 SOCKS 서버 측에 맡긴다는 의미로, 로컬 DNS와 프록시 규칙이 서로 달라지는 문제를 줄일 수 있습니다. 장기간 설정하기 전 적용 범위를 명확히 하세요. Shell 설정에 기록하면 해당 사용자 세션에만 영향을 주고, systemd 서비스 환경에 기록하면 해당 서비스에만 영향을 주며, Docker 데몬에 설정하면 이미지 가져오기에 영향을 줍니다. 문제를 확인할 때 변수 값이 이전 포트를 가리키고 있지 않은지 확인하고, 대소문자가 다른 변수가 동시에 존재할 수 있다는 점에도 주의하세요.
TUN, 권한과 방화벽
Linux TUN은 가상 인터페이스, 정책 라우팅, DNS와 방화벽을 함께 다룹니다. 높은 권한으로 직접 실행하면 간단하지만, 장기 배포에서는 필요한 권한만 부여하고 서비스 계정을 제한하는 방식이 더 적합합니다. TUN 인터페이스 생성에 실패하면 커널이 TUN 장치를 제공하는지, 컨테이너가 해당 장치를 허용하는지, 서비스에 네트워크 관리 권한이 있는지 확인하세요. 인터페이스는 존재하지만 트래픽이 흐르지 않으면 라우팅 테이블, 정책 규칙과 방화벽 전달 체인을 점검합니다.
서버에서 다른 기기가 사용할 수 있도록 mixed-port를 열 때 모든 공인 인터페이스에서 수신하도록 기본 설정하지 마세요. 관리되는 LAN 주소에 우선 바인딩하고 방화벽으로 접근 출처를 제한하세요. 컨트롤 인터페이스도 보호해야 하며 신뢰할 수 없는 네트워크에 직접 노출해서는 안 됩니다. 일반적인 데스크톱 단일 기기 사용에서는 루프백 수신을 유지하는 것이 가장 간단합니다. LAN 공유가 명확히 필요할 때만 allow-lan을 켜고 접근 범위를 확인하세요.
문제 해결
자주 발생하는 설정 문제: 네트워크 진입점부터 규칙 결과까지 단계별 확인
Clash로 인터넷에 연결할 수 없을 때 가장 효과적인 방법은 클라이언트, 구독, DNS와 모드를 동시에 바꾸는 것이 아니라 데이터 경로를 따라 각 계층을 확인하는 것입니다. 전체 경로는 기기 기본 네트워크 → 클라이언트 코어 → 현재 설정 → 시스템 프록시 또는 TUN → DNS → 규칙 → 정책 그룹 → 프록시 서버 → 대상 서비스로 요약할 수 있습니다. 한 번에 한 계층만 확인해야 결과를 재현할 수 있습니다. 짧은 질문은 문제 해결 가이드에서 분류별로 확인할 수 있으며, 이 장에서는 모든 플랫폼에 적용되는 체계적인 문제 해결 순서를 설명합니다.
1단계: Clash를 끈 뒤 기본 네트워크가 작동하는지 확인
먼저 시스템 프록시, TUN 또는 모바일 VPN을 끄고 현재 무선 네트워크, 유선 네트워크 또는 셀룰러 네트워크로 일반 웹사이트에 직접 접속합니다. 직접 연결 자체가 되지 않으면 라우터, 통신사 네트워크, 로그인 인증 또는 시스템 네트워크 설정부터 수정해야 합니다. 공용 Wi-Fi는 먼저 웹페이지 인증을 완료해야 하는 경우가 많으며, TUN이 미리 트래픽을 가로채면 인증 페이지가 표시되지 않을 수 있습니다. 인증을 완료한 뒤 클라이언트를 시작하세요.
클라이언트를 껐는데도 인터넷이 되지 않으면 시스템 프록시가 남아 있는지 확인하세요. 데스크톱에서는 클라이언트가 종료되었는데도 127.0.0.1의 로컬 포트를 가리킬 수 있으며, 시스템 프록시를 읽는 모든 앱의 연결이 실패합니다. 클라이언트를 다시 실행해 시스템 프록시를 올바르게 끄거나 운영체제 네트워크 설정에서 프록시를 해제하세요. 모바일에서는 시스템 VPN 상태를 확인해 다른 네트워크 확장이 연결 중이지 않은지 확인합니다.
2단계: 코어와 설정이 시작되었는지 확인
클라이언트 창이 열린다고 코어가 반드시 실행 중인 것은 아닙니다. 상태 페이지에 실행 중으로 표시되는지, 로그에 설정 로드, 수신 포트 또는 시작 오류가 나타나는지 확인하세요. 흔한 실패 원인은 포트 사용 중, 잘못된 설정 구문, 규칙 세트 파일 누락, 데이터 폴더 권한 부족과 TUN 권한 부족입니다. 로그에 주소가 이미 사용 중이라고 나오면 다른 프록시 클라이언트를 먼저 종료하거나 같은 포트를 사용하는 프로세스를 찾아보세요. 포트를 여러 값으로 임의 변경한 뒤 시스템 프록시와 동기화하지 않는 일은 피해야 합니다.
현재 설정이 방금 가져온 대상 설정인지, 클라이언트 내장 예시나 이전 파일이 아닌지 확인하세요. 구독 항목이 존재해도 선택되지 않았다면 코어는 계속 이전 설정을 로드합니다. 구독 업데이트 후 시작에 실패하면 마지막으로 성공한 설정으로 돌아가 새 내용이 원인인지 확인할 수 있습니다. YAML은 들여쓰기에 민감하므로 직접 편집할 때 공백을 사용하고 계층을 일관되게 유지하세요. 탭과 잘못된 콜론 구조는 피해야 합니다.
3단계: 가로채기 실패와 프록시 서버 실패 구분
시스템 프록시를 켠 뒤 연결 기록에 브라우저 요청이 나타나는지 확인하세요. 기록이 전혀 없다면 트래픽이 클라이언트로 들어오지 않은 것이므로 시스템 프록시가 기록되었는지, 앱이 프록시를 읽는지, 수신 포트가 일치하는지 확인해야 합니다. 연결 기록에 요청은 나타나지만 계속 시간 초과가 발생한다면 매칭된 규칙, 정책 그룹과 프록시 서버를 계속 확인하세요. TUN 모드에서 기록이 없다면 가상 인터페이스, 라우팅과 권한을 우선 점검하고, 모바일에서는 VPN 승인과 앱별 프록시 목록을 확인합니다.
같은 기기에서 두 가지 방식으로 비교할 수 있습니다. 먼저 TUN을 끄고 시스템 프록시만 켜서 브라우저를 테스트한 다음, 시스템 프록시를 끄고 TUN만 켜서 같은 대상을 테스트하세요. 시스템 프록시는 되지만 TUN이 안 되면 구독과 대부분의 규칙에는 문제가 없을 가능성이 높으므로 TUN 권한, 라우팅과 DNS를 집중적으로 확인합니다. 반대로 TUN은 되지만 시스템 프록시가 작동하지 않으면 시스템 설정, 앱의 프록시 동작과 로컬 포트를 확인하세요.
4단계: DNS와 규칙 매칭 확인
도메인 접속만 실패하고 알려진 주소나 클라이언트 내장 연결 테스트는 작동한다면 DNS를 확인해야 합니다. 로그의 해석 시간 초과는 상위 서버 접근 불가, 초기 해석 실패, 포트 충돌 또는 DNS 요청이 가로채기되지 않은 데서 발생할 수 있습니다. 원래 구독의 DNS 설정으로 잠시 전환하면 사용자 설정이 원인인지 확인할 수 있습니다. 여러 리졸버, Fake-IP, 비공개 DNS와 시스템 암호화 DNS를 동시에 변경하지 마세요.
연결 기록에 요청이 DIRECT로 처리되었지만 PROXY가 예상된다면 실제로 매칭된 규칙을 확인하세요. 더 넓은 DOMAIN-SUFFIX, GEOSITE 또는 지역 규칙이 먼저 매칭되었을 수 있습니다. REJECT로 표시되면 광고 규칙 세트가 대상 도메인을 잘못 포함했는지 확인합니다. MATCH로 떨어졌다면 앞부분에 더 구체적인 규칙이 없다는 뜻입니다. 규칙을 조정한 뒤 다시 연결해야 하며, 이미 연결된 장시간 세션은 새 정책을 자동으로 사용하지 않습니다.
5단계: 구독과 프록시 서버 상태 확인
설정은 로드되지만 모든 프록시 요청이 실패한다면 먼저 구독을 한 번 업데이트하고 응답 오류를 확인하세요. 비정상적인 HTTP 상태, 빈 내용 또는 형식 오류는 구독을 가져오는 단계에 문제가 있다는 뜻입니다. 업데이트가 성공한 뒤 다른 정책 그룹 항목을 선택해 비교하되, 클라이언트 테스트 결과를 실제 속도와 동일하게 보지 마세요. 특정 테스트 주소가 대상 네트워크의 제한을 받거나 일상적인 웹사이트와 다른 경로를 사용할 수 있습니다.
특정 대상 서비스 하나만 실패한다면 도메인 규칙, 프로토콜 지원과 대상 서비스 자체의 상태를 확인하세요. 모든 대상이 연결 수립 단계에서 시간 초과될 때만 프록시 서버나 현재 네트워크가 차단했을 가능성이 커집니다. 로그의 timeout, connection refused와 DNS 오류는 의미가 서로 다르므로 모두 ‘노드가 작동하지 않는다’고 단정할 수 없습니다. 자주 나오는 로그 필드 설명과 함께 하나씩 판단하세요.
자주 발생하는 증상 비교
| 증상 | 가능한 원인 위치 | 처리 순서 |
|---|---|---|
| 클라이언트를 종료한 뒤 브라우저가 모두 실패함 | 시스템 프록시 잔류 | 시스템 프록시를 복원한 뒤 클라이언트 종료 설정 확인 |
| 브라우저는 되지만 게임 또는 터미널은 안 됨 | 앱이 시스템 프록시를 읽지 않음 | 앱 프록시를 설정하거나 충돌이 없는지 확인한 뒤 TUN 활성화 |
| TUN을 시작한 뒤 LAN 기기가 사라짐 | 사설 대역 라우팅 또는 DNS | LAN 직접 연결 규칙, 자동 라우팅과 Fake-IP 필터 확인 |
| 화면을 잠근 뒤 Android 연결이 끊김 | 백그라운드 및 배터리 제한 | 백그라운드 실행을 허용하고 클라이언트 자동 정리 끄기 |
| iOS 스위치가 즉시 다시 꺼짐 | VPN 승인, 설정 또는 확장 충돌 | 시스템 승인, 다른 VPN과 시작 로그 확인 |
| Linux 서비스가 반복해서 재시작됨 | 설정 해석, 권한 또는 경로 | 포그라운드에서 실행하고 처음 발견되는 명확한 오류 수정 |
필요한 정보만 충분히 수집
서비스 제공자나 커뮤니티에 문제를 설명할 때 운영체제, 클라이언트 이름, 트래픽 가로채기 방식, 프록시 모드, 문제가 시작된 시각, 모든 대상이 실패하는지와 로그의 첫 관련 오류를 알려야 합니다. 단순히 ‘작동하지 않는다’고만 쓰거나 전체 설정을 그대로 붙여 넣지 마세요. 구독 주소, 인증 필드와 프록시 정보는 가리세요. 문제가 안정적으로 재현된다면 ‘TUN을 끄면 브라우저는 정상이고, TUN을 켜면 모든 연결 기록이 비어 있다’처럼 가장 짧은 절차를 적는 것이 긴 무관 로그보다 문제를 찾는 데 도움이 됩니다.
로그 수준은 보통 info면 충분합니다. 복잡한 규칙이나 DNS 처리 과정을 추적해야 할 때만 잠시 상세 수준을 높이고, 끝나면 다시 낮춰 로그가 빠르게 쌓이지 않도록 하세요. 문제가 해결된 것을 확인한 뒤 사용자 DNS, 규칙 덮어쓰기, 시작 시 자동 실행과 다른 네트워크 도구를 하나씩 복원합니다. 항목을 하나 복원할 때마다 연결을 확인하면 최종적으로 원인을 설명할 수 있고 되돌리기도 쉬운 설정을 만들 수 있습니다.
초기화할 때와 재설치할 때
설정이 손상되었거나 클라이언트 데이터 폴더에 쓸 수 없거나 업그레이드 후 설정 구조가 이상해졌다면 먼저 필요한 설정을 내보낸 뒤 클라이언트가 제공하는 초기화 기능을 사용해 보세요. 프로그램을 재설치해도 데이터 폴더가 반드시 삭제되는 것은 아니므로 ‘재설치했는데 문제가 그대로’인 상황은 이상하지 않습니다. 반대로 데이터 폴더를 바로 삭제하면 구독, 덮어쓰기와 정책 선택이 사라지므로 먼저 복구 자료를 보관해야 합니다. 프로그램 파일, 보조 서비스 또는 시스템 구성 요소의 설치 자체가 잘못되었다고 확인된 경우에만 재설치가 합리적인 절차입니다.
문제 해결이 끝나면 ‘기존 클라이언트가 mixed 포트를 점유함’, ‘Android 백그라운드 제한으로 VPN이 종료됨’, ‘MATCH 앞에 너무 넓은 직접 연결 규칙이 있었음’처럼 최종 원인을 기록하는 것이 좋습니다. 이런 기록이 임시 설정을 대량으로 저장하는 것보다 훨씬 유용합니다. 나중에 플랫폼을 바꿀 때는 먼저 이 설명서의 공통 원리를 따라 최소한의 작동 설정을 만든 뒤 플랫폼별 기능을 추가하면 반복적인 문제 해결을 크게 줄일 수 있습니다.