이 글의 목차
구독의 이름 해석 설정이 완전해 보여도 가상 어댑터를 켜면 도메인 이름으로 접속하지 못할 수 있습니다. 앱은 병합된 설정을 사용하므로 어떤 설정이 해석 내용을 바꿨는지 찾아야 합니다. 일반 연결 수단을 확보하고 구독, 기본 파일과 실행 설정을 저장한 뒤 확인된 잔여 필드를 처리할지 판단하세요.
TUN을 켜면 이름 조회가 안 되나요: 실행 설정의 dns가 불완전한지 확인하기
이 방법은 TUN을 끄면 일반 네트워크나 동일 노드의 시스템 프록시가 작동하고, TUN을 켰을 때 도메인 이름 해석이 실패하며, 기본 설정과 실행 설정 사이에 실제로 해당 차이가 확인될 때만 적용합니다.
앱은 병합된 설정을 실행합니다. 기본 config.yaml에 불완전한 dns 블록이 남아 있으면 구독의 이름 해석 설정을 덮어쓸 수 있습니다. 아래 표로 DNS 잔여 설정, 권한, 인터페이스와 노드 문제를 구분한 다음 세 파일을 저장해 비교하세요.
이름 조회, 권한과 인터페이스 오류 구분하기
| 확인된 증거 | 우선 판단 |
|---|---|
| 실행 설정의 dns에 enhanced-mode만 남고 기본 config.yaml에도 같은 잔여 항목이 있음 | 이 글의 설정 덮어쓰기 경로를 계속 확인 |
| TUN 스위치가 즉시 꺼지거나 로그에 operation not permitted가 표시됨 | macOS 서비스 권한부터 확인 |
| 로그에 get empty name / interface not found가 먼저 표시됨 | 현재 출구 인터페이스부터 확인 |
| 시스템 프록시와 TUN 모두 같은 사이트에 접속할 수 없음 | Profile, 노드 및 두 모드에 공통인 DNS 문제부터 확인 |
TUN을 꺼 연결을 복구하고 구독, 기본 파일과 실행 설정 보관하기
먼저 TUN을 끄고 macOS의 일반 네트워크가 즉시 복구되는지 확인하세요. 시스템 프록시가 원래 작동했다면 당분간 그것만 사용해도 됩니다. 클라이언트를 종료한 뒤에도 인터넷에 연결되지 않는다면 시스템 네트워크 설정에 이전 프록시나 DNS가 남았는지 확인하고, 테스트를 위해 문제가 있는 TUN을 반복해서 켜지 마세요.
수정하기 전에 원본 구독 또는 Profile, 기본 config.yaml, 앱이 생성한 실행 설정을 각각 저장하고 현재 클라이언트와 코어 버전을 기록하세요.
v2.5.7/v2.5.8에서 Profiles(구독) 페이지를 열고 현재 구독 카드를 마우스 오른쪽 버튼으로 클릭한 뒤 Edit File을 선택하세요. Profile 원문만 확인하고 복사한 다음 저장하지 않고 편집기를 닫으세요. Edit Info는 구독 정보 양식이며 파일 원문을 보여 주는 화면이 아닙니다.
기본 설정은 일반적으로 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/config.yaml에 있습니다. 이 컴퓨터의 앱 디렉터리나 파일 관리자에서 실제 경로를 확인하세요. 여기서 보는 것은 기본 설정이며 dns_config.yaml이나 실행 설정이 아닙니다.
병합 결과를 보려면 같은 페이지 오른쪽 위에 있는 View Runtime Config 문서 아이콘을 클릭하세요. 이 창은 앱에서 생성한 병합 설정을 읽기 전용으로 보여 줍니다. 구독 원본 파일이나 기본 config.yaml과는 다르므로 기본 파일을 실행 설정으로 간주하지 마세요.
구독과 설정에는 노드 인증 정보가 들어 있을 수 있으므로 백업은 기기의 안전한 위치에 보관하고 공개 제보에는 민감 정보를 가린 사본만 사용하세요.
같은 네트워크에서 세 가지 상태를 기록하세요. TUN을 껐을 때 도메인이 해석되는지, TUN을 켠 직후 첫 DNS 또는 TUN 로그가 무엇인지, 다시 끄면 복구되는지입니다. 그래야 브라우저 캐시, 노드 장애나 시스템 권한이 아니라 DNS를 인계받는 경로에서 문제가 생겼는지 구분할 수 있습니다.
세 설정 중 어느 것이 구독 DNS를 바꿨나요?
먼저 원본 구독의 dns가 완전한지 확인하세요. 특히 enable: true, nameserver와 기존의 다른 이름 해석 설정을 보세요. 다음으로 기본 config.yaml에 dns.enhanced-mode: redir-host나 그와 비슷한 불완전한 필드만 남았는지 살피세요.
마지막으로 앱이 생성한 실행 설정이 원본 구독의 DNS 대신 그 잔여 항목과 비슷한지 확인하세요. 세 파일을 비교하기 전에는 ‘DNS 재정의’ 스위치가 꺼져 있다는 이유만으로 설정을 삭제하지 마세요.
Mihomo 공식 문서는 dns.enable을 코어 DNS 사용 여부를 결정하는 필드로 정의하고 nameserver 등의 이름 해석 필드를 설명합니다. TUN의 dns-hijack은 DNS 질의를 코어로 넘깁니다.
실행 설정에 사용할 수 있는 DNS 경로가 없는데 TUN이 질의를 계속 인계받으면 도메인 요청이 실패할 수 있습니다. 그래서 시스템 프록시나 일반 직접 연결은 작동했지만 TUN을 켠 뒤 모든 사이트가 실패하는 현상을 설명할 수 있습니다. 다만 #8122에 해당하는지는 이 기기에서 확인한 설정 차이를 기준으로 판단해야 합니다.
Clash Verge Rev 공식 문서에 따르면 v2.5.5부터 확장 설정에 작성한 dns 필드는 정해진 규칙에 따라 해당 값을 덮어씁니다. 앱 설정, 전역 확장, 구독별 확장 및 앱의 최종 기록에는 적용 순서가 있습니다. 구독 원본이 올바르더라도 뒤의 설정 출처가 최종 결과를 바꿀 수 있습니다. 기본 config.yaml에 잔여 항목이 없다면 자신의 확장 설정과 스크립트를 확인하고, 이 issue의 처리 절차를 억지로 적용하지 마세요.
원본 구독 DNS는 완전하지만 기본 설정과 실행 설정은 모두 불완전함
백업한 뒤 기본 설정에서 확인된 잔여 항목만 처리하세요.
원본 구독 자체에 enable 또는 nameserver가 없음
구독 제공자에게 원본 설정을 먼저 확인하고 기본 설정의 덮어쓰기를 원인으로 단정하지 마세요.
기본 설정은 정상인데 실행 설정이 변경됨
전역/구독별 확장, 스크립트 및 앱 설정의 적용 순서를 확인하세요.
실행 설정의 DNS가 완전한데도 인터넷에 연결되지 않음
상위 DNS 서버의 도달 가능성, 규칙, 노드, 인터페이스 및 서비스 로그를 확인하세요.
Clash Verge Rev issue #8122에는 macOS 기기 한 대에서 v2.5.6, 서비스 모드, Mihomo v1.19.31을 사용하던 중 TUN을 켜자 원래 직접 접속되던 사이트조차 도메인으로 열리지 않은 사례가 기록돼 있습니다. 제보자가 확인한 실행 설정에는 dns.enhanced-mode: redir-host만 남아 있었습니다.
해당 issue는 2026년 10월 2일에 닫혔습니다. 논의에는 자세한 재현 과정과 소수의 같은 증상 보고가 있지만 닫힘 상태가 일반적인 수정이 확인되었다는 뜻은 아니며 모든 Mac이나 구독에 같은 오류가 발생한다고 단정할 수도 없습니다.
보고자는 처음에 DNS 덮어쓰기를 끄면 구독의 dns가 제거된다고 생각했습니다. 프로젝트 구성원은 기본 config.yaml에 남은 불완전한 dns 블록이 병합 시 구독 DNS를 덮어쓰고 enable: true가 없어 코어 DNS를 사용할 수 없게 된다고 설명했습니다.
공식 확장 설정 문서는 DNS 덮어쓰기가 꺼져 있으면 앱 자체는 구독의 dns를 바꾸지 않는다고 설명합니다. 보고자의 추측과 프로젝트 구성원의 잔여 설정 설명은 구분해야 합니다. 해당 부분을 삭제할지는 세 파일의 실제 차이를 보고 판단하세요.
기본 설정에서 잔여 설정으로 확인된 dns 블록만 삭제하기
세 파일을 비교한 결과가 위 경로를 뒷받침할 때에만 #8122의 프로젝트 구성원이 제안한 방법을 적용하세요. 먼저 메뉴 막대 프로세스까지 포함해 Clash Verge Rev를 완전히 종료하고 기본 config.yaml을 백업했는지 확인하세요.
그다음 텍스트 편집기에서 이 파일에 남은 것으로 확인된 최상위 dns 항목만 제거하고, 다른 키와 구독 원본은 유지하세요. config.yaml, dns_config.yaml, Profile 또는 앱 데이터 폴더 전체를 삭제하지 말고 다시 생성되는 실행 설정을 직접 고치지도 마세요.
저장한 뒤 Clash Verge Rev를 다시 시작하되 TUN은 계속 꺼 두세요. 실행 설정에 원본 구독에서 예상한 DNS 필드가 복구됐는지 확인하고, 설정 검증을 통과한 뒤 시스템 프록시로 실제 HTTPS 요청을 한 번 수행하세요. 여기까지 정상일 때에만 잠시 TUN을 다시 켜서 테스트합니다.
제보자는 전체 DNS를 전역 Merge에 넣어 임시로 우회했지만, 공식 문서에 따르면 확장 설정은 우선순위에 따라 구독을 덮어씁니다. 다른 사람의 DNS나 규칙 전체를 그대로 복사하면 자신의 로컬 네트워크, 회사 DNS 및 노드 이름 해석 정책이 바뀔 수 있습니다. 이 글은 전역 Merge 주입을 일반적인 해결책으로 권하지 않습니다. 조직에서 관리하는 기기이거나 설정을 중앙에서 배포받는다면 관리 담당자에게 먼저 문의하고 관리 대상 설정을 임의로 수정하지 마세요.
시스템 프록시와 TUN에서 도메인에 접속되고 재시작 후에도 정상인지 확인하기
먼저 다시 생성된 실행 설정의 dns.enable과 nameserver가 원본 구독 또는 확장 설정에서 예상한 값과 일치하는지 확인하세요. 화면의 DNS 재정의 스위치만 봐서는 안 됩니다. 다음으로 같은 Profile과 노드를 고정한 채 시스템 프록시 모드와 TUN 모드에서 동일한 실제 HTTPS 사이트를 요청하고, 연결 기록과 로그에서 이름 해석 성공 여부를 확인하세요.
앱을 완전히 종료했다가 다시 시작해 TUN 테스트를 반복하세요. 이번 세션에서만 효과가 있다면 재시작할 때 다른 설정 출처가 값을 다시 기록하고 있을 수 있습니다. TUN을 끈 뒤에는 Mac 전체를 재부팅하지 않아도 일반 네트워크가 복구되는지 확인하세요.
DNS 검사 페이지에 특정 주소가 표시되거나 TUN 스위치가 켜져 있거나 지연 시간 테스트에 숫자가 나온다는 것만으로 성공을 판단하지 마세요. 실제 대상 도메인이 해석되고 웹페이지가 끝까지 로드되며 연결 기록이 예상과 일치하고 재시작 후에도 유지돼야 복구를 확인할 수 있습니다.
문제가 계속되면 되돌리고 상위 프로젝트에 보고하는 방법
잔여 항목을 제거한 뒤 설정 검증에 실패하거나 기존 분기가 바뀌거나 TUN에서 여전히 연결이 끊긴다면 TUN을 먼저 끄고 수정 전 백업해 둔 기본 config.yaml을 복원한 다음 앱을 다시 시작하세요. 이전 설정은 이번 DNS 문제를 다시 일으킬 수 있으므로 복원 목적은 원래 설정과 증거를 보존하는 데 있습니다. 임시 인터넷 연결에는 검증된 시스템 프록시나 DNS를 인계받지 않는 일반 네트워크를 사용하세요.
실행 설정에 완전한 DNS가 있는데도 도메인 접속이 실패한다면 nameserver 자체에 도달할 수 있는지, 현재 네트워크에 회사 DNS가 있는지, 다른 VPN/TUN이 실행 중인지, 코어의 첫 오류가 무엇인지 별도로 확인하세요. 오류를 없애려고 시스템 보안 기능을 끄거나 모든 Profile을 비우거나 앱 데이터 폴더 전체를 삭제하거나 공용 DNS를 무작위로 바꾸지 마세요.
#8122에 제보할 때는 macOS, Clash Verge Rev, Mihomo 버전과 TUN/시스템 프록시 비교 결과, 세 설정 파일의 dns 관련 부분에서 민감 정보를 가린 발췌본, 재시작 전후 결과를 제공하세요. 제보자의 설명과 프로젝트 구성원의 잔여 설정 진단을 구분해 적어야 합니다. 현재 모든 유사한 연결 끊김이 해결됐다고 보장할 수 있는 정식 버전 공지는 없습니다.
참고 자료
- Clash Verge RevClash Verge Rev macOS TUN 및 DNS 잔여 설정 논의 #8122
- Clash Verge RevClash Verge Rev 프로젝트 구성원의 기본 설정 잔여 항목 진단과 처리 방법
- Clash Verge Rev DocsClash Verge Rev 확장 설정, DNS 재정의 및 앱 설정 우선순위
- Mihomo WikiMihomo DNS의 enable과 nameserver 필드
- Mihomo WikiMihomo TUN의 dns-hijack 설정
- Clash Verge Revv2.5.8 구독 페이지의 실행 설정 보기 기능
- Clash Verge Revv2.5.8 읽기 전용 실행 설정 뷰어
- Clash Verge Revv2.5.8 구독 원본 파일을 보는 우클릭 메뉴
