Clash 문제 해결 가이드

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

클라이언트에서 시스템 프록시와 TUN 모드를 끈 다음, 평소 프록시 없이 접속할 수 있는 웹사이트를 열어 보세요. TUN은 가상 네트워크 어댑터로 트래픽을 처리하는 방식입니다. 이를 끄면 우선 일반 네트워크부터 확인할 수 있습니다. 직접 연결도 실패한다면 Wi-Fi 연결, 인터넷 회선 인증, 학교 네트워크 로그인 또는 라우터 문제부터 해결하세요. 이때 노드를 계속 바꿔도 도움이 되지 않습니다. 프록시 서버 역시 기기의 기존 네트워크 연결을 통해 접속하기 때문입니다.

코어가 실행 중인지 확인한 다음 수신 포트를 점검하세요

클라이언트 로그에서 로컬 프록시 포트가 수신 대기 상태로 전환된 기록을 찾으세요. 그래픽 인터페이스가 열린다고 해서 mihomo 코어까지 실행 중인 것은 아닙니다. 코어는 설정을 해석하고 실제 요청을 전달합니다. 로그가 설정을 불러오는 단계에서 멈췄다면 첫 번째 오류부터 확인하고 설정 파일 경로, 들여쓰기, 포트 충돌을 점검하세요. 마지막 종료 메시지만 보지 마세요. 앞서 발생한 오류의 결과일 때가 많습니다. 실제 포트를 기록해 두고 이후 테스트에서도 같은 포트를 사용하세요.

별도로 설치한 mihomo를 사용한다면 먼저 아래 명령어로 설정을 테스트할 수 있습니다. 이 명령은 지정한 디렉터리의 설정을 불러올 수 있는지만 확인하며, 원격 노드의 사용 가능 여부까지 확인하지는 않습니다. 테스트를 통과한 뒤 코어를 실행하세요. 그래픽 클라이언트를 사용한다면 클라이언트에서 코어를 다시 시작하는 것이 좋습니다. 두 번째 프로세스를 수동으로 실행하면 포트를 두고 충돌할 수 있습니다. 그래픽 클라이언트의 작업 디렉터리는 아래 기본 경로와 다를 수도 있습니다.

mihomo -d ~/.config/mihomo -t

시스템 설정을 거치지 않고 로컬 프록시를 직접 테스트하세요

먼저 명시적 프록시 명령으로 같은 URL에 접속해 보세요. 명시적 프록시는 테스트 프로그램에 사용할 로컬 포트를 직접 지정하므로 시스템 프록시가 설정되었는지에 영향을 받지 않습니다. 아래 예시는 혼합 포트가 칠팔구공이라고 가정합니다. 실제 포트는 클라이언트 설정을 기준으로 하세요. Windows PowerShell에서는 명령어 이름을 curl.exe로 입력하면 터미널마다 명령어 이름을 다르게 해석하는 문제를 피할 수 있습니다. 테스트에 실패하면 오류 원문과 발생 시각을 기록하세요.

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

로그를 따라 요청 경로를 확인하세요

요청을 한 번 보낸 직후 연결 목록을 열어 대상 도메인, 적용된 규칙과 최종 출구 노드를 확인하세요. 규칙 모드는 규칙에 따라 프록시 또는 직접 연결을 선택합니다. 전역 모드는 보통 요청을 전역 정책 그룹에 전달하지만, 해당 그룹에서 실제로 어떤 노드를 선택했는지도 확인해야 합니다. 비교를 위해 잠시 전역 모드로 바꿔 볼 수 있습니다. 이때 연결이 복구된다면 전체 네트워크보다 규칙이나 정책 선택에 문제가 있을 가능성이 큽니다. 테스트를 마친 뒤 원래 규칙 모드로 되돌리세요.

특정 웹사이트만 열리지 않는다면 다른 독립된 사이트로 확인하세요. 모든 노드가 고장 났다고 단정하지 마세요. 대상 서비스에서 로그인을 요구하거나 현재 출구 IP 주소를 차단할 수 있습니다. 클라이언트를 종료한 뒤 모든 사이트에 접속할 수 없다면 시스템에 로컬 프록시 주소가 남아 있는지 확인하세요. 프록시 프로그램은 종료됐는데 시스템이 계속 해당 주소로 요청을 보내면 기기 전체가 인터넷에 연결되지 않는 것처럼 보일 수 있습니다. 남아 있는 프록시 설정을 먼저 지우고 진단을 계속하세요.

02 노드 시간 초과: 탐색 테스트, 핸드셰이크, 출구 문제를 구분하세요

먼저 시간 초과가 발생한 위치를 확인하세요. 클라이언트의 노드 테스트는 보통 노드를 통해 특정 테스트 URL에 요청을 보내며, 서버에 단순히 네트워크 에코 테스트를 하는 것이 아닙니다. 테스트 URL에 접속할 수 없거나 예상한 상태 코드가 반환되지 않거나 도메인 이름을 확인하지 못해도 테스트 결과가 시간 초과로 표시될 수 있습니다. 노드 하나를 직접 선택해 브라우저에서 실제 필요한 웹사이트에 접속한 다음 로그를 확인하세요. 목록의 테스트 결과만 보고 설정 전체를 삭제하지 마세요.

단일 노드와 전체 노드의 차이부터 확인하세요

노드 하나를 테스트한 다음 같은 구독에서 서버 주소가 다른 노드도 테스트하세요. 첫 번째 노드만 실패한다면 서비스 상태, 노드 만료 여부, 연결 매개변수가 최근에 바뀌었는지 확인하세요. 모든 노드가 동시에 실패한다면 로컬 네트워크, 구독 계정, 시스템 시간과 공용 DNS 문제부터 살펴보세요. 이름이 다른 여러 노드가 같은 서버를 가리킬 수도 있으므로 이름만 바꿔 테스트하는 것은 효과적인 비교가 아닐 수 있습니다.

집 Wi-Fi에서 모바일 핫스팟으로 바꾸는 등 접속 네트워크를 한 번 바꿔 테스트하세요. 모바일 데이터 사용량에는 유의하세요. 같은 설정이 핫스팟에서는 작동하고 기존 네트워크에서는 실패한다면 기존 네트워크의 접속 제한, 라우팅 또는 DNS 문제가 원인일 수 있습니다. 두 네트워크 모두에서 실패한다면 구독과 프로토콜 매개변수를 확인하세요. 네트워크와 클라이언트를 바꾸면서 설정까지 동시에 수정하지 마세요. 연결이 복구되어도 무엇이 원인이었는지 알 수 없습니다.

오류의 끝부분만 보지 말고 연결 단계를 확인하세요

로그에서 서버 주소와 실패 단계를 확인하세요. 로컬 DNS 조회에 실패했다면 서버 주소를 아직 가져오지 못한 것입니다. 연결이 거부됐다면 대상 포트에서 연결을 받지 않는 경우가 많습니다. 연결 시간 초과는 중간 구간의 패킷 손실이나 서비스 접근 불가와 관련될 수 있습니다. 암호화 핸드셰이크 실패라면 프로토콜, 서버 이름과 인증 매개변수를 추가로 점검하세요. 이 정보만으로 특정 서비스의 장애를 단정할 수는 없지만, 다음 단계에서 로컬 설정과 원격 서비스 중 무엇을 확인할지 판단하는 데 도움이 됩니다.

운영체제 날짜와 시간, 시간대를 확인하고 자동 시간 동기화를 켜세요. TLS 기반 연결은 인증서 유효 기간을 확인하므로 기기 시간이 어긋나면 네트워크 문제처럼 보이는 핸드셰이크 오류가 발생할 수 있습니다. 로그에 인증서 이름이 일치하지 않는다고 표시되면 구독을 제대로 가져왔는지, 서비스 제공자가 지정한 서버 이름을 사용하고 있는지 확인하세요. 인증서 검증을 건너뛰는 방식은 일반적인 해결책이 아닙니다. 설정 오류를 감추고 연결 인증을 약화할 수 있습니다.

# PowerShell: 서비스 제공자가 안내한 실제 주소와 포트 확인
# 명령어 구조 설명을 위해 예시 도메인 사용
Test-NetConnection example.com -Port 443

위 포트 테스트는 지정한 주소에 TCP 연결을 설정할 수 있는지만 확인합니다. 프록시 프로토콜을 검증하지 않으며 전체 요청 테스트를 대신할 수도 없습니다. 주로 UDP를 사용하는 프로토콜이라면 TCP 테스트만으로 사용 가능 여부를 판단할 수 없습니다. 서버에서 탐색 테스트를 제한할 수도 있고, 앱마다 다른 경로를 사용할 수도 있습니다. 따라서 포트 테스트는 참고 자료로만 사용하고 프록시 요청, 코어 로그와 서비스 제공자의 안내를 함께 확인하세요.

정책 그룹에서 출구 노드가 실제로 바뀌었는지 확인하세요

노드를 선택한 뒤 연결 상세 정보를 열어 실제 출구를 확인하세요. 정책 그룹 안에 다른 정책 그룹이 중첩된 경우 자동 선택을 고른 것처럼 보여도 실제로는 내부 노드가 사용될 수 있습니다. 이미 연결된 장시간 연결은 이전 출구를 계속 사용할 수도 있습니다. 관련 연결만 닫고 새 요청을 보내 보세요. 다운로드, 회의 또는 다른 작업에 영향을 줄 수 있으므로 처음부터 모든 연결을 지우지는 마세요.

마지막으로 구독을 업데이트하고 서비스 제공자에게 문의하세요. 문제 발생 시각, 네트워크 유형, 프로토콜 이름과 이미 진행한 비교 테스트를 전달하되 구독 링크 전체를 보내지는 마세요. 업데이트 후 일부 노드만 복구됐다면 사용할 수 있는 노드는 그대로 두고 나머지 회선은 원격 조치를 기다리세요. 로그에 알 수 없는 프로토콜이나 지원되지 않는 필드가 명확히 표시되면 코어 호환성을 확인하고 다운로드 페이지에서 계속 유지 관리되는 클라이언트를 선택하세요. 보안 설정을 무작정 낮추지 마세요.

03 구독 실패: 다운로드, 파싱, 설정 병합을 나눠 확인하세요

먼저 구독 과정의 어느 단계에서 실패했는지 확인하세요. 구독 링크는 노드나 전체 설정을 가져오는 주소입니다. 가져오기에 실패한 원인은 콘텐츠를 다운로드하지 못했거나 다운로드한 콘텐츠를 파싱할 수 없는 것일 수 있습니다. 구독 관리 페이지에서 업데이트 결과와 코어 로그의 구체적인 메시지를 확인하세요. 모든 실패를 링크 만료 탓으로 돌리지 마세요. 비공개 링크에는 계정 리소스에 접근할 수 있는 인증 정보가 포함될 수 있으므로 공개 변환 사이트에 붙여 넣어 테스트하지 마세요.

주소와 응답 내용을 확인하세요

서비스 제공자 계정 페이지에서 링크를 다시 복사하세요. 안내 페이지나 QR 코드 이미지 주소를 복사하지 않았는지, 링크 중간에 공백이 들어가지 않았는지 확인하세요. 메신저에서 링크가 잘리지 않았는지, 문장 끝의 문장 부호가 함께 복사되지 않았는지도 살펴보세요. 일부 링크에는 긴 쿼리 매개변수가 포함되므로 물음표 앞부분만 남겨서는 안 됩니다. 최근 계정을 갱신하거나 구독 주소를 재설정했다면 이전 주소가 더 이상 작동하지 않을 수 있으니 계정 페이지의 최신 주소를 사용하세요.

업데이트 오류의 유형을 확인하세요. 인증 실패나 접근 거부는 계정 권한, 링크 인증 정보 또는 서비스 제한을 확인해야 할 수 있습니다. 리소스를 찾을 수 없다는 오류는 주소 경로가 변경됐을 가능성이 있습니다. 요청 시간 초과가 발생하면 기본 네트워크와 구독 사이트 접속 여부부터 확인하세요. 로그인 페이지, 점검 페이지 또는 접근 확인 페이지가 반환되면 다운로드에 성공했다고 표시되더라도 사용할 수 있는 설정이 아닙니다. 권한 오류가 분명한데도 반복해서 재시도하며 문제를 감추지 마세요.

구독 주소에 프록시 연결이 필요한 경우, 업데이트할 때 사용할 프록시 경로를 클라이언트에서 선택할 수 있는지 확인하세요. 이미 사용할 수 있는 설정이 있다면 먼저 활성화한 뒤 업데이트할 수 있습니다. 사용 가능한 노드가 전혀 없다면 서비스 제공자가 안내하는 다른 공식 수단을 이용하세요. 낯선 도메인으로 업데이트 주소를 임의로 바꾸거나 구독을 받기 위해 설정 디렉터리 전체를 공개적으로 공유하지 마세요.

구독 형식과 코어 호환성을 확인하세요

노드 목록과 전체 설정을 구분하세요. 전체 설정에는 포트, 규칙과 정책 그룹이 포함될 수 있습니다. 노드 목록은 proxy-providers에 정의된 프록시 제공자에 넣어야 할 수도 있습니다. 클라이언트의 구독 가져오기 기능이 모든 공유 링크 형식을 지원하는 것은 아닙니다. 먼저 서비스 제공자가 Clash 또는 mihomo용 형식을 제공하는지 확인하고 형식에 맞는 가져오기 기능을 사용하세요. 파일 확장자만 바꿔 콘텐츠를 변환하려고 하지 마세요.

오류에 YAML 줄 번호가 표시되면 파일을 먼저 백업한 다음 해당 줄 주변의 들여쓰기, 콜론과 목록 기호를 확인하세요. YAML은 공백으로 계층을 표현하므로 탭을 섞어 쓰면 안 됩니다. 오류 줄 번호는 이전 줄의 따옴표가 닫히지 않아 발생한 결과를 가리킬 수도 있습니다. 다운로드한 설정을 대규모로 직접 수정하기보다는 원본 파일을 다시 받아 복사, 저장 또는 자동 병합 과정에서 손상됐는지 확인하세요.

# 프록시 제공자 필드 구조 예시이며 전체 설정에 병합해야 합니다.
# 구조 설명용 예시 도메인으로, 실제 가져오기에 사용할 수 있는 구독 주소가 아닙니다.
proxy-providers:
  subscription:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/subscription.yaml
    interval: 3600

사용 가능한 설정은 보존하고 덮어쓰기와 업데이트 문제를 확인하세요

원래 구독은 다운로드되지만 로컬 덮어쓰기를 켠 뒤에만 실행에 실패한다면 병합 과정으로 범위를 좁혀 보세요. 덮어쓰기는 구독 설정에 로컬 설정을 추가하는 기능으로 DNS, 규칙과 포트를 바꿀 수 있습니다. 최근 추가한 덮어쓰기 항목을 하나 비활성화한 다음 실행 설정을 다시 생성하세요. 클라이언트가 자동 생성한 임시 파일을 직접 수정하지 마세요. 다음 업데이트에서 변경 사항이 덮어써져 문제가 반복되는 것처럼 보일 수 있습니다.

업데이트는 성공했는데 새 노드가 보이지 않는다면 현재 활성화된 설정이 방금 업데이트한 설정인지, 정책 그룹에서 새 노드를 제외하고 있지는 않은지 확인하세요. 자동 업데이트와 현재 설정 전환은 서로 다른 작업입니다. 로컬 파일 경로에 쓰기 권한이 있는지, 디스크 공간이 충분한지도 확인하세요. 마지막으로 사용 가능했던 설정은 보존하고 새 설정을 테스트한 뒤 교체하세요. 구독을 가져오는 기본 방법은 구독 가져오기 안내에서 확인할 수 있습니다.

04 속도 저하: 전송량, 응답 시간, 특정 사이트 제한을 구분하세요

먼저 어떤 상황에서 느린지 구체적으로 확인하세요. 웹페이지를 열기까지 오래 걸리는 경우, 다운로드가 시작된 뒤 속도가 느린 경우, 동영상 재생이 간헐적으로 멈추는 경우는 각각 다른 현상입니다. 첫 번째는 DNS나 연결 핸드셰이크 문제일 수 있고, 두 번째는 지속적인 전송 속도 부족에 가까우며, 세 번째는 대상 서비스의 콘텐츠 전송과 관련될 수 있습니다. 같은 시간대, 같은 URL, 같은 네트워크에서 상태를 기록해 비교하세요. 노드 테스트의 응답 시간을 다운로드 속도로 간주하지 마세요.

반복 가능한 테스트 조건을 만드세요

클라우드 동기화, 시스템 업데이트 등 대용량 작업을 일시 중지하고 같은 기기에서 직접 연결과 프록시 연결을 각각 테스트하세요. 직접 연결도 느리다면 Wi-Fi 신호, 라우터 부하와 인터넷 회선을 먼저 확인하세요. Wi-Fi에 연결됐다고 해서 네트워크가 안정적인 것은 아닙니다. 라우터 가까이에서 테스트하거나 가능하면 유선 연결을 사용하세요. 테스트 중에는 기기를 이동하지 마세요. 신호 변화가 결과에 영향을 줄 수 있습니다.

출처를 신뢰할 수 있고 크기가 적당한 파일 하나만 다운로드하세요. 여러 속도 측정 도구를 동시에 실행하지 마세요. 짧은 시간 동안 다수의 연결을 만들어 테스트하면 대역폭을 나눠 쓰게 되고 원격 서비스의 제한을 받을 수도 있어 평소 사용을 반영하지 못합니다. 노드를 비교할 때는 같은 리소스를 사용하고 실제 출구를 기록하세요. 테스트 사이트마다 지역과 서비스 성능이 다르므로 결과를 그대로 비교할 수는 없습니다.

연결 상세 정보에서 실제 병목을 확인하세요

속도가 느린 요청에 어떤 규칙이 적용됐는지 확인하세요. 일부 사이트는 메인 페이지와 이미지, 동영상에 서로 다른 도메인을 사용합니다. 메인 도메인만 프록시를 통하면 하위 리소스가 접속할 수 없는 직접 연결 경로로 빠질 수 있습니다. 반대로 가까운 곳에서 직접 연결할 수 있는 리소스가 원격을 거치면 대기 시간이 늘어납니다. 연결 목록에서 실제로 실패했거나 느린 리소스 도메인을 찾은 다음 범위를 적절히 제한한 규칙을 추가하세요. 지나치게 넓은 키워드로 전체 네트워크를 매칭하지 마세요.

특정 서비스 하나만 느리다면 같은 노드로 다른 독립 서비스에 접속해 보고, 다른 노드로 원래 서비스를 다시 테스트하세요. 노드를 바꾼 뒤 나아진다면 출구 경로나 대상 서비스의 출구별 트래픽 처리와 관련됐을 수 있습니다. 모든 노드에서 해당 서비스만 느리다면 서비스 자체, 계정 제한과 클라이언트 재생 설정을 살펴보세요. 동영상 사이트의 버퍼링 상태는 프록시 코어의 전송 속도를 직접 측정한 결과가 아닙니다. 연결 목록과 실제 재생 상태를 함께 확인하세요.

프로토콜과 네트워크 어댑터 설정은 신중하게 조정하세요

클라이언트와 다른 VPN, 트래픽 필터링 도구가 같은 연결을 중복 처리하는지 확인하세요. 여러 도구가 동시에 연결을 가로채면 처리 부하가 늘고 우회 경로가 생길 수 있습니다. 바로 제거하지 말고 도구 하나를 종료한 뒤 테스트하세요. TUN을 켰을 때만 느려진다면 라우팅, DNS 가로채기와 보안 소프트웨어 차단 여부를 확인하세요. 시스템 프록시 모드가 정상이라면 우선 그 모드로 작업을 이어가면서 TUN 호환성은 별도로 점검할 수 있습니다.

모든 속도 문제의 첫 해결책으로 MTU를 바꾸지 마세요. MTU는 한 번에 전송할 수 있는 네트워크 패킷의 크기입니다. 경로와 맞지 않으면 일부 연결이 멈출 수 있지만, 값이 작을수록 좋은 것은 아닙니다. 특정 네트워크에서 큰 요청이 자주 멈추고 다른 네트워크로 바꾸면 정상화되는 경우에만 백업 후 제한적으로 조정해 보세요. 원래 값과 변경 값, 같은 요청의 결과를 매번 기록하고 개선되지 않으면 되돌리세요.

마지막으로 CPU 사용량, 기기 온도와 절전 상태를 확인하세요. 오래된 기기에서 암호화 트래픽을 처리하고 다수의 연결과 상세 로그를 계속 유지하면 리소스가 부족할 수 있습니다. 우선 일반 로그 수준으로 되돌리고 불필요한 백그라운드 연결을 줄인 다음 확인하세요. 원인을 찾기 전에 속도 향상용이라는 설정을 한꺼번에 추가하지 마세요. 설정 간 상호작용 때문에 문제를 재현하기 어려워집니다. 속도 문제는 한 번의 속도 측정에서 최고치가 나오는 것이 아니라 자주 사용하는 상황에서 안정적으로 개선됐는지를 기준으로 판단하세요.

05 DNS 문제: 시스템, 코어, 프록시 출구의 DNS 조회를 구분하세요

먼저 DNS 조회가 어디서 이뤄지는지 파악하세요. DNS는 도메인 이름을 네트워크 주소로 변환하는 서비스이며 운영체제, 브라우저와 mihomo가 각각 조회를 요청할 수 있습니다. 시스템 명령어로 주소를 확인해도 프록시 코어가 같은 결과를 사용한다는 뜻은 아닙니다. 브라우저에서 보안 DNS를 사용하면 예상한 조회 경로를 우회할 수도 있습니다. 도메인 관련 오류가 나타나면 어떤 프로그램이 실패를 보고했는지 확인한 다음 실제 DNS 조회 방식을 살펴보세요.

접속 경로를 달리해 문제가 발생한 단계를 확인하세요

먼저 시스템 DNS 도구로 평소 사용하는 도메인을 조회한 다음 명시적 HTTP 프록시 명령으로 해당 도메인에 접속해 보세요. 첫 번째 테스트는 시스템 DNS를 확인하고 두 번째는 대상 도메인을 로컬 프록시에 전달하므로 결과가 같다고 보장할 수 없습니다. 비교 테스트에서 URL 대신 IP 주소만 사용하지 마세요. HTTPS에는 인증서의 도메인 이름과 사이트 식별도 필요합니다. IP 주소로 직접 접속이 실패했다고 네트워크가 끊긴 것은 아니며, 일반 사용자용 최종 테스트로도 적절하지 않습니다.

nslookup example.com
curl --proxy http://127.0.0.1:7890 -I https://example.com

# socks5h는 SOCKS 프록시가 대상 도메인을 조회하도록 지정합니다
curl --proxy socks5h://127.0.0.1:7890 -I https://example.com

비교 테스트를 하기 전에 프록시 포트와 작동 모드를 정확히 기록하세요. SOCKS의 로컬 DNS 조회와 프록시 측 DNS 조회는 서로 다릅니다. 명령어에 문자 접미사가 있는지에 따라 DNS 조회 위치가 바뀔 수 있습니다. 시스템 조회는 실패했지만 프록시 요청은 성공한다면 시스템 DNS를 먼저 확인하세요. 시스템 조회는 정상인데 코어 로그에 오류가 있다면 코어 DNS 설정, 상위 DNS 서버 접속 가능 여부, 아직 연결되지 않은 프록시에 DNS 요청이 의존하는지 점검하세요.

설정 단계와 DNS 조회 경로를 확인하세요

실제 실행 중인 설정을 열어 dns.enable이 활성화되어 있는지 확인하고, nameserver가 어떤 서버를 가리키는지 살펴보세요. 이는 일반 도메인 조회에 사용하는 업스트림 서버 목록입니다. proxy-server-nameserver는 프록시 서버 자체의 도메인을 조회할 때 사용할 수 있습니다. 노드 도메인을 조회하려면 해당 노드에 먼저 연결해야 하는 상황이라면 순환 의존성이 생길 수 있습니다. 먼저 서버 도메인을 독립적으로 조회할 수 있는 경로를 마련한 다음 다른 도메인을 처리하세요.

# 진단용 DNS 설정 조각이며 기존 전체 설정에 병합해야 합니다.
# 현재 네트워크에서 접속 가능한지와 사용 목적을 고려해 상위 DNS 서버를 선택하세요.
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

Fake IP의 작동 방식을 이해한 뒤 주소가 비정상인지 판단하세요. 이 모드에서는 도메인에 예약 주소를 할당하고 이후 연결에서 코어가 원래 대상을 복원합니다. 따라서 예약 주소가 보인다고 DNS가 손상된 것은 아닙니다. 이후 연결이 제대로 가로채지는지 확인해야 합니다. 앱이 가상 주소를 받은 뒤 프록시를 거치지 않고 직접 접속하면 실패할 수 있습니다. 이때는 트래픽 가로채기 범위를 확인하거나 호환성 문제가 실제로 있는 도메인에만 적절한 필터를 적용하세요. DNS 설정 전체를 지우지는 마세요.

캐시, IPv6, 브라우저 설정을 각각 확인하세요

DNS를 변경한 뒤에도 기존 연결과 캐시에 예전 결과가 남아 있을 수 있습니다. 먼저 대상 앱의 관련 연결을 닫고 클라이언트가 제공하는 방법으로 DNS 캐시를 새로 고친 다음 다시 접속하세요. 필요하면 대상 앱을 재시작하세요. 처음부터 기기 전체 네트워크를 초기화할 필요는 없습니다. 브라우저에서 별도의 보안 DNS를 사용한다면 비교를 위해 잠시 비활성화할 수 있습니다. 기존 설정을 기록해 두고 문제를 확인한 뒤 어떤 DNS 경로를 유지할지 결정하세요.

IPv6를 지원하는 네트워크에서만 문제가 발생한다면 주소 체계와 라우팅이 일치하는지 각각 확인하세요. IPv6 주소를 받았다고 해서 해당 주소까지의 경로가 작동한다는 뜻은 아닙니다. 프록시가 IPv6를 지원해도 로컬 접속 네트워크가 IPv6를 지원한다고 보장할 수 없습니다. 주소 체계를 하나씩 바꿔 비교 테스트할 수 있지만 시스템 IPv6를 영구적으로 끄는 것이 일반적인 해결책은 아닙니다. 복구 후에는 문제가 접속 네트워크, 규칙, 프록시 출구 중 어디에 있었는지 확인하세요.

TUN을 사용한다면 DNS 요청이 가로채지고 있는지, 로컬 네트워크 기기와 기업 내부 도메인에 로컬 DNS 조회가 필요한지 추가로 확인하세요. 내부 도메인을 모두 공용 DNS로 보내지 마세요. 보통 해당 네트워크의 DNS 서버에서만 조회할 수 있습니다. 필드 간 관계와 상황별 설정은 mihomo DNS 설정 자세히 알아보기에서 확인하세요. 설정을 바꿀 때마다 공용 사이트와 내부 리소스 모두 테스트해야 합니다.

06 시스템 프록시가 작동하지 않음: 앱 연결 경로별로 확인하세요

먼저 시스템 프록시와 전체 트래픽 가로채기를 구분하세요. 시스템 프록시는 운영체제에 프록시 주소를 등록하고 해당 설정을 사용하는 앱이 이를 읽도록 하는 방식입니다. 모든 연결을 강제로 전달하지는 않습니다. 터미널 도구, 게임, 백그라운드 서비스와 일부 스토어 앱은 같은 설정을 사용하지 않을 수 있습니다. 스위치가 켜져 있다는 것은 클라이언트가 설정을 적용하려 했다는 뜻일 뿐, 모든 프로그램이 프록시를 사용한다는 의미는 아닙니다. 먼저 명시적 프록시 테스트로 코어가 작동하는지 확인하세요.

시스템 설정이 실제로 적용됐는지 확인하세요

운영체제의 네트워크 설정에서 프록시 서버 주소와 포트를 확인하고 자동 설정 스크립트도 동시에 켜져 있는지 살펴보세요. 클라이언트가 루프백 주소에서 수신 대기한다면 시스템 설정도 해당 로컬 주소를 가리켜야 하며, 포트는 현재 실행 중인 설정과 일치해야 합니다. 다른 안내서의 포트 번호를 그대로 복사하지 마세요. 설정을 적용한 직후 자동으로 되돌아간다면 다른 프록시 도구, 기기 관리 정책 또는 보안 소프트웨어가 계속 설정을 변경하는지 확인하세요.

Windows의 네트워크 구성 요소마다 서로 다른 프록시 설정을 참조할 수 있으므로 브라우저는 작동하지만 백그라운드 프로그램은 작동하지 않는 경우가 있습니다. macOS에서는 현재 네트워크 서비스를 확인해야 합니다. 이전에 Wi-Fi에 설정한 프록시가 나중에 연결한 유선 네트워크에도 적용된다고 볼 수 없습니다. Linux 데스크톱의 네트워크 프록시 설정도 모든 명령줄 프로그램에 적용되는 것은 아닙니다. 먼저 문제가 발생한 앱을 찾고 해당 앱이 지원하는 설정 방법을 선택하세요. 여러 시스템 계층을 동시에 변경하지 마세요.

브라우저와 터미널을 각각 테스트하세요

브라우저에서는 프록시를 제어하는 확장 프로그램을 먼저 비활성화한 다음 브라우저를 완전히 종료하고 다시 열어 테스트하세요. 일부 확장 프로그램은 시스템 설정보다 우선 적용될 수 있습니다. 시크릿 창으로 열어도 기업 정책이나 확장 프로그램 권한까지 모두 배제할 수 있는 것은 아닙니다. 브라우저 자체 프록시 옵션이 시스템 설정을 따르는지 확인하고 새 요청을 보낸 뒤 연결 목록을 살펴보세요. 브라우저에서 페이지가 열렸는데 코어에 새 연결이 없다면 캐시된 페이지인지도 확인하세요. 화면만 보고 트래픽 경로를 단정하지 마세요.

터미널에서는 먼저 명령어 매개변수로 테스트한 다음 환경 변수를 설정할지 결정하세요. 환경 변수는 프로세스에 설정을 전달하며 일반적으로 새로 실행하는 자식 프로세스에만 영향을 줍니다. 이미 실행 중인 모든 터미널 창의 설정을 자동으로 바꾸지는 않습니다. 아래 예시는 현재 셸 세션에 일반적인 변수만 설정합니다. 도구마다 지원하는 변수 이름이 다를 수 있습니다. 빌드 도구, 패키지 관리자 또는 원격 개발을 사용한다면 해당 도구의 프록시 안내도 확인하세요.

# 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 변수는 HTTPS 대상 요청에 사용된다는 뜻이며, 변수 값에는 로컬 HTTP 프록시 주소를 사용할 수 있습니다. 대상 URL이 HTTPS라고 해서 로컬 주소의 프로토콜까지 HTTPS로 바꾸지 마세요. 기존 ALL_PROXY, 대문자 변수와 도구 내부 설정도 확인해 종료된 포트를 가리키는 값이 남아 있지 않도록 하세요. 클라이언트를 종료한 뒤에도 터미널에 저장된 프록시 변수를 정리해야 합니다.

필요한 경우에만 TUN을 사용하고 제외 설정을 확인하세요

프록시 설정을 지원하지 않는 앱에만 TUN 사용을 고려하세요. 활성화하기 전에 클라이언트에 필요한 권한이 있는지, 서비스 모드나 가상 네트워크 어댑터가 제대로 시작됐는지 확인하고 코어 로그의 라우팅 오류도 살펴보세요. 서비스 모드는 백그라운드 서비스가 권한이 필요한 작업을 수행하도록 하는 방식입니다. 진단 대신 인터페이스를 계속 관리자 권한으로 실행하지 마세요. TUN을 켠 뒤 내부 네트워크에 연결할 수 없다면 먼저 TUN을 꺼서 연결을 복구한 다음 제외 경로와 내부 DNS를 확인하세요.

마지막으로 우회 목록을 확인하세요. 일부 앱에는 로컬 주소 무시, 특정 도메인 직접 연결 또는 별도 네트워크 격리 기능이 있습니다. 이런 조건에 해당하면 프록시를 사용하지 않는 것이 정상입니다. 컨테이너, 가상 머신과 원격 개발 환경의 루프백 주소는 각 환경을 가리키므로 호스트 기기의 포트를 그대로 사용할 수 없습니다. 다른 기기에서 프록시에 접속할 수 있도록 열 때는 접근 제어를 설정하세요. 일반적인 로컬 사용에서는 LAN 접근을 꺼 두면 됩니다. 자세한 비교 방법은 브라우저와 터미널을 나눠 문제 해결하기에서 확인하세요.

07 클라이언트 충돌: 로그를 보존하고 충돌 원인을 찾은 뒤 설정을 되돌리세요

먼저 종료된 것이 그래픽 인터페이스인지 코어인지 확인하세요. 인터페이스가 갑자기 사라지는 경우, 인터페이스는 열려 있지만 연결이 끊기는 경우, 부팅 후 백그라운드 서비스가 반복해서 재시작되는 경우는 각각 원인이 다를 수 있습니다. 소프트웨어를 열 때, 구독을 업데이트한 뒤, 특정 기능을 켠 뒤 중 언제 재현되는지 기록하세요. 앱 데이터 디렉터리 전체를 바로 삭제하지 마세요. 로그, 설정과 복구 단서가 함께 사라질 수 있고 구독 인증 정보와 로컬 규칙을 복구하지 못할 수도 있습니다.

로그와 설정 파일을 보존하세요

인터페이스를 열 수 있다면 클라이언트가 제공하는 로그와 설정 디렉터리 바로가기를 먼저 사용하세요. 열 수 없다면 해당 클라이언트 문서에서 데이터 디렉터리 위치를 확인한 다음 설정, 덮어쓰기 규칙과 최근 로그를 개인 백업 위치에 복사하세요. 백업 파일에도 민감한 정보가 포함될 수 있으므로 공개 포럼에 그대로 올리지 마세요. 스크린샷에는 오류 유형, 파일 이름과 발생 순서가 보이도록 하되 구독 주소와 인증 정보는 가리세요. 도움을 요청하는 과정에서 정보 노출을 늘리지 않도록 주의하세요.

설정을 수정한 직후 문제가 생겼다면 최근 변경 사항부터 되돌린 다음 설정을 테스트하세요. 문법이 올바르다고 모든 리소스를 읽을 수 있는 것은 아닙니다. 로그에 규칙 파일이 없거나, 프록시 그룹 참조가 잘못됐거나, 경로에 접근 권한이 없다는 메시지가 계속 표시될 수 있습니다. 상대 경로가 기기에 파일이 있는지만 확인하지 말고 어떤 작업 디렉터리를 기준으로 하는지 확인하세요. 그래픽 클라이언트가 생성한 설정은 원본 구독과 다르므로 실제로 코어에 전달된 파일을 점검해야 합니다.

포트 점유와 실행 권한을 확인하세요

로그에 주소가 이미 사용 중이라고 표시되면 다른 클라이언트나 이전 코어 프로세스가 실행 중인지 먼저 확인하세요. 일반적으로 여러 프로세스가 같은 포트에서 동시에 수신 대기할 수는 없습니다. 아래 명령어는 포트와 연결된 프로세스 정보를 확인하며 프로세스를 자동으로 종료하지는 않습니다. 프로세스 번호를 확인한 다음 작업 관리자나 시스템 도구에서 프로그램 이름을 확인하세요. 다른 서비스를 실수로 종료할 수 있으므로 인터넷에 있는 일괄 종료 명령을 그대로 복사하지 마세요.

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

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

# Linux
ss -ltnp 'sport = :7890'

포트를 점유한 프로그램이 이전 클라이언트라면 정상적으로 종료한 뒤 현재 클라이언트를 다시 시작하세요. 필요한 다른 서비스가 포트를 사용 중이라면 클라이언트에서 비어 있는 포트를 사용하고 시스템 프록시와 터미널 변수도 함께 수정하세요. 설정 한 곳만 바꾸고 테스트를 시작하지 마세요. 앱이 이전 포트에 계속 접속하면 포트 충돌이 연결 거부 문제로 바뀔 수 있습니다. 조정을 마친 뒤 로그, 시스템 설정과 명시적 테스트 명령에서 같은 포트를 사용하는지 확인하세요.

권한 부족 오류가 발생하면 설정 디렉터리가 읽기 전용인지, 다른 계정에서 복사한 것인지, 보안 소프트웨어가 코어 또는 가상 네트워크 어댑터 작업을 차단하는지 확인하세요. 모든 보안 기능을 바로 끄지 마세요. 먼저 시스템 알림을 읽고 차단된 파일 경로와 출처를 확인한 다음 필요한 구성 요소만 허용하세요. 설치 파일의 아키텍처가 기기와 일치하는지도 확인하세요. 특히 프로세서가 다른 macOS와 Linux 기기는 파일 확장자만으로 판단할 수 없습니다.

전체 삭제 대신 필요한 부분만 복구하세요

먼저 TUN을 끄고 새로 추가한 덮어쓰기를 비활성화한 뒤 마지막으로 사용할 수 있었던 설정으로 전환해 기본 인터페이스와 코어가 안정적으로 실행되는지 확인하세요. 사용자 데이터 손상 여부를 확인해야 한다면 클라이언트가 지원하는 방식으로 별도 테스트 환경을 만들거나 전체 백업 후 관련 설정을 잠시 다른 위치로 옮기세요. 모든 파일을 영구 삭제하지 마세요. 복구가 확인되면 구독, 규칙과 고급 설정을 하나씩 추가하고 매번 시작 로그를 확인하세요.

특정 클라이언트만 계속 종료되고 같은 구독이 유지 관리 중인 다른 클라이언트에서는 작동한다면 로그를 보존해 해당 프로젝트에 전달하세요. 클라이언트를 바꿀 때는 클라이언트 다운로드 페이지에서 플랫폼에 맞는 버전을 선택하고 여러 프록시 클라이언트의 트래픽 가로채기를 동시에 켜지 마세요. 되돌리는 순서를 자세히 확인하려면 클라이언트 실행 직후 충돌 해결하기를 참고하세요. 연속 실행, 구독 업데이트와 정상 종료가 모두 되는지 확인한 뒤 이전 백업을 정리하세요.

08 모바일 문제: VPN 권한, 백그라운드 제한, 네트워크 전환을 확인하세요

앱을 화면에 띄운 상태에서 연결을 한 번 테스트한 다음 화면을 잠그거나 백그라운드로 전환해 보세요. 모바일 운영체제는 백그라운드 실행, 네트워크 권한과 VPN 연결을 관리합니다. 데스크톱에서 작동하는 설정이 휴대폰에서도 같은 권한과 실행 조건으로 작동한다고 볼 수 없습니다. 화면을 켜 두었을 때는 정상인데 잠금 후 연결이 끊긴다면 백그라운드 제한부터 확인하세요. 처음부터 연결이 되지 않는다면 권한, 구독과 노드를 확인하세요. 모든 모바일 문제를 절전 설정 탓으로 돌리지는 마세요.

Android: 권한과 백그라운드 실행 조건을 확인하세요

처음 연결할 때 시스템 팝업에서 VPN 연결을 허용하고 다른 앱이 필요한 VPN 연결을 이미 사용 중인지 확인하세요. 여기서 VPN은 시스템이 제공하는 트래픽 전달 인터페이스를 뜻하며 특정 프록시 프로토콜을 사용한다는 의미는 아닙니다. 광고 차단, 기업 네트워크 연결이나 다른 네트워크 도구도 이 인터페이스를 사용할 수 있습니다. 하나를 켜면 다른 도구의 연결이 대체될 수 있습니다. 먼저 다른 트래픽 가로채기 도구를 일시 중지하고 Clash 클라이언트만 테스트하세요.

시스템 앱 설정에서 배터리 최적화, 백그라운드 활동과 데이터 사용 권한을 확인하세요. 기기마다 메뉴 이름이 다르므로 실제 시스템 옵션을 기준으로 사용 중인 클라이언트의 백그라운드 실행을 허용하세요. 테스트할 때 최근 앱 목록에 앱 카드가 남아 있는지만 확인하지 마세요. 목록에 보여도 서비스가 계속 실행 중이라는 뜻은 아닙니다. 화면을 잠근 뒤 잠시 기다렸다가 코어 로그를 다시 확인해 서비스가 종료됐는지, 서비스는 실행 중이지만 네트워크 연결을 다시 설정해야 하는지 판단하세요.

앱별 프록시를 사용하는지 확인하세요. 일부 앱이 우회 목록에 포함됐거나 선택한 앱만 프록시를 사용하는 모드가 켜져 있을 수 있습니다. 새로 설치한 앱을 목록에서 선택하지 않으면 해당 앱만 프록시를 사용하지 않는 것처럼 보일 수 있습니다. 설정을 바꾼 뒤 대상 앱을 재시작하고 연결 목록에서 요청을 확인하세요. Android의 비공개 DNS도 도메인 조회에 영향을 줄 수 있습니다. 도메인 오류가 발생하면 비교를 위해 잠시 시스템 기본값으로 바꾼 다음 필요에 따라 원래 설정으로 되돌리세요.

iOS: 터널 상태, 네트워크 권한과 리소스 업데이트를 구분하세요

iOS 사용자는 iOS 다운로드 페이지에서 Clash Plus를 설치한 뒤 시스템 안내에 따라 VPN 구성을 추가할 수 있습니다. 시스템에 VPN 표시가 나타나도 터널이 연결됐다는 뜻일 뿐, 노드와 규칙, 대상 서비스까지 사용할 수 있다는 보장은 없습니다. 클라이언트로 돌아가 현재 구독, 선택한 출구와 최근 로그를 확인한 다음 새 요청을 보내세요. 특정 앱에서만 문제가 발생한다면 셀룰러 데이터 사용이 허용되어 있는지도 확인하세요.

로컬 네트워크 리소스에 연결할 수 없다면 앱에 필요한 로컬 네트워크 접근 권한이 있는지, 내부 주소가 잘못 프록시로 전달되지는 않는지 확인하세요. 권한과 트래픽 분기는 별개의 문제이므로 직접 연결 규칙을 추가해도 시스템 권한을 대신할 수 없습니다. 대용량 설정이나 규칙 리소스를 업데이트한 뒤 연결이 끊겼다면 불필요한 규칙 그룹과 동시 작업을 줄인 다음 상태를 확인하세요. 연결을 복구하려고 모든 구독을 한 번에 삭제하지 마세요.

네트워크를 바꿔 다시 확인하고 문제를 전달할 자료를 정리하세요

Wi-Fi에서 모바일 데이터로 전환하면 기존 연결이 더 이상 유효하지 않을 수 있고 새 네트워크의 IPv6, DNS와 접근 제한도 다를 수 있습니다. 시스템 네트워크가 안정될 때까지 기다린 다음 프록시 연결을 다시 설정하고 대상 앱에서 이전 요청을 종료한 뒤 테스트하세요. 특정 Wi-Fi에서만 실패한다면 웹 로그인 인증이 필요한지 확인하세요. 먼저 프록시를 잠시 끄고 인증을 마친 다음 연결을 복구하세요. 인증 페이지가 원격 출구로 잘못 전달되는 일을 막을 수 있습니다.

항상 켜기 VPN 또는 VPN 연결이 아닐 때 연결 차단 같은 시스템 정책을 켤 때는 연결이 끊긴 뒤 어떤 일이 생기는지 알아야 합니다. 터널에 일시적인 문제가 생기면 기기 전체의 인터넷 연결이 차단될 수 있습니다. 이는 정책에 따른 동작이지 Wi-Fi 고장이라는 뜻은 아닙니다. 문제를 해결할 때 먼저 원래 설정을 기록한 다음 비교를 위해 관련 제한을 잠시 끄세요. 테스트가 끝나면 필요한 보호 수준에 맞게 설정을 복구하세요. 내용을 모른 채 시스템 정책을 장기간 변경하지 마세요.

마지막으로 재현할 수 있는 내용을 정리하세요. 기기 운영체제, 클라이언트 이름, 접속 네트워크, 앱이 화면에 있을 때와 백그라운드일 때의 차이, 특정 앱에서만 실패하는지 여부와 민감 정보를 가린 첫 번째 오류를 포함하세요. 구독 링크 전체, 계정 화면 캡처나 전체 설정은 보내지 마세요. 기본 개념은 자주 묻는 질문과 용어집에서 확인할 수 있습니다. 설치와 첫 연결을 다시 진행하려면 사용 안내로 돌아가 최소한의 설정으로 먼저 연결한 뒤 고급 기능을 하나씩 켜세요.