Clash 문제 해결 가이드

인터넷 연결 안 됨: 로컬 네트워크와 프록시 경로 분리하기

연결이 끊긴 구간부터 확인하기

먼저 시스템 프록시와 TUN 모드를 끈 다음 평소에 직접 접속되는 사이트를 열어 보세요. 그래도 연결되지 않으면 Wi-Fi 로그인 페이지가 필요한지, 이더넷 케이블이 연결되어 있는지, 운영체제에 유효한 게이트웨이가 설정되어 있는지 확인하세요. 이 단계의 문제는 아직 Clash와 무관합니다. 공용 네트워크 인증은 보통 프록시를 끈 상태에서 완료해야 합니다. 인증 후 클라이언트를 다시 켜고 재확인하세요.

직접 연결은 되는데 프록시를 켜면 실패한다면 다음으로 코어 상태를 확인하세요. 트레이 아이콘이 있는지만 보지 말고 클라이언트 로그 페이지에서 설정이 로드되었는지, 수신 포트가 열렸는지, 설정 파싱 실패·주소 충돌·시작 직후 종료가 반복되는지 확인하세요. 화면을 표시하는 프로세스와 mihomo 코어는 별개입니다. 창이 열려 있어도 로컬 프록시 서비스가 실행 중이라는 뜻은 아닙니다.

설정에서 실제 혼합 포트를 확인하세요. 아래에서는 로컬 포트 7890을 예로 들었으므로 테스트 전에 사용 중인 포트 번호로 바꿔야 합니다. 명령에 프록시를 직접 지정하면 브라우저가 시스템 설정을 읽는지 여부와 무관하게 테스트할 수 있습니다. Windows에서는 일부 PowerShell 환경에서 curl이 다른 명령으로 해석될 수 있으므로 curl.exe를 사용하세요.

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

로컬 주소에 연결할 수 없다는 오류가 나면 수신 포트, 코어 상태, PC 보안 소프트웨어의 차단 기록을 우선 확인하세요. 로컬 프록시에 연결된 뒤 시간 초과가 발생한다면 정책 그룹과 원격 연결을 점검하세요. HTTP 응답 헤더를 받았다면 상태 코드가 성공이 아니더라도 요청이 서버 응답 단계까지 진행된 것입니다. 이를 단순히 로컬 프록시가 시작되지 않은 문제로 볼 수는 없습니다.

로그에서 규칙과 정책 그룹 확인하기

모드를 ‘규칙’로 바꾸고 프록시 페이지에서 매칭된 정책 그룹에 사용 가능한 출구가 선택되어 있는지 확인하세요. 설정에 따라 트래픽이 여러 그룹으로 나뉠 수 있으므로 기본 그룹만 바꿔서는 다른 트래픽의 경로가 달라지지 않습니다. 대상에 한 번 접속한 뒤 연결 페이지나 로그에서 도메인을 찾아 규칙 유형, 정책 그룹, 최종 정책을 확인하세요. 다른 사이트가 정상이라는 사실로 해당 요청의 성공을 판단하지 마세요.

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

이 예시는 설정에 Proxy라는 프록시 또는 정책 그룹이 이미 있어야 합니다. 완성된 설정 파일이 아니므로 단독으로 가져오지 마세요. 규칙은 위에서 아래로 확인하며 처음 일치하는 규칙이 적용됩니다. 대상이 앞쪽의 거부 규칙이나 직접 연결 규칙에 먼저 매칭되면 마지막의 MATCH가 다시 적용되지 않습니다. 수정할 때는 대상에 해당하는 규칙 하나만 바꾸고, 되돌릴 수 있도록 기존 순서를 보존하세요.

비교를 위해 잠시 ‘전역’ 모드로 전환할 수 있지만 전역 정책 그룹에서도 출구를 선택해야 합니다. 전역 모드는 정상인데 규칙 모드에서만 실패한다면 규칙, 트래픽별 정책 그룹 또는 관련 DNS 동작으로 원인을 좁힐 수 있습니다. 두 모드 모두 실패하면 공통으로 쓰는 로컬 수신 포트와 출구를 먼저 확인하세요. 비교가 끝나면 규칙 모드로 되돌려 임시 진단 설정이 계속 적용되지 않게 하세요.

충돌을 정리한 뒤 복구 확인하기

문제를 확인하는 동안 네트워크를 제어하는 도구는 하나만 사용하세요. 다른 VPN, 브라우저 프록시 확장 프로그램, 기존 프록시 클라이언트, 패킷 캡처 도구가 연결 경로를 동시에 바꿀 수 있습니다. 하나씩 종료하고 다시 테스트하세요. 네트워크 어댑터를 삭제하거나 네트워크 전체를 초기화하지 마세요. 클라이언트를 종료한 뒤에도 직접 연결이 안 된다면 시스템 프록시 설정에 로컬 포트가 남아 있는지 확인하세요. 서비스는 중지됐는데 프록시 설정이 유지되면 모든 네트워크가 끊긴 것처럼 보일 수 있습니다.

복구 후 직접 연결 대상 하나와 프록시 대상 하나를 각각 테스트하고, 두 요청이 예상한 정책에 매칭되는지 확인하세요. 웹페이지가 열리는지만 보지 말고 로그에 표시된 연결 경로와 규칙도 확인해야 합니다. 브라우저만 실패하고 명령줄 테스트가 정상이라면 시스템 프록시 항목을 확인하세요. 도메인 해석 오류가 집중된다면 DNS 항목으로 이동하세요. 전체 절차를 처음부터 다시 진행할 필요는 없습니다.

노드 시간 초과: 포트·핸드셰이크·대상 요청 구분하기

오류가 발생한 단계부터 확인하기

‘시간 초과’는 제한 시간 안에 응답을 받지 못했다는 뜻이지, 원인이 하나라는 의미는 아닙니다. 클라이언트가 노드 서버에 연결하지 못하거나, 프로토콜 핸드셰이크가 완료되지 않거나, 출구에서 대상에 연결하지 못해도 비슷한 메시지가 표시될 수 있습니다. 서버 주소, 연결 방식, 오류가 연결 시도·TLS·응답 읽기 중 어느 단계에서 발생했는지 포함해 전체 오류 내용을 보존하세요. 마지막 몇 글자만 캡처하면 중요한 단서를 놓칠 수 있습니다.

먼저 영향 범위를 확인하세요. 같은 노드로 모든 대상에 연결할 수 없는지, 특정 사이트만 실패하는지, 같은 구독의 다른 노드는 정상인지, 휴대폰 핫스팟으로 바꾸면 해결되는지 비교합니다. 한 번에 조건 하나만 바꾸세요. 특정 Wi-Fi에서만 모든 노드가 실패한다면 노드별 프로토콜을 한꺼번에 수정하기보다 해당 네트워크의 접속 제한, 인증 상태, 출구 정책을 우선 확인하세요.

클라이언트가 이전 설정의 동명 노드가 아니라 현재 구독을 사용 중인지 확인하세요. 설정 페이지에서 대상 설정을 선택한 다음 정책 그룹으로 돌아가 선택 항목을 다시 확인하세요. 일부 그룹은 자동 선택이나 장애 조치 정책을 사용하므로 테스트 도중 최종 출구가 바뀔 수 있습니다. 목록에서 노드 하나의 단일 테스트 결과만 보지 말고 로그에 기록된 실제 정책을 기준으로 판단하세요.

서버 주소와 TCP 연결 확인하기

Windows에서는 Test-NetConnection으로 서버의 TCP 포트를 확인할 수 있습니다. 아래의 예시 주소는 명령 형식을 보여 주기 위한 것이므로 실제 테스트에는 설정에 기재된 서버와 포트를 입력해야 합니다. 예시 결과로 서비스 상태를 판단하지 마세요. 이 테스트는 프록시 비밀번호, 프로토콜 옵션, UDP 사용 가능 여부를 확인하지 않고 TCP 연결이 한 번 성립하는지만 보여 줍니다.

Test-NetConnection -ComputerName 192.0.2.10 -Port 443

TCP 연결에 실패하면 서버 점검 여부, 구독 업데이트 상태, 로컬 방화벽의 프로세스 차단 여부, 현재 네트워크의 포트 제한을 확인하세요. 연결에 성공해도 프록시가 정상 작동한다는 뜻은 아닙니다. 비밀번호, 전송 경로, TLS 서버 이름, 프로토콜 옵션이 잘못되면 핸드셰이크가 실패할 수 있습니다. 구독으로 관리되는 노드는 먼저 구독을 새로고침하세요. 인증 정보를 추측해 하나씩 바꾸지는 마세요.

로그에 인증서 검증 실패가 표시되면 먼저 시스템 날짜, 시간대, 시각을 동기화한 다음 노드 도메인과 인증서 설정을 확인하세요. 인증서 검증을 끄는 것은 일반적인 해결책이 아닙니다. 서버 설정 오류나 연결 간섭 위험을 가릴 수 있습니다. 브라우저의 인증서 경고는 시스템 신뢰 체인과 관련됐을 수도 있습니다. 자세한 점검 순서는 HTTPS 인증서 오류 원인 분석을 참고하세요.

서버 주소를 도메인으로 지정했다면 시작 단계의 DNS에도 의존합니다. 서버 도메인 자체를 해석하지 못하면 원격 연결은 시작되지 않습니다. 다른 웹사이트에 접속해도 이 단계의 문제를 확인할 수 없습니다. 오류에 표시된 도메인이 노드 도메인인지 방문하려는 사이트의 도메인인지 확인하세요. 전자는 직접 연결 가능한 초기 DNS 경로를, 후자는 DNS 및 트래픽 분할 설정을 점검해야 합니다. 두 경우를 같은 설정 문제로 취급하지 마세요.

연결 테스트와 실제 서비스 이용을 구분하기

노드 목록의 연결 테스트는 보통 지정된 테스트 주소에 간단한 요청을 보냅니다. 테스트 주소가 차단되어 있거나 응답 방식이 다르거나 현재 네트워크에 적합하지 않으면 잘못된 결과가 나올 수 있습니다. 반대로 테스트 성공이 동영상, 게임, 모든 웹사이트의 정상 작동을 보장하지도 않습니다. 먼저 일반 HTTPS 요청을 테스트한 뒤 실제 대상에서도 확인해 특정 서비스에만 문제가 있는지 살펴보세요. 한 번의 결과로 모든 노드를 삭제하지 마세요.

게임과 통화는 UDP에 의존할 수도 있습니다. 웹페이지는 열리는데 실시간 서비스가 실패한다면 노드 프로토콜과 서버가 필요한 전송 방식을 지원하는지, 클라이언트의 트래픽 처리 범위에 해당 앱이 포함되는지 확인하세요. TCP 포트 테스트는 UDP 테스트를 대신할 수 없으며 브라우저 속도 측정도 UDP 경로가 정상임을 증명하지 않습니다. 서버 지원 여부를 모른다면 설정을 반복해서 바꾸기보다 구독 제공업체에 문의하세요.

연결을 계속 재시도하면 비슷한 로그가 쌓여 최초 오류를 찾기 어려워집니다. 자동 테스트를 일시 중지하고 출구 하나를 선택해 연결 과정을 한 번 기록한 뒤, 정상 작동이 확인된 다른 출구와 비교하세요. 새 출구는 정상이라면 기존 노드에서 실패한 단계와 테스트 시각을 보존해 서비스 제공업체에 전달하세요. 모든 출구가 똑같이 실패하면 로컬 네트워크, DNS, 클라이언트 연결 경로 등 공통 요소를 다시 살펴보세요.

복구 여부는 테스트 버튼이 성공으로 바뀌었는지가 아니라 실제 요청이 안정적으로 완료되는지로 판단하세요. 확인이 끝나면 기존 자동 선택 설정으로 되돌리고 임시 전역 모드가 남아 있지 않은지 확인하세요. 같은 문제가 반복되면 발생한 네트워크, 노드 유형, 오류 단계 세 가지를 기록해 두세요. 이후 네트워크 환경 변화, 구독 업데이트 지연, 특정 출구의 지속적인 장애를 구분하기 쉽습니다.

구독 실패: 다운로드 경로와 설정 파싱 확인하기

구독 가져오기 실패와 설정 불러오기 실패 구분하기

구독 업데이트는 콘텐츠를 가져오는 단계와 설정을 파싱하는 단계로 나뉩니다. 요청 시간 초과, 연결 거부, 비정상 HTTP 상태는 가져오기 단계의 문제입니다. 콘텐츠를 받았지만 YAML 오류, 필드 유형 오류, 참조된 정책이 없다는 메시지가 나오면 파싱 단계의 문제입니다. 먼저 설정 페이지에서 업데이트 오류를 확인하고 같은 시각의 로그를 찾아보세요. 업데이트 버튼을 반복해서 눌러도 요청 경로는 바뀌지 않으며 문법 오류도 해결되지 않습니다.

구독 링크가 온전한지, 복사 과정에서 끝부분 매개변수가 빠지거나 공백·줄바꿈이 들어가지 않았는지 확인하세요. 구독 URL에는 계정 접속 정보가 포함되는 경우가 많으므로 공개 포럼, 온라인 변환 사이트, 스크린샷에 노출하지 마세요. 도움을 요청할 때는 도메인, 상태 코드, 오류 유형만 남기고 경로에 포함된 개인 식별 정보는 가리세요. 링크가 공개됐다면 이미 올린 메시지를 삭제하는 데 그치지 말고 서버에서 새 링크를 발급하세요.

서비스 제공업체 홈페이지가 열린다고 해서 구독 API에도 접속할 수 있는 것은 아닙니다. 홈페이지와 구독 API는 도메인, 접근 제어, 콘텐츠 전달 경로가 다를 수 있고, 한쪽은 웹페이지를 반환하지만 다른 쪽은 유효한 인증 정보가 필요할 수 있습니다. 인증 실패, 접근 거부, 과도한 요청 등의 응답이 나오면 서비스 제공업체 안내에 따라 계정 상태와 업데이트 주기를 확인하세요. 제한을 우회하려고 짧은 간격으로 재시도하지 마세요.

구독 업데이트의 네트워크 의존성 확인하기

구독 도메인에 접속하려면 프록시가 필요한데 현재 설정에는 사용 가능한 노드가 없다면, 업데이트에 프록시가 필요하지만 노드를 받으려면 먼저 업데이트해야 하는 순환 문제가 생길 수 있습니다. 정상 작동이 확인된 다른 설정으로 전환하거나 구독 API에 직접 연결할 수 있는 네트워크에서 업데이트하세요. 클라이언트마다 구독 다운로드에 프록시를 사용하는 설정이 다릅니다. 관련 옵션을 설정 페이지에서 확인하고 시스템 프록시가 코어의 요청에도 적용된다고 가정하지 마세요.

업데이트 후 노드와 정책 그룹이 추가되었는지 확인한 뒤 방금 업데이트한 설정을 실제로 사용 중인지 살펴보세요. 여러 설정을 동시에 보관할 수 있는 클라이언트에서는 다운로드가 완료되어도 자동으로 활성 설정이 바뀌지 않을 수 있습니다. 로그에 이전 서버가 계속 표시되면 설정 선택 상태, 원격 프록시 목록 새로고침 여부, 기존 주소를 유지하는 덮어쓰기 규칙을 확인하세요. 설정 선택 문제를 캐시 문제로 오인하지 마세요.

응답 내용이 로그인 페이지, 접근 확인 페이지, 일반 오류 안내라면 파일 확장자를 YAML로 저장해도 그대로 가져올 수 없습니다. 파서가 오류를 보고한 위치는 구독 규칙의 문제가 아니라 웹페이지의 특정 문자일 수도 있습니다. 신뢰할 수 있는 로컬 텍스트 편집기로 파일의 시작 부분과 구조를 확인하세요. 계정 정보가 포함된 설정 파일 전체를 공개 문법 검사 서비스에 올리지 마세요.

YAML 문법과 참조 오류 찾기

YAML 들여쓰기에는 공백을 사용하고 같은 계층의 키는 가지런히 맞추세요. 콜론 뒤에 공백이 없거나, 복사 과정에서 전각 문자가 들어가거나, 목록을 일반 문자열로 작성하는 경우가 흔합니다. 오류 행 번호는 파서가 충돌을 발견한 위치를 가리키지만 실제 원인은 바로 앞 행에 있을 수도 있습니다. 해당 계층의 앞뒤 몇 줄을 확인하고 오류를 없애려고 프록시 그룹 전체를 함부로 삭제하지 마세요.

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,DIRECT

이 예시는 구조를 설명하기 위한 것으로 정책 그룹에는 DIRECT만 들어 있습니다. 이름 참조 방식만 보여 주며 원격 프록시 기능은 제공하지 않습니다. 규칙의 Proxy는 그룹 이름과 정확히 일치해야 합니다. 원격 프록시 목록과 규칙 목록도 각각 정의되어 있어야 합니다. 이름의 철자나 대소문자가 다르거나 덮어쓰기로 이름이 바뀌면 다운로드에 성공한 설정도 불러오지 못할 수 있습니다.

클라이언트에 설정 검사 기능이 있다면 먼저 검사를 실행한 뒤 적용하세요. 명령줄을 사용하는 경우 아래 명령을 설정 파일이 있는 디렉터리에서 실행하세요. 설정에 상대 경로가 있으면 실제 작업 디렉터리도 확인해야 합니다. 검사 통과는 해당 코어가 설정을 읽을 수 있다는 뜻일 뿐, 원격 노드 연결이나 규칙의 실제 업무 적합성까지 보장하지는 않습니다.

mihomo -t -f config.yaml

구독 자체는 정상인데 적용 후 문제가 생긴다면 로컬 덮어쓰기, 병합 스크립트, 확장 설정을 잠시 끄고 원본 구독을 불러와 비교하세요. 원본은 정상이라면 2차 수정 단계에 원인이 있을 가능성이 높습니다. 변경 사항을 하나씩 다시 적용해 문제를 일으키는 항목을 찾으세요. 유일한 백업을 바로 덮어쓰지 마세요. 여러 기기에서 동기화한다면 클라이언트마다 같은 덮어쓰기 형식을 지원하는지도 확인하세요. 자세한 내용은 여러 기기 간 설정 동기화 방법을 참고하세요.

장기적으로는 서비스 제공업체의 원격 설정과 로컬 맞춤 규칙을 분리해 보관하세요. 업데이트에 실패하면 이전에 정상 작동한 설정을 유지하고 새 설정이 제대로 불러와진 뒤 전환하세요. 구독에서 서버 오류가 계속 반환되면 운영체제를 재설치하거나 앱 데이터를 모두 지우지 말고, 개인정보를 가린 상태 코드와 발생 시각, 클라이언트 이름을 서비스 제공업체에 전달하세요.

속도 저하: DNS·연결·전송 단계별로 확인하기

느려진 상황을 구체적으로 파악하기

웹페이지 첫 로딩이 오래 걸리는 경우, 페이지가 열린 뒤 로딩이 느린 경우, 대용량 파일 전송 속도가 들쭉날쭉한 경우는 서로 다른 단계의 문제입니다. 전송이 시작되기 전인지 도중인지 기록하고 같은 대상을 연속으로 테스트하세요. 처음에는 느리고 다시 열면 빨라지는 경우 DNS, 연결 설정, 앱 캐시와 관련될 수 있습니다. 전송 내내 느리다면 Wi-Fi 신호, 출구 회선, 서버 속도 제한을 확인하는 편이 좋습니다.

속도 측정 시 기기, 네트워크, 대상, 정책 그룹 선택을 고정하고 시스템 업데이트, 클라우드 동기화 등 다른 대용량 작업은 잠시 중지하세요. Wi-Fi 신호가 약하면 먼저 신호 상태를 확인하고 필요하면 유선 연결과 비교하세요. 휴대폰 핫스팟은 로컬 광대역 문제를 분리하는 데 도움이 될 수 있지만 통신사 경로도 함께 바뀝니다. 결과만으로 특정 노드나 클라이언트에 문제가 있다고 단정할 수는 없습니다.

로그에 기록된 최종 정책을 확인해 느린 요청이 의도한 출구를 거쳤는지 살펴보세요. 특정 사이트가 다른 정책 그룹에 매칭되면 기본 그룹을 바꿔도 속도는 달라지지 않습니다. 여러 도메인에서 리소스를 불러오는 웹페이지라면 주요 문서와 정적 리소스의 경로가 다른지도 확인하세요. 페이지 본문은 빠르게 표시되는데 이미지가 늦게 뜬다면 특정 리소스 도메인의 규칙이나 원격 연결만 문제일 수 있습니다.

연결 테스트 값 대신 단계별 시간 확인하기

아래 명령은 요청 시작부터 각 단계까지의 누적 시간을 출력하므로 같은 환경에서 전후를 비교할 수 있습니다. Windows에서는 curl.exe, macOS와 Linux에서는 curl을 사용하세요. 프록시 포트는 실제 설정에 맞게 바꾸세요. HTTP 프록시로 HTTPS에 접속하면 도메인 해석을 프록시 쪽에서 처리할 수 있으므로 로컬 DNS 시간은 대상 사이트의 전체 DNS 소요 시간과 같지 않습니다.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -o NUL -sS -w "connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/

각 값은 요청 시작부터 누적된 시간이므로 서로 독립된 소요 시간은 아닙니다. 연결은 빨리 됐지만 첫 바이트를 받기까지 오래 걸렸다면 프록시 핸드셰이크, 원격 연결 또는 서버 처리와 관련될 수 있습니다. 전체 시간이 길어진 것은 응답 데이터가 많아서일 수도 있습니다. macOS와 Linux에서는 출력 파일 NUL을 /dev/null로 바꾸세요. 응답 내용과 서버 동작이 다르므로 서로 다른 웹페이지의 총 소요 시간을 비교해 회선 품질을 판단하지 마세요.

노드 연결 테스트는 작은 요청이 제때 완료되는지를 확인할 뿐 다운로드 대역폭을 직접 보여 주지는 않습니다. 회선이 단일 연결과 다중 연결에 서로 다른 정책을 적용할 수도 있어 브라우저 다운로드, 온라인 동영상, 속도 측정 도구의 결과가 다를 수 있습니다. 접근 권한이 있는 동일한 리소스를 여러 번 테스트한 뒤 다른 출구와 비교하세요. 측정 결과를 좋게 보이게 하려고 코어의 시간 초과 값을 자주 바꾸지 마세요.

프로토콜·라우팅·트래픽 처리 방식 비교하기

TUN 모드에서만 느리다면 다른 VPN이 동시에 실행 중인지 확인한 뒤 로그에 라우팅 중복 처리나 연결 루프가 있는지 살펴보세요. 시스템 프록시를 잠시 사용해 비교하면 앱의 연결 경로와 출구 회선을 구분하는 데 도움이 됩니다. 시스템 프록시는 정상인데 TUN에서 문제가 생겨도 모든 노드를 바로 바꾸지는 마세요. 가상 네트워크 어댑터, DNS 처리, 네트워크 어댑터 선택을 먼저 확인하세요. 가상 머신이나 컨테이너 네트워크가 설치된 기기라면 특히 주의해야 합니다.

일부 앱은 UDP 기반 전송 방식을 우선 사용합니다. 현재 출구가 해당 트래픽을 지원하지 않으면 실패를 기다린 뒤 TCP로 전환하면서 연결 초반이 멈춘 것처럼 보일 수 있습니다. 제어된 테스트에서 앱의 관련 전송 옵션을 잠시 끄고 개선되는지 확인할 수 있지만 변경 내용을 기록하고 테스트 후 원래대로 돌려놓으세요. 이 결과만으로 UDP를 전체 차단하면 통화, 게임 등 다른 서비스에 문제가 생길 수 있습니다.

MTU 불일치로 작은 요청은 성공하지만 대용량 전송이 멈출 수도 있습니다. 다만 모든 지연을 MTU 문제로 볼 수는 없습니다. 특정 네트워크나 TUN 경로에서 반복 재현되고 다른 연결 경로에서는 정상일 때만 추가로 확인하세요. 클라이언트와 네트워크 환경의 안내에 따라 범위를 좁혀 조정하고 기존 값을 보존하세요. 값을 무작정 낮추면 패킷 수가 늘어나고 실제 연결 경로나 서버 문제를 가릴 수 있습니다.

오래 실행한 뒤에만 느려진다면 연결 페이지에 비정상 재연결이 쌓였는지, 디버그 로그가 계속 기록되고 있는지, 기기가 절전 상태거나 과열로 성능이 제한되는지 확인하세요. 비정상 요청을 발생시키는 앱을 먼저 종료하고 클라이언트 사용량이 줄어드는지 살펴보세요. 높은 로그 수준은 짧은 진단에만 사용하고 계속 켜 두지 마세요. 디스크 쓰기와 화면 렌더링도 저사양 기기의 사용 경험에 영향을 줄 수 있습니다.

점검이 끝나면 같은 대상, 같은 네트워크, 같은 연결 경로로 다시 테스트해 기존 대기 구간이 줄었는지 비교하세요. 특정 사이트만 계속 느리고 다른 서비스는 정상이라면 도메인, 매칭된 정책, 발생 시간을 기록해 대상 서비스나 출구 경로를 확인하세요. 사이트 하나의 혼잡을 클라이언트 전체의 성능 문제로 확대 해석하지 말고 한 번의 테스트로 고정 속도를 보장하지도 마세요.

DNS 문제: 해석 경로와 Fake-IP 매핑 확인하기

DNS 요청을 처리하는 주체부터 확인하기

로그에 도메인 해석 실패가 표시되면 먼저 운영체제, 브라우저, mihomo, 노드 서버 중 어느 곳에서 발생했는지 구분해야 합니다. 시스템 DNS 조회에 성공해도 코어가 사용하는 상위 DNS 서버가 정상이라는 뜻은 아닙니다. 브라우저에서 자체 보안 DNS를 사용하면 시스템 DNS 경로를 우회할 수도 있습니다. 현재 트래픽 처리 방식과 DNS 설정을 확인한 뒤 해당 경로에 맞는 도구로 테스트하세요. 한 계층의 결과로 다른 계층이 정상이라고 판단하지 마세요.

먼저 오류에 표시된 도메인을 확인하세요. 노드 서버 도메인을 해석하지 못하면 프록시 연결을 시작할 수 없습니다. 방문하려는 사이트의 도메인을 해석하지 못한 경우라면 연결이 시작된 뒤에 발생한 문제일 수 있습니다. 암호화 DNS를 사용하면 상위 DNS 서버의 호스트 이름도 먼저 해석해야 할 수 있습니다. 초기 해석, 프록시 서버 해석, 일반 대상 도메인 해석을 구분해야 의존성 순환이 어디서 발생하는지 파악할 수 있습니다.

Windows에서는 Resolve-DnsName example.com으로 시스템 DNS 경로를 확인할 수 있고, macOS와 Linux에서는 nslookup example.com을 사용할 수 있습니다. 특정 DNS 서버를 지정해 테스트하기 전에 주소와 수신 포트를 확인하세요. 시스템 도구는 보통 표준 DNS 포트로 요청하므로 임의의 로컬 포트를 그대로 테스트할 수는 없습니다. 명령이 성공했다는 것은 해당 조회가 응답을 받았다는 뜻일 뿐입니다. 클라이언트 로그에서 실제 요청을 확인하세요.

Fake-IP의 정상 동작 이해하기

Fake-IP 모드는 예약된 주소 대역의 매핑 주소를 반환할 수 있습니다. 이는 코어가 도메인을 연결과 대응시키는 방식이므로 그 자체로 DNS 변조를 의미하지는 않습니다. 중요한 것은 매핑 주소를 향하는 연결도 계속 같은 코어를 통과하는지 여부입니다. DNS는 클라이언트가 처리했지만 연결이 클라이언트를 우회하면 앱은 매핑 테이블에서만 의미가 있는 주소에 접속하게 되어 실패할 수 있습니다.

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
    - 119.29.29.29

아래는 DNS 일부 설정을 보여 주는 예시입니다. 기존 설정에 병합해야 하며 최상위 dns 항목을 중복 선언하면 안 됩니다. 상위 서버 주소 두 개는 교체 가능한 예시이므로 사용 중인 네트워크에서 연결 가능한 주소를 선택하세요. 루프백 주소의 비표준 포트에서 수신하도록 설정해도 시스템 DNS가 자동으로 바뀌지는 않습니다. 시스템 DNS 요청을 처리하는지는 클라이언트 설정, TUN, 플랫폼에 따라 다르므로 가져온 뒤 모든 앱에 적용됐다고 가정하지 마세요.

로컬 프린터, 화면 전송 기기, 실제 IP 주소가 필요한 앱은 fake-ip-filter로 특정 이름을 제외해야 할 수 있습니다. 먼저 해당 이름이 실제로 어떻게 해석되는지와 어떤 로컬 DNS를 사용하는지 확인한 뒤 필요한 범위만 추가하세요. 모든 도메인을 제외하면 모드 전체의 동작이 바뀌어 원인을 비교하기 어려워집니다. 작동 원리와 필터 적용 범위는 Fake-IP 모드 자세히 알아보기를 참고하세요.

캐시와 암호화 DNS의 의존성 확인하기

DNS 모드를 바꾼 뒤에도 운영체제와 브라우저가 이전 주소를 캐시하거나 앱이 기존 연결을 재사용할 수 있습니다. ‘설정 저장 → 코어 다시 불러오기 → 대상 앱 종료 → 필요한 캐시 정리 → 재테스트’ 순서로 진행하세요. Windows에서는 아래 명령으로 시스템 DNS 캐시를 지울 수 있습니다. 이 명령은 브라우저의 별도 캐시를 지우지 않으며 서버가 잘못된 응답을 반환하는 문제도 해결하지 않습니다.

ipconfig /flushdns

클라이언트 설정과 캐시를 전부 한꺼번에 지우지 마세요. Fake-IP 매핑과 기존 연결이 맞지 않는 문제라면 앱을 다시 시작해 매핑을 새로 만드는 편이 데이터 폴더 전체를 삭제하는 것보다 적절합니다. 절전 모드에서 깨어난 뒤 문제가 생겼다면 네트워크가 바뀌었는지, 가상 인터페이스가 복구됐는지, 기존 연결이 이전 네트워크에 묶여 있는지 먼저 확인한 뒤 코어를 다시 시작할지 판단하세요.

DoH 또는 DoT를 사용한다면 상위 DNS 주소에 연결할 수 있는지, 인증서가 유효한지, 상위 DNS 요청이 아직 연결되지 않은 프록시로 전달되지는 않는지 확인하세요. 암호화가 자동으로 안정성을 보장하지는 않습니다. 현재 네트워크에서 연결을 맺을 수 없다면 조회도 실패합니다. 먼저 현재 연결 가능한 일반 DNS 서버와 비교해 문제 계층을 확인한 다음 기존 암호화 DNS 설정을 복구하세요. 아무 서버로나 장기간 바꾸지 마세요.

IPv6 전용 환경이나 듀얼 스택 네트워크에서만 문제가 생기면 로그에서 IPv4와 IPv6 중 어느 주소를 선택했는지 확인하고 기기의 실제 라우팅 가능 여부와 비교하세요. 시스템에 IPv6 주소가 할당되어 있어도 모든 출구에서 IPv6 연결이 되는 것은 아닙니다. 제어된 테스트에서 IPv6 관련 설정을 바꿔 원인을 찾을 수 있지만, DNS 문제를 해결할 때마다 IPv6를 끄는 것을 고정 절차로 삼지 마세요.

문제를 해결한 뒤 이전에 실패한 도메인 하나와 로컬 네트워크 대상 하나에 다시 접속해 공용 인터넷 트래픽 분할과 로컬 기기 검색이 서로 영향을 주지 않는지 확인하세요. 필요하면 시스템 DNS, 코어의 상위 DNS, 브라우저 자체 DNS 설정을 기록해 각 항목의 역할을 구분하세요. 특정 도메인만 비정상 응답을 반환한다면 전체 기기의 DNS를 초기화하기보다 권한 DNS와 규칙을 먼저 확인하세요.

시스템 프록시 미작동: 앱 연결 경로와 포트 유형 확인하기

시스템 프록시가 모든 연결에 적용되는 것은 아닙니다

시스템 프록시는 해당 설정을 읽는 앱에 프록시 주소를 제공할 뿐, 모든 네트워크 트래픽을 강제로 가져오지는 않습니다. 브라우저, 명령줄 도구, 스토어 앱, 게임은 서로 다른 네트워크 라이브러리를 사용하므로 동작도 다를 수 있습니다. 웹페이지는 정상인데 특정 앱이 직접 연결된다면 해당 앱이 시스템 프록시를 지원하는지, 별도 프록시 설정이 있는지 먼저 확인하세요. 정상 작동 중인 구독 설정부터 바꾸지 말고 필요할 때 TUN 사용을 검토하세요.

프록시 주소가 현재 기기의 루프백 주소를 가리키고 포트가 클라이언트 설정과 일치하는지 확인하세요. HTTP 포트, SOCKS 포트, 혼합 포트는 서로 바꿔 쓸 수 없습니다. SOCKS 요청만 받는 포트에 HTTP 프록시 요청을 보내면 연결 종료나 프로토콜 오류가 발생할 수 있습니다. 클라이언트에서 혼합 포트를 사용하면 하나의 수신 포트가 해당 프록시 프로토콜을 처리할 수 있지만, 앱에서도 올바른 유형을 선택해야 합니다.

먼저 프록시를 명령에 직접 지정해 테스트한 뒤 프록시를 지정하지 않은 앱의 접속 결과와 비교하세요. 명령줄 요청은 성공하는데 브라우저가 실패한다면 브라우저 확장 프로그램, 별도 프록시 설정, 시스템 프록시 적용 여부, 우회 목록을 확인하세요. 둘 다 실패한다면 로컬 수신 포트나 노드 연결을 살펴보세요. 이렇게 하면 ‘앱이 클라이언트를 통과하지 않음’과 ‘통과한 뒤 전달에 실패함’을 구분할 수 있습니다.

플랫폼별 실제 설정 확인하기

Windows에서 netsh winhttp show proxy를 실행하면 WinHTTP 프록시 상태를 확인할 수 있지만 브라우저의 사용자 프록시 설정을 그대로 보여 주지는 않습니다. 직접 연결로 표시된다고 해서 클라이언트의 시스템 프록시가 꺼져 있다고 단정하지 마세요. 특정 앱 하나를 고치려고 설정 전체를 가져오지도 마세요. 특히 서비스 계정으로 실행되는 프로그램은 네트워크 스택을 확인한 뒤 해당 앱의 문서에 따라 설정해야 합니다.

macOS에서 Wi-Fi, 유선 또는 다른 네트워크 서비스로 전환한 뒤에는 클라이언트가 현재 활성 서비스의 설정을 업데이트했는지 확인하세요. 자동 프록시 설정 스크립트를 사용한다면 수동 HTTP, HTTPS, SOCKS 설정과 겹치는지도 살펴보세요. 업무용 기기는 관리 정책에 따라 화면에서 저장한 값이 다시 덮어써질 수 있습니다. 이런 경우 설정을 계속 강제로 바꾸기보다 기기 관리 담당자에게 확인하세요.

Linux 명령줄 프로그램은 http_proxy, https_proxy, no_proxy 등의 환경 변수를 읽는 경우가 많지만 지원 방식은 프로그램마다 다릅니다. 새 변수는 보통 해당 터미널에서 실행한 프로세스에만 적용되며 이미 실행 중인 앱의 설정은 바꾸지 않습니다. 임시로 테스트하려면 명령 하나에 프록시를 지정하는 편이 되돌리기 쉽습니다. 세션이나 시스템 전체 설정을 먼저 변경할 필요는 없습니다.

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

socks5h는 대상 도메인 해석을 프록시 쪽에서 처리하도록 지정하므로 로컬 DNS의 영향을 구분하는 데 적합합니다. 단, 해당 포트가 실제로 SOCKS 요청을 받아야 합니다. 로컬에서 도메인을 해석하도록 바꾸면 테스트 경로가 달라집니다. 이후 결과를 비교할 때는 명령에 사용한 프로토콜과 해석 위치를 동일하게 유지하세요. 포트 번호만 같다고 두 테스트 조건이 같다는 뜻은 아닙니다.

우회 설정과 샌드박스 제한 확인하기

시스템이나 앱의 우회 목록을 확인하세요. 대상이 로컬 네트워크, 특정 도메인, 자동 설정 스크립트의 직접 연결 조건에 해당하면 예상한 프록시 경로를 거치지 않습니다. 대상에 해당하는 항목만 정확히 조정하세요. 우회 설정을 모두 지우면 로컬 서비스와 사내 리소스에 문제가 생길 수 있습니다. 브라우저 확장 프로그램이 프록시 연결을 따로 제어할 수도 있으므로 점검하는 동안 일시 중지하고 시스템 설정 하나만 사용하세요.

일부 Windows UWP 앱에서는 로컬 루프백 접근 제한도 원인이 될 수 있습니다. 프록시 수신은 정상인데 앱이 루프백 주소에 연결하지 못하는 경우입니다. UWP 루프백 제한 해결 방법을 참고해 대상 앱만 예외로 설정하거나, 해당 환경에 적합하다면 TUN을 사용하세요. 모든 앱에 일괄적으로 권한을 열지 말고 이 플랫폼에만 해당하는 문제를 일반 데스크톱 프로그램에 적용하지 마세요.

TUN을 사용하기 전에 충돌하는 VPN을 종료하고 클라이언트에서 요구하는 서비스나 권한이 준비됐는지 확인하세요. TUN은 트래픽 처리 방식을 바꾸는 기능이지 고장 난 노드나 잘못된 구독을 고치는 기능은 아닙니다. 테스트가 끝나면 시스템 프록시도 함께 켜야 하는지 확인하고 최종 조합을 기록하세요. 기본 연결 설정은 시스템 프록시 빠른 설정을 참고하고, 대상 연결이 로그에 표시되는지로 적용 여부를 확인하세요.

클라이언트 충돌: 화면·코어·설정 데이터 분리해서 확인하기

어떤 프로세스가 종료되는지 확인하기

창이 닫히거나 트레이 아이콘이 사라지고 네트워크가 끊기는 현상이 반드시 하나의 프로세스 때문에 발생하는 것은 아닙니다. 작업 관리자나 활성 상태 보기에서 화면 프로세스가 계속 실행 중인지, mihomo 코어가 반복해서 시작되는지, 종료 직전에 오류가 표시됐는지 확인하세요. 화면이 멈춰도 프록시가 정상이라면 렌더링과 앱 데이터를 살펴보세요. 화면은 정상인데 프록시가 중단됐다면 코어 로그와 설정 로드 과정을 우선 확인하세요.

시작 직후 종료, 설정 전환 후 종료, TUN을 켠 뒤 종료, 절전 모드에서 깨어난 뒤 오류 등 발생 조건을 기록하세요. 무작위로 오래 사용한 기록보다 안정적으로 재현되는 최소 단계가 더 유용합니다. 재시작하기 전에 종료 전후 로그를 별도 파일로 복사해 두세요. 앱을 반복해서 실행하면 로그가 덮어써질 수 있고 데이터를 지우면 문제를 진단할 단서가 사라집니다.

운영체제 이벤트 기록, 여유 디스크 공간, 보안 소프트웨어의 차단 내역도 확인하세요. 디스크가 가득 찼거나 폴더에 쓸 수 없거나 코어 파일이 격리되면 시작 실패처럼 보일 수 있습니다. 모든 보안 기능을 바로 끄지 마세요. 차단된 파일과 다운로드 출처를 확인한 뒤 보안 소프트웨어 및 클라이언트 안내에 따라 조치하세요. 업무용 기기의 정책 제한은 관리자에게 확인해야 합니다.

설치 파일과 실행 환경 확인하기

설치 파일이 운영체제와 CPU 아키텍처에 맞는지 확인하세요. Windows와 macOS의 아키텍처별 빌드, Linux 패키지 형식은 파일 이름이 비슷하다고 서로 바꿔 쓸 수 없습니다. 클라이언트 다운로드 페이지에서 플랫폼에 맞는 파일을 선택하세요. 일반 사용자는 Clash Plus부터 사용할 수 있습니다. Linux 사용자는 배포판 의존성, 그래픽 환경, 패키지 관리자에 표시된 구체적인 오류도 확인하고 시스템 라이브러리를 바로 교체하지 마세요.

업데이트 후 문제가 생기면 기존 프로세스를 모두 종료해 이전 화면이 새 코어에 연결되거나 여러 인스턴스가 포트를 두고 충돌하지 않게 하세요. 포터블 폴더, 시스템 설치 경로, 자동 시작 항목에 각각 복사본이 남아 있을 수도 있습니다. 현재 프로세스가 실제로 실행되는 경로를 확인한 뒤 정리할 위치를 결정하세요. 이름이 비슷한 폴더를 바로 삭제하지 마세요. 사용 중인 설정과 백업이 들어 있을 수 있습니다.

로그에 주소 사용 중 오류가 표시되면 점유 프로세스를 먼저 확인한 뒤 포트를 바꿀지 결정하세요. Windows에서는 아래 명령을 실행하고 포트 번호를 실제 수신 포트로 바꾸면 됩니다. 출력에 표시된 프로세스 ID를 작업 관리자에서 확인하세요. 포트가 사용 중이라는 이유만으로 알 수 없는 프로세스를 강제 종료하지 마세요. 다른 클라이언트 인스턴스나 로컬 서비스가 실행 중일 수 있습니다.

netstat -ano | findstr :7890

다른 프록시 도구가 원인임을 확인했다면 정상 종료한 뒤 현재 클라이언트를 시작하세요. 포트를 바꿀 때는 시스템 프록시, 앱별 프록시 설정, 관련 스크립트도 함께 업데이트해야 합니다. 코어가 다시 시작되더라도 앱이 이전 주소로 요청을 보내면 문제가 계속됩니다. 제어 인터페이스 포트와 트래픽 프록시 포트는 용도가 다르므로 숫자가 비슷하다고 서로 바꿔 쓰지 마세요. 제어 인터페이스를 신뢰할 수 없는 네트워크에 노출하지 마세요.

설정을 최소한으로 바꿔 문제 찾기

특정 설정에서만 종료된다면 로컬 덮어쓰기와 스크립트를 끈 뒤 원본을 대상으로 설정 검사를 실행하세요. 사용자 정의 규칙이 너무 많거나, 원격 목록이 중복 로드되거나, 스크립트 오류가 계속되면 시작 시간과 메모리 사용량이 늘어날 수 있습니다. 확장 항목을 하나씩 다시 적용해 문제를 일으키는 항목을 확인하세요. 다른 대용량 설정으로 바꾸는 것만으로는 유효한 비교가 되지 않으며 코어 자체의 결함을 증명할 수도 없습니다.

앱을 초기 상태로 테스트해야 한다면 먼저 구독 정보, 덮어쓰기 규칙, 정책 그룹 선택을 내보내고 기존 데이터 폴더를 별도 위치에 백업하세요. 클라이언트 설명에 따라 원래 폴더를 잠시 옮긴 뒤 테스트를 시작하세요. 용도를 모르는 상태에서 폴더를 재귀적으로 삭제하지 마세요. 초기 상태에서 정상 작동하더라도 기존 데이터가 관련 있다는 뜻일 뿐입니다. 원인을 찾으려면 파일을 하나씩 복원하세요. 기존 설정을 영구히 버릴 필요는 없습니다.

TUN을 켰을 때만 문제가 발생하면 서비스 권한, 가상 인터페이스, 다른 VPN 드라이버를 확인하세요. 앱 전체를 바로 재설치하지 마세요. 로그 페이지를 열 때만 화면이 멈춘다면 로그 양을 줄이고 반복 요청을 중단한 뒤 다시 살펴보세요. 두 현상은 서로 다른 구성 요소와 관련됩니다. 발생 과정을 자세히 적으면 유지관리자가 화면 로그와 코어 로그 중 무엇이 필요한지 판단하기 쉽습니다.

마지막 테스트에는 완전 종료 후 다시 시작하기, 설정 불러오기, 요청 한 번 보내기, 정상 종료하기가 포함되어야 합니다. 필요하면 절전 모드 복구도 확인하세요. 클라이언트 이름, 시스템 아키텍처, 재현 동작, 개인정보를 가린 오류 내용을 기록하고 버전 정보를 임의로 만들지 마세요. 실제 버전은 ‘정보’ 페이지에서 확인할 수 있습니다. 클라이언트를 바꿔야 한다면 먼저 기존 데이터를 보존하세요. 화면 구성, 트래픽 처리 방식, 설정 호환성 차이는 클라이언트 비교에서 확인할 수 있습니다.

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

시스템 VPN 연결 상태부터 확인하기

모바일 클라이언트는 보통 시스템 VPN 인터페이스를 통해 앱 트래픽을 처리합니다. 처음 실행할 때 시스템 권한을 허용해야 합니다. 상태 아이콘이 표시된다는 것은 인터페이스가 만들어졌다는 뜻일 뿐 원격 노드에 연결됐다는 의미는 아닙니다. 클라이언트 로그를 열고 대상 앱에서 요청을 보내 코어에 연결이 들어왔는지, 예상한 정책에 매칭됐는지 확인하세요. 관련 기록이 없다면 트래픽 처리 범위와 앱 제외 설정을 우선 점검하세요.

문제 해결 중에는 VPN 서비스를 하나만 켜 두세요. 회사 VPN, 로컬 VPN 방식의 필터링 앱, 다른 프록시 앱이 시스템 인터페이스를 두고 충돌할 수 있습니다. 나중에 시작한 서비스가 먼저 실행 중이던 서비스를 중단시킬 수 있습니다. 기기가 업무용 프로필이나 관리 정책의 적용을 받는다면 개인 영역과 업무 영역도 구분하세요. 한 영역의 앱이 다른 영역에서 설정한 네트워크 경로를 사용하지 않을 수 있습니다.

Android에서는 Clash Plus를 먼저 사용해 볼 수 있으며, 필요에 따라 Clash Meta for Android, FlClash, Surfboard를 선택할 수도 있습니다. 지원하는 설정과 메뉴는 앱마다 다릅니다. iOS에서는 iOS 다운로드에서 Clash Plus를 확인하세요. 공식 사이트는 clashplus.io입니다. 데스크톱 전용 서비스 모드나 시스템 프록시 설정 절차를 휴대폰에 그대로 적용하지 마세요.

Android 백그라운드 실행과 앱별 프록시

화면이 켜져 있을 때는 정상인데 잠금 후 연결이 끊긴다면 배터리 최적화, 백그라운드 실행 제한, 제조사 자동 시작 관리 기능을 확인하세요. 필요한 경우 앱이 백그라운드에서 실행되도록 허용한 뒤 종료되는지 살펴보세요. 절전 설정은 앱 정보, 배터리 관리, 백그라운드 시작 메뉴 등에 흩어져 있고 이름도 기기마다 다를 수 있습니다. 앱 하나의 문제를 해결하려고 모든 앱을 제한 없음으로 설정하지 마세요.

‘항상 켜져 있는 VPN’이나 VPN을 통하지 않는 연결 차단을 켜면 클라이언트가 중지된 뒤에도 시스템이 네트워크를 막을 수 있습니다. 이는 보호 기능의 정상 동작일 수 있습니다. 문제를 확인할 때는 기존 설정을 기록하고 관련 제한을 잠시 꺼서 비교하세요. 해결 후 필요에 따라 다시 켜세요. 앱만 종료하고 시스템 상태를 확인하지 않으면 이 현상을 Wi-Fi 자체 문제로 오해하기 쉽습니다.

일부 앱만 프록시를 사용하도록 설정했다면 목록이 포함 목록인지 제외 목록인지 확인하세요. 목록 유형을 반대로 선택하면 대상 앱이 계속 직접 연결될 수 있습니다. 새로 설치한 앱이 자동으로 목록에 추가되는지도 클라이언트에 따라 다릅니다. 적용 범위를 바꾼 뒤 대상 앱을 완전히 종료하고 다시 실행해 기존 연결이 이전 경로를 계속 사용하지 않게 하세요. 브라우저와 앱 안에 표시되는 웹페이지는 서로 다른 프로세스일 수 있으므로 각각 확인하세요.

앱이 자체 DNS, 전용 프로토콜, 고정 IP 직접 연결을 사용할 수도 있습니다. 브라우저 하나가 정상이라고 해서 모든 앱의 트래픽이 처리된다고 볼 수는 없습니다. 먼저 로그에서 대상 요청을 찾아 연결 경로 누락, 규칙 오류, 출구 미지원 중 무엇인지 판단하세요. Android의 기본 가져오기와 활성화 방법은 Android 빠른 시작 가이드를 참고하세요. 문제가 있는 상태에서 같은 설정을 반복해서 다시 가져오지 마세요.

iOS와 네트워크 전환 후 복구하기

iOS에서는 시스템 VPN 설정이 현재 사용하는 클라이언트에 연결되어 있는지 확인하고 자동으로 연결될 수 있는 다른 VPN을 끈 뒤 현재 연결을 시작하세요. 시스템 설정과 클라이언트 상태가 일치하지 않으면 연결을 정상적으로 끊고 앱을 다시 시작하세요. 권한을 다시 요청할 때 앱 이름도 확인해야 합니다. 회사 관리 설정을 함부로 삭제하지 마세요. 조직 기기의 네트워크 제한은 먼저 관리 범위를 확인해야 합니다.

Wi-Fi에서 셀룰러 네트워크로 전환한 뒤에도 기존 연결이 이전 경로에 묶여 있을 수 있습니다. 시스템이 전환을 마칠 때까지 기다린 다음 클라이언트에서 다시 연결하고 대상 앱을 종료한 뒤 재시도하세요. 셀룰러에서만 실패한다면 클라이언트와 대상 앱의 셀룰러 데이터 권한, 통신사 네트워크 제한, 현재 노드의 전송 방식을 확인하세요. 네트워크를 바꾸면 DNS, IP 주소 체계, 라우팅도 함께 바뀌므로 노드 문제라고만 단정하지 마세요.

호텔이나 공항 Wi-Fi에서 웹 로그인이 필요하면 프록시를 중지한 상태에서 인증을 완료한 뒤 다시 연결하세요. VPN을 통해서만 통신하도록 설정되어 인증 페이지가 열리지 않는다면 해당 제한을 잠시 조정하고 변경 내용을 기록하세요. 인증이 끝난 뒤 일반 페이지를 열어 직접 연결이 복구됐는지 확인한 다음 프록시를 테스트하세요. 인증을 마치기 전에 구독이나 DNS 설정을 반복해서 바꾸면 문제 발생 계층을 구분하기 어려워집니다.

휴대폰은 인터넷에 연결되는데 핫스팟으로 연결한 기기에서는 같은 경로를 사용하지 못하더라도 반드시 오류는 아닙니다. 운영체제가 핫스팟 트래픽을 휴대폰의 VPN으로 보내지 않을 수 있고, 일부 클라이언트는 이 기능을 지원하지 않습니다. 휴대폰에서 연결이 성공했다는 이유만으로 핫스팟 기기도 프록시를 사용한다고 볼 수는 없습니다. 로컬 네트워크에서 명시적 프록시가 필요하다면 클라이언트 지원 여부, 수신 주소 범위, 접근 제어를 확인하고 신뢰할 수 있는 네트워크에서만 활성화하세요.

모바일 문제를 해결한 뒤 화면이 켜진 상태, 잠금 해제 후 복구, Wi-Fi와 셀룰러 전환을 각각 테스트하고 대상 앱이 예상한 규칙을 계속 사용하는지 확인하세요. 특정 상황에서만 실패한다면 매번 클라이언트를 재설치하지 말고 해당 상황과 시스템 제한을 기록하세요. 자주 쓰는 버튼과 로그 항목은 클라이언트 화면 빠르게 살펴보기에서 확인할 수 있습니다. 평소처럼 사용하기 전에 임시로 끈 보안 설정을 복구하고 정상 작동하는 설정을 백업해 두세요.