이 글의 목차
이 로그 조합이 있을 때만 외부 인터페이스 고정
이 글은 매우 구체적인 장애를 다룹니다. Intel Mac을 iPhone 개인용 핫스팟에 연결하면 시스템 직접 연결은 정상이지만 Clash Verge Rev에서 TUN을 켜면 인터넷을 사용할 수 없는 경우입니다. 공식 issue #7576의 환경은 클라이언트 v2.5.2와 Mihomo v1.19.29이며 다른 Mac에서도 같은 로그가 나타날 때만 이 방법을 적용할 수 있습니다.
핵심은 웹페이지의 시간 초과가 아닙니다. TUN 시작 직후 get empty name, <invalid>, interface not found가 차례로 나타난 뒤 dns resolve failed가 표시되는 것이 중요합니다. 자동으로 외부 경로를 감지할 때 빈 인터페이스를 먼저 받아 DNS와 프록시 연결에 사용할 외부 경로가 없다는 뜻입니다.
같은 문제인지 먼저 확인
| 증상 | 판단 | 다음 단계 |
|---|---|---|
| TUN을 끄면 시스템 직접 연결이 즉시 복구됨 | 노드와 시스템 네트워크가 함께 작동하지 않는 상황은 아님 | 외부 인터페이스 계속 확인 |
| 로그에 get empty name 또는 <invalid>가 먼저 나타남 | 자동 감지가 외부 경로를 제때 얻지 못함 | 현재 물리 네트워크 인터페이스 조회 |
| 로그에는 operation not permitted만 있음 | 권한 또는 서비스 모드 문제 | 외부 인터페이스를 수정하지 마세요 |
| 시스템 프록시와 TUN이 모두 연결되지 않음 | 노드, 구독 또는 코어 장애일 수 있음 | 공통 장애부터 처리 |
- iPhone 개인용 핫스팟Mac에 현재 네트워크 외부 경로 제공
- macOS 물리 네트워크 인터페이스route 명령에 실제 interface 표시
- Mihomo TUN해당 인터페이스로 DNS 및 연결 전송
- 대상 웹사이트이름 해석, 규칙 일치와 접속 완료
자동 감지가 두 번째 단계에서 빈 값을 얻으면 이후 DNS와 외부 연결이 모두 실패합니다. 인터페이스 고정은 이 로그 특성이 있을 때만 적용됩니다.
시스템 경로에서 핫스팟이 사용하는 네트워크 인터페이스 확인
TUN을 먼저 끄고 macOS가 직접 연결할 수 있는 상태로 돌아간 뒤 터미널에서 공용 주소의 경로를 조회합니다. 명령 출력의 interface가 현재 핫스팟 트래픽을 실제로 전달하는 물리 네트워크 인터페이스입니다. 다른 사람의 화면만 보고 이름을 추측하지 마세요.
route -n get 223.5.5.5현재 기기의 실제 결과만 기록
직접 연결 가능 여부 확인
TUN과 시스템 프록시를 끄고 브라우저에서 일반 웹페이지를 열어 장애 상태의 경로를 읽지 않도록 합니다.
interface 줄 찾기
issue 제보자의 결과는 en0이었지만 Wi-Fi, USB 네트워크 인터페이스와 이더넷은 다른 이름을 받을 수 있습니다.
한 번 더 실행
모바일 핫스팟 연결을 끊었다가 다시 연결한 뒤 재조회하고 인터페이스 이름이 바뀌지 않았는지 확인한 다음 덮어쓰기에 기록합니다.
Merge에서 필드 두 개만 덮어쓰기
Mihomo의 interface-name은 최상위 외부 인터페이스이고 auto-detect-interface는 tun 아래에 둡니다. 현재 Profile의 Merge 또는 덮어쓰기 구성을 열어 이 두 키만 추가하세요. issue의 TUN, DNS 또는 IPv6 구성 전체를 복사해 기존에 작동하던 설정까지 바꾸면 안 됩니다.
interface-name: en0
tun:
auto-detect-interface: false여기서 en0은 예시일 뿐입니다. tun.device에 쓰지 마세요. 공식 문서에 따르면 macOS의 TUN 기기 이름은 utun으로 시작하지만 interface-name은 Mihomo가 실제로 외부로 트래픽을 보내는 인터페이스를 가리킵니다. 두 필드의 용도가 다릅니다.
코어 재시작 후 로그를 먼저 확인하고 DNS와 웹페이지 테스트
덮어쓰기를 저장하고 구성 검증을 통과한 뒤 코어를 완전히 한 번 재시작하고 TUN을 켭니다. 스위치 색만 보지 말고 새 로그를 먼저 확인하세요. 인터페이스 오류가 사라지면 새 DNS 조회와 HTTPS 접속을 한 번 실행합니다.
같은 순서로 검증
현재 구성 리로드
기존 Profile과 노드가 계속 선택되어 있는지 확인하고 구독, DNS 또는 프록시 모드를 동시에 바꾸지 않습니다.
TUN 다시 켜기
이번 시작 지점부터 로그를 읽어 <invalid> 또는 interface not found가 계속 나타나는지 확인합니다.
두 종류의 요청 실행
일반 웹페이지를 먼저 열고 연결 페이지에 해당 도메인, 규칙과 실제 외부 경로가 나타나는지 확인합니다.
TUN을 끄고 비교
시스템 직접 연결이 계속 복구되는지 확인해 캐시 적중 한 번을 수정 완료로 오인하지 않도록 합니다.
빈 인터페이스와 interface not found가 모두 사라지고 웹페이지 복구
인터페이스 고정으로 이번 자동 감지 실패를 피했으므로 네트워크 전환 검증을 계속 완료합니다.
interface not found가 계속 표시됨
인터페이스 이름이 잘못되었거나 이미 바뀌었습니다. TUN을 끈 뒤 시스템 경로를 다시 조회하세요.
인터페이스 오류는 사라졌지만 dns resolve failed는 계속 발생
DNS 필드를 더 추가하지 말고 덮어쓰기를 취소한 뒤 별도 DNS 문제로 점검합니다.
구성 검증 실패
interface-name이 최상위에 있는지, tun 아래 들여쓰기가 공백 두 칸인지 확인합니다.
인터페이스를 고정했다면 네트워크를 전환할 때 다시 확인
인터페이스를 수동으로 지정하면 자동 감지가 중지됩니다. 모바일 핫스팟 환경을 임시로 안정화하는 데 적합하지만 핫스팟에서 가정용 Wi-Fi, USB 네트워크 또는 이더넷으로 전환하면 기존 인터페이스가 더 이상 기본 외부 경로가 아닐 수 있습니다. 업데이트를 잊으면 TUN은 켜져 있지만 새 연결을 만들 수 없는 현상이 다시 나타납니다.
네트워크 변경 후 처리
| 조회 결과 | 처리 |
|---|---|
| interface와 덮어쓰기 값이 같음 | 현재 설정을 유지하고 DNS와 웹페이지를 다시 테스트 |
| interface가 다른 이름으로 바뀜 | TUN을 끄고 interface-name을 업데이트한 뒤 코어 재시작 |
| 앞으로 네트워크를 자주 전환해야 함 | 고정 인터페이스 덮어쓰기를 삭제하고 자동 감지를 복원한 뒤 문제가 재현되는지 관찰 |
| 다른 VPN 또는 TUN을 동시에 실행 중 | 각각 끈 상태로 먼저 테스트하고 고정 값 하나로 경로 충돌을 숨기지 않음 |
효과가 없으면 덮어쓰기를 삭제하고 기존 구성으로 복귀
올바른 인터페이스를 고정해도 계속 실패한다면 현재 장애 원인이 자동 감지만은 아닙니다. 출처가 불분명한 DNS, 경로 또는 스크립트 설정을 계속 추가하지 말고 수정 전 Profile로 먼저 돌아가세요.
전체 롤백 순서
TUN 끄기
시스템의 일반 네트워크가 복구될 때까지 기다린 뒤 Merge를 수정해 기존 코어가 장애 경로를 계속 점유하지 않도록 합니다.
덮어쓰기 키 두 개 삭제
최상위 interface-name과 이번에 추가한 tun.auto-detect-interface를 제거해 수정 전 내용으로 복원합니다.
원래 Profile 다시 불러오기
기존 노드와 규칙을 유지한 채 시스템 프록시로 한 번 접속해 기본 연결이 계속 가능한지 확인합니다.
민감 정보를 제거한 로그 보존
macOS, 클라이언트와 코어 버전, TUN을 켠 뒤의 첫 오류를 기록해 해당 공식 issue에 제출합니다.
다섯 가지 점검으로 핫스팟 환경의 TUN 복구 확인
최종 검증 체크리스트
- 시스템 프록시를 끄고 TUN만 켜도 브라우저와 터미널에서 새 연결을 만들 수 있음
- 로그에 get empty name, <invalid> 또는 interface not found가 더 이상 나타나지 않음
- 연결 페이지에서 예상한 도메인, 규칙과 프록시 또는 직접 연결 외부 경로를 확인할 수 있음
- 같은 핫스팟을 끊었다가 다시 연결해도 인터페이스 이름과 덮어쓰기가 일치함
- TUN을 끄면 Mac을 재시작하지 않아도 시스템 직접 연결이 즉시 복구됨