이 글의 목차
로그에서 TUN 루프백 폭주가 발생하는지 확인
이 글은 명확한 Windows 증상 한 가지를 다룹니다. Clash Verge Rev의 시스템 프록시는 정상인데 TUN을 켜면 로그에 reject loopback connection이 연속으로 표시되고 verge-mihomo.exe가 노드 연결을 반복해서 실패하며 CPU 사용량이 크게 증가합니다. 심한 경우 코어에 thread exhaustion이 발생해 충돌합니다.
공식 issue #7764에는 서비스 모드, Clash Verge Rev v2.5.2 및 Mihomo v1.19.29, v1.19.30에서 발생한 이 장애 흐름이 기록되어 있습니다. 제보자는 자동 감지가 v2rayN의 Wintun 가상 네트워크 어댑터를 선택했음을 최종 확인했습니다. 실제 이더넷 인터페이스를 직접 고정한 뒤 루프백 로그, CPU 이상 및 스레드 고갈이 모두 멈췄습니다.
이는 여러 가상 네트워크 어댑터가 설치된 컴퓨터에서 확인된 완결된 결과이며 모든 TUN 시간 초과의 원인이 인터페이스 선택이라는 뜻은 아닙니다. 로그에 reject loopback이 없거나 TUN을 끈 뒤에도 시스템 프록시가 실패한다면 구독, 노드, DNS 또는 서비스 모드를 먼저 점검하세요.
세 가지 신호로 문제 범위 제한
| 신호 | 이 문제에서 나타나는 증상 | 일치하지 않을 때 |
|---|---|---|
| 트리거 작업 | TUN을 켠 뒤 몇 초 이내에 시작 | 시스템 프록시도 실패하면 공통 경로부터 확인 |
| 주요 로그 | verge-mihomo.exe가 노드 연결을 시도하며 reject loopback을 반복 | 일반 앱의 시간 초과만으로는 같은 장애로 볼 수 없음 |
| 자원 변화 | CPU가 빠르게 상승하며 thread exhaustion이 발생할 수 있음 | 자원이 안정적이면 첫 오류를 기준으로 계속 분기 |
- verge-mihomo.exe현재 프록시 노드로 아웃바운드 연결 시도
- 잘못 선택된 가상 네트워크 어댑터auto-detect-interface가 실제 물리 아웃바운드를 사용하지 않음
- Mihomo TUN코어 자체의 연결이 TUN에 다시 진입
- 루프백 감지 및 재시도reject loopback이 계속되고 CPU 및 스레드가 빠르게 증가
아웃바운드 인터페이스를 현재 기본 라우트가 사용하는 물리 네트워크 어댑터로 고정하면 코어의 연결이 자체 TUN으로 돌아오지 않습니다. 루프백 로그와 자원 폭주가 함께 멈춰야 합니다.
TUN을 끄고 컴퓨터부터 안정화
로그가 빠르게 반복되면 TUN부터 끄세요. 동시에 노드를 바꾸거나 DNS를 수정하거나 코어를 반복해서 다시 불러오지 않습니다. CPU가 내려간 뒤 기존 Profile과 노드에서 시스템 프록시만 켜고 웹페이지에 한 번 접속하세요. 시스템 프록시가 복구되면 구독과 노드는 사용할 수 있는 기반이 남아 있으며 장애 범위는 TUN 아웃바운드 선택에 더 가깝습니다.
화면이 이미 멈췄다면 작업 관리자에서 Clash Verge Rev를 정상 종료한 뒤 Windows 시스템 프록시가 중지된 로컬 포트를 계속 가리키지 않는지 확인하세요. 직접 연결을 복원한 뒤 앱 로그, 현재 실행 구성 및 네트워크 어댑터 목록을 내보냅니다. 구성 사본에서는 구독 token, 노드 주소 및 비밀번호를 제거해야 합니다.
롤백 가능한 문제 해결 기준선 만들기
TUN 끄기
새 루프백 연결 시도를 중지하고 CPU와 로그 쓰기가 정상으로 돌아올 때까지 기다립니다.
시스템 프록시 검증
기존 Profile과 노드를 그대로 두고 시스템 프록시만 켜서 새 요청을 한 번 보냅니다.
현재 Merge 저장
사용 중인 덮어쓰기와 최종 구성을 복사하고 이후에는 아웃바운드 인터페이스 필드 두 개만 수정합니다.
첫 로그 구간 보존
클라이언트, 코어 및 Windows 버전과 첫 reject loopback 전후의 민감 정보를 제거한 내용을 기록합니다.
현재 실제로 인터넷에 연결된 물리 네트워크 어댑터 확인
TUN을 끈 상태에서 PowerShell로 표시되는 네트워크 어댑터와 IPv4 기본 라우트를 함께 확인합니다. Get-NetAdapter의 Name은 이후 입력할 인터페이스 이름이며 Get-NetRoute는 현재 어느 네트워크 어댑터가 기본 아웃바운드를 담당하는지 보여줍니다. 무선 네트워크 이름은 Wi-Fi일 수 있고 유선 네트워크는 이더넷 또는 Ethernet일 수 있으므로 반드시 현재 시스템의 결과를 사용하세요.
Get-NetAdapter -Name * |
Format-Table Name, InterfaceDescription, Status, LinkSpeed, ifIndex
Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
Sort-Object RouteMetric |
Format-Table InterfaceAlias, NextHop, RouteMetric, InterfaceMetric결과에서 잘못된 후보 제외
| 결과 | 판단 |
|---|---|
| Status가 Up이고 기본 라우트에서 같은 InterfaceAlias를 사용함 | 현재 실제 아웃바운드의 우선 후보 |
| 이름 또는 설명에 Wintun, TAP, VMware, VirtualBox가 포함됨 | 가상 어댑터라면 LinkSpeed만 보고 선택하면 안 됨 |
| 네트워크 어댑터는 Up이지만 현재 기본 라우트가 없음 | 가상 머신, VPN 또는 LAN 전용일 수 있음 |
| Wi-Fi와 이더넷에 기본 라우트가 모두 있음 | 사용하지 않는 연결을 먼저 끊고 실제 아웃바운드를 다시 확인 |
자동 선택 결과와 기본 라우트 비교
앞서 저장한 실행 구성과 이번 시작 로그를 열어 auto-detect-interface가 활성화되어 있는지 확인하고 Mihomo가 실제 사용한 아웃바운드 인터페이스를 찾으세요. 시스템 기본 라우트는 물리 Wi-Fi 또는 이더넷인데 로그에서 노드 연결이 Wintun, TAP 또는 VMware 인터페이스에 바인딩되었다고 표시될 때만 공식 issue의 원인과 일치합니다.
가상 네트워크 어댑터의 명목상 고속 전송률을 기준으로 판단하지 마세요. #7764 환경에서 vgate0은 100 Gbps를 보고했고 자동 감지는 이 때문에 잘못된 아웃바운드를 선택했습니다. 인터페이스 증거가 일치한 뒤 덮어쓰기를 추가하세요. 선택 결과를 찾을 수 없다면 이름을 추측하지 말고 네트워크 어댑터 목록과 첫 로그 구간을 프로젝트 관리자에게 제출할 수 있습니다.
기본 라우트는 이더넷이지만 실행 로그에서는 vgate0을 사용
인터페이스 오선택과 일치하므로 최소 덮어쓰기 진행
기본 라우트와 Mihomo가 같은 물리 네트워크 어댑터를 사용
알려진 원인과 일치하지 않으므로 이 글의 구성 적용 중단
로그에 dns resolve failed만 있음
DNS 경로부터 점검하고 reject loopback으로 판단하지 않음
다른 VPN을 끈 뒤 장애가 사라짐
충돌 소프트웨어와 네트워크 어댑터를 기록하고 인터페이스는 고정하지 않아도 됨
Merge에서 아웃바운드 인터페이스만 고정
Mihomo 공식 구성에서 interface-name은 최상위 아웃바운드 인터페이스로 정의되고 auto-detect-interface는 tun 아래에 배치됩니다. 현재 Profile의 Merge 또는 덮어쓰기를 열어 이 두 필드만 추가하세요. issue의 TUN 및 DNS 구성 전체를 복사하거나 물리 네트워크 어댑터 이름을 tun.device에 입력하지 마세요.
interface-name: "以太网"
tun:
auto-detect-interface: false변경 범위를 최소로 유지
인터페이스 이름이 완전히 일치하는지 확인
공백, 하이픈 및 언어까지 일치해야 하며 InterfaceDescription을 Name 대신 사용하지 않습니다.
저장하고 구성 검증 실행
interface-name은 최상위에 있고 auto-detect-interface는 tun 아래에서 공백 두 칸으로 들여씁니다.
다른 필드는 그대로 유지
기존 노드, 규칙, DNS, stack 및 strict-route를 계속 사용해 두 번째 변수를 한 번에 추가하지 않도록 합니다.
코어 완전히 다시 시작
새 실행 구성에 덮어쓰기 값 두 개가 포함되었는지 확인한 뒤 통제된 TUN 테스트를 한 번 실행합니다.
한 번의 통제된 테스트로 인터페이스 수정 검증
코어를 다시 시작한 뒤 로그를 먼저 열고 TUN을 켜세요. 테스트 창을 보이게 유지하고 일반 HTTPS 요청을 하나 보냅니다. reject loopback이 다시 빠르게 반복되면 즉시 TUN을 끄세요. 실제 수정은 로그, CPU, 코어 실행 상태 및 실제 연결을 모두 바꿔야 하며 TUN 스위치가 켜진 상태로 유지되는지만 보면 안 됩니다.
공식 issue 제보자는 물리 이더넷을 고정한 뒤 루프백 폭주가 완전히 사라지고 CPU가 정상으로 돌아왔으며 v1.19.29와 v1.19.30 모두 스레드 고갈이 더 이상 발생하지 않음을 확인했습니다. 이후 업스트림 issue #3122는 Mihomo 코어 변경이 필요하지 않다는 결론으로 종료되었으므로 이 사례를 새 코어 버전에서 수정된 문제라고 설명하면 안 됩니다.
인터페이스 수정 완료 기준
- TUN을 켠 뒤 새 reject loopback connection이 더 이상 표시되지 않음
- 작업 관리자의 verge-mihomo.exe CPU 사용량이 안정적으로 유지됨
- 코어가 계속 실행되고 thread exhaustion 또는 반복 reload가 없음
- 같은 노드로 새 HTTPS 요청을 한 번 완료하고 연결 기록에 표시됨
- TUN을 끈 뒤 시스템 직접 연결이 즉시 복구됨
루프백이 사라진 뒤 남은 DNS 오류는 별도로 처리
#7764에서는 인터페이스 문제를 해결한 뒤 별도의 DNS 구성 오류도 드러났으며 그중 하나는 DoH 도메인의 부트스트랩 루프에서 발생했습니다. 관리자도 제보자의 proxy-server-nameserver 관련 초기 판단을 바로잡았습니다. issue의 DoT, nameserver-policy 또는 DNS 예제 전체를 자체 구성에 복사하지 마세요.
reject loopback이 사라지고 CPU도 정상인데 웹페이지에 계속 dns resolve failed가 표시된다면 검증된 인터페이스 덮어쓰기는 유지하고 같은 노드에서 도메인 조회와 직접 접속을 비교하세요. DNS 증거가 명확할 때만 해당 업스트림이나 정책을 바꿔 분리된 두 장애가 다시 섞이지 않도록 합니다.
인터페이스 수정 후의 다음 오류
| 증상 | 처리 |
|---|---|
| 연결 기록에 도메인이 있고 노드 연결이 정상임 | 인터페이스 문제가 해결되었으므로 실제 서비스 계속 검증 |
| dns resolve failed만 있음 | DNS 업스트림, 부트스트랩 및 proxy-server-nameserver 확인 |
| reject loopback이 계속됨 | TUN을 끄고 실제 인터페이스 이름과 실행 구성 다시 확인 |
| 구성 검증 실패 | 덮어쓰기를 되돌리고 최상위 필드와 YAML 들여쓰기 확인 |
네트워크를 전환한 뒤 인터페이스를 갱신하고, 작동하지 않으면 완전히 롤백
자동 감지를 끄면 Mihomo는 직접 지정한 네트워크 어댑터를 계속 사용합니다. 유선 연결에서 Wi-Fi, 모바일 핫스팟 또는 USB 네트워크 어댑터로 전환하면 이전 인터페이스가 더 이상 기본 라우트를 담당하지 않을 수 있습니다. 네트워크를 바꾼 뒤 TUN이 다시 실패하면 TUN을 끄고 읽기 전용 확인을 반복하세요. 이전 인터페이스 이름을 모든 네트워크 환경에 영구적으로 남기지 않습니다.
덮어쓰기가 작동하지 않으면 원래 상태로 복원
TUN 끄기
Windows 직접 연결이 복구되었는지 확인한 뒤 Merge를 편집합니다.
두 필드 제거
최상위 interface-name과 이번에 추가한 tun.auto-detect-interface를 삭제합니다.
원래 Profile 다시 불러오기
시스템 프록시로 기존 구독, 노드 및 규칙이 계속 작동하는지 확인합니다.
민감 정보를 제거한 증거 보존
실제 네트워크 어댑터 목록, 첫 오류 및 실행 구성 차이를 제출하고 구독과 노드 자격 증명은 공개하지 않습니다.
여섯 가지 점검으로 Windows TUN 복구 확인
최종 검증 체크리스트
- 시스템 프록시를 사용할 수 있고 TUN을 켠 뒤에도 기존 요청이 정상적으로 완료됨
- 새 로그에 reject loopback, thread exhaustion 또는 코어 교체 루프가 없음
- 실행 구성의 interface-name이 현재 기본 라우트 인터페이스와 일치함
- 작업 관리자에서 일정 시간 관찰한 뒤에도 CPU와 스레드가 계속 증가하지 않음
- 노드를 전환하거나 새 연결을 시작할 때 연결 페이지에 예상한 규칙과 아웃바운드가 표시됨
- TUN을 끄고 클라이언트를 종료한 뒤 Windows의 일반 네트워크가 복구됨