CLASH / TROUBLESHOOTING

Clash 문제 해결 가이드

접속, 구독, DNS, 시스템 프록시와 모바일 문제를 증상별로 확인하세요. 처음 설정한다면 Clash 시작 가이드에서 다운로드, 설정 가져오기, 연결까지 진행하세요. 이미 설정을 가져왔는데 문제가 발생했다면 이 페이지에서 원인을 찾아보세요. 시작 가이드는 연결 설정을, 이 페이지는 연결이 끊기는 지점을 설명합니다.

문제를 확인하기 전에 운영체제, 클라이언트 이름, 현재 설정, 프록시 모드와 발생 시각을 기록하세요. 처음 사용하는 경우 Clash Plus를 우선 선택할 수 있습니다. 이미 Clash Verge Rev, FlClash 등의 클라이언트를 사용 중이라면 먼저 다른 소프트웨어로 바꿀 필요는 없습니다. 화면의 메뉴 이름은 다를 수 있으므로 아래 내용은 코어 동작과 설정 항목을 기준으로 확인하세요. 설치 파일은 Clash 다운로드 페이지에서 확인할 수 있습니다.

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

프록시를 끄고 직접 연결 상태부터 확인하세요

다른 프록시, 가속기, VPN을 종료한 다음 현재 클라이언트의 시스템 프록시와 TUN을 끄세요. 평소 직접 접속하는 사이트를 열고 라우터 관리 페이지에도 접속해 보세요. 두 곳 모두 연결되지 않으면 Wi-Fi, 케이블, 게이트웨이와 네트워크 인증 페이지부터 확인하세요. 공용 Wi-Fi는 브라우저에서 먼저 인증해야 하는 경우가 많습니다. 프록시가 먼저 연결을 가로채면 인증 페이지가 열리지 않을 수 있습니다. 이때는 시스템의 IP 주소와 DNS를 자동으로 설정하고 인증을 마친 뒤 클라이언트를 실행하세요.

직접 연결 테스트는 두 단계로 확인해야 합니다. 라우터 페이지가 열린다는 사실은 기기와 로컬 네트워크 사이의 연결만 보여 줄 뿐, 인터넷 회선이 정상이라는 뜻은 아닙니다. 같은 네트워크를 쓰는 다른 기기도 외부 사이트에 접속하지 못한다면 라우터나 상위 네트워크를 먼저 점검하세요. 현재 기기만 문제가 있다면 방화벽, 남아 있는 프록시 설정과 정적 라우트를 확인하세요. 기본 네트워크가 복구되기 전에 구독을 반복해서 업데이트하면 네트워크 오류를 링크 만료로 오해할 수 있습니다.

프록시 진입점·규칙·출구를 나눠서 테스트하세요

직접 연결이 복구되면 클라이언트를 실행하고 코어가 작동하는지, 설정이 로드되었는지 확인하세요. 화면이 열려도 프록시 포트가 수신 대기 중이라는 뜻은 아닙니다. 시작 로그에서 설정 파싱 오류, 포트 충돌 또는 권한 부족을 확인하세요. 그다음 TUN은 켜지 말고 시스템 프록시만 활성화하세요. 클라이언트에 표시된 실제 혼합 포트를 확인한 뒤 아래 명령으로 프록시 진입점을 지정해 요청을 보내세요. 예시 포트는 설명용이므로 실제 설정이 다르면 명령도 함께 바꿔야 합니다.

# macOS / Linux; Windows에서는 curl.exe로 같은 방식의 명령을 실행할 수 있습니다
curl --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 \
  --head https://example.com

# 환경 변수에 지정된 프록시를 사용하지 않는 비교 테스트
curl --noproxy '*' --connect-timeout 10 --max-time 20 \
  --head https://example.com

프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면, 이번 요청에서는 코어 진입점부터 대상 사이트까지의 경로가 작동한 것입니다. 브라우저 프록시 설정, 확장 프로그램 또는 시스템 프록시 적용 여부를 확인하세요. 로컬 포트 연결에 실패했다면 수신 주소와 포트부터 점검하세요. 프록시에 연결된 뒤 시간 초과가 발생한다면 해당 연결에 적용된 규칙, 정책 그룹과 노드를 확인하세요. 테스트 사이트가 성공 상태 코드를 반환할 필요는 없습니다. 정상적인 HTTP 응답을 받았다면 요청이 서버에 도달한 것입니다.

규칙 모드에서 특정 사이트만 접속되지 않는다면 해당 정책 그룹을 정상 작동이 확인된 노드로 잠시 바꾼 뒤 연결 기록의 대상 도메인과 최종 정책을 비교하세요. 일시적으로 전역 프록시를 사용하면 규칙 차이를 확인할 수 있지만, 모든 규칙이 잘못되었다는 뜻은 아닙니다. 규칙 모드로 돌아간 뒤 실제로 일치한 항목을 찾아야 합니다. 연결에 REJECT가 적용되면 규칙 출처와 순서를 확인하고, DIRECT로 잘못 연결되면 도메인이 앞선 규칙에 매칭되었는지 점검하세요. 잘못된 규칙 하나를 감추려고 규칙 전체를 삭제하지 마세요.

네트워크 복구 후 불완전한 설정이 남지 않도록 하세요

TUN을 켰을 때 모든 연결이 끊기지만 시스템 프록시만 사용할 때는 정상이라면 노드 비밀번호를 다시 입력하기보다 가상 네트워크 어댑터, 라우트와 DNS 처리부터 확인하세요. 관리자 권한 부족, 다른 VPN의 기본 라우트, 동일한 서브넷 충돌 때문에 트래픽이 가상 인터페이스로 들어간 뒤 정상적으로 돌아오지 않을 수 있습니다. 먼저 TUN을 끄고 라우트가 복구되는지 확인한 다음 클라이언트 안내에 따라 서비스 모드를 점검하세요. 가상 네트워크 드라이버를 여러 개 연속 설치하지 마세요. 네트워크를 제어하는 클라이언트 하나만 유지해야 문제를 재현하기 쉽습니다.

클라이언트를 종료한 뒤에도 인터넷이 되지 않는다면 시스템 프록시가 이전 로컬 포트를 가리키는지, 수동 DNS 설정이 남아 있는지 확인하세요. 설정을 정리하기 전에 기존 값을 기록하고 회사 네트워크에서 요구하는 정적 설정은 변경하지 마세요. 복구한 뒤 새 연결을 열어 테스트하세요. 기존 브라우저 연결은 이전 세션을 계속 사용할 수 있습니다. 마지막으로 직접 연결, 프록시 진입점, 규칙 또는 출구 중 어느 부분에 문제가 있었는지 결론을 내리세요. 단순히 “아무것도 열리지 않는다”고 설명하는 것보다 원인을 구분해 두면 다음 점검이 수월합니다.

노드 시간 초과: 테스트 대상과 실패 단계 확인하기

지연 시간 테스트 실패와 실제 접속 실패를 구분하세요

클라이언트에 timeout이 표시되면 지정된 테스트 주소의 요청이 제한 시간 안에 끝나지 않았다는 뜻일 수 있습니다. 모든 상황에서 노드를 사용할 수 없다는 의미는 아닙니다. 노드를 선택하고 브라우저나 프록시를 명시한 명령으로 접속 가능한 HTTPS 사이트를 요청한 뒤 지연 시간 테스트 결과와 비교하세요. 실제 접속은 정상이라면 테스트 주소, 제한 시간 설정과 사이트의 자동 요청 차단 여부를 확인하세요. 테스트 주소 하나의 결과만 보고 구독 전체를 삭제하지 마세요.

모든 노드에서 동시에 시간 초과가 발생한다면 같은 네트워크, 같은 클라이언트 또는 같은 시점에 문제가 생겼는지 비교하세요. 기기 시간이 크게 틀리면 TLS 인증서 확인에 영향을 줄 수 있으므로 자동 시간 설정과 시간대를 확인하세요. 이어서 기기에서 노드 서버 도메인을 해석할 수 있는지 점검하세요. 일반 웹사이트의 DNS가 정상이어도 서버 도메인의 DNS는 실패할 수 있습니다. 두 요청의 DNS 경로가 다를 수 있기 때문입니다. 로그에 서버 도메인 해석 오류가 있다면 노드 경로를 점검하기 전에 DNS부터 복구하세요.

DNS 조회부터 포트와 프로토콜까지 단계별 확인

서버 도메인이 해석되면 해당 서버 포트의 TCP 연결도 테스트하세요. 아래는 문서용 도메인과 포트를 사용한 예시입니다. 실제로 점검할 때는 구독에 있는 서버 주소와 포트로 바꾸고 자신의 기기에서만 실행하세요. TCP 테스트 성공은 해당 포트까지 연결할 수 있다는 뜻일 뿐 인증, 암호화 설정이나 UDP 경로를 확인하지는 않습니다. UDP에 주로 의존하는 프로토콜은 TCP 연결 실패만으로 노드가 작동하지 않는다고 판단할 수 없습니다.

# Windows PowerShell: TCP 연결만 테스트
Test-NetConnection -ComputerName example.com -Port 443

# macOS / Linux: nc가 설치되어 있으면 사용할 수 있습니다
nc -vz -w 5 example.com 443

로그에 연결 거부가 표시되면 대상 포트에서 연결을 받지 않거나 중간 장비가 연결을 거부했을 가능성이 큽니다. 연결을 기다리다가 시간 초과되면 경로에서 패킷이 차단되거나 원격 서버에 도달하지 못했거나 응답 트래픽이 막혔을 수 있습니다. 두 경우의 해결 방법은 다릅니다. 거부되면 서버 포트와 원격 서버의 수신 상태를 확인하세요. 시간 초과가 발생하면 다른 네트워크에서도 비교해 보세요. 회사, 학교와 공용 Wi-Fi는 일부 포트나 프로토콜을 제한할 수 있으므로 해당 환경에서의 결과만으로 설정이 손상되었다고 판단하지 마세요.

전송 계층 연결은 되지만 핸드셰이크에 실패한다면 노드 유형, 비밀번호나 식별자, 전송 방식, TLS 설정, 서버 이름과 경로를 하나씩 확인하세요. 일부 프로토콜은 공개 키, 지문 또는 추가 전송 매개변수도 필요합니다. 필수 필드가 빠지면 클라이언트가 무시하거나 파싱 오류를 낼 수 있습니다. 다른 코어용 필드를 이름만 보고 조합하기보다 서비스에서 제공한 호환 설정을 다시 가져오세요. 인증서 검증을 꺼서 핸드셰이크 오류를 장기간 우회하지 말고 도메인과 인증서가 일치하는지 확인하세요.

비교 테스트로 문제 범위를 좁히세요

특정 노드만 실패하고 다른 노드는 정상이라면 해당 노드 설정과 원격 서버 상태부터 확인하세요. 한 기기에서 모든 노드가 실패하지만 다른 기기는 정상이라면 코어 호환성, 보안 소프트웨어와 로컬 네트워크 처리 방식을 비교하세요. 네트워크를 바꿀 때는 노드와 설정을 유지하고, 노드를 바꿀 때는 네트워크를 유지하세요. 네트워크, 소프트웨어와 구독을 한꺼번에 바꾸면 문제가 해결되어도 원인을 알 수 없어 다시 발생할 가능성이 큽니다.

노드 선택이 실제 연결에 적용되었는지도 확인하세요. 정책 그룹이 다른 그룹을 포함하거나 자동 선택 그룹이 다른 노드를 다시 선택할 수 있습니다. 일부 연결은 이미 만들어진 세션을 재사용하기도 합니다. 연결 세부 정보에서 전체 정책 경로를 확인하고 필요한 경우 대상 앱의 기존 연결만 종료한 뒤 다시 요청하세요. 일반적인 속도 테스트를 위해 모든 연결을 반복해서 종료하지 마세요. 다운로드와 통화가 중단될 수 있고 동시에 다시 연결되면 측정 결과도 달라집니다.

서비스 제공자에게 문의할 때는 발생 시각, 네트워크 유형, 프로토콜, 실패 단계와 민감 정보를 가린 오류 내용을 전달하세요. 전체 구독 링크는 보내지 마세요. 점검 순서를 자세히 확인하려면 모든 노드에 timeout이 표시될 때의 점검 절차를 참고하세요. 복구 후 정상 접속 로그 일부를 보관하고 테스트용 주소와 로그 수준은 원래대로 되돌려 다음 점검에 임시 설정이 영향을 주지 않게 하세요.

구독 오류: 가져오기·파싱·적용 단계별 확인

먼저 링크가 어떤 내용을 반환하는지 확인하세요

구독 오류는 최소 세 단계로 나눠야 합니다. 클라이언트가 내용을 다운로드하는지, 다운로드한 내용을 파싱할 수 있는지, 파싱한 설정을 활성화할 수 있는지 확인하세요. 먼저 오류 메시지 원문을 읽으세요. 연결 시간 초과와 도메인 해석 오류는 다운로드 문제입니다. 줄 번호, 들여쓰기 또는 필드 유형 오류는 파싱 문제입니다. 가져오기는 성공했지만 노드가 보이지 않는다면 새 설정이 선택되었는지, 정책 그룹이 노드를 참조하는지 확인해야 합니다. 모든 문제를 클라이언트 재설치로 해결하려 하지 마세요.

서비스 페이지에서 구독 주소를 다시 복사하고 줄바꿈, 앞뒤 공백이나 메신저가 덧붙인 문장부호가 없는지 확인하세요. 링크에는 계정 인증 정보가 들어 있는 경우가 많으므로 공개 변환 사이트, 스크린샷이나 온라인 디버깅 도구에 붙여넣지 마세요. 브라우저에서 로그인 페이지, CAPTCHA 또는 서비스 안내 페이지가 열린다면 설정이 아니라 HTML을 받은 것일 수 있습니다. 서버가 성공 상태 코드를 반환해도 내용 형식이 잘못되었을 수 있으므로 상태 코드만 확인해서는 안 됩니다.

인증되지 않음 또는 접근 금지가 반환되면 구독이 초기화되었는지, 계정 권한이 변경되었는지, 요청 빈도 제한에 걸렸는지 확인하세요. 리소스를 찾을 수 없다면 주소가 완전한지 확인하고, 서버 오류는 발생 시각을 기록한 뒤 잠시 후 다시 시도하세요. 재시도 사이에는 간격을 두고 업데이트 버튼을 연속으로 누르지 마세요. 직접 연결로는 가져오지 못하지만 기존 프록시로는 접속할 수 있다면 클라이언트에서 지원하는 경우 업데이트에 사용할 출구를 지정하세요. 기존 설정이 이미 만료되었다면 복구 경로를 만들 수 있도록 먼저 사용할 수 있는 로컬 설정을 확보해야 합니다.

전체 설정과 노드 제공기 구분하기

전체 Clash 설정에는 노드, 정책 그룹, 규칙과 DNS가 포함될 수 있습니다. 노드 제공기 파일은 보통 노드 목록만 제공하며 주 설정의 provider 항목에서 참조합니다. 두 파일의 용도는 다릅니다. 제공기 주소를 전체 설정으로 가져오면 화면이 비거나 정책 그룹이 없을 수 있고, 전체 설정을 노드 목록 전용 메뉴에 넣으면 형식 오류가 발생할 수 있습니다. 먼저 서비스가 제공한 링크의 유형을 확인한 뒤 클라이언트의 설정 가져오기 또는 제공기 메뉴를 선택하세요.

# 전체 설정 구조 예시; proxies가 비어 있으면 원격 프록시 노드가 생성되지 않습니다
mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,수동 선택

위 예시는 설정 구조를 확인하기 위한 것으로 기본 연결은 직접 연결이며 사용할 수 있는 프록시 서버는 포함되어 있지 않습니다. 실제 노드는 본인이 사용하는 서비스의 설정에서 가져와야 합니다. YAML은 공백으로 들여쓰고 같은 단계의 필드는 정렬하며 목록 항목은 올바른 상위 필드 아래에 두세요. 오류 줄뿐 아니라 앞 줄에 콜론이나 따옴표가 빠졌는지도 확인하세요. 영문 콜론을 전각 콜론으로 바꾸거나 웹페이지 코드 블록의 구분 기호까지 파일에 복사하지 마세요.

요청 헤더가 반환되는 설정 형식에 영향을 줄 수도 있습니다. 일부 구독 서비스는 User-Agent에 따라 서로 다른 설정을 생성하므로 브라우저에서 다운로드된다고 클라이언트에도 같은 내용이 제공되는 것은 아닙니다. 서비스 문서에서 명시적으로 요구할 때만 지원되는 클라이언트 식별자를 요청 헤더에 설정하세요. 다른 소프트웨어로 임의로 위장하면 서버가 호환되지 않는 필드를 반환할 수 있습니다. 지원하지 않는 프로토콜이나 알 수 없는 필드가 나타나면 오류 필드를 모두 삭제하기보다 현재 클라이언트의 코어와 구독이 해당 코어용으로 출력되었는지 확인하세요.

새 설정이 실제 실행 상태인지 확인하세요

가져오기가 완료되면 설정 목록의 업데이트 시각과 선택 상태를 확인한 다음 프록시 그룹에 노드가 표시되는지 살펴보세요. 제공기는 별도로 업데이트해야 할 수도 있습니다. 주 설정의 업데이트 시각이 바뀌어도 하위 리소스가 갱신되었다는 뜻은 아닙니다. 그룹의 필터 표현식이 특정 이름만 남기도록 설정되어 있으면 노드 목록이 비어 보일 수 있습니다. 이 경우 필터 조건, 제공기 로드 오류와 이름 변경을 확인하고 서비스가 노드를 보내지 않았다고 단정하지 마세요.

로컬 덮어쓰기, 스크립트와 병합 설정이 가져온 뒤 규칙이나 노드를 다시 변경할 수 있습니다. 문제를 점검할 때 먼저 백업하고 해당 처리를 잠시 끈 다음 원본 설정과 최종 실행 설정을 비교하세요. 클라이언트가 자동 생성한 실행 파일을 직접 편집하지 마세요. 다음에 설정을 불러오면 변경 사항이 덮어써질 수 있습니다. 계속 유지해야 할 변경은 클라이언트가 지원하는 명시적인 덮어쓰기 메뉴에 넣고 변경 범위를 최소화하세요.

구독이 복구되면 한 번 수동으로 업데이트하고 새 설정을 활성화한 뒤 새 연결을 만들어 확인하세요. 노드 수만 보지 말고 규칙, DNS와 정책 그룹이 예상대로 작동하는지도 점검하세요. 형식과 요청 헤더를 자세히 확인하려면 구독 업데이트 오류 및 YAML 자체 점검 목록을 참고하세요. 서비스에서 링크를 초기화했다면 만료된 주소도 정리해 다른 기기에서 오래된 인증 정보로 계속 요청하지 않도록 하세요.

속도 저하: 첫 응답·전송 속도·앱별 차이 확인

어느 단계에서 느린지 먼저 구분하세요

웹페이지가 표시되기까지 오래 걸리는 경우, 다운로드가 시작된 뒤 속도가 느린 경우, 동영상이 간헐적으로 멈추는 경우는 서로 다른 증상입니다. 첫 번째는 DNS, 연결 설정 또는 TLS 핸드셰이크와 관련될 수 있습니다. 지속적인 전송 속도 저하는 네트워크 혼잡, 원격 서버의 속도 제한이나 기기 성능 문제일 수 있고, 간헐적인 끊김은 패킷 손실, 무선 간섭과 앱 캐시를 살펴봐야 합니다. 대상 하나, 노드 하나와 네트워크 하나를 고정하고 대기 시간과 전송 중 상태를 기록하세요. 여러 사이트의 결과를 한데 섞어 비교하지 마세요.

클라이언트의 지연 시간 테스트는 대역폭 측정이 아닙니다. 테스트 사이트에서 빠르게 응답하는 노드라도 동영상 서비스나 파일 서버까지의 경로가 더 좋다는 보장은 없습니다. 속도 측정 사이트가 매번 다른 지역의 서버를 선택할 수도 있어 결과를 비교할 수 없을 수 있습니다. 실제 사용 사례로 비교하세요. 같은 파일을 같은 시간대에 같은 기기에서 직접 연결과 프록시 연결로 각각 받아 프록시 경로에서만 느려지는지 기록하세요. 대용량 다운로드와 여러 노드의 속도 측정을 동시에 실행하면 테스트 트래픽이 확인 중인 대역폭을 차지합니다.

연결 단계와 정책 기록을 확인하세요

아래 명령은 DNS 조회, 연결, TLS와 첫 바이트까지 걸린 누적 시간을 출력합니다. HTTP 프록시를 거치면 일부 값은 프록시 진입점까지의 시간을 나타내므로 원격 노드 자체의 처리 시간으로 해석할 수 없습니다. 이 값은 같은 조건에서 변경 전후를 비교할 때 유용하며 특정 경로의 실제 지연 시간을 단독으로 계산하는 데 적합하지 않습니다. 먼저 요청이 성공했는지 확인한 뒤 시간을 비교하세요. 오류 페이지나 캐시 응답은 실제보다 짧게 측정될 수 있습니다.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  --output /dev/null --silent --show-error \
  --write-out 'DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} FIRST:%{time_starttransfer} TOTAL:%{time_total}\n' \
  https://example.com

Windows에서 curl.exe를 사용한다면 출력 대상을 NUL로 바꾸고 명령을 한 줄로 실행할 수 있습니다. 첫 바이트를 받기까지 오래 걸리지만 전송이 시작된 뒤에는 정상이라면 DNS, 핸드셰이크, 대상 서버 응답과 노드에서 대상까지의 경로를 확인하세요. 시작은 빠르지만 이후 전송 속도가 크게 떨어진다면 다른 노드, 다른 파일 출처와 기기의 무선 품질을 비교하세요. 한 번의 짧은 요청으로 장시간 다운로드 성능을 판단하지 마세요. 두 상황의 혼잡과 속도 제한 조건은 다를 수 있습니다.

연결 패널을 열어 대상 요청이 예상한 노드를 실제로 통과하는지 확인하세요. 웹페이지의 주 도메인과 이미지, 동영상, 다운로드 도메인은 서로 다른 규칙에 매칭될 수 있습니다. “페이지는 빠른데 동영상은 느린” 경우라면 도메인별로 확인하세요. 자동 정책 그룹이 테스트 중 출구를 바꿀 수 있으므로 비교할 때는 노드를 임시로 고정하고 끝난 뒤 원래 정책으로 돌리세요. 일부 서비스는 다른 지역의 세션을 제한하므로 노드를 자주 바꾸면 추가 인증이 발생해 접속이 더 불편해질 수 있습니다.

기기·프로토콜·네트워크 경계를 확인하세요

먼저 CPU, 메모리와 디스크 사용량을 확인하세요. 상세 로그가 너무 많거나 연결 수가 지나치게 많을 때, 실시간 검사 또는 다른 다운로드가 실행 중일 때는 기기 자체가 병목이 될 수 있습니다. 노트북의 절전 모드와 모바일 기기의 과열에 따른 성능 저하도 암호화 처리에 영향을 줍니다. 테스트 중에는 관계없는 고부하 작업을 종료하고 로그 수준을 평소대로 낮춘 뒤 같은 요청을 확인하세요. 속도 측정을 위해 방화벽을 장시간 끄지 말고 명확한 차단 기록을 근거로 필요한 규칙만 추가하세요.

실시간 통화, 게임 또는 일부 동영상에서만 문제가 발생한다면 UDP 지원과 트래픽 처리 방식을 확인하세요. 브라우저는 QUIC을 사용할 수 있지만 시스템 HTTP 프록시가 해당 경로를 처리하지 않을 수 있습니다. 통제된 테스트에서 앱이 TCP를 사용하도록 바꿔 문제가 해결되는지 확인한 뒤 TUN이나 관련 규칙을 조정할지 결정하세요. 프로토콜 변경은 원인을 찾기 위한 테스트일 뿐 모든 기기에 적용할 고정 최적화가 아닙니다. MTU는 큰 패킷 전송만 멈추고 작은 요청은 정상이라는 등의 증거가 있을 때 확인하세요. 먼저 인터페이스의 기존 값을 기록하고 제한된 범위에서 비교하세요.

로컬 네트워크의 Wi-Fi 신호가 강하다고 간섭이 적은 것은 아닙니다. 라우터에 가까이 가거나 유선 연결을 사용하거나 다른 네트워크로 바꾸면 무선과 프록시 중 어느 쪽이 병목인지 구분하는 데 도움이 됩니다. 여러 기기와 클라이언트에서 같은 노드로 같은 리소스에 접속해도 느리다면 원격 서버나 중간 네트워크의 문제일 가능성이 더 큽니다. 이 경우 서비스 제공자에게 대상 유형, 시간대와 비교 결과를 전달하세요. 기기 최적화 설정만 계속 추가하지 마세요. 복구 후에는 임시 속도 제한, 노드 고정과 프로토콜 테스트 설정을 되돌려 설정 상태를 명확하게 유지하세요.

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

도메인이 어느 단계에서 조회되는지 확인하세요

일부 연결은 유지되지만 도메인을 열 수 없다면 DNS 문제일 수 있지만 단정해서는 안 됩니다. 먼저 로그의 DNS 오류를 기록한 다음 시스템에서 사용하는 DNS 주소, 클라이언트 DNS 활성화 여부와 앱 자체의 암호화 DNS 사용 여부를 확인하세요. 운영체제, 브라우저, 프록시 코어와 라우터는 각각 캐시와 조회 경로를 사용할 수 있습니다. 한 계층만 바꿔 놓고 다른 계층을 테스트하면 결과가 서로 맞지 않을 수 있으므로 각 테스트에서 누가 DNS 조회를 처리했는지 기록하세요.

프록시 요청은 프록시 서버에서 대상 도메인을 조회할 수도 있습니다. 따라서 로컬 DNS 조회는 실패하지만 프록시 접속은 성공하는 상황이 함께 발생할 수 있습니다. 노드 서버 도메인의 조회는 별개의 문제입니다. 노드에 연결하기 전에 DNS가 필요한데 선택한 DNS 서버에 접속하려면 그 노드를 먼저 거쳐야 한다면 시작 단계에서 의존성이 생깁니다. 먼저 DNS 서버의 도메인을 조회할 수 있는 별도의 경로를 확보한 다음 일반 도메인을 확인하세요. 아직 연결되지 않은 프록시로 모든 DNS 요청을 무리하게 보내지 마세요.

포트를 지정해 코어 DNS를 테스트하세요

아래는 mihomo DNS 필드 설정 예시입니다. 수신 주소는 로컬 기기로 제한하고 테스트용 별도 포트를 사용합니다. 공용 DNS 서버는 설정 예시일 뿐 현재 네트워크에서 접속 가능하다는 보장이나 개인정보 보호 또는 경로 추천을 의미하지 않습니다. 기존 설정에 추가하기 전에 최상위 dns 필드가 중복되지 않는지, 클라이언트가 해당 필드를 덮어쓰는지 확인하세요. 수신 기능만 켜서는 시스템이 자동으로 이를 사용하지 않습니다. 클라이언트가 DNS를 처리하도록 설정하거나 명시적으로 조회해야 합니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query
# macOS / Linux: dig 설치 후 지정한 DNS 주소로 테스트
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

Fake-IP 모드가 예약된 주소 범위의 매핑 주소를 반환하는 것은 정상이며 웹사이트 서버가 실제로 그 주소에 있다는 뜻은 아닙니다. 코어는 매핑을 통해 도메인을 복원한 다음 규칙과 전달 경로를 적용합니다. 앱이 매핑 주소를 받은 뒤 코어를 우회해 직접 연결하면 실패할 수 있습니다. 따라서 DNS 결과가 공인 IP처럼 보이는지만 보고 Fake-IP가 정상인지 판단하지 마세요. 이후 연결이 같은 코어에 의해 처리되는지, 매핑 테이블이 유지되는지도 확인해야 합니다.

강화 모드 전환, 코어 재시작 또는 설정 변경 뒤에도 운영체제와 앱에 이전 매핑이 남아 있을 수 있습니다. 먼저 대상 앱을 종료하고 관련 캐시를 비운 다음 새 요청을 만드세요. Windows에서는 ipconfig /flushdns로 시스템 캐시를 비울 수 있지만 브라우저, 앱과 라우터에도 별도 캐시가 있을 수 있습니다. 다른 플랫폼에서는 해당 시스템의 방법을 따르고 한 플랫폼의 명령을 모든 기기에 그대로 적용하지 마세요. 캐시를 비우기 전에 DNS 경로부터 고치지 않으면 같은 오류가 반복될 뿐입니다.

로컬 도메인·IPv6·라우트 충돌 확인

프린터, 회사 내부망과 가정용 스토리지의 도메인은 대개 로컬 DNS나 특정 검색 도메인에 의존합니다. 모든 도메인을 공용 DNS로 보내면 해당 서비스가 작동하지 않을 수 있습니다. 로컬 DNS가 필요한 도메인에는 조회 정책을 설정하고 필요하면 Fake-IP 필터를 추가해 실제 주소를 반환하도록 하세요. 확인된 문제 도메인만 필터에 넣으세요. 지나치게 넓은 와일드카드는 많은 정상 요청의 처리 방식을 바꾸고 오류 재현을 어렵게 할 수 있습니다.

IPv4와 IPv6도 함께 확인하세요. 도메인이 AAAA 레코드를 반환하지만 기기의 IPv6 경로를 사용할 수 없다면 앱이 먼저 연결을 기다리다가 실패하고 나중에 다른 경로로 전환해 첫 접속이 느려질 수 있습니다. 비교를 위해 특정 계층의 IPv6 처리를 잠시 끌 수 있지만 시스템 인터페이스, 코어의 DNS 조회와 노드 출구 중 어느 부분의 문제인지 구분하세요. 마지막에는 경로를 수정하거나 명시적인 정책을 사용해야 합니다. 모든 계층을 한꺼번에 끄면 원인을 판단할 수 없습니다. 기업 네트워크의 라우트가 Fake-IP 주소 범위와 충돌할 수도 있으므로 주소 범위를 바꾸기 전에 기존 서브넷을 확인하세요.

브라우저의 보안 DNS와 시스템 DNS 처리가 동시에 적용될 수 있습니다. 브라우저만 문제가 있다면 보안 DNS 설정을 비교하고, 내부망만 문제가 있다면 분할 DNS와 로컬 라우트를 확인하세요. 복구 여부는 새 조회가 응답하는지, 새 연결에 예상한 정책이 적용되는지, 내부망 서비스가 계속 작동하는지로 판단하세요. DNS가 응답을 반환해도 답이 올바르거나 연결 경로가 안전하다는 뜻은 아닙니다. 설정 항목의 의미는 용어 빠른 확인에서 DNS와 네트워크 스택 관련 용어를 살펴보세요.

시스템 프록시가 작동하지 않을 때: 앱이 프록시로 들어오는지 확인

시스템 프록시·환경 변수·TUN의 적용 범위는 서로 다릅니다

시스템 프록시는 일반적으로 운영체제 설정을 따르는 앱에 HTTP 프록시 진입점을 제공할 뿐 기기의 모든 트래픽을 처리하지는 않습니다. 명령줄 도구, 게임, 서비스 프로세스와 자체 네트워크 스택을 사용하는 앱은 이 설정을 무시할 수 있습니다. TUN은 가상 인터페이스와 라우트를 통해 트래픽을 처리하지만 권한, 제외 규칙과 다른 네트워크 소프트웨어의 영향을 받습니다. 먼저 대상 앱이 어떤 진입점을 사용하는지 확인한 뒤 방법을 선택하세요. 시스템 프록시 스위치만으로 기기 전체가 프록시를 사용한다고 판단하지 마세요.

프록시를 명시한 명령으로 요청하는 것이 가장 간단한 구분 테스트입니다. 명시적 요청은 성공하지만 대상 앱이 클라이언트 연결 기록에 전혀 나타나지 않는다면 노드를 바꾸기보다 앱의 프록시 진입 방식을 확인하세요. 요청 기록은 있지만 DIRECT로 연결된다면 규칙이나 정책 문제입니다. 예상한 노드를 거친 뒤 실패한다면 출구를 점검하세요. 연결 기록을 확인할 때는 요청을 새로 보내세요. 이미 연결된 장시간 세션은 시스템 설정을 바꿔도 즉시 전환되지 않을 수 있습니다.

수신 대기·환경 변수·플랫폼 설정 확인

로컬 프록시는 보통 루프백 주소에서 수신 대기합니다. 클라이언트와 앱이 같은 운영체제 환경에 있다면 127.0.0.1을 사용할 수 있습니다. 컨테이너, 가상 머신과 일부 서브시스템의 루프백 주소는 해당 환경 자체를 가리키며 호스트 기기를 가리키지 않을 수 있습니다. 실제 네트워크 모드에 따라 호스트 주소와 접근 권한을 확인하세요. 로컬 환경의 명령을 그대로 복사하지 마세요. LAN에서 접근해야 한다면 수신 범위, 방화벽과 인증을 함께 설정하세요. 컨테이너를 테스트한다는 이유로 프록시 포트를 전체 네트워크에 노출하지 마세요.

진입 방식주요 적용 대상중점 확인 사항
시스템 프록시시스템 설정을 따르는 앱프록시 주소, 예외 목록, 브라우저 확장 프로그램
환경 변수해당 환경 변수를 지원하는 명령줄 프로그램현재 프로세스 환경, 변수 우선순위
TUN가상 인터페이스로 들어오는 트래픽권한, 라우트, 제외 항목과 DNS
앱 내부 프록시해당 앱 자체프로토콜 유형, 포트와 원격 DNS 조회 방식

명령줄 도구는 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 읽을 수 있으며 소문자 변수만 사용하는 경우도 있습니다. 실제 동작은 해당 도구의 문서를 확인하세요. 변수를 변경해도 이미 실행 중인 프로세스에 새 환경이 자동으로 반영되지는 않습니다. 현재 터미널에서 임시로 설정해 테스트하고 전역 시작 파일에는 바로 기록하지 마세요. NO_PROXY도 확인하세요. 예외 범위가 너무 넓으면 대상 요청이 프록시를 우회할 수 있습니다. 설정이 남는 문제를 피하기 위해 아래 예시는 한 번의 명령에만 적용되는 방식을 사용합니다.

# macOS / Linux: 이번 요청에만 환경 변수 적용
HTTP_PROXY=http://127.0.0.1:7890 \
HTTPS_PROXY=http://127.0.0.1:7890 \
curl --head --max-time 20 https://example.com

# Windows: 현재 사용자 설정과 WinHTTP 설정 확인; 두 설정은 서로 다른 진입점입니다
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
netsh winhttp show proxy

Windows의 사용자 프록시와 WinHTTP 서비스 프록시는 서로 다른 설정이며 확인 명령의 결과도 서로 대신할 수 없습니다. 서비스 프로그램이 프록시를 사용하지 않는다고 전역 설정을 바로 가져오지 마세요. 먼저 서비스 실행 계정과 프록시 지원 방식을 확인해야 합니다. macOS 프록시는 네트워크 서비스마다 별도로 설정되므로 Wi-Fi와 유선 네트워크를 바꾸면 다른 설정이 적용될 수 있습니다. Linux 데스크톱 환경의 프록시 설정도 백그라운드 서비스에 전달된다고 보장할 수 없습니다. 네트워크를 바꿀 때마다 대상 앱의 실제 진입점을 다시 확인하세요.

UWP·확장 프로그램·비정상 종료 후 남은 설정 확인

일부 Windows 샌드박스 앱은 로컬 루프백에 접근할 수 없습니다. 코어 진입점이 작동하고 일반 데스크톱 앱은 정상이지만 특정 앱만 루프백 포트에 연결할 수 없을 때 UWP 루프백 예외를 고려하세요. 클라이언트에서 제공하는 관리 메뉴를 우선 사용하고 모든 앱이 아니라 필요한 앱만 선택하세요. 예외 설정은 로컬 네트워크 접근 권한만 변경하며 노드 인증, 구독이나 원격 연결 오류를 해결하지 않습니다. 더 이상 필요하지 않으면 해당 앱의 예외를 삭제하세요.

브라우저 프록시 확장 프로그램, 자동 설정 스크립트와 시스템 수동 프록시가 서로 덮어쓸 수 있습니다. 문제를 확인할 때는 확장 프로그램을 잠시 끄고 한 가지 설정만 남긴 뒤 예외 목록에 대상 도메인이 있는지 확인하세요. 클라이언트가 비정상 종료된 뒤에도 시스템이 종료된 로컬 포트를 가리키면 브라우저 전체가 접속되지 않을 수 있습니다. 시스템 설정을 복구한 다음 클라이언트를 재시작하고 프록시 스위치와 실제 주소가 일치하는지 확인하세요. 종료할 때마다 설정이 남는다면 잘못된 프록시를 계속 유지하고 매번 실행으로 우회하지 말고 종료 로그를 수집하세요.

클라이언트 충돌: UI·코어·서비스 오류 구분

먼저 어떤 프로세스가 중단되었는지 확인하세요

창이 사라지는 문제, 빈 화면, 코어 종료와 서비스 시작 실패는 해결 방법이 서로 다릅니다. 창은 열리지 않지만 프록시가 계속 작동한다면 UI 계층의 문제일 수 있습니다. UI는 정상인데 프록시 포트가 수신 대기하지 않는다면 코어 로그를 확인하세요. TUN만 시작되지 않는다면 서비스 권한이나 가상 인터페이스를 살펴봐야 합니다. 작업 관리자나 시스템 활동 모니터에서 프로세스 상태를 확인하고 마지막 오류를 기록하세요. 창에 문제가 있다고 설정을 전부 삭제하지 마세요. 문제를 재현하는 데 가장 중요한 조건을 잃게 됩니다.

문제가 발생하기 직전에 한 동작을 기록하세요. 시작하자마자 종료되는지, 특정 설정을 불러온 뒤 종료되는지, TUN을 켠 뒤 종료되는지, 오래 실행한 뒤 종료되는지 확인합니다. 시작 직후 실패하면 파일 권한, 아키텍처와 실행 종속성을 확인하세요. 특정 설정이 원인이라면 파싱 오류와 사용자 지정 처리 과정을 점검하고, 장시간 실행 후 종료된다면 메모리, 연결 수와 로그 증가량을 살펴보세요. 시스템 이벤트 뷰어 또는 충돌 보고서가 클라이언트 로그를 보완할 수 있지만 공유 전에 사용자 이름, 경로와 접속 정보를 삭제하세요.

설정 검사와 최소 구성 실행으로 원인 찾기

mihomo를 독립 실행할 수 있는 환경이라면 코어의 설정 검사 기능으로 파일을 파싱할 수 있는지 먼저 확인하세요. 명령에서 실제 설정 파일을 지정해야 합니다. 설정이 외부 규칙이나 노드 제공기를 참조한다면 해당 리소스 경로도 있어야 합니다. 검사가 통과해도 모든 원격 노드에 연결할 수 있다는 뜻은 아니며 GUI에서 덮어쓴 최종 설정도 동일하다는 보장은 없습니다. 클라이언트에서 실행 설정을 확인할 수 있다면 구독 원본만 검사하지 말고 실행 중인 설정을 우선 확인하세요.

# macOS / Linux: 코어가 있는 디렉터리에서 실행
./mihomo -t -f ./config.yaml

# Windows PowerShell: 코어가 있는 디렉터리에서 실행
.\mihomo.exe -t -f .\config.yaml

설정 검사에서 포트 충돌이 보고되면 누가 수신 대기 중인지 확인한 뒤 기존 프로세스를 종료할지 포트를 바꿀지 결정하세요. 이름이 비슷한 프로세스를 모두 종료하지 마세요. 시스템 서비스나 다른 앱에서 사용 중일 수 있습니다. mixed-port를 변경했다면 시스템 프록시, 앱 내부 프록시와 명령줄 환경 변수도 함께 업데이트해야 합니다. 컨트롤 인터페이스 포트와 프록시 포트의 용도는 다릅니다. 브라우저를 컨트롤 인터페이스에 연결해도 정상적인 프록시 연결은 만들어지지 않습니다.

최소 구성으로 실행할 때도 원래 상태로 되돌릴 방법을 남겨 두세요. 설정 디렉터리 전체를 복사한 뒤 스크립트, 덮어쓰기, 사용자 지정 규칙과 추가 제공기를 잠시 끄고 한 번에 하나씩 다시 적용하세요. 최소 설정이 정상 작동하면 기존 항목을 차례로 추가해 오류를 재현합니다. 백업 없이 앱 데이터를 삭제하지 마세요. 구독, 정책 선택과 로컬 규칙이 함께 저장되어 있을 수 있습니다. 디렉터리 위치는 클라이언트 설정이나 로그를 기준으로 확인하세요. 플랫폼과 설치 방식에 따라 경로가 다릅니다.

시스템 환경을 확인하고 복구 가능한 상태를 유지하세요

설치 파일은 CPU 아키텍처와 운영체제 유형에 맞아야 하며 Linux에서는 배포판별 패키지 형식도 확인해야 합니다. 보안 소프트웨어가 실행을 차단하면 파일 출처와 명확한 차단 기록부터 확인하세요. 실행을 위해 보안 기능 전체를 끄지 마세요. 디렉터리에 쓸 권한이 없거나 디스크 공간이 부족한 경우, 사용자 설정 디렉터리를 동기화 도구가 잠근 경우에도 저장이나 실행이 실패할 수 있습니다. 일반 사용자 계정으로 쓸 수 있는 별도 디렉터리에서 비교 테스트를 할 수 있지만 모든 프로그램을 관리자 권한으로 계속 실행하지 마세요.

빈 화면은 WebView나 그래픽 드라이버 문제일 수도 있습니다. 이는 해당 구성 요소에 의존하는 클라이언트에만 적용되며 모든 Clash 클라이언트가 같은 방식으로 작동하지는 않습니다. 먼저 시스템 구성 요소가 정상인지 확인한 뒤 해당 클라이언트의 문서를 따르세요. 코어 로그는 계속 출력되지만 창이 응답하지 않는다면 연결 새로 고침이나 로그 스크롤이 과도하게 발생했는지 기록하세요. 비교를 위해 UI 새로 고침 부담을 낮출 수 있지만 로그를 모두 끈 상태에서 원인을 추측하지 마세요.

다시 설치해야 한다면 다운로드 페이지에서 플랫폼과 아키텍처에 맞는 파일을 선택하고 백업한 설정 사본으로 먼저 테스트하세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단된 보관용 클라이언트입니다. 최신 시스템과의 호환성 문제가 있다면 Clash Plus 또는 다운로드 페이지의 다른 호환 클라이언트를 검토하세요. 화면만 바꾸면 모든 설정이 자동으로 이전된다고 가정하지 마세요. Linux에서 코어를 독립 배포하는 방법은 mihomo 및 systemd 설치 절차를 참고하세요.

문제를 신고할 때 플랫폼, 아키텍처, 클라이언트 이름, 재현 단계, 설정 검사 결과와 민감 정보를 가린 오류 내용을 첨부하세요. 특정 설정에서만 재현된다면 최소 예제로 줄이고 실제 서버 인증 정보를 삭제한 뒤에도 문제가 발생하는지 확인하세요. 복구 후 시스템 프록시와 TUN 상태를 다시 점검하세요. 충돌 뒤 남은 설정이 두 번째 네트워크 문제를 일으킬 수 있습니다. 마지막으로 점검 중 높인 로그 수준을 원래대로 복구해 로그가 디스크를 계속 차지하지 않게 하세요.

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

Android: VPN 권한과 앱 적용 범위 확인

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 처음 실행할 때 시스템 권한 요청을 승인해야 합니다. 다른 VPN, 업무용 프로필의 네트워크 도구 또는 보안 앱이 같은 인터페이스를 사용 중일 수 있습니다. 다른 네트워크 제어 앱을 끄고 현재 클라이언트를 실행한 다음 시스템 VPN 상태와 클라이언트 로그가 일치하는지 확인하세요. 상태 표시줄 아이콘은 시스템 인터페이스가 존재한다는 뜻일 뿐 노드, DNS와 규칙이 정상이라는 증거는 아닙니다. 새 요청을 보내 적용된 정책을 확인하세요.

Clash Plus, Clash Meta for Android, FlClash와 Surfboard는 화면 구성과 설정 지원 범위가 서로 다릅니다. 한 클라이언트의 필드 지원 여부를 다른 클라이언트에도 그대로 적용할 수 없습니다. 가져온 뒤 프로토콜이나 규칙 오류가 발생하면 구독 출력이 선택한 클라이언트와 호환되는지 확인하세요. Surfboard 설정 형식도 모든 Clash YAML과 동일하지 않습니다. 처음 사용하는 경우 시작 가이드에 따라 기본 연결을 설정한 다음 앱별 설정과 사용자 지정 규칙을 하나씩 추가하세요.

앱별 프록시를 사용 중이라면 선택한 앱만 프록시하는 모드인지, 선택한 앱을 제외하는 모드인지 확인하세요. 앱 목록은 비슷해 보여도 동작은 반대입니다. 대상 앱이 연결 기록에 나타나지 않는다면 제외 대상이거나 앱이 이전 연결을 캐시했을 수 있습니다. 적용 범위를 바꾼 뒤 해당 앱의 기존 세션을 종료하고 다시 실행하세요. 브라우저는 되지만 다른 앱이 안 된다면 백그라운드 권한 탓으로만 돌리지 말고 앱 내부 DNS, 인증서 요구 사항과 자체 프록시 설정도 확인하세요.

iOS: 설정 활성화와 시스템 터널 상태 확인

iPhone에서는 iOS 다운로드 메뉴를 통해 Clash Plus의 App Store 페이지로 이동할 수 있습니다. 공식 사이트는 clashplus.io입니다. 설치한 뒤 설정을 가져오고 시스템 VPN 권한을 승인한 다음 새로 가져온 설정이 현재 활성화되어 있는지 확인하세요. 구독 목록에 파일이 있다고 터널이 해당 파일을 사용 중인 것은 아닙니다. 구독을 업데이트한 뒤 정책 그룹을 확인하고 새 연결로 출구를 테스트하세요.

iOS에서도 VPN 설정이나 네트워크 확장이 여러 개 등록되어 있을 수 있습니다. 실제로 작동할 네트워크 처리 항목 하나만 남긴 뒤 터널이 연결되는지 확인하세요. 앱을 전면에 둘 때는 작동하지만 화면을 잠근 뒤 끊긴다면 시스템의 백그라운드 처리, 네트워크 전환과 원격 장기 연결 종료를 구분해야 합니다. 앱으로 돌아온 뒤 표시되는 상태만 보지 말고 끊긴 시각을 기록한 다음 새 요청이 자동으로 복구되는지 확인하세요. 잠깐 끊겼다가 다시 연결되는 경우와 계속 사용할 수 없는 경우는 별도로 설명해야 합니다.

특정 앱에서만 문제가 생긴다면 일반 웹페이지, 같은 서비스의 다른 접속 경로와 해당 앱의 연결 기록을 비교하세요. 앱에는 지역, 계정, 위험 관리 또는 서버 정책이 적용될 수 있으므로 프록시 연결에 성공해도 모든 기능을 사용할 수 있는 것은 아닙니다. 하나의 앱 문제를 해결하려고 출구를 여러 번 바꾸면 추가 인증이 발생할 수 있습니다. 앱 설치와 설정 가져오기를 이어서 확인하려면 iPhone 클라이언트 및 구독 설정 가져오기를 참고하세요.

백그라운드·배터리 절약·Wi-Fi 전환 공통 점검

Android에서 화면을 잠근 뒤 연결이 끊긴다면 백그라운드 실행, 배터리 최적화와 백그라운드 데이터 제한을 먼저 확인하세요. 기기 설정에서 필요한 앱 권한만 허용하고 기기 전체의 배터리 관리를 끄지 마세요. 일부 시스템은 작업을 정리하는 과정에서 네트워크 프로세스를 종료할 수 있습니다. 전면에서 안정적으로 연결되는지 확인한 뒤 화면을 잠그고 로그에 프로세스 재시작 기록이 있는지 살펴보세요. 프로세스가 계속 실행되는데 연결만 끊긴다면 네트워크와 노드를 확인하고 모든 중단을 시스템 정리 탓으로 돌리지 마세요.

Wi-Fi와 모바일 데이터 사이를 전환하면 IP 주소, 기본 라우트와 DNS 환경이 바뀌어 기존 연결을 재사용하지 못할 수 있습니다. 테스트할 때는 네트워크 하나를 고정해 안정성을 확인한 다음 전환하세요. 전환 순간에만 실패하는지, 이후 새 연결도 만들 수 없는지 기록해야 합니다. 전환 뒤 터널을 다시 연결하면 복구된다면 네트워크 변경 처리에 집중하세요. 네트워크를 고정해도 주기적으로 실패한다면 노드, DNS와 백그라운드 제한을 다시 확인하세요. 핫스팟을 바꾸며 이동하는 동안의 결과로 노드 안정성을 판단하지 마세요.

모바일 핫스팟에도 트래픽 처리 범위가 있습니다. 휴대전화 자체가 VPN을 사용한다고 핫스팟에 연결된 컴퓨터도 같은 경로를 거치는 것은 아닙니다. 공유 트래픽이 터널을 통과하는지는 운영체제와 클라이언트 기능에 따라 달라집니다. 휴대전화 상태 표시줄만 보지 말고 연결된 기기에서 별도로 확인하세요. 데이터 사용량이 제한된 네트워크에서는 구독 일괄 테스트와 대용량 속도 측정을 잠시 멈춰 점검 자체로 데이터를 계속 소비하지 않게 하세요.