Clash 문제 해결
연결 및 설정 진단

인터넷 연결 불가: 트래픽이 끊기는 단계 확인

먼저 비교 가능한 기본 환경을 복원해 문제 범위를 좁히세요

먼저 클라이언트의 시스템 프록시와 TUN을 끄고, 다른 VPN이나 프록시 프로그램도 종료하세요. 평소 직접 접속할 수 있는 웹사이트를 열어 Wi-Fi, 유선 네트워크 또는 모바일 데이터가 정상인지 확인합니다. 끈 뒤에도 연결되지 않으면 라우터, 네트워크 인증, 시스템에 남아 있는 프록시 설정부터 확인하세요. 노드를 계속 바꾸지는 마세요. 공용 네트워크는 인증 페이지를 먼저 열어야 할 수 있습니다. 프록시가 너무 일찍 시작되면 인증 요청이 우회되어 모든 웹사이트가 동시에 열리지 않을 수 있습니다.

기본 네트워크가 정상이라면 클라이언트를 다시 시작하고, 설정이 선택되어 있는지, 코어가 실행 중인지, 프록시 그룹에 사용할 수 있는 구성원이 있는지 확인하세요. 화면의 ‘연결됨’은 로컬 서비스가 시작되었다는 뜻일 수 있으며 원격 프록시에 연결되었다는 보장은 아닙니다. 먼저 규칙 모드로 같은 웹사이트에 접속한 뒤 연결 목록에 요청이 표시되는지 확인하세요. 기록이 없다면 트래픽 진입 경로를, 기록은 있지만 연결에 실패한다면 정책, 노드, DNS 응답을 점검하세요.

프록시를 명시한 요청으로 진입과 출구를 구분하세요

설정에서 실제 혼합 포트를 확인한 뒤 아래 테스트를 실행하세요. 예시는 로컬 포트 7890을 사용합니다. 설정이 다르면 명령에 지정된 포트를 실제 값으로 바꾸세요. Windows에서는 curl.exe를 사용하세요. 구버전 PowerShell에서 같은 이름의 명령이 다르게 동작할 수 있습니다. 테스트 대상은 현재 열리지 않는 웹사이트로 바꿔도 됩니다. 한두 번만 요청하고 동시 부하 테스트는 하지 마세요.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://example.com

Connection refused가 표시되면 해당 포트에서 서비스가 대기 중이지 않거나 포트 번호가 잘못된 경우가 많습니다. 로컬 프록시 연결은 성공한 뒤 시간 초과가 발생한다면 출구 노드, 규칙 또는 원격 네트워크를 의심할 수 있습니다. HTTP 상태 코드가 반환되면 네트워크 경로 일부는 연결된 것입니다. 다만 응답이 대상 웹사이트에서 왔는지 중간 서비스에서 왔는지 확인해야 합니다. 인증서 오류는 별도로 처리하고, 인증서 검증을 끄는 방식으로 원인을 덮지 마세요.

모드, 프록시 그룹, 규칙 순서 확인

규칙 모드는 설정에 적힌 순서대로 규칙을 확인하고, 처음 일치한 규칙의 정책을 적용합니다. 특정 웹사이트가 앞부분에서 REJECT에 걸리면 노드를 바꿔도 차단 결과는 달라지지 않습니다. 프록시 그룹에서 DIRECT가 선택되어 있다면 프록시 스위치를 켜도 해당 연결이 원격으로 자동 전환되지는 않습니다. 전체 스위치 상태만 보는 것보다 연결 상세 정보에서 일치한 규칙과 실제 경로를 확인하는 편이 정확합니다. 사용자 규칙에 지정한 정책 이름은 기존 프록시 그룹 이름과 정확히 일치해야 합니다.

비교를 위해 잠시 전역 모드로 전환하고, 확인된 노드를 직접 선택해도 됩니다. 전역 모드는 되지만 규칙 모드가 안 된다면 규칙 일치 결과, 프록시 그룹 중첩, 직접 연결 시 DNS를 우선 확인하세요. 두 모드 모두 실패하면 로컬 진입 지점과 노드를 점검합니다. 비교가 끝나면 규칙 모드로 되돌리세요. 전역 전달은 로컬 네트워크, 업무 시스템, 데이터 사용량에 영향을 줄 수 있습니다.

반복 가능한 방식으로 수정 결과 확인

페이지가 우연히 새로고침되어 열린 것을 문제 해결로 보지 마세요. 기존 연결을 닫거나 테스트 앱을 다시 시작한 뒤 직접 연결할 웹사이트 하나, 프록시가 필요한 웹사이트 하나, 로컬 네트워크 주소 하나를 차례로 확인하세요. 연결 목록이 예상한 대로 표시되는지도 살펴봅니다. 브라우저는 기존 연결을 재사용할 수 있어 정책을 바꾼 뒤에도 새 요청과 기존 요청의 경로가 다를 수 있습니다. 결과가 안정적으로 확인되면 설정을 저장하고 정상 작동한 포트, 모드, 선택한 프록시 그룹을 기록하세요.

노드 시간 초과: 테스트 실패와 실제 연결 실패 구분

먼저 어떤 테스트에서 시간 초과가 발생했는지 확인하세요

노드 목록의 시간 초과는 일반적으로 클라이언트가 실행한 연결 테스트 결과이며, 모든 서비스 연결이 실패한다는 뜻은 아닙니다. 테스트 주소에 연결할 수 없거나 대상이 요청을 제한하거나 응답 조건이 예상과 다르면, 사용 가능한 노드도 비정상으로 표시될 수 있습니다. 먼저 해당 노드를 선택해 실제 대상에 접속하면서 로그를 확인하세요. 웹페이지는 열리지만 테스트만 실패한다면 노드를 삭제하거나 구독이 무효라고 단정하지 말고 테스트 주소와 시간 제한 설정을 점검하세요.

실제 접속도 실패한다면 같은 프록시 그룹의 다른 노드와 비교하세요. 모든 노드가 실패하면 기본 네트워크, 계정 상태, 공통 설정 또는 로컬 차단 문제일 가능성이 높습니다. 노드 하나만 실패한다면 노드 주소, 프로토콜 매개변수 또는 해당 회선 문제일 수 있습니다. 제한을 유발할 수 있으므로 목록 전체를 한꺼번에 테스트하지 마세요. 서로 다른 주소의 노드 두 개를 차례로 테스트하면 초기 판단에 충분합니다.

로그로 연결, 핸드셰이크, DNS 오류를 구분하세요

dial tcp 뒤에 시간 초과가 표시되면 TCP 연결이 제때 성립하지 않은 경우가 많습니다. connection refused는 연결이 거부되었음을 뜻하며 포트가 열려 있지 않거나 서비스가 실행되지 않았을 수 있습니다. 핸드셰이크 실패는 프로토콜이나 TLS 단계까지 진행되었다는 뜻입니다. 오류에 표시된 대상이 노드 서버인지 웹사이트 서버인지 확인하세요. 각각 점검 방향이 다르므로 마지막에 적힌 ‘timeout’만 잘라 보고 판단하지 마세요.

노드 주소가 도메인 이름이라면 먼저 DNS 조회가 되는지 확인하세요. DNS 조회 실패 시 이를 사용하는 연결이 모두 시작 단계에서 중단될 수 있고, 잘못된 주소로 조회되면 핸드셰이크 실패로 나타날 수 있습니다. TLS 기반 프로토콜은 시스템 시간, 서버 이름, 구독에 포함된 매개변수도 확인해야 합니다. servername을 임의로 지우거나 지문, 전송 경로를 바꾸지 마세요. 이 값들은 대개 서버 설정과 일치해야 하며, 추측으로 변경하면 변수가 늘어납니다.

현재 네트워크에 맞는 프로토콜인지 확인하세요

일부 네트워크는 UDP를 제한합니다. TCP 기반 노드는 되지만 UDP에 의존하는 프로토콜이 계속 실패한다면 네트워크를 바꿔 다시 테스트해 로컬 네트워크 제한과 서버 문제를 구분하세요. Hysteria2, TUIC 같은 프로토콜의 동작을 일반 TCP 포트 테스트만으로 판단할 수 없습니다. 반대로 TCP 연결이 성립해도 프록시 프로토콜의 인증과 트래픽 전달이 성공했다는 뜻은 아닙니다.

회사 네트워크, 학교 네트워크, 공용 Wi-Fi에는 명시적인 접속 정책이 있을 수 있습니다. 점검할 때 네트워크 관리 규정을 따르고 조직의 제한을 우회하지 마세요. 허용되는 가정용 네트워크나 모바일 데이터에서 같은 노드를 비교할 수 있습니다. 특정 네트워크에서만 실패한다면 발생 시각, 프로토콜 종류, 오류 단계가 서비스 제공자의 판단에 도움이 됩니다. 테스트를 위해 로컬 프록시 포트를 전체 로컬 네트워크에 공개하지 마세요.

프록시 그룹에서 실제로 선택된 노드 확인

수동 선택 그룹, 자동 테스트 그룹, 장애 조치 그룹은 동작 방식이 다릅니다. 화면에서 상위 그룹을 선택했더라도 실제 출구는 그 아래의 자동 그룹이 정할 수 있습니다. 표시된 그룹 이름이 최종 노드라고 단정할 수 없습니다. 연결 경로를 펼쳐 어떤 구성원이 요청을 처리하는지 확인하세요. 자동 선택 결과는 테스트 캐시에 영향을 받을 수도 있습니다. 테스트를 새로고침한 뒤 실제 요청으로 확인하고, 색상이나 상태 표시 하나만으로 판단하지 마세요.

서비스 상태와 트래픽 한도도 확인하세요. 계정 만료, 노드 이전, 동시 연결 제한 때문에 설정 형식이 올바른 노드도 작동하지 않을 수 있습니다. 먼저 구독을 업데이트하고 서비스 제공자가 공지한 상태와 비교하세요. 공개된 게시물에 전체 노드 URI를 올리지 마세요. 노드 비밀번호, UUID, 구독 링크는 접속 권한을 부여할 수 있으므로 계정 인증 정보처럼 다뤄야 합니다.

해결 방법과 되돌릴 범위

먼저 유효한 구독으로 업데이트하고, 검증된 노드를 선택하고, 서비스 제공자가 안내한 원래 매개변수를 복원한 뒤 네트워크를 바꿔 테스트하세요. 인증서 오류를 skip-cert-verify를 장기간 설정해 해결할 수는 없습니다. 먼저 시스템 시간과 서버 이름을 확인하고, 인증서 문제는 서비스 제공자가 처리하도록 하세요. 시간 제한을 일시적으로 늘리는 방법은 응답 지연을 확인할 때만 유용하며 인증 실패, 잘못된 도메인, 닫힌 포트를 해결하지는 못합니다.

자동 테스트만 비정상이라면 안정적으로 접속할 수 있는 주소로 바꿔 다시 테스트할 수 있습니다. 확인할 때 ‘테스트 성공 여부’와 ‘실제 연결 성공 여부’를 따로 기록하세요. 지연 시간, 트래픽 배율, 지역 선택은 Clash 노드 선택 가이드를 참고하세요. 지연 시간이 짧아도 대역폭이 충분한 것은 아니며, 노드가 작동해도 모든 웹사이트가 해당 출구를 허용하는 것은 아닙니다.

구독 실패: 요청 실패와 설정 파싱 실패 구분

가져온 항목과 오류 발생 단계를 확인하세요

구독 업데이트는 두 단계로 진행됩니다. 먼저 주소에서 응답을 가져온 뒤 클라이언트나 코어가 내용을 파싱합니다. 연결 시간 초과, 인증서 실패, 비정상 HTTP 상태는 요청 단계의 문제입니다. 가져오기에 성공한 뒤 YAML 오류, 알 수 없는 필드, 프록시 그룹 참조 오류가 나타난다면 파싱 단계의 문제입니다. 먼저 오류 메시지를 끝까지 읽고 어느 단계에서 실패했는지 확인하세요. 업데이트 버튼만 반복해서 눌러도 만료된 링크나 호환되지 않는 형식은 해결되지 않습니다.

붙여넣은 내용의 앞뒤 공백, 줄바꿈, 한글 문장부호를 확인하세요. 계정 관리 페이지, 결제 페이지, 노드 관리 페이지가 아니라 서비스 제공자가 안내한 구독 주소를 가져와야 합니다. 링크의 쿼리 매개변수에는 접속 정보가 포함될 수 있습니다. 복사할 때 뒤쪽이 빠지면 다른 요청이 됩니다. 전체 구독 링크가 포함된 명령을 공용 기기에서 실행하거나 링크를 스크린샷, 공개 로그에 올리지 마세요.

HTTP 응답으로 다음 점검 항목 판단

상태 코드는 점검 방향을 정하는 참고 정보이며, 구체적인 의미는 서비스 제공자의 구현에 따라 다릅니다. 인증 실패나 접근 거부는 인증 정보, 계정 상태, 요청 정책과 관련될 수 있습니다. 리소스를 찾을 수 없다면 주소가 변경되었을 수 있고, 요청이 너무 많다면 업데이트를 멈춰야 합니다. 성공 상태를 반환해도 내용이 설정 파일이 아니라 로그인 페이지, 점검 페이지, 오류 안내일 수 있습니다. 브라우저에서 주소가 열려도 클라이언트가 같은 내용을 받는다는 보장은 없습니다.

업데이트 경로가 시작 단계의 의존성을 만들지 않도록 확인

일부 구독 주소는 프록시를 통해서만 접속할 수 있습니다. 현재 프록시 노드가 작동하지 않는데 업데이트 요청도 해당 노드에 의존하면 새 노드를 가져올 수 없는 순환 문제가 생깁니다. 클라이언트에 프록시를 통한 업데이트 옵션이 있는지 확인하세요. 네트워크에서 허용한다면 직접 연결로 업데이트를 비교하거나, 보관해 둔 사용 가능한 설정으로 먼저 연결하세요. 접속할 수 없는 구독 주소를 여러 형태의 링크로 계속 바꾸면 실제 경로 문제를 가릴 수 있습니다.

일부 서비스는 User-Agent에 따라 다른 형식으로 응답합니다. 서비스 계정 페이지에서 Clash 또는 mihomo에 맞는 가져오기 메뉴를 사용하고, 해당 클라이언트 요구사항을 따르세요. 요청 헤더를 임의로 위장하면 다른 클라이언트용 형식을 받을 수 있습니다. 비공개 구독을 낯선 온라인 변환 서비스에 제출하면 인증 정보가 노출될 위험이 커집니다. 변환이 필요하다면 먼저 도구의 출처와 데이터 처리 방식을 확인하세요.

YAML 및 코어 호환성 오류 확인

YAML은 공백으로 들여쓰고 탭을 섞지 마세요. 오류 줄 번호는 파서가 더 이상 진행할 수 없게 된 위치를 가리킬 수 있으며, 실제 원인은 바로 앞 줄의 따옴표, 콜론, 목록 들여쓰기일 수 있습니다. 오류가 난 줄과 앞뒤 몇 줄, 최상위 구조를 먼저 확인하세요. 아래는 문법에 맞는 규칙 예시일 뿐, 단독으로 연결할 수 있는 전체 설정은 아닙니다. 지정한 프록시 정책 이름은 기존 설정의 그룹 이름과 일치해야 합니다.

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

YAML 문법은 정상이지만 프로토콜이나 필드를 지원하지 않는다는 오류가 발생하면 실제 실행 중인 코어를 확인하세요. 클라이언트 이름, 화면 버전, 코어 기능은 서로 다른 개념입니다. 구버전 코어는 mihomo 확장 문법을 지원하지 않을 수 있습니다. 설정이 억지로 로드되도록 오류가 난 필드만 삭제하지 마세요. 해당 필드가 프로토콜에 필요한 매개변수일 수 있습니다. 호환 범위는 mihomo와 원본 코어의 차이에서 확인할 수 있습니다.

로컬 수정 사항을 보호하고 업데이트 확인

원격 구독을 업데이트하면 직접 편집한 내용이 덮어써질 수 있습니다. 클라이언트가 오버라이드, 병합, 로컬 규칙을 지원한다면 다운로드 캐시를 수정하지 말고 해당 기능에 사용자 설정을 추가하세요. 업데이트 후 노드 목록, 프록시 그룹 구성원, 규칙이 예상대로 유지되었는지 확인하고 노드 하나를 선택해 실제 연결을 테스트합니다. 구독 파일이 로드되었다는 것은 파싱에 성공했다는 뜻일 뿐, 모든 원격 노드가 온라인이라는 의미는 아닙니다.

새 설정이 실패했지만 이전 설정은 작동한다면 먼저 이전 사본을 복원하고, 새 설정의 오류 기록은 보관한 뒤 처리하세요. 비교할 자료를 잃지 않도록 설정과 캐시를 한꺼번에 지우지 마세요. 추가 점검 항목은 구독 업데이트 오류 자가 점검 목록을 참고하세요. 문제를 해결한 뒤 불필요한 자동 업데이트 횟수를 줄이고 클라이언트를 다시 시작해도 같은 유효한 설정을 불러오는지 확인하세요.

속도 저하: 노드·회선·기기별로 원인 좁히기

같은 조건에서 비교하고 서로 다른 지표를 섞지 마세요

웹페이지 로딩, 동영상 버퍼링, 파일 다운로드 속도 저하는 원인이 다를 수 있습니다. 대상, 시간대, 작업을 구체적으로 기록하세요. 첫 페이지가 뜨기까지 오래 걸리는지, 다운로드가 시작된 뒤 전송 속도가 계속 낮은지 구분합니다. 테스트하는 동안 다른 다운로드, 클라우드 동기화, 시스템 업데이트를 멈추고 기기 위치와 네트워크를 일정하게 유지하세요. 시간대나 웹사이트가 다른 결과는 그대로 비교할 수 없습니다. 조건이 다르면 변화가 노드 때문인지 대상 서비스 때문인지 판단하기 어렵습니다.

지연 시간 테스트는 주로 테스트 요청의 왕복 시간과 처리 시간을 보여 주며 대역폭을 측정하지 않습니다. 지연 시간이 짧아도 노드가 혼잡할 수 있고, 대역폭이 높아도 지역 간 왕복 시간이 길면 웹페이지가 느리게 열릴 수 있습니다. 서로 다른 회선의 노드 두 개를 골라 같은 테스트 대상에 접속하고, 첫 응답 시간과 지속 전송 속도를 각각 살펴보세요. 대용량 테스트를 반복하지 마세요. 트래픽은 서비스 제공자의 정책에 따라 차감됩니다.

노드 부하와 네트워크 회선부터 확인

노드 하나만 느리고 다른 노드와 직접 연결은 정상이라면 해당 노드의 회선이나 부하를 우선 확인하세요. 저녁에 느려졌다가 다른 시간대에 회복된다면 공유 출구나 통신사 경로의 혼잡이 원인일 수 있습니다. 인접 지역으로만 바꾸기보다 같은 지역의 다른 회선과 비교하는 편이 진단에 더 도움이 됩니다. 지역 표시는 실제 회선, 출구 주소, 대상 콘텐츠 서비스가 같다는 보장이 없습니다. 실제 연결 결과를 기준으로 판단하세요.

모든 노드가 느리다면 프록시를 끈 일반 네트워크 연결을 기준으로 삼으세요. 직접 다운로드도 느리다면 Wi-Fi 신호, 주파수 대역, 라우터 부하, 인터넷 회선을 점검하고 가능하면 유선 연결과 비교하세요. 특정 웹사이트만 느리다면 콘텐츠 전송 경로, 속도 제한, 출구 식별 정책이 원인일 수 있습니다. 다른 대상으로 테스트하면 기기 전반의 문제를 제외하는 데 도움이 되지만, 원래 대상도 반드시 작동한다고 보장할 수는 없습니다.

DNS 대기와 전송 병목 구분

처음 열 때는 느리지만 다시 열면 빨라지는 경우 DNS 조회, TLS 핸드셰이크, 캐시가 원인일 수 있습니다. 로그에서 DNS 조회 단계가 오래 대기하는지, 도메인 조회를 반복하는지 확인하세요. 다운로드가 시작된 뒤 계속 느리다면 회선 처리량, 패킷 손실, 서버 제한을 우선 살펴봐야 합니다. 속도가 느리다고 모든 DNS 설정을 바꾸지 마세요. DNS 서버를 바꾸면 콘텐츠 전송 주소도 달라질 수 있어 비교 조건이 달라집니다.

추가 도구를 설치하지 않고 프록시를 명시한 요청으로 응답 시간을 기록할 수 있습니다. 아래 명령은 전체 시간과 첫 바이트까지 걸린 시간을 출력합니다. 값은 실제 요청 결과에 따라 달라집니다. HTTP 프록시를 이용하면 도메인 조회가 프록시 코어 또는 원격에서 이루어질 수 있으므로 이 결과를 독립적인 DNS 테스트로 사용하지 마세요. 같은 요청을 서로 다른 노드에서 비교할 때만 활용하세요.

curl --proxy http://127.0.0.1:7890 --max-time 30 -o /dev/null -sS \
  -w '첫 바이트: %{time_starttransfer}s\n총 시간: %{time_total}s\n' \
  https://example.com

Windows에서는 curl.exe를 사용하고 출력 대상 /dev/null을 NUL로 바꾼 뒤 명령을 한 줄로 작성하세요. 응답이 작은 페이지를 테스트해 주로 응답 대기 시간을 확인합니다. 대용량 파일의 대역폭을 측정하는 용도는 아닙니다. 첫 바이트 응답은 정상인데 특정 다운로드만 계속 느리다면 대상의 속도 제한, 다운로드 도구의 동시 연결 설정, 프록시 규칙이 같은 출구를 선택하는지 확인하세요.

기기 내 트래픽 처리와 자원 사용 확인

시스템 프록시와 TUN 모드를 비교하되 프로토콜, DNS, 프록시 그룹을 동시에 바꾸지 마세요. TUN 모드에서만 느리다면 다른 VPN, 가상 네트워크 어댑터, 보안 소프트웨어가 함께 실행 중인지 확인하고 로그에서 같은 연결을 반복 처리하는지 살펴보세요. 작업 관리자에서 CPU 사용량이 높거나 디스크에 계속 기록하고 있다면 네트워크 체감에 영향을 줄 수 있습니다. 단기 진단이 끝나면 로그 수준을 보통으로 되돌려 장시간 대량 기록을 피하세요.

연결이 많거나 작은 파일을 동시에 처리하고 백그라운드 동기화를 실행하면 코어와 기기에 부담이 커집니다. 관계없는 앱을 먼저 닫고 같은 작업을 다시 수행하세요. 라우터나 저전력 기기는 처리 성능에 따라 암호화 프로토콜과 연결 수가 제한될 수 있습니다. 데스크톱의 높은 동시 연결 설정을 그대로 적용하거나 속도를 높이려고 모든 보안 기능을 영구적으로 끄지 마세요. 프로세스, 규칙, 시간대별 결과를 비교해 충돌을 찾으세요.

MTU와 트래픽 분기 경계 점검

작은 요청은 정상이지만 큰 페이지나 장시간 연결이 멈추고, 특히 TUN이나 특정 네트워크에서만 문제가 발생한다면 MTU, 경로상 패킷 손실, UDP 처리 문제를 의심할 수 있습니다. 먼저 다른 네트워크와 프로토콜로 재시험해 안정적인 차이가 있는지 확인한 뒤 지원되는 MTU 설정을 조금씩 조정하고 원래 값을 기록하세요. 모든 기기에 맞는 공통 최적값은 없습니다. 무작정 값을 낮추면 오버헤드만 늘고 문제가 해결되지 않을 수 있습니다.

마지막으로 속도가 느린 요청이 어떤 규칙과 일치했는지 확인하세요. 일부 다운로드는 직접 연결되고 일부 미디어 요청은 다른 프록시 그룹으로 전달될 수 있습니다. 모든 문제를 현재 수동으로 선택한 노드 탓으로 돌릴 수는 없습니다. 임시 설정을 되돌린 뒤 같은 대상을 다시 테스트하고 비슷한 시간대에 한 번 더 확인하세요. 계층별 점검 방법은 Clash 속도 저하 단계별 진단을 참고해 일시적인 변동을 지속적인 문제로 오인하지 마세요.

DNS 문제: 조회 경로와 Fake-IP 매핑 확인

시스템 DNS와 코어 DNS의 차이부터 확인하세요

브라우저, 보안 소프트웨어, 운영체제, 프록시 코어가 모두 DNS 조회에 관여할 수 있습니다. 터미널에서 도메인을 조회할 수 있어도 앱이 같은 결과를 사용한다는 보장은 없습니다. 앱에서 암호화 DNS를 사용하면 시스템 DNS 서버를 우회할 수도 있습니다. 먼저 실패한 도메인, 오류 메시지, 현재 트래픽 처리 모드를 기록하세요. 로그에 해당 DNS 요청이 없다면 코어의 모든 DNS 설정을 바꾸기 전에 앱이 사용하는 조회 경로부터 확인하세요.

시스템 도구를 이용한 조회는 기준을 잡는 데 도움이 되지만 테스트 범위를 알아야 합니다. nslookup은 일반적으로 시스템에 지정된 DNS 서버로 조회 요청을 보냅니다. 브라우저의 암호화 DNS 동작을 완전히 재현하지 못하고 현재 HTTP 프록시를 통과하지 않을 수도 있습니다. 응답에 표시된 DNS 서버와 주소를 확인해 클라이언트 로그와 비교하세요. 도메인 조회는 되지만 연결에 실패한다면 경로, 규칙, TLS, 대상 서비스 문제를 점검하고 각 단계를 혼동하지 마세요.

nslookup example.com

Fake-IP의 정상 동작 이해

Fake-IP는 매핑 주소를 이용해 도메인과 연결을 연결하고, 코어가 도메인 기준 규칙을 적용하도록 합니다. 이 기능을 켠 뒤 매핑 범위에 속하는 주소가 보여도 반드시 오류는 아닙니다. 일반적인 직접 연결 방식으로 해당 주소가 실제 서버인지 확인할 수도 없습니다. 앱이 매핑 주소를 받은 뒤 연결도 같은 코어가 처리해야 합니다. DNS 조회만 처리하고 이후 연결은 가로채지 못하면 매핑 주소가 잘못된 경로로 전달될 수 있습니다.

모드 전환, 코어 재시작, 설정 변경 후에도 앱이 이전 매핑을 캐시할 수 있습니다. 먼저 관련 앱을 닫고 플랫폼에서 지원하는 방법으로 캐시를 지운 뒤 새 요청을 시작하세요. Windows에서는 시스템 DNS 캐시를 지울 수 있지만 브라우저와 앱에도 별도 캐시가 있을 수 있으므로 앱을 다시 시작하거나 네트워크 설정에서 처리해야 합니다. 이전 연결을 그대로 둔 채 모드만 반복해서 바꾸면 이전 매핑과 새 매핑이 섞일 수 있습니다.

ipconfig /flushdns

호환성 문제에 맞춰 필터 설정

로컬 네트워크 기기 검색, 일부 게임, 실제 주소가 필요한 앱은 예외 설정이 필요할 수 있습니다. 문제가 확인된 도메인에만 fake-ip-filter를 우선 적용하고 모든 도메인을 제외하지 마세요. 아래 예시는 매핑 범위와 로컬 네트워크 접미사 필터를 보여 주며 상위 DNS 서버 설정은 포함하지 않습니다. 전체 DNS 설정을 대신할 수 없습니다. 변경하기 전에 현재 코어가 지원하는 필터 문법을 확인하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"

사설 DNS와 사내 도메인은 조직에서 제공하는 DNS 서버가 필요한 경우가 많습니다. 공용 DNS는 사내 DNS를 대체하지 못하며 공용 서비스로 바꾸면 업무 시스템에 접속할 수 없게 될 수 있습니다. 회사 네트워크에서만 문제가 발생하는지 기록하고 도메인 접미사와 VPN의 DNS 요구사항을 확인하세요. 로컬 네트워크 기기 검색은 mDNS나 브로드캐스트에 의존할 수도 있으므로 도메인 필터만 추가해 모든 기기 검색이 복구된다고 볼 수 없습니다.

상위 DNS와 노드 도메인의 시작 단계 의존성 점검

암호화 DNS 서버 주소도 도메인 이름일 수 있어 먼저 조회가 필요합니다. 노드 서버의 도메인 역시 프록시가 연결되기 전에 올바른 주소로 확인되어야 합니다. 노드 도메인 조회가 아직 연결되지 않은 프록시에 의존하면 순환 문제가 생길 수 있습니다. mihomo의 default-nameserver, proxy-server-nameserver 등은 역할이 다르므로 현재 코어의 설정 의미를 확인한 뒤 필요한 항목만 조정하세요.

규칙에 따라 DNS 요청을 처리하도록 설정했다면 DNS 서버 연결이 최종적으로 어느 경로를 사용하는지도 확인하세요. 서로 참조하는 정책을 여러 개 추가한 뒤 코어가 알아서 의존성을 해결하길 기대하지 마세요. 로그에서 같은 상위 DNS 도메인을 반복 조회하지만 연결이 완료되지 않는다면 시작 단계의 DNS 경로를 먼저 점검하세요. 상위 서버 응답이 시간 초과되면 서버 이름이 익숙한지만 볼 것이 아니라 현재 네트워크에서 접속할 수 있는지 확인해야 합니다.

DNS 누출과 비정상 조회 결과 확인

DNS 누출은 조회 요청이 예상하지 않은 경로로 전송되는 것을 뜻합니다. 결과에 로컬 통신사 이름이 표시되는 것과는 다릅니다. 웹사이트 테스트는 참고 정보일 뿐이며 캐시, 브라우저 암호화 DNS, IPv6, 테스트 서비스의 관측 방식에 영향을 받을 수 있습니다. 시스템 DNS 설정, 클라이언트 조회 로그, 앱 설정을 함께 확인해 요청을 보낸 주체와 경로를 파악한 뒤 설계와 다른지 판단하세요.

IPv6를 사용한다면 AAAA 레코드와 IPv6 경로도 함께 확인하세요. IPv4 프록시 진입만 처리한다고 IPv6 요청까지 가로채는 것은 아닙니다. 반대로 IPv6를 끄면 정상적으로 작동하던 네트워크에 영향을 줄 수 있습니다. 같은 도메인의 주소 유형과 연결 결과를 비교하고, 플랫폼 설정에 따라 트래픽을 완전히 처리하거나 직접 연결 정책을 명확히 설정하세요. 용어 설명은 Fake-IP 용어 항목에서 확인할 수 있습니다.

시스템 프록시가 작동하지 않음: 진입 경로, 포트, TUN 라우팅 확인

시스템 프록시가 모든 앱의 트래픽을 처리하는 것은 아닙니다

시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정이며, 앱이 이를 사용하는지는 구현에 따라 다릅니다. 일부 브라우저는 설정을 읽지만 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 프로그램은 그렇지 않을 수 있습니다. 브라우저는 되는데 특정 앱만 안 된다면 시스템 프록시 스위치만 보고 코어 문제라고 판단하지 말고 앱에 별도 프록시 설정이 있는지 확인하세요. 더 많은 트래픽을 처리해야 할 때 TUN 사용을 검토하세요.

먼저 프록시를 명시한 요청을 실행하세요. 명시적 요청은 정상인데 시스템 설정을 따르는 요청은 실패한다면 로컬 프록시 서비스와 일부 출구 경로는 작동하는 것이므로 시스템 설정이나 앱 연결 경로에 문제가 있을 가능성이 큽니다. 명시적 요청도 연결되지 않으면 대기 포트, 코어 시작 상태, 설정 로드를 확인하세요. 특히 비정상 종료나 여러 프로그램의 선점이 있었을 때 화면의 스위치 상태와 운영체제의 실제 값이 잠시 다를 수 있습니다.

포트와 수신 주소 확인

mixed-port는 HTTP와 SOCKS 연결을 모두 제공하고, port와 socks-port는 각 연결을 따로 설정합니다. 외부 제어 인터페이스의 포트를 프록시 포트로 입력하지 마세요. 제어 인터페이스는 코어 관리용이지 일반 요청 전달용이 아닙니다. 설정을 바꾼 뒤 코어가 다시 로드되었는지 확인하세요. 이전 프로세스가 종료되지 않고 포트를 계속 사용하면 화면 표시와 실제 수신 포트가 다를 수 있습니다.

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info

이 예시는 로컬에서 사용할 기본 설정 일부이므로 기존 설정에 합쳐야 합니다. 이 기기에서만 사용한다면 루프백 주소로 수신하고 로컬 네트워크에 공개할 필요는 없습니다. allow-lan은 다른 기기의 접근 가능 여부를 설정하며, 로컬 시스템 프록시 문제를 해결하는 데 반드시 필요한 옵션은 아닙니다. 포트 충돌이 발생하면 시스템 도구로 해당 프로세스를 확인한 뒤 포트를 바꾸거나 충돌 프로그램을 종료하세요. 정체를 모르는 시스템 서비스를 임의로 종료하지 마세요.

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux
ss -lntp 'sport = :7890'

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

플랫폼별 설정과 명령줄 환경 확인

Windows의 사용자 프록시 설정과 WinHTTP 프록시는 별개의 연결 경로입니다. 한쪽 설정을 읽는 프로그램은 다른 쪽 설정의 영향을 받지 않을 수 있습니다. macOS 프록시 설정은 네트워크 서비스별로 적용되므로 Wi-Fi, 유선 네트워크로 전환하거나 서비스를 새로 만든 뒤 현재 서비스의 설정을 확인하세요. Linux 데스크톱 프록시 설정과 터미널 환경 변수도 따로 적용될 수 있습니다. 점검할 때 대상 앱이 어떤 설정을 읽는지 확인하고 서로 다른 인터페이스를 같은 스위치로 취급하지 마세요.

명령줄 도구는 보통 명시적 매개변수나 환경 변수가 필요합니다. 아래 변수는 현재 터미널과 여기서 시작한 하위 프로세스에만 적용되며 모든 앱 설정을 바꾸지는 않습니다. 이미 열려 있는 터미널이나 백그라운드 서비스에는 이전 값이 남을 수 있습니다. NO_PROXY에 예외가 있으면 대상이 프록시를 우회할 수도 있습니다. 도메인을 원격에서 조회하는 SOCKS 주소에는 socks5h를 사용할 수 있으며, 지원 여부는 도구에 따라 다릅니다.

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
export NO_PROXY=localhost,127.0.0.1,::1

TUN 권한, 라우팅, 제외 항목

TUN은 가상 네트워크 인터페이스로 트래픽을 처리하므로 필요한 권한과 라우팅 설정이 있어야 합니다. 클라이언트는 서비스 모드나 시스템 권한을 이용해 이를 설정할 수 있습니다. 화면에서 스위치를 켰다고 라우팅까지 설치된 것은 아닙니다. 먼저 로그에 권한, 네트워크 어댑터, 라우팅 오류가 있는지 확인한 뒤 실제 인터페이스를 살펴보세요. 회사 기기에서 가상 네트워크 어댑터를 제한한다면 기기 관리 규정을 따르고 제한을 우회하지 마세요.

TUN을 전환하기 전에 다른 VPN을 끄고 시스템 프록시 상태를 저장하세요. 시작 후 일반 앱, 명령줄, 로컬 네트워크가 정상인지 확인합니다. 업무 네트워크에 접속할 수 없다면 자동 라우팅과 제외 범위를 점검하세요. 모든 사설 주소 대역을 제외하는 설정은 모든 네트워크에 적합하지 않으며 VPN으로 접근해야 하는 리소스에 영향을 줄 수 있습니다. 현재 네트워크 구조에 맞게 설정하고 환경과 관계없는 주소 목록을 복사하지 마세요.

비정상 종료 후 복구와 확인

클라이언트를 종료한 뒤 인터넷이 되지 않는다면 시스템이 중지된 로컬 포트를 계속 가리키고 있을 수 있습니다. 먼저 시스템 네트워크 설정에서 이전 프록시 상태를 복원한 뒤 앱이 직접 연결되는지 확인하세요. TUN 설정이 남아 있다면 클라이언트를 정상 종료하거나 네트워크 서비스를 복원하거나 기기를 재시작해 처리하세요. 알 수 없는 라우팅 항목을 직접 삭제하지 마세요. 시작 프로그램에 등록했다면 시작 순서도 확인하세요. 네트워크 준비가 끝나기 전에 시작하면 첫 연결이 실패할 수 있습니다.

상시 실행 서비스가 필요한 Linux 환경은 mihomo와 systemd 설치 가이드를 참고하세요. 복구 후 클라이언트를 종료하고 다시 시작해 수신 포트, 프록시 설정, 라우팅이 제대로 복원되는지 확인합니다. 마지막으로 프록시를 중지한 상태에서도 네트워크가 정상인지 확인해 시작과 종료 과정을 모두 점검하세요.

클라이언트 충돌: UI, 코어, 시스템 서비스 구분

먼저 어느 부분이 종료되었는지 확인하세요

창이 사라졌다고 코어까지 중지된 것은 아닙니다. 트레이 아이콘이 남아 있어도 코어가 정상이라는 보장은 없습니다. 클라이언트 로그와 시스템 프로세스를 확인해 UI 강제 종료, 코어 종료, 백그라운드 서비스 시작 실패를 구분하세요. UI 문제는 조작과 화면 표시에, 코어 문제는 프록시 수신에 직접 영향을 줍니다. 서비스 문제는 TUN이나 높은 권한이 필요한 기능에만 영향을 줄 수 있습니다. 시작 직후인지, 설정을 가져온 뒤인지, 특정 기능을 켠 뒤인지 기록하세요.

먼저 정상적인 종료 절차로 남아 있는 프로세스를 종료한 뒤 한 번 다시 시작하세요. 여러 인스턴스가 설정 파일, 제어 인터페이스, 프록시 포트를 함께 사용하면 두 번째 인스턴스가 충돌한 것처럼 보일 수 있습니다. 백그라운드에 기존 프로세스가 남아 있다면 다른 클라이언트를 설치해 같은 트래픽 처리 기능을 동시에 켜지 마세요. 프로세스가 종료되었는지 확인한 뒤 다시 테스트해 프로그램 간 충돌을 호환성 문제로 오인하지 않도록 합니다.

설정 비교로 새 변경 사항이 원인인지 확인

구독 업데이트나 설정 편집 뒤 충돌이 발생했다면 시작할 수 있었던 이전 사본을 먼저 복원하세요. 이전 설정은 정상이지만 새 설정에서 실패한다면 문법, 규칙 집합 로드, 프로토콜 호환성, 파일 경로를 확인합니다. 일부 클라이언트는 UI에 설정 오류를 표시하면서 코어 시작을 거부할 수 있습니다. 이런 문제를 해결하려고 반드시 재설치할 필요는 없습니다. 오류 줄 번호와 주변 설정을 보관하고 노드 인증 정보는 가린 뒤 분석하세요.

명령줄로 배포한 mihomo는 테스트 모드로 설정을 확인할 수 있습니다. 아래 명령만으로 전체 실행 상태를 확인할 수 있는 것은 아닙니다. 설치 위치에 따라 프로그램 이름과 경로를 바꾸세요. Windows에서는 mihomo.exe를 실행해야 할 수 있습니다. GUI 클라이언트에 내장 검사 기능이 있다면 이를 우선 사용해 다른 코어가 같은 설정 디렉터리를 읽으면서 생기는 간섭을 피하세요.

mihomo -t -f ./config.yaml

규칙만 있는 설정은 로드되지만 특정 규칙 집합을 추가한 뒤 실패한다면 규칙 집합 경로, 형식, 다운로드 결과를 확인하세요. 상대 경로는 일반적으로 설정 디렉터리를 기준으로 해석되지만 작업 디렉터리가 항상 같다고 가정할 수는 없습니다. 새로 추가한 내용을 일부씩 복원해 문제를 일으키는 항목을 찾으세요. 모든 파일을 비운 뒤 구독 주소와 로컬 오버라이드가 백업되지 않았다는 사실을 알게 되지 않도록 하세요.

아키텍처, 시스템 지원, 권한 확인

다운로드할 때 운영체제와 프로세서 아키텍처를 구분하세요. Apple Silicon, Intel, ARM 기기는 서로 다른 패키지가 필요할 수 있습니다. 실행 오류는 아키텍처 불일치, 시스템 구성 요소 누락, 지원되지 않는 운영체제 버전 때문일 수 있습니다. 먼저 다운로드 센터에서 기기에 맞는 패키지와 요구 사항을 확인하세요. 파일 이름이 비슷하다고 다른 패키지로 바꾸지 마세요. 새로 설치한다면 Clash Plus를 우선 고려하고 플랫폼 요구사항에 따라 다른 클라이언트를 선택하세요.

설정 디렉터리에 쓰기 권한이 없거나 디스크 공간이 부족하거나 로그 디렉터리 권한이 잘못된 경우에도 시작에 실패할 수 있습니다. 현재 사용자에게 클라이언트의 데이터 디렉터리를 읽고 쓸 권한이 있는지 확인하고, 시스템 전체 디렉터리를 모든 사용자가 쓸 수 있도록 변경하지 마세요. Linux 서비스 실행 사용자와 로그인 사용자는 다를 수 있습니다. 터미널에서 설정을 읽을 수 있어도 systemd 서비스가 읽을 수 있다는 뜻은 아니므로 실제 서비스 사용자 권한으로 확인하세요.

보안 소프트웨어와 자원 문제는 근거를 확인해 처리

보안 소프트웨어가 가상 네트워크 어댑터, 백그라운드 서비스, 프로그램 시작을 차단할 수 있습니다. 먼저 격리 기록과 시스템 알림에서 차단된 파일과 동작을 확인하고 전체 보안을 장기간 끄지 마세요. 회사 기기를 관리자가 관리한다면 로그를 제공해 확인을 요청하세요. TUN을 켠 뒤에만 종료된다면 네트워크 어댑터와 권한이 필요한 서비스를 집중적으로 점검하세요. 창을 여는 즉시 실패한다면 그래픽 구성 요소와 사용자 데이터부터 확인하세요.

메모리나 CPU 사용량이 계속 높다면 지나치게 상세한 로그, 큰 규칙 집합, 연결 루프가 있는지 확인하세요. 자원 사용량 상승은 현상일 뿐이므로 연결 수, 로그 내용, 문제가 발생한 동작과 함께 살펴봐야 합니다. 먼저 일반 로그 수준으로 되돌리고 트래픽을 중복 처리하는 프로그램을 종료한 뒤 개선 여부를 확인하세요. 메모리가 적은 기기에서는 캐시를 계속 늘리기보다 불필요한 설정 규모를 줄이는 편이 합리적입니다.

범위를 정해 초기화하고 이전 설정을 옮기세요

초기화하기 전에 백업하고 손상된 것으로 의심되는 사용자 상태나 캐시 파일만 다른 위치로 옮겨 클라이언트가 다시 만들도록 하세요. 먼저 화면에서 제공하는 초기화 기능을 사용하고 삭제되는 항목을 확인합니다. 원격 구독, 로컬 규칙, 프록시 그룹 선택, 시스템 서비스 설정은 서로 다른 데이터입니다. 다른 클라이언트로 옮길 때도 모든 화면 설정이 YAML만으로 자동 이전된다고 가정하지 마세요.

Clash for Windows와 ClashX Meta는 업데이트가 중단된 클라이언트입니다. 새 운영체제와의 호환성 문제가 발생한다면 유지 관리 중인 대안으로 이전하는 것을 고려하세요. 이전하기 전에 설정과 사용자 항목을 내보내고 다운로드 페이지의 플랫폼별 안내에 따라 클라이언트를 선택하세요. 기본 프록시 연결부터 확인한 다음 TUN과 시작 설정을 복원합니다. 이전 클라이언트와 새 클라이언트를 모두 시작 시 네트워크 처리하도록 설정하지 마세요.

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

VPN 권한과 설정 로드부터 확인

모바일 기기는 일반적으로 시스템 VPN 인터페이스로 트래픽을 처리합니다. 처음 연결할 때 시스템 권한을 승인해야 하며 구독 가져오기에 성공했다고 권한 설정까지 끝난 것은 아닙니다. 설정이 선택되어 있는지, 프록시 그룹에 사용할 수 있는 구성원이 있는지 확인한 뒤 연결을 시작하세요. 시스템에 VPN 상태가 표시되고 클라이언트에 연결 기록이 생기는지 확인합니다. 권한이 거부되었거나 기기 관리 정책이 제한한다면 같은 구독을 반복해서 가져오지 말고 시스템 단계의 문제부터 해결하세요.

같은 기기의 다른 VPN, 업무용 프로필, 보안 필터, 일부 광고 차단 도구가 트래픽 처리 권한을 두고 충돌할 수 있습니다. 테스트할 때 네트워크를 처리하는 도구 하나만 남기고 같은 기능을 하는 다른 서비스를 끄세요. 브라우저 확장 프로그램의 필터링은 VPN과 반드시 충돌하는 것은 아니므로 실제 동작 방식에 따라 구분해야 합니다. 조직에서 관리하는 기기라면 관리 정책을 따르고 관리 설정을 삭제해 프록시를 강제로 시작하지 마세요.

Android 백그라운드 및 배터리 제한

Android에서 화면을 잠근 뒤 연결이 끊기고 앱으로 돌아오면 복구되는 경우 백그라운드 제한이 원인일 수 있습니다. 클라이언트 알림이 계속 표시되는지, 시스템이 백그라운드 활동을 제한하는지 확인하고 기기의 배터리 설정에서 필요한 백그라운드 실행을 허용하세요. 제조사마다 메뉴가 다르므로 다른 브랜드의 경로를 그대로 따라 하지 마세요. 설정 변경 뒤 화면을 잠근 채 기다렸다가 다시 접속하고 로그를 확인하세요. 화면이 켜져 있을 때의 스위치만 보고 판단하지 마세요.

‘항상 사용 VPN’과 ‘VPN 연결 없이는 차단’ 옵션은 연결이 끊겼을 때의 동작을 바꿉니다. 연결을 차단하도록 설정했다면 클라이언트가 중지된 뒤 기기 전체에서 인터넷이 끊기는 것이 시스템 정책에 따른 정상 동작일 수 있습니다. 점검하기 전에 이 옵션의 의미를 확인하고, 비교를 위해 잠시 끌지 결정하세요. 진단이 끝나면 필요한 보호 설정을 복원합니다. 시스템이 의도적으로 트래픽을 차단한 상황을 DNS나 모든 노드의 고장으로 오인하지 마세요.

Android 클라이언트는 앱별 프록시나 우회 목록을 제공할 수 있습니다. 특정 앱에 대한 로그만 없다면 제외 목록에 등록되어 있는지 확인하세요. 업무용 프로필에 같은 앱이 설치되어 있다면 특히 주의해야 합니다. 우회 기능을 켰다면 해당 앱의 동작을 프록시 그룹만으로 설명할 수 없습니다. Clash Plus, Clash Meta for Android, FlClash, Surfboard는 화면 구성과 설정 지원 범위가 다르므로 이전할 때 기능을 하나씩 확인하고 모든 설정을 그대로 복사하지 마세요.

iOS 연결 및 클라이언트 선택

iOS에서 Clash Plus를 사용할 때는 먼저 시스템 안내에 따라 VPN 구성을 추가한 뒤 유효한 구독을 가져오고 정책을 선택하세요. 시스템에 VPN 상태가 표시되면 트래픽 처리 경로가 만들어진 것이지만 실제 출구는 요청을 보내 확인해야 합니다. 설정을 바꾼 뒤 기존 요청이 실패한다면 테스트 앱을 닫았다가 다시 열어 연결 재사용의 영향을 줄이세요. 업무용 기기에서 제한이 발생하면 개인 VPN 추가가 허용되는지 먼저 확인하세요.

클라이언트 선택과 설치 방법은 iOS 다운로드 안내를 참고하세요. Clash Plus 공식 사이트는 clashplus.io입니다. 앱에서 설정에 실패했다면 가져오기 오류와 연결 오류를 따로 기록하고 두 문제를 한꺼번에 처리하지 마세요. 계정, 구독 서비스, 클라이언트는 서로 다른 단계입니다. 앱을 설치했다고 사용할 수 있는 노드가 자동으로 제공되는 것은 아닙니다.

Wi-Fi, 모바일 데이터, 핫스팟을 각각 확인

Wi-Fi에서는 정상인데 모바일 데이터에서 실패한다면 클라이언트의 모바일 데이터 권한, 시스템 데이터 제한, 서비스 제공자의 네트워크 제한을 확인하세요. 반대로 Wi-Fi에서만 실패한다면 인증 페이지, 라우터 DNS, 네트워크 프로토콜 제한, 해당 네트워크의 관리 정책을 점검합니다. 같은 노드와 대상을 유지하면서 두 네트워크의 결과를 각각 기록하면 문제 범위를 좁힐 수 있습니다. 네트워크와 설정을 동시에 바꾸지 마세요.

Wi-Fi와 모바일 데이터 간 전환으로 로컬 주소, IPv6 상태, NAT 매핑이 바뀌어 기존 연결이 유지되지 않을 수 있습니다. 전환 후 시스템 네트워크가 안정될 때까지 기다린 뒤 새 요청을 보내세요. 계속 복구되지 않는다면 클라이언트 연결을 껐다가 다시 켜고 출구가 새로 연결되는지 확인합니다. 전환 순간에만 실패한 경우와 전환 후에도 계속 실패하는 경우는 다른 증상이므로 따로 기록하세요.

휴대폰에서 핫스팟을 켜도 연결된 기기가 자동으로 휴대폰 VPN을 사용하는 것은 아닙니다. 트래픽 전달 여부는 운영체제와 구현에 따라 다르므로 휴대폰의 웹페이지가 열린다는 사실만으로 컴퓨터도 프록시를 사용한다고 볼 수 없습니다. 연결된 기기에서 출구를 별도로 확인하세요. 프록시를 공유하려면 클라이언트가 지원하는 로컬 네트워크 연결 방식과 네트워크 격리 설정을 확인하고 접근 범위를 제한하세요. 공용 핫스팟에서 프록시 포트를 공개하지 마세요.

로컬 네트워크와 해결 결과 확인

화면 미러링, 프린터, 로컬 네트워크 관리, 게임 기기 검색은 직접 연결, 브로드캐스트, 로컬 DNS에 의존할 수 있습니다. 프록시를 켠 뒤 이런 기능이 작동하지 않는다면 로컬 네트워크 우회, 라우팅, Fake-IP 예외를 확인하세요. 화면 미러링을 복구하려고 모든 트래픽을 직접 연결로 바꾸지 마세요. 먼저 문제가 발생한 앱과 대상 주소를 찾은 뒤 필요한 예외만 추가합니다. 로컬 기기 검색과 공용 인터넷 접속은 따로 확인해야 합니다.

마지막으로 네 가지를 확인하세요. 앱을 열어 둔 상태의 접속, 화면을 잠근 뒤 복구, Wi-Fi와 모바일 데이터 간 전환, 클라이언트 종료 후의 네트워크 상태입니다. 사용자 규칙이 구독 업데이트로 덮어써지지 않는지 확인하고 사용할 수 있는 설정 사본을 보관하세요. 자주 묻는 내용은 도움말 센터에서 확인할 수 있습니다. 처음 설치하거나 다른 클라이언트로 이전하는 경우 빠른 시작 가이드로 돌아가 기본 연결을 확인한 뒤 백그라운드 실행, 앱별 설정, 로컬 네트워크 설정을 복원하세요.