이 글의 목차
시스템 프록시는 앱이 트래픽을 직접 전달하고 TUN은 시스템 네트워크 계층에서 트래픽을 받습니다
시스템 프록시를 켜면 Clash가 로컬 프록시 주소를 운영체제에 기록하고 이 설정을 읽는 앱이 HTTP, HTTPS 요청을 해당 포트로 보냅니다. 브라우저는 보통 사용하지만 터미널 도구, 게임, 일부 데스크톱 앱은 사용하지 않을 수 있습니다. 시스템 프록시만으로 UDP 전체를 통합해서 제어할 수도 없습니다.
TUN은 가상 네트워크 어댑터를 만들고 시스템 경로를 통해 더 많은 TCP, UDP 연결을 Mihomo에 넣습니다. "이 프로세스가 로컬 프록시 포트를 사용하지 않음"을 해결하지만 노드 사용 가능성, 규칙 순서 또는 서버의 403 응답은 바꾸지 않습니다.
두 진입점의 핵심 차이
| 항목 | 시스템 프록시 | TUN |
|---|---|---|
| Clash 진입 여부를 결정하는 요소 | 앱의 시스템 설정 읽기 여부 | 시스템 경로와 가상 네트워크 어댑터 |
| UDP | 보통 제어하지 않음 | TUN에 들어올 수 있지만 노드와 설정에 따라 달라짐 |
| 시스템 권한 | 프록시 설정 수정 | 가상 네트워크 어댑터, 서비스 또는 네트워크 확장 권한도 필요 |
| 롤백 | 프록시 스위치를 끄면 됨 | TUN을 끄고 경로와 인터페이스가 철회될 때까지 대기 |
- 앱에서 연결 시작브라우저, 터미널, 게임 또는 백그라운드 서비스
- 시스템 프록시 또는 TUN트래픽의 커널 진입 여부 결정
- 규칙 및 DNS도메인을 보존하고 직접 연결 또는 프록시 결정
- 실제 출구DIRECT, 프록시 노드 또는 거부
진입점은 트래픽을 받아들일 뿐입니다. 실제 출구는 규칙, DNS 결과, 정책 그룹이 함께 결정합니다.
진입점은 원래 실패한 프로그램이 연결 기록에 나타나는지만 보고 판단하세요
같은 동작으로 전후 비교
Profile, Rule 모드, 노드 고정
자동 전환 또는 설정 업데이트가 진입점 시험을 방해하지 않게 합니다.
시스템 프록시만 켜기
대상 프로그램에서 고정 동작 하나를 반복합니다.
Connections 확인
요청이 이미 나타난다면 진입점은 빠지지 않았으므로 규칙과 로그를 계속 읽습니다.
기록이 없을 때만 TUN 켜기
같은 동작을 다시 수행하고 새 연결이 생기는지 비교합니다.
TUN을 켠 뒤 새 연결이 나타나 성공하면 제어 범위를 보완한 것입니다. 두 진입점에서 모두 요청이 보이지만 똑같이 timeout이면 진입점을 계속 바꾸지 말고 노드, DNS 또는 대상 네트워크를 확인해야 합니다.
auto-route, interface, stack이 함께 데이터의 가상 네트워크 어댑터 통과 방식을 결정합니다
Mihomo의 auto-route는 트래픽을 TUN으로 라우팅하고 auto-detect-interface는 실제 출구 네트워크 어댑터를 식별합니다. stack에는 system, gvisor, mixed 같은 구현을 선택할 수 있습니다. 기본값으로 대상 앱을 처리할 수 있다면 "더 빠르게" 만들려고 임의로 바꿀 필요는 없습니다.
Wi-Fi에서 핫스폿으로 전환한 뒤 갑자기 인터넷이 끊겼다면 출구 네트워크 어댑터 변경이 원인일 수 있습니다. 특정 컴퓨터에서 system 또는 mixed만 방화벽에 차단될 때 커널 프로세스의 방화벽을 조정하세요. Windows의 strict-route는 VirtualBox 같은 가상 네트워크에도 영향을 줄 수 있으므로 가상 머신 사용 시 별도로 검증해야 합니다.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53DNS 덮어쓰기는 이름 해석 요청을 같은 판단 경로에 넣어야 합니다
앱은 먼저 도메인 이름을 주소로 해석한 뒤 연결합니다. DNS 요청이 Mihomo를 우회하면 커널에 IP만 보여 도메인 규칙이 예상대로 동작하지 않을 수 있습니다. 프록시 출구와 맞지 않는 이름 해석 결과를 받아 홈 화면은 열리지만 이미지가 실패하거나 같은 서비스가 간헐적으로 작동할 수도 있습니다.
dns-hijack은 일치하는 DNS 트래픽을 Mihomo 내부 DNS에 전달합니다. 모든 시스템과 출처에서 자동으로 적용되는 것은 아닙니다. Windows와 macOS는 LAN의 다른 기기 DNS를 자동으로 가로챌 수 없으므로 라우터나 휴대전화의 요청은 별도로 설정해야 합니다. Android 비공개 DNS도 일반 가로채기 경로를 우회합니다.
- Connections에 도메인이 있고 규칙이 올바름
- DNS와 스니핑이 규칙 판단에 사용할 정보를 제공했습니다.
- IP만 보이고 도메인 규칙이 적용되지 않음
- DNS가 Mihomo에 들어오는지와 앱이 암호화 DNS를 사용하는지 확인하세요.
- IP로는 접근하지만 도메인 이름 해석 오류가 남
- 시스템 DNS, Mihomo DNS, 현재 네트워크를 중점적으로 비교하세요.
Fake-IP는 도메인 관계를 보존하며 저절로 속도를 높이지 않습니다
fake-ip 모드에서 Mihomo는 앱에 예약 주소를 먼저 반환하고 내부에 "이 가짜 주소가 어느 도메인에 대응하는지"를 저장합니다. 앱이 해당 주소에 연결하면 커널이 원래 도메인을 복원해 더 이른 단계에서 DOMAIN, DOMAIN-SUFFIX, RULE-SET을 판단할 수 있습니다.
이 방식이 DNS를 자동으로 빠르게 만들거나 원격 노드 품질을 바꾸지는 않습니다. 일부 LAN 서비스, 기기 검색, 기업용 소프트웨어 또는 IP를 직접 검증하는 프로그램은 호환되지 않을 수 있습니다. 구체적인 도메인을 fake-ip-filter에 넣거나 검증 후 다른 DNS 강화 모드를 선택하세요.
Fake-IP에서 흔한 결과
| 동작 | 설명 |
|---|---|
| 시스템 조회에서 예약 주소를 받음 | 정상적인 fake-ip 매핑일 수 있으며 도메인이 가로채였다는 뜻은 아님 |
| Connections에 원래 도메인이 표시됨 | 매핑으로 커널이 도메인 규칙에 따라 판단할 수 있음 |
| 특정 내부 도메인이 fake-ip에서 실패함 | 정확한 도메인을 제외하고 내부 DNS로 이름 해석 |
| 모든 웹사이트가 느림 | fake-ip만으로 결론 내리지 말고 노드, DNS 상위 서버, 로그를 계속 확인 |
실제 IP가 필요한 앱에는 redir-host 또는 정확한 Fake-IP 예외를 사용하세요
일부 기업용 소프트웨어, LAN 서비스 또는 기기 검색 기능은 DNS가 반환한 실제 주소를 직접 사용하므로 Fake-IP에 적합하지 않습니다. 전체 설정에서 redir-host를 사용하거나 명확히 호환되지 않는 도메인만 fake-ip-filter에 넣을 수 있습니다. 전자는 모든 도메인의 이름 해석 방식을 바꾸고 후자는 영향 범위가 더 작습니다.
redir-host는 일반 DNS에 가깝고 앱이 상위 서버의 실제 IP를 직접 받습니다. 대신 Mihomo가 Fake-IP만큼 이른 단계에서 도메인 매핑을 보존하지 못할 수 있고 도메인 규칙 식별도 클라이언트, 캐시, 스니핑 설정의 영향을 받습니다. 내부 도메인 하나가 실패했다고 사이트 전체를 전환하지 말고 단일 도메인 예외부터 적용하세요.
실제 IP가 필요할 때 선택 방법
| 상황 | 더 적합한 처리 | 검증 결과 |
|---|---|---|
| 기업 내부 도메인 하나만 실패함 | 정확한 fake-ip-filter에 추가하고 내부 DNS 사용 | 내부망 실제 IP를 반환하고 연결이 DIRECT에 맞음 |
| 특정 유형의 앱이 Fake-IP와 전반적으로 호환되지 않음 | redir-host로 별도 설정 비교 | 앱이 복원되고 공개 도메인 규칙도 계속 올바르게 적용됨 |
| NAS와 프린터가 고정 사설 IP 사용 | 사설 네트워크 범위 DIRECT 유지 | 접속이 더 이상 프록시 정책으로 우회되지 않음 |
| 호환되지 않는 도메인을 모름 | Connections와 DNS 로그에서 대상을 먼저 찾기 | 대상을 확인한 뒤 예외를 추가하고 광범위한 와일드카드를 사용하지 마세요 |
DNS 진단에서는 동일한 요청 하나를 유지하세요
도메인 문제가 생기면 노드와 요청을 고정하고 현재 enhanced-mode, 상위 DNS, 오류를 먼저 기록하세요. 변수 하나만 바꿔 비교합니다. 예를 들어 호환되지 않는 특정 내부 도메인을 fake-ip-filter에 넣거나 Android 비공개 DNS 상태를 잠시 전환하세요. 결과가 달라질 때만 해당 변경을 유지합니다.
no such host / DNS lookup failed
상위 DNS에 접근할 수 있는지와 요청이 Mihomo에 들어오는지 확인하세요.
LAN 도메인은 작동하지 않고 공개 도메인은 정상
내부 DNS 경로를 유지하고 정확한 도메인에 직접 연결 또는 Fake-IP 제외를 설정하세요.
네트워크를 전환한 뒤에만 이름 해석 오류가 생김
두 네트워크의 DNS, IPv6, 출구 인터페이스를 비교하고 모든 노드부터 바꾸지 마세요.
도메인 규칙이 항상 MATCH로 표시됨
커널이 도메인을 받았는지와 더 넓은 규칙이 먼저 일치했는지 확인하세요.
브라우저 사용자는 시스템 프록시부터 시작하고 UDP 또는 누락 트래픽이 필요할 때 TUN을 사용하세요
사용 환경에 맞춰 선택
| 사용 상황 | 권장 시작점 | 이유 |
|---|---|---|
| 주로 웹과 시스템 프록시를 따르는 데스크톱 소프트웨어 사용 | 시스템 프록시 | 권한이 적고 끄기 쉬우며 연결 경로가 명확함 |
| 터미널과 게임 런처가 Connections에 나타나지 않음 | 앱 프록시 또는 TUN 비교 | 시스템 프록시를 읽지 않는 프로세스 보완 |
| UDP 처리가 필요한 앱 | TUN | 시스템 프록시는 UDP 전체를 통합해서 제어할 수 없음 |
| 기업 내부망, 가상 머신, 복잡한 LAN | 시스템 프록시부터 시작 | 기존 경로를 먼저 유지하고 TUN 제외 범위를 하나씩 검증 |
| 특정 도메인 규칙이 잘못된 출구를 사용함 | 기존 진입점 중 하나 + 규칙 수정 | 진입점을 넓혀도 처음 일치한 규칙은 바뀌지 않음 |
선택은 영구적이지 않습니다. 브라우저만 필요할 때는 TUN을 끄고 시스템 프록시로 돌아가며 특정 프로그램이 필요할 때 다시 켤 수 있습니다. 전환 후에는 스위치 색상만 보지 말고 원래 대상 동작과 Connections로 검증하세요.
인터넷이 끊기면 TUN, DNS, 시스템 프록시 순서로 되돌리세요
TUN을 켜자마자 모든 연결이 끊기면 TUN부터 끄고 기존 Profile과 노드를 유지하세요. 시스템 프록시가 복원되면 가상 네트워크 어댑터, 경로 또는 TUN DNS의 문제입니다. 시스템 프록시도 실패하면 노드와 설정으로 돌아갑니다. 운영체제의 네트워크 재설정을 바로 사용하지 마세요. 관련 없는 설정까지 더 많이 지웁니다.
클라이언트를 닫은 뒤에도 웹페이지가 열리지 않으면 시스템 프록시가 127.0.0.1의 기존 포트에 남았는지 확인하세요. 잔여 값을 지우면 직접 연결이 복원되어야 합니다. 선택 결과는 구체적이어야 합니다. 시스템 프록시는 브라우저를 담당하고 TUN은 기존에 빠진 프로세스를 받으며 DNS 모드는 대상 도메인이 예상 규칙에 안정적으로 맞게 합니다. 필요한 결과를 만들지 못하는 계층은 장기간 유지하지 마세요.