DNS 문제 해결: Fake-IP, DoH, IPv6-블로그-Clash Verge Rev

설정을 바꾸기 전에 실패한 단계를 찾으세요.웹 페이지가 열리지 않는 원인은 이름 해석, 연결, TLS 검증 또는 애플리케이션 응답일 수 있습니다. 해당 요청이 실제로 Clash Verge Rev를 거쳤는지도 확인해야 합니다. 브라우저가 된다고 다른 앱도 같은 DNS와 경로를 쓴다는 뜻은 아닙니다.

이 글은 Windows, macOS, Linux 데스크톱 환경을 위한 진단 절차입니다. 공개 문서를 바탕으로 구성했으며 모든 환경에서 실측했다는 보장은 아닙니다. 메뉴 이름은 버전에 따라 달라집니다. 회사나 학교가 관리하는 DNS, VPN, 보안 정책은 관리자에게 문의하세요.

1. 변경 전 기준 상태를 기록하세요

접근이 허용되고 문제를 반복 확인할 수 있는 대상 하나를 고릅니다. 클라이언트와 코어 버전, 운영체제, 활성 프로필 이름, 시스템 프록시와 TUN 상태, 문제 앱, 시각, 오류 원문을 기록하세요. 구독 갱신, 노드 변경, DNS 수정을 동시에 하면 복구되더라도 어떤 조치가 효과가 있었는지 알 수 없습니다.

같은 대상에 대해 브라우저 결과, 원래 앱 결과, 클라이언트 연결 기록의 존재 여부를 비교합니다. 허용된 다른 네트워크에서도 비교할 수 있지만 나머지 조건은 유지하세요. 비공개 내부 호스트 이름을 공용 DNS나 공개 진단 사이트로 보내지 마세요.

2. 오류를 네 단계로 나누세요

이름 해석 시간 초과:사용한 DNS, 도달 가능성, hosts와 캐시를 확인합니다. 한 번의 실패만으로 DNS 오염을 단정할 수 없습니다.
주소를 받았지만 연결 실패:목적지 서비스, 경로, 노드, 방화벽을 살펴봅니다. 이름 해석과 연결 성공은 별개입니다.
TLS 또는 인증서 오류:시스템 시각, 호스트 이름, 신뢰 체인, 중간 장비를 확인합니다. 인증서 검증을 꺼서 원인을 숨기지 마세요.
HTTP 403, 404, 429:어떤 HTTP 응답 지점에는 도달했지만 목적지, 프록시, 게이트웨이 중 누가 응답했는지는 확인해야 합니다.

이는 조사 편의를 위한 분류이며 모든 오류의 유일한 해석은 아닙니다. 한 서비스만 실패한다면 컴퓨터 네트워크 전체를 초기화하기 전에 그 대상에 관한 증거를 확보하세요.

3. 누가 해석하고 어떤 경로로 연결하는지 확인하세요

연결 기록과 로그로 트래픽이 코어에 들어오는지 확인합니다. 모든 앱이 시스템 프록시를 따르는 것은 아닙니다. TUN에서도 라우팅과 DNS 가로채기를 따로 검증해야 하며, 켜짐 표시만으로 모든 질의가 처리된다고 판단하면 안 됩니다.

nslookup example.com은 그 도구가 보낸 질의의 결과를 보여줄 뿐 브라우저 캐시나 앱 자체 DNS 동작 전체를 재현하지 않습니다. Firefox의 DoH 설정도 별도 변수입니다. 코어의 처리 순서와 적용 범위는 글 끝의 Mihomo 문서에서 확인할 수 있습니다.

4. Fake-IP의 특이한 주소가 곧 오류는 아닙니다

Fake-IP는 목적지의 공인 주소 대신 매핑 주소를 반환할 수 있습니다. 198.18.x.x 같은 결과는 현재 fake-ip-range와 비교하세요. 낯설다는 이유로 오염으로 단정하거나 시스템 hosts에 고정하지 마세요.

그다음 연결이 해당 매핑을 관리하는 코어로 다시 들어오는지가 중요합니다. 앱의 다른 경로, 오래된 캐시, 프로필 변경 후 연결 재사용은 해석 성공과 연결 실패가 함께 나타나는 가설입니다. 주소만 보고 결론 내리지 말고 로그로 확인하세요.

특정 앱에서만 발생한다면 설정 사본을 보관한 뒤 호환성을 조사합니다. 근거가 있을 때 필요한 도메인만 예외로 처리하세요. DNS 설정 전체 교체나 모든 도메인 제외는 원인 파악을 어렵게 만듭니다.

5. DoH와 IPv6는 비교한 후 판단하세요

자체 DoH를 사용하는 브라우저는 명령줄 도구와 다른 결과를 낼 수 있습니다. 일반적인 53번 포트 DNS 처리와 HTTPS 내부 DNS 복호화는 다릅니다. 보안 DNS 설정과 관리 정책을 먼저 기록하고, 허용된 임시 비교가 끝나면 원래대로 복원하세요. 암호화 DNS의 영구 비활성화를 기본 해결책으로 삼지 마세요.

IPv6에서는 AAAA 응답을 받는 것과 실제 IPv6 경로가 작동하는 것을 구분합니다. Mihomo의 dns.ipv6는 AAAA 응답 동작을 제어하며 운영체제 전체의 IPv6 스위치가 아닙니다. IPv4와 IPv6 경로의 결과 차이를 관찰했을 때 경로, 노드 지원, 앱의 주소 선택을 조사하세요.

6. 명시적 프록시 테스트로 범위를 좁히세요

아래 예시는 이미 켜진 로컬 SOCKS 또는 혼합 리스너가 필요합니다. PORT를 실제 표시된 포트로 바꾸고 접근이 허용되며 토큰이 없는 테스트 주소를 사용하세요. 예시를 실행하려고 LAN 공개를 켜지 마세요.

curl --proxy socks5h://127.0.0.1:PORT --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.com

Windows PowerShell에서는 curl.exe로 실행할 수 있습니다. socks5h는 대상 호스트 이름 해석을 SOCKS 프록시에 맡깁니다. 이는 지정된 경로의 비교이지 원래 앱을 완전히 모사하는 것은 아닙니다. 서버가 HEAD를 지원하지 않아 메서드 오류를 반환해도 그것만으로 네트워크 실패는 아닙니다.

이 테스트만 성공하면 앱의 경로와 캐시를 먼저 확인합니다. 둘 다 실패하면 코어 로그로 목적지 해석, 노드 연결, 규칙 선택을 구분하세요. 간헐적이라면 절전 복귀, 네트워크 변경, 연결 재사용 시점과의 관계를 기록합니다.

7. 모든 변경을 되돌릴 수 있게 하세요

프로필을 백업하고 검증할 가설 하나를 정합니다.
관련 설정 하나만 바꾸고 지원되는 적용 방식으로 반영한 뒤 오류를 확인합니다.
테스트 앱을 다시 엽니다. 캐시 처리는 해당 문서를 따르고 설정 폴더 전체를 삭제하지 않습니다.
원래 대상, 정상 비교 대상, 원래 앱의 작업을 다시 테스트합니다.
개선이 없으면 복원합니다. 개선됐어도 클라이언트 재시작이나 네트워크 재연결 후 확인합니다.

DNS 서버 자체나 프록시 노드의 이름이 해석되지 않는다면 초기 연결에 필요한 해석 의존성을 살펴보세요. 방화벽을 끄거나 TLS 검증을 생략하거나 제어 인터페이스를 공개해서 테스트를 통과시키지 마세요.

8. 사례와 문의 전 점검표

가상 사례:브라우저는 정상이고 데스크톱 앱은 시간 초과이며 코어에 해당 연결이 없습니다. 다음 단계는 앱이 시스템 프록시를 따르는지, TUN 적용 대상인지 확인하는 것입니다. 명시적 프록시 테스트가 성공하면 경로 가설을 뒷받침하지만 앱에 다른 결함이 없다는 증명은 아닙니다.

문의에는 버전, 운영체제, 모드, 민감 정보를 가린 오류, 재현 시각, 변경 전후 비교를 포함하세요. 구독 URL, 쿼리 토큰, 노드 인증 정보, 컨트롤러 비밀값은 제거합니다. 원래 작업과 비교 대상이 재연결 후에도 정상이어야 완료입니다. 한 번의 지연 시간 수치만으로는 충분하지 않습니다.

참고 자료

참고 자료 확인일: 2026-10-14. 아래 링크는 프로젝트 및 플랫폼 문서이며, 이 글은 본 사이트가 독립적으로 작성한 가이드입니다.

DNS,Fake-IP,문제 해결,네트워크 진단