Clash 문제 해결 가이드

인터넷에 연결되지 않음: 기본 네트워크와 프록시 경로 구분하기

프록시를 끄고 기존 네트워크부터 확인

웹페이지가 전혀 열리지 않으면 먼저 클라이언트의 시스템 프록시와 TUN을 끈 다음 메뉴에서 정상적으로 종료하세요. 시스템 프록시 설정이 남아 있지 않은지 확인하고, 평소 프록시 없이 접속할 수 있는 사이트를 열어 보세요. 그래도 연결되지 않으면 Wi-Fi, 게이트웨이, 학교 네트워크 인증 또는 인터넷 회선 문제부터 해결해야 합니다. 프록시 클라이언트가 기본 네트워크 연결을 대신할 수는 없습니다. 공용 Wi-Fi는 먼저 로그인해야 하는 경우가 많고, 인증 페이지가 프록시를 거칠 수도 있습니다. 프록시를 끄고 인증을 마친 뒤 다시 테스트하세요.

프록시를 끈 뒤 인터넷이 복구되면 문제 범위는 프록시 진입점, 코어 또는 설정으로 좁혀집니다. 클라이언트를 다시 시작하되 모든 기능을 한꺼번에 켜지는 마세요. 로그에서 설정을 정상적으로 불러왔는지, 수신 포트를 열었는지 확인하세요. 창이 정상적으로 표시된다는 것은 그래픽 인터페이스가 실행 중이라는 뜻일 뿐, 코어가 시작되었다는 보장은 없습니다. 포트 충돌, 설정 문법 오류, 권한 부족으로 인터페이스는 떠 있어도 프록시 서비스를 사용할 수 없는 경우가 있습니다.

명시적 프록시 요청으로 시스템 설정 우회하기

설정에서 실제 혼합 포트를 확인하세요. 아래 예시는 로컬 주소와 포트 7890을 사용합니다. 클라이언트의 포트가 다르면 해당 값으로 바꾸세요. 이 명령은 HTTP 프록시를 직접 지정해 시스템 프록시나 브라우저 확장 등의 변수를 잠시 제외합니다. Windows에서는 일부 PowerShell 환경에서 curl이 다른 명령으로 해석되는 것을 피하려고 curl.exe를 사용하세요. 다른 데스크톱 운영체제에서는 보통 curl을 사용합니다.

# Windows PowerShell
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

# macOS / Linux
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

로컬 포트 연결에 실패했다면 요청이 원격 노드에 도달하기 전 단계에서 막힌 것입니다. 코어 실행 여부와 수신 주소 및 포트가 맞는지 확인하세요. 프록시 터널이 만들어진 뒤 원격 연결이 시간 초과된다면 노드와 규칙을 살펴보세요. HTTP 응답을 받았다는 것은 해당 요청이 성공했다는 뜻이지만, 사이트 하나만으로 네트워크 전체가 정상이라고 판단할 수는 없습니다. 실제로 열리지 않는 대상도 테스트하고 클라이언트 연결 기록에서 어떤 정책이 적용됐는지 확인하세요.

규칙, 정책 그룹, 복구 순서 확인

프록시 화면에서 현재 정책 그룹을 확인하세요. REJECT가 선택되어 있거나 삭제된 노드를 참조하고 있지 않은지 살펴보세요. 설정을 업데이트한 뒤에도 화면에 이전 선택이 남아 있을 수 있습니다. 작동이 확인된 정책을 임시로 선택해 비교하세요. 전역 모드에서는 접속되지만 규칙 모드에서는 안 된다면 어떤 규칙이 적용됐는지, 최종 출구가 무엇인지 확인하세요. 설치 파일을 계속 바꿔 보는 것은 해결책이 아닙니다. 테스트가 끝나면 원래 모드로 되돌려 임시 상태를 최종 해결로 착각하지 않도록 하세요.

TUN을 켰을 때만 인터넷이 끊긴다면 TUN을 끄고 시스템 프록시만 사용해 확인하세요. 시스템 프록시가 작동한다면 구독이 잘못됐다고 단정하기보다 가상 네트워크 어댑터 권한, 라우팅 충돌, 다른 VPN부터 살펴보세요. 회사 보안 프로그램, 가상 머신 네트워크, 다른 터널링 도구도 라우팅에 영향을 줄 수 있습니다. 네트워크 어댑터를 전부 삭제하지 마세요. 충돌하는 앱을 먼저 종료하고 작업을 저장한 뒤 시스템을 재시작한 다음, 필요한 네트워크 도구를 하나씩 다시 켜세요.

권장 복구 순서: TUN 끄기 → 시스템 프록시 끄기 → 클라이언트 정상 종료 → 시스템 프록시 설정 잔존 여부 확인 → 직접 연결 테스트. 네트워크 스택 초기화는 마지막 수단으로 남겨 두고, 먼저 고정 IP 주소, DNS, 회사 네트워크 설정을 기록하세요.

마지막 테스트에는 두 가지 대상이 포함되어야 합니다. 원래 직접 연결할 수 있던 사이트 하나와 현재 프록시 정책이 필요한 사이트 하나를 확인하세요. 시간, 모드, 대상, 결과를 기록해 사이트 자체의 장애를 클라이언트 전체 문제로 오해하지 않도록 하세요. 여전히 판단하기 어렵다면 자주 묻는 질문에서 시스템 프록시와 TUN의 역할을 확인한 뒤 다음 항목에서 구체적인 시간 초과 단계를 살펴보세요.

노드 시간 초과: DNS 조회·연결·핸드셰이크 단계 구분하기

어느 단계에서 시간 초과되는지 확인

노드 속도 측정이 시간 초과됐다고 해서 노드가 영구적으로 작동하지 않는 것은 아닙니다. 속도 측정에는 서버 도메인 조회, 서버 연결, 프로토콜 핸드셰이크, 테스트 주소 접속 등 여러 단계가 포함되며, 어느 단계에서든 실패하면 비슷한 결과가 나올 수 있습니다. 로그를 열고 테스트를 한 번 직접 실행한 뒤 같은 시간대의 기록을 찾으세요. 한 번의 테스트에서 노드, 네트워크, DNS를 동시에 바꾸면 성공하더라도 어떤 변경이 효과가 있었는지 알 수 없습니다.

dial tcp 뒤에 i/o timeout이 표시되면 일반적으로 제한 시간 안에 TCP 연결을 완료하지 못했다는 뜻입니다. 단, 표시된 주소가 노드 서버인지 최종 대상인지 확인해야 합니다. 노드 서버 주소라면 기기에서 서버까지의 네트워크 경로를 점검하세요. 대상 사이트 주소라면 노드 접속 단계는 이미 통과했을 수 있습니다. connection refused는 대상 포트가 연결을 거부했을 가능성이 높습니다. 응답 없이 패킷이 손실된 시간 초과와는 원인과 해결 방향이 다릅니다.

구독과 서버 진입점 확인

먼저 구독이 정상적으로 업데이트되고 서비스가 유효한지 확인한 다음, 선택한 노드의 서버 도메인과 포트가 제공업체의 최신 설정과 일치하는지 살펴보세요. 익숙하다는 이유로 프로토콜 필드를 임의로 추가하지 마세요. TLS 서버 이름, WebSocket 경로, 전송 방식은 서로 연관된 경우가 많습니다. 어느 하나를 임의로 바꾸면 TCP 연결은 되더라도 핸드셰이크가 실패할 수 있습니다. 구독에서 가져온 노드라면 제공업체의 원본 설정을 다시 받는 것이 우선입니다. 직접 수정하기 전에는 사본을 보관하고 이유를 기록하세요.

시스템 도구로 포트 연결 여부를 확인할 수 있지만, 접근 권한이 있는 서버만 테스트하세요. Windows의 Test-NetConnection으로 TCP 포트에 연결할 수 있는지 확인할 수 있습니다. 하지만 프록시 인증, 암호화 매개변수, 대상 사이트까지 검증하는 것은 아닙니다. 일부 프로토콜은 주로 UDP를 사용하므로 TCP 테스트만으로 상태를 판단할 수 없습니다. 서버가 ping에 응답하지 않아도 프록시 포트가 작동할 수 있습니다. ICMP 결과만으로 결론 내리지 마세요.

교차 테스트로 네트워크와 노드 분리하기

클라이언트, 설정, 노드는 그대로 두고 컴퓨터를 기존 Wi-Fi에서 휴대전화 핫스팟으로 바꾼 뒤 같은 대상에 접속하세요. 핫스팟에서는 되고 기존 네트워크에서는 실패한다면 기존 네트워크의 외부 연결 정책, UDP 제한, 인증 상태를 중점적으로 확인하세요. 두 네트워크에서 모두 실패하면 같은 구독에 있는 다른 진입점의 노드를 선택해 보세요. 여러 노드가 같은 서버 도메인을 사용한다면 서로 독립적인 테스트 대상이 아닙니다. 모두 실패해도 공통 진입점 문제일 수 있습니다.

속도 측정은 실패했지만 웹페이지가 열린다면 측정 주소에 접속할 수 있는지, 규칙에 따라 직접 연결되는지, 접근 제한이 있는지 확인하세요. 상태 확인은 지정된 주소만 테스트하며 인터넷 서비스 전체를 측정하는 것은 아닙니다. 시간 초과를 계속 늘려 안정적인 오류를 감추지 마세요. 네트워크가 실제로 느린지 확인할 때는 대기 시간을 늘릴 수 있지만, 잘못된 포트나 인증 정보, 조회할 수 없는 서버 도메인에는 도움이 되지 않습니다.

TLS 인증서 오류가 발생하면 먼저 시스템 날짜, 시간, 시간대를 동기화한 다음 설정의 서버 이름을 확인하세요. 인증서 검증을 건너뛰는 방법은 일반적인 해결책으로 사용하지 마세요. 연결 상대의 신원을 확인하는 기능이 약해집니다. 로그를 자세히 읽는 순서는 Clash 실행 로그로 문제 위치 찾기를 참고하세요. 제공업체에 문의할 때는 발생 시간, 연결 네트워크, 민감 정보를 가린 오류 내용을 전달하세요. 구독 주소 전체나 인증 필드는 보내지 마세요.

구독 업데이트 실패: 다운로드·형식·설정 불러오기 확인

다운로드 실패와 설정 파싱 실패 구분하기

구독을 가져오지 못하는 원인은 대개 두 가지입니다. 클라이언트가 콘텐츠를 받지 못했거나, 콘텐츠를 받았지만 설정으로 파싱하지 못한 경우입니다. 오류가 다운로드 단계와 설정 불러오기 단계 중 어디서 발생했는지 먼저 확인하세요. HTTP 상태 코드, 연결 시간 초과, 인증서 오류는 다운로드 문제의 단서입니다. 줄 번호, 들여쓰기, 알 수 없는 필드, 존재하지 않는 정책 그룹 참조는 파싱 문제에 가깝습니다. 화면에 업데이트 실패라고만 표시되면 로그에서 구체적인 원인을 확인하세요. 설정을 모두 삭제하고 다시 가져오지는 마세요.

제공업체에서 구독 주소 전체를 복사하세요. 메신저를 거치면서 주소 끝에 공백, 줄바꿈, 문장 부호가 붙지 않았는지도 확인하세요. 일부 링크에는 계정 인증 정보가 포함되므로 주소 전체를 민감 정보로 취급해야 합니다. 공개 게시판이나 온라인 검색창, 스크린샷에 올리지 마세요. 주소가 이미 공개됐다면 제공업체에서 폐기하거나 재설정하세요. 개인 구독 정보를 모르는 변환 사이트에 함부로 제출하지 마세요. 변환 서비스가 노드와 인증 정보에 접근할 수 있습니다.

응답 결과에 따라 다음 단계 선택하기

401 또는 403이 표시되면 계정 상태, 링크 유효성, 제공업체의 접근 조건을 먼저 확인하세요. 404라면 주소가 이전됐거나 복사 과정에서 잘리지 않았는지 확인하고, 429라면 연속으로 요청하지 말고 서비스 안내에 따라 기다리세요. 상태 코드는 문제를 좁히는 단서일 뿐이므로 응답 내용도 함께 확인해야 합니다. 성공 상태가 반환되어도 설정 파일이라는 보장은 없습니다. 로그인 페이지, 인증 페이지, 오류 안내도 일반 웹페이지로 반환될 수 있습니다.

브라우저에서는 다운로드되지만 클라이언트에서 실패한다면 두 요청이 같은 경로로 나가는지 확인하세요. 브라우저는 별도 확장 프로그램, 로그인 세션, 시스템 프록시를 사용할 수 있지만 클라이언트의 구독 업데이트는 직접 연결을 사용할 수 있습니다. 반대 상황도 가능합니다. 업데이트 요청에 프록시가 필요하다는 점을 확인한 경우에만 클라이언트에서 해당 구독 다운로드 프록시 옵션을 켜세요. 기존 노드가 모두 작동하지 않는데 그 노드를 통해 구독을 업데이트하도록 설정하면 순환 문제가 생깁니다. 신뢰할 수 있고 사용할 수 있는 네트워크에서 직접 업데이트를 시도하세요.

YAML 구조와 코어 기능 확인

파일을 다운로드했다면 먼저 Clash YAML 설정인지 노드 공유 링크 모음인지 확인하세요. 둘은 서로 바꿔 쓸 수 없습니다. YAML은 공백으로 계층을 표현하므로 탭 문자를 섞지 마세요. 특수 문자가 포함된 문자열은 올바르게 따옴표로 묶어야 합니다. 특정 줄에 오류가 표시되더라도 위쪽 몇 줄까지 함께 확인하세요. 콜론, 따옴표, 목록 표시가 누락된 위치가 오류 표시 줄보다 앞일 수 있습니다.

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

이 내용은 최상위 기본 필드 예시일 뿐, 노드와 정책 그룹이 없어 원격 프록시를 구성할 수 없습니다. 합칠 때 파일에 같은 최상위 키가 이미 있는지 확인해 rules나 dns가 중복으로 생기지 않도록 하세요. 규칙에서 참조하는 정책 이름은 프록시 그룹 이름과 일치해야 합니다. 이름의 공백과 대소문자도 그대로 유지하세요. YAML 구조가 익숙하지 않다면 설정 파일 구조 자세히 알아보기를 참고해 항목별로 확인하세요.

오류에 지원되지 않는 프로토콜이나 필드가 표시되면 클라이언트 창에 보이는 이름만 보지 말고 실제로 어떤 코어가 실행 중인지 확인하세요. 그래픽 클라이언트와 코어는 지원 기능이 다를 수 있으며, 구형 코어는 제공업체가 새로 추가한 설정을 지원하지 않을 수 있습니다. 코어를 바꿔야 한다면 클라이언트 페이지에서 시스템에 맞는 설치 파일을 선택하세요. 우선 Clash Plus를 고려할 수 있습니다. 해당 클라이언트가 명시적으로 지원하지 않는 한 새 코어 파일을 구형 클라이언트 폴더에 임의로 넣지 마세요.

자동 업데이트가 수동 변경 사항을 덮어쓰는 경우도 흔합니다. 구독 파일은 보통 원격 콘텐츠를 바탕으로 다시 생성되므로, 변경 사항을 유지하려면 클라이언트가 지원하는 오버라이드 또는 병합 기능을 사용하세요. 다운로드 캐시를 계속 수정하는 방법은 적절하지 않습니다. 수정 후 수동 업데이트를 한 번 실행하고 코어를 다시 시작해 다운로드와 설정 불러오기가 모두 되는지 확인하세요. 최근에 정상적으로 작동한 설정은 보관하되, 만료된 구독이 백그라운드에서 계속 재시도해 요청 제한에 걸리고 새로운 네트워크 문제로 오인되지 않게 하세요.

연결 속도 저하: 지연 시간·대역폭·앱 동작 구분하기

어떤 종류의 속도 저하인지 먼저 확인

웹페이지가 열리기까지 오래 걸리는 현상, 다운로드 속도 저하, 동영상 재생 중 버퍼링, 게임 조작 지연은 서로 다른 문제입니다. 재현 가능한 상황을 먼저 정리하세요. 첫 접속만 느린지, 모든 사이트가 느린지, 저녁에만 발생하는지, Wi-Fi를 바꾸면 해결되는지 확인하세요. 노드 속도 측정은 특정 요청이 완료되는 시간을 확인하는 경우가 많습니다. 지속적인 다운로드 속도를 그대로 예측할 수 없으며 지연 시간 하나만으로 모든 앱의 체감 속도를 설명할 수도 없습니다.

노드와 대상을 그대로 둔 채 기본 네트워크부터 확인하세요. 노트북이 라우터에서 멀리 떨어져 있거나 Wi-Fi 채널이 혼잡하거나, 백그라운드에서 클라우드 동기화와 시스템 업데이트가 실행 중이면 대역폭을 사용할 수 있습니다. 같은 기기에서 동일한 대상을 직접 연결로 접속한 결과와 프록시를 거친 결과를 여러 번 기록하세요. 서로 다른 사이트, 파일, 시간대의 다운로드 속도를 그대로 비교하지 마세요. 대상 서버의 위치, 속도 제한, 캐시 정책도 결과에 차이를 만듭니다.

연결 기록에서 실제 출구 확인

앱 요청이 예상한 정책을 실제로 거치는지 확인하세요. 웹페이지 본문, 이미지, 동영상 조각 파일, 로그인 API가 서로 다른 도메인에서 제공되어 각기 다른 규칙이 적용될 수 있습니다. 따라서 첫 화면이 빨리 열린다고 동영상 스트리밍도 같은 경로를 이용한다고 볼 수는 없습니다. 연결 기록을 앱이나 도메인별로 필터링해 최종 정책 그룹과 출구를 확인하세요. 일부 리소스만 잘못 분기됐다면 규칙을 수정하세요. 리소스 하나가 느리다고 모든 연결을 전역 프록시로 바꾸지는 마세요.

자동 선택 그룹 때문에 결과를 잘못 해석할 수도 있습니다. 정책 그룹의 확인 주소, 확인 주기, 사용 가능 여부 판단 기준에 따라 선택 결과가 달라지며 현재 작업에 최적화되어 있지 않을 수 있습니다. 짧은 시간 동안 작동이 확인된 노드를 수동으로 고정하면 테스트 중 자동 전환으로 변수가 생기는 일을 막을 수 있습니다. 노드를 바꿔도 앱에서 이미 만들어진 장시간 연결은 이전 출구를 계속 사용할 수 있습니다. 해당 페이지를 닫거나 앱을 다시 연결해 새 연결을 만든 뒤 확인하세요. 선택 버튼 상태만 보아서는 안 됩니다.

프로토콜, UDP, 네트워크 경로 차이 이해하기

일부 브라우저와 동영상 앱은 QUIC를 시도하며, 이 트래픽은 UDP를 사용합니다. 접속 네트워크나 노드가 필요한 UDP 전달을 지원하지 않으면 연결이 다른 방식으로 전환될 때까지 지연되거나 일부 리소스가 느리게 로드되거나 연결이 반복해서 재시도될 수 있습니다. 먼저 로그에서 사용된 프로토콜을 확인하고 노드와 클라이언트가 해당 기능을 지원하는지 살펴보세요. 웹페이지 하나를 확인하려고 모든 UDP를 전역 차단하지 마세요. 제어 가능한 앱에서 해당 프로토콜을 잠시 끄고 비교한 뒤 테스트를 마치면 원래 설정으로 되돌리세요.

TUN을 사용할 때만 눈에 띄게 느려진다면 라우팅 루프, 경로 MTU, 네트워크 어댑터 충돌을 확인하세요. 간단한 페이지는 열리지만 큰 파일 전송이 멈추거나, 특정 네트워크에서만 문제가 발생하는 것이 단서가 될 수 있습니다. 다른 VPN을 먼저 끄고 시스템 프록시 경로와 TUN 경로를 비교하세요. MTU를 변경하기 전에는 클라이언트와 코어 문서를 확인하고 기존 값을 기록해 두세요. 인터넷에서 찾은 고정값을 그대로 적용하면 다른 네트워크 경로가 느려져 안정적인 해결이 되지 않을 수 있습니다.

서버까지의 거리, 네트워크 간 연결, 피크 시간대 혼잡도도 성능에 영향을 줍니다. 같은 노드에서 여러 기기와 접속 네트워크를 사용해 같은 대상에 접속해도 결과가 나쁘고, 다른 노드는 정상일 때 제공업체에 회선 문제를 문의할 근거가 더 확실해집니다. 문의할 때는 테스트 시간, 대상, 연결 방식, 재현 가능한 증상을 알려주세요. 속도가 매우 느리다는 말만으로는 원인을 파악하기 어렵습니다. 처리량 수치를 임의로 만들거나 일시적인 최고 속도를 지속 가능한 대역폭으로 간주하지 마세요.

테스트에 사용한 임시 변경 사항은 마지막에 모두 되돌리세요. 전역 모드, 앱 프로토콜 설정, 수동으로 고정한 정책을 원래대로 복구한 뒤 실제 사용 환경에서 계속 확인하세요. 문제를 설명하는 데 필요한 최소한의 변경만 남기세요. DNS 일괄 변경, 네트워크 어댑터 설정 수정, 코어 교체, 클라이언트 재설치를 한꺼번에 하면 빨리 해결하는 것처럼 보여도 재현이 불가능해집니다. 다음 네트워크 변경 후 문제가 생겨도 원인을 찾기 어려워집니다.

DNS 문제: 실제 DNS 요청이 거치는 경로 찾기

도메인이 열리지 않아도 모든 DNS 서버부터 바꾸지는 마세요

DNS 문제는 도메인을 찾지 못하거나 일부 사이트의 첫 접속이 멈추거나 노드 서버 주소를 조회하지 못하는 형태로 나타납니다. 먼저 대상 도메인과 노드 도메인 중 어느 쪽에서 문제가 발생하는지 확인하세요. 둘은 서로 다른 DNS 경로를 사용할 수 있습니다. 시스템 DNS, 브라우저 보안 DNS, 클라이언트 내장 DNS, 앱 자체 DNS가 동시에 작동할 수도 있습니다. 시스템 설정을 바꿔도 달라지지 않는다면 설정이 적용되지 않은 것이 아니라 앱이 해당 경로를 사용하지 않는 것일 수 있습니다.

Windows에서는 nslookup example.com을, 해당 도구를 사용할 수 있는 macOS 또는 Linux에서는 dig example.com을 실행해 시스템의 조회 결과를 확인할 수 있습니다. 이 도구가 보여 주는 것은 해당 조회 경로뿐이며 브라우저나 TUN의 DNS 동작을 직접 증명하지는 않습니다. 사용한 서버, 응답 결과, 오류를 기록한 뒤 클라이언트 로그와 비교하세요. 서로 다른 DNS 경로에서 다른 주소가 반환된다고 항상 비정상인 것은 아닙니다. CDN은 지역에 따라 다른 주소를 반환할 수 있습니다.

Fake-IP와 실제 주소의 차이 이해하기

Fake-IP 모드에서는 도메인에 예약된 주소를 할당하고 코어에 매핑을 저장합니다. 이후 이 매핑으로 대상 도메인을 복원해 라우팅합니다. 따라서 예약 주소가 보인다고 해서 웹사이트 서버가 실제로 해당 네트워크에 있는 것은 아닙니다. 연결을 시작한 앱의 트래픽이 해당 매핑을 관리하는 코어를 계속 통과하는지가 중요합니다. 클라이언트를 종료한 뒤 시스템이나 앱에 합성 주소가 캐시되어 있으면 일시적으로 연결되지 않을 수 있습니다. 이 경우 정상적인 DNS 경로를 복구하고 관련 캐시를 비워야 합니다.

로컬 네트워크 기기 검색, 프린터 서비스, 실제 주소가 필요한 일부 앱은 합성 주소를 일괄 적용하기에 적합하지 않을 수 있습니다. 모든 도메인을 제외하기보다 문제가 발생하는 도메인과 증상을 먼저 확인한 뒤 코어가 지원하는 규칙에 따라 fake-ip-filter에 추가하세요. 필터 문법과 정책 지원 여부는 현재 사용하는 코어를 기준으로 확인해야 합니다. 원리와 적용 범위는 Fake-IP와 redir-host 비교를 참고하세요.

설정, 상위 DNS, 시작 단계 의존성 확인

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

아래 예시는 로컬 DNS 수신과 상위 DNS 설정 방법을 보여 줍니다. 상위 서버에 연결할 수 있는지는 현재 네트워크에 따라 달라집니다. 1053 포트에서 수신한다고 시스템의 모든 DNS 요청이 자동으로 이곳에 전달되는 것은 아닙니다. 시스템 설정, TUN의 DNS 가로채기 또는 다른 전달 방식을 별도로 연결해야 합니다. 접근 제어 없이 DNS 수신 포트를 공용 네트워크에 노출하지 마세요. 로컬 루프백 주소를 다른 기기의 DNS 주소로 입력해서도 안 됩니다.

암호화 DNS를 사용할 때는 시작 단계 의존성도 고려해야 합니다. 상위 서버의 도메인을 먼저 조회해야 할 수 있고, 상위 서버 연결이 아직 사용할 수 없는 프록시에 의존할 수도 있습니다. 순환 의존성이 생기면 코어가 지원하는 부트스트랩 DNS와 노드 도메인 조회 필드를 나눠 설정하고 상위 서버에 연결할 수 있는지 먼저 확인하세요. 운에 맡기고 DNS 서버를 많이 추가하지 마세요. 서버가 많아지면 변수가 늘어나며 잘못된 라우팅 문제도 해결되지 않습니다. 회사 내부 도메인은 보통 조직에서 지정한 DNS 경로를 유지해야 합니다.

IPv6도 별도로 확인하세요. 도메인에서 IPv4와 IPv6 주소를 모두 반환하면 기기가 실제로 사용할 수 없는 경로를 먼저 시도할 수 있습니다. 두 주소 계열의 연결 결과를 비교한 다음 라우팅, 노드 지원 여부, 클라이언트 설정을 확인하세요. IPv6를 끄는 것을 모든 DNS 문제의 표준 해결책으로 삼지 마세요. 임시 테스트를 위해 꺼야 한다면 기존 상태를 기록하고 로컬 네트워크나 다른 서비스에 영향이 없는지 확인하세요.

캐시 정리는 DNS 경로를 바로잡은 다음에 하세요. 앱의 재시도를 멈추고 시스템에서 지원하는 방법으로 캐시를 새로 고친 뒤 앱을 다시 열어 새 DNS 요청을 생성하세요. 캐시를 반복해서 비워도 연결할 수 없는 상위 서버나 잘못된 DNS 가로채기는 해결되지 않습니다.

마지막으로 일반 도메인, 이전에 실패한 도메인, 필요한 내부 도메인을 모두 확인하세요. DNS 조회에 성공한 것만으로는 충분하지 않습니다. 올바른 정책이 적용되고 요청이 완료됐는지도 확인해야 합니다. 브라우저에서만 문제가 발생하면 보안 DNS와 확장 프로그램 설정을 잠시 비교하세요. TUN에서만 발생한다면 DNS 가로채기와 라우팅 경로를 다시 확인하고, 현재 문제와 무관한 구독 노드 설정은 더 이상 변경하지 마세요.

시스템 프록시가 작동하지 않음: 진입점·앱·라우팅 범위 확인

시스템 프록시 설정만으로 모든 트래픽이 프록시를 통과하지는 않습니다

시스템 프록시는 운영체제 설정을 따르는 앱에 프록시 진입점을 제공합니다. 일부 명령줄 프로그램, 게임, 백그라운드 서비스, 자체 네트워크 설정이 있는 앱은 시스템 프록시를 읽지 않습니다. 따라서 브라우저는 되는데 터미널은 안 된다고 해서 반드시 클라이언트 문제인 것은 아닙니다. 첫 번째 항목의 명시적 프록시 명령으로 로컬 진입점을 테스트하세요. 진입점이 정상이라면 대상 앱이 시스템 프록시를 지원하는지, 별도로 프록시를 설정해야 하는지, TUN으로 트래픽을 처리해야 하는지 확인하세요.

Windows에서는 시스템 네트워크 설정에서 수동 프록시 주소와 포트를 확인하세요. macOS에서는 현재 사용하는 네트워크 서비스의 프록시 설정을 확인하고, Linux 데스크톱 설정은 데스크톱 환경과 앱에 따라 다릅니다. Wi-Fi와 유선 네트워크의 설정 항목이 다를 수 있으므로 네트워크를 바꾼 뒤 이전 화면만 확인하지 마세요. 자동 프록시 스크립트를 사용하는 환경에서는 스크립트 주소와 수동 HTTP 프록시를 구분해야 합니다. 두 방식이 동시에 적용되면 결과가 달라질 수 있습니다.

로컬 수신 포트와 환경 변수 확인

일반적으로 로컬 클라이언트 포트에는 127.0.0.1로 접속합니다. 이 주소는 로컬 네트워크 주소와 용도가 다릅니다. 다른 기기에서 접속해야 하는 경우에만 allow-lan과 수신 범위를 설정하세요. 로컬 시스템 프록시가 작동하지 않는다고 해서 LAN 허용을 켜도 잘못된 포트가 해결되지는 않습니다. 오히려 접근 범위가 넓어질 수 있으므로 먼저 로컬 경로가 올바른지 확인한 뒤 신뢰할 수 있는 네트워크에서 공유 기능을 별도로 설정하세요.

# 현재 macOS / Linux 셸과 하위 프로세스에만 적용
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

# 테스트가 끝나면 현재 셸의 설정을 원래대로 복구
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

위 환경 변수는 이를 지원하는 프로그램이 읽는 값이며 모든 트래픽을 강제로 다른 경로로 보내지는 않습니다. 일부 프로그램은 소문자 변수만 읽고, 자체 설정 파일을 사용하는 프로그램도 있습니다. 여러 종류의 변수를 한꺼번에 설정하기보다 대상 프로그램의 문서를 확인하세요. 여기서 HTTPS_PROXY 값에 http://를 사용해도 됩니다. 로컬 HTTP 프록시에 연결한 뒤 프록시가 터널을 만드는 방식이며 대상 사이트를 일반 HTTP로 낮추는 것은 아닙니다.

여러 프록시 설정이 서로 덮어쓰는지 확인

브라우저 확장 프로그램, 이전 클라이언트, 회사 프록시 스크립트, 시작 프로그램이 시스템 프록시 설정을 다시 쓸 수 있습니다. 설정을 켜자마자 원래대로 바뀐다면 다른 프록시 도구를 종료한 뒤 백그라운드 프로세스와 시작 앱 목록을 확인하세요. 브라우저 확장 프로그램은 비교를 위해 잠시 꺼 볼 수 있지만, 회사에서 설치를 강제한 네트워크 구성 요소는 삭제하지 마세요. 관리되는 기기는 조직 정책을 따라야 하며, 보안 서비스를 꺼서 기존 제한을 우회하면 안 됩니다.

TUN이 필요하다면 먼저 클라이언트가 지원하는지, 서비스가 설치되어 있는지, 운영체제에서 요구하는 권한을 받았는지 확인하세요. TUN은 가상 네트워크 인터페이스와 라우팅으로 트래픽을 처리하므로 시스템 프록시와는 다르게 작동합니다. 규칙, DNS, 제외 라우트의 영향도 받습니다. TUN을 모든 문제를 자동으로 해결하는 스위치로 생각하지 마세요. 켠 뒤 로컬 기기에 연결할 수 없다면 로컬 네트워크 라우팅과 제외 규칙을 확인하세요. 내부 네트워크 전체를 원격 프록시로 보내지는 마세요.

가상 머신, 컨테이너, 하위 시스템에는 각각 별도의 네트워크 경계가 있습니다. 컨테이너 내부의 127.0.0.1은 호스트가 아니라 컨테이너 자신을 가리킵니다. 가상 머신이 호스트의 시스템 프록시 설정을 그대로 사용하는 것도 아닙니다. 해당 환경에서 지원하는 호스트 접근 주소를 사용하고 필요한 경우 수신 범위와 방화벽을 설정하세요. 네트워크 모드마다 접속 방법이 다르므로 호스트 명령 하나를 모든 컨테이너에 그대로 복사하지 마세요.

휴대전화나 TV에서 컴퓨터의 프록시를 사용하려면 먼저 두 기기가 같은 신뢰할 수 있는 네트워크에 있는지 확인하세요. 컴퓨터에서 LAN 접속을 허용하고 방화벽은 필요한 기기에서 오는 연결만 허용해야 합니다. 연결하는 기기에는 루프백 주소가 아니라 컴퓨터의 로컬 네트워크 주소를 입력하세요. 자세한 설정은 혼합 포트와 로컬 네트워크 공유 설정을 참고하세요. 테스트가 끝나면 더 이상 필요하지 않은 공유 진입점을 닫아 열어 둔 채 잊지 않도록 하세요.

최종 판단 기준은 대상 앱의 새 연결이 클라이언트 기록에 나타나는지, 그리고 어떤 정책이 적용되는지입니다. 로그에 요청이 전혀 없다면 앱의 프록시 진입점을 확인하세요. 요청은 있지만 출구가 잘못됐다면 규칙을 살펴보세요. 출구가 올바른데도 실패하면 노드를 확인하세요. 이 세 경계를 따라 점검하면 시스템 프록시 스위치를 반복해서 누르는 것보다 결과를 이해하기 쉽습니다.

클라이언트 충돌: 인터페이스·코어·시스템 구성 요소 구분하기

어느 부분이 종료됐는지 먼저 확인

창이 사라지는 경우, 창이 멈추는 경우, 시스템 트레이에는 남아 있지만 프록시가 작동하지 않는 경우는 서로 다릅니다. 그래픽 인터페이스가 종료되어도 코어는 백그라운드에서 계속 실행될 수 있으며, 코어가 종료되어도 인터페이스는 남아 있을 수 있습니다. 작업 관리자나 활성 상태 보기에서 관련 프로세스를 확인한 뒤 클라이언트 로그의 마지막 몇 줄을 살펴보세요. 시작, 설정 가져오기, TUN 켜기, 구독 업데이트, 절전 모드 해제 중 어느 시점에 문제가 발생했는지 기록하세요. 막연히 충돌했다고 설명하는 것보다 재현을 일으키는 단계가 더 유용합니다.

현재 작업을 먼저 저장하고 클라이언트를 정상 종료한 뒤 백그라운드에 프로세스가 남아 있는지 확인하세요. 이전 프로세스가 종료되지 않은 상태에서 여러 인스턴스를 반복 실행하지 마세요. 포트 충돌이나 설정 파일 잠금이 발생할 수 있습니다. 프로세스를 강제로 종료해야 했다면 시스템 프록시 설정이 남아 있는지 확인하세요. 서비스는 멈췄는데 로컬 포트를 계속 가리켜 인터넷이 끊길 수 있습니다. 직접 연결이 복구된 뒤 정보를 수집하고 문제를 해결하세요. 연결이 끊긴 상태에서 파일을 반복 다운로드해 혼란을 키우지 마세요.

아키텍처·설치 위치·필수 구성 요소 확인

설치 파일은 운영체제와 프로세서 아키텍처에 맞아야 합니다. Apple Silicon과 Intel, Windows 아키텍처별 파일, Linux 패키지 형식은 파일 이름이 비슷하다고 서로 바꿔 쓸 수 없습니다. 클라이언트 다운로드 페이지에서 플랫폼에 맞는 파일을 선택하세요. 일반적인 그래픽 인터페이스 사용자는 Clash Plus를 우선 고려할 수 있고, Linux 사용자는 페이지의 목록에서 적절한 클라이언트를 고르면 됩니다. 오래된 가이드에 나오는 화면을 찾기 위해 지원이 중단된 프로그램을 먼저 설치하지 마세요.

처음 실행할 때부터 실패한다면 시스템에서 보고하는 필수 런타임 구성 요소 누락, 권한, 설치 경로 문제를 확인하세요. Windows 그래픽 인터페이스에는 WebView 시스템 구성 요소가 필요할 수 있고, Linux에서는 공유 라이브러리 누락이 표시될 수 있으며, macOS에서는 앱 권한과 보안 확인 안내가 나타날 수 있습니다. 클라이언트 문서와 운영체제 안내에 따라 해결하세요. 낯선 사이트에서 공유 라이브러리 파일 하나만 내려받거나 앱을 실행하려고 시스템 보안 기능 전체를 끄지 마세요.

최소한의 변경으로 설정과 상태 분리하기

특정 설정을 불러온 뒤에만 충돌한다면 클라이언트 설정과 데이터 폴더를 백업한 후 정상 작동이 확인된 설정으로 바꿔 테스트하세요. 최근 추가한 오버라이드, 스크립트, 외부 규칙을 끄고 문제가 해결되는지 확인하세요. 용량이 큰 규칙 세트, 연결 기록 과다, 높은 로그 수준은 리소스 사용량을 늘릴 수 있습니다. 메모리 사용량이 늘었다는 이유만으로 누수라고 단정하지 말고, 문제를 일으킨 동작, 지속 시간, 시스템 리소스 변화 추이를 함께 살펴보세요.

설정 오류로 코어가 종료되면 문법이나 참조 오류를 확인할 수 있는 로그가 남는 경우가 많습니다. 인터페이스 구성 요소 충돌에는 시스템 이벤트나 충돌 보고서가 필요할 수 있습니다. 둘을 구분하지 않고 설정을 전부 삭제하지 마세요. 클라이언트에서 별도 데이터 폴더를 임시로 사용할 수 있다면 기존 데이터를 보존한 채 새 상태와 비교하세요. 지원하지 않는다면 클라이언트의 데이터 이전 안내를 따르세요. 구독, 오버라이드 규칙, 로컬 사용자 설정을 실수로 삭제하지 않도록 주의하세요.

재설치한다고 사용자 데이터가 반드시 삭제되는 것은 아니며, 이전 설정 문제가 해결된다는 보장도 없습니다. 작업 전에 설정 폴더와 프로그램 폴더를 구분하세요. 서비스 제거 또는 데이터 정리 전에는 복원 가능한 사본을 보관하고 다시 권한을 부여해야 하는 시스템 구성 요소를 기록하세요.

절전 모드에서 깨어난 뒤에만 문제가 생긴다면 네트워크 인터페이스가 바뀌었는지, 시스템 프록시가 이전 포트를 계속 가리키는지, TUN 라우트가 복구됐는지 확인하세요. 즉시 재설치하기보다 코어를 중지했다가 다시 시작해 볼 수 있습니다. 네트워크를 바꿀 때마다 문제가 재현된다면 유선에서 Wi-Fi로 전환하거나 핫스팟에서 라우터로 돌아가는 구체적인 단계를 기록하세요. 이러한 재현 경로가 서비스 복구와 라우팅 재구성 문제를 찾는 데 도움이 됩니다.

문제를 제보할 때는 클라이언트 이름, 시스템 아키텍처, 코어 정보, 재현 단계, 민감 정보를 가린 로그를 제공하세요. 구독 인증 정보, 노드 로그인 정보, 개인 경로에 포함된 민감한 내용은 삭제하세요. 충돌 보고서에도 사용자 이름과 파일 위치가 포함될 수 있습니다. 디버그 로그는 짧게 재현하는 동안에만 켜고 완료 후 log-level: info로 되돌리세요. 불필요한 로그가 계속 쌓여 일상적인 사용과 이후 문제 분석에 지장을 주지 않도록 하세요.

문제 해결 후에는 정상 종료, 재실행, 네트워크 재연결을 각각 한 번 이상 확인해 시스템 프록시, 설정 불러오기, 코어 서비스가 정상적으로 복구되는지 점검하세요. 새로 설치해도 같은 단계에서 문제가 반복되면 재설치를 거듭하지 말고 재현 조건을 기준으로 다시 살펴보세요. 기록 없이 클라이언트를 계속 바꾸는 것보다 직접 연결로 네트워크를 복구할 수 있는 방법을 하나 확보해 두는 것이 중요합니다.

모바일 문제: VPN 권한·백그라운드 제한·네트워크 전환

기기에서 트래픽을 처리하는 방식 확인

휴대전화는 보통 시스템 VPN 인터페이스로 트래픽을 처리합니다. 데스크톱에서 로컬 HTTP 프록시를 설정하는 방식과는 다릅니다. 처음 켤 때 시스템 팝업에서 VPN 구성을 허용하고 현재 연결이 대상 클라이언트에 속하는지 확인하세요. 상태 표시줄에 VPN 아이콘이 보인다는 것은 시스템 터널이 만들어졌다는 뜻일 뿐, 구독 노드, 규칙, DNS가 모두 정상이라는 보장은 없습니다. 클라이언트에서 새 요청, 적용된 정책, 오류 로그를 확인한 뒤 어느 단계의 문제인지 판단하세요.

운영체제에 맞춰 Android 다운로드 또는 iOS 다운로드에서 클라이언트를 선택하세요. 우선 Clash Plus를 고려할 수 있습니다. iOS에서는 App Store 페이지에서 받을 수 있으며 공식 사이트는 clashplus.io입니다. 클라이언트마다 지원하는 설정 필드와 시스템 기능이 다르므로 데스크톱 YAML의 모든 TUN 매개변수를 모바일에서 필수로 사용할 수는 없습니다.

Android: 백그라운드 중단과 앱별 적용 범위

화면이 켜져 있을 때는 작동하지만 잠금 상태로 한동안 둔 뒤 끊긴다면 시스템 배터리 정책, 백그라운드 활동, 제조사별 프로세스 관리 설정을 확인하세요. 사용하는 클라이언트에 필요한 만큼만 제한을 완화하고 기기의 절전 기능 전체를 끄지는 마세요. 같은 노드를 유지한 채 화면을 잠갔다가 다시 켜고 로그의 시간 흐름을 확인하세요. 시스템이 앱을 종료한 경우, 터널은 유지됐지만 연결이 만료된 경우, Wi-Fi가 절전 상태에 들어간 경우를 구분할 수 있습니다.

일부 Android 클라이언트는 프록시를 적용할 앱을 선택할 수 있습니다. 브라우저는 되는데 특정 앱만 연결되지 않으면 해당 앱이 제외됐는지, 별도 프로세스를 사용하는지, 업무용 프로필에 별도 앱으로 설치됐는지 확인하세요. VPN 연결을 항상 유지하거나 VPN을 거치지 않는 연결을 차단하는 시스템 옵션 때문에 터널이 끊겼을 때 기기 전체가 인터넷에 연결되지 않는 것처럼 보일 수도 있습니다. 옵션의 영향을 먼저 이해한 뒤 필요한 경우 조정하세요. 보호 기능을 노드 문제로 오해하지 않도록 주의하세요.

iOS: 권한·요청 시 연결·설정 호환성

iOS에서 VPN을 켤 수 없다면 시스템에 VPN 구성이 있는지, 현재 클라이언트에 연결된 설정인지, 다른 앱이 터널을 만들고 있는지 확인하세요. 기존 설정은 이전 설치나 기기 관리 정책에서 만들어졌을 수 있습니다. 출처를 모르는 회사 설정을 바로 삭제하지 마세요. 개인 기기에서 권한을 다시 받아야 한다면 먼저 클라이언트 연결을 중지하고 시스템 안내에 따라 처리한 다음 앱으로 돌아와 권한 요청을 다시 시작하고 화면에 표시되는 내용을 확인하세요.

시스템에는 연결됨으로 표시되지만 일부 서비스가 실패한다면 설정을 제대로 가져왔는지, 규칙 그룹을 수동으로 선택해야 하는지, 클라이언트가 구독 프로토콜을 지원하는지 확인하세요. 모바일의 호환성은 실제 앱 설명을 기준으로 판단해야 합니다. 설정을 가져올 수 있다고 해서 모든 필드가 데스크톱과 같은 의미로 작동하는 것은 아닙니다. 처음 설정을 가져오는 순서는 iPhone 설정 가져오기 안내를 참고하세요. 권한 설정이 끝나기 전에 규칙을 여러 개 바꾸지 마세요.

Wi-Fi와 모바일 데이터를 각각 테스트

노드와 설정은 그대로 두고 Wi-Fi와 모바일 데이터에서 같은 대상을 각각 테스트하세요. 특정 Wi-Fi에서만 실패한다면 포털 인증을 마친 뒤 기기 간 통신이 차단되는지, 특정 전송 방식이 제한되는지 확인하세요. 모바일 데이터에서만 실패한다면 통신사 네트워크 경로, IPv6, 데이터 사용 제한을 살펴보세요. 네트워크를 바꾸면 기존 연결이 끊겼을 수 있으므로 새 요청을 보내야 합니다. 필요하면 터널을 중지했다가 다시 시작하세요. 전환 전부터 열려 있던 페이지의 결과만으로 판단하지 마세요.

휴대전화가 컴퓨터의 프록시를 공유해 사용하는 경우에는 점검 방법이 다릅니다. 휴대전화 프록시 설정에는 컴퓨터의 로컬 네트워크 주소를 입력하고, 포트는 컴퓨터의 혼합 포트와 일치시켜야 합니다. 컴퓨터가 절전 모드에 들어가지 않도록 하세요. Wi-Fi의 클라이언트 격리 기능은 기기 간 연결을 차단할 수 있으며, 모바일 데이터에서는 보통 집에 있는 컴퓨터의 사설 주소에 직접 연결할 수 없습니다. 이 방식에서는 휴대전화에서 로컬 VPN이 실행되지 않을 수 있으므로 VPN 상태 아이콘으로 공유 성공 여부를 판단하지 마세요.

마지막으로 앱 자체 캐시와 기존 연결 상태를 확인하세요. 출구를 바꾼 뒤 로그인 서비스, 동영상 재생, 메신저의 장시간 연결은 다시 연결해야 할 수 있습니다. 대상 앱을 완전히 닫았다가 다시 열고 새 연결 기록을 확인하세요. 한 앱이 복구됐다고 모든 문제가 해결된 것은 아닙니다. 이전에 실패했던 서비스도 다시 테스트하세요. 도움이 필요하다면 휴대전화 운영체제, 클라이언트 이름, 네트워크 종류, 민감 정보를 가린 오류를 제공하고 이 페이지의 해당 항목을 따라 문제 범위를 좁히세요.