이 글의 목차
먼저 실행 모드, 시스템 프록시, TUN이 서로 다르다는 점을 구분하세요
현재 Mihomo 문서에 나오는 실행 모드는 Rule, Global, Direct이며 기본값은 Rule입니다. 이미 커널에 들어온 연결을 처리하고 이후에 규칙에 따라 라우팅할지, GLOBAL 정책 그룹에 모두 보낼지, 로컬 네트워크를 직접 사용할지 결정합니다.
시스템 프록시, TUN, 모바일 VPN은 트래픽이 커널에 들어오는 방식을 해결합니다. select, url-test, fallback은 정책 그룹의 출구 선택 방식을 다루고 fake-ip와 redir-host는 DNS 강화 모드입니다. 서로 다른 계층을 모두 "프록시 모드"라고 부르면 진단할 때 잘못된 옵션을 바꾸기 쉽습니다.
각 이름이 속하는 계층
| 계층 | 일반적인 옵션 | 실제 결정 항목 |
|---|---|---|
| 실행 모드 | Rule / Global / Direct | 커널에 들어온 연결이 최종적으로 사용할 출구 |
| 제어 방식 | System Proxy / TUN / 모바일 VPN | 커널에 들어올 수 있는 앱 또는 시스템 트래픽 |
| 정책 그룹 유형 | select / url-test / fallback | 정책 그룹 내부에서 노드 또는 다른 정책을 선택하는 방식 |
| DNS 강화 모드 | fake-ip / redir-host | 도메인 이름 해석 결과를 규칙과 연결 절차에 전달하는 방식 |
세 가지 실행 모드는 출구 결정을 바꾸며 노드 속도는 바꾸지 않습니다
Clash Verge Rev 같은 데스크톱 클라이언트에서는 주 화면의 "프록시 모드" 항목을 열거나 트레이 아이콘을 오른쪽 클릭해 Mode / 모드 하위 메뉴로 이동합니다. 모바일에서는 보통 홈 또는 Proxies / 프록시 페이지의 "모드" 행에 있습니다. 일상에서는 Rule을 먼저 사용하고 규칙 때문에 특정 웹사이트의 출구가 잘못되었는지 판단할 때만 잠시 Global 또는 Direct로 바꾸세요.
세 모드는 Clash에 들어온 같은 연결을 받지만 이후 출구 선택 방식이 다릅니다. Rule은 규칙을 위에서 아래로 비교하고 Global은 연결을 전역 정책 그룹에 전달하며 Direct는 로컬 네트워크를 직접 사용합니다. 노드 자체의 대역폭과 지연 시간은 바꾸지 않습니다.
클라이언트에서 실제 전환 한 번 수행
Mode / 프록시 모드 열기
주 화면 모드 항목이나 트레이 메뉴에서 들어가고 원격 YAML의 mode 필드를 수정하지 마세요.
Rule 선택
대상 웹페이지를 열고 Connections에서 현재 일치한 규칙과 출구를 기록합니다.
비교가 필요할 때 Global 또는 Direct 선택
같은 노드와 대상을 유지하고 모드만 바꾼 뒤 연결을 다시 만듭니다.
비교가 끝나면 Rule로 복귀
대상을 다시 요청해 새 연결이 규칙 기반 라우팅으로 복구되었는지 확인합니다.
모드별 실제 용도
| 모드 | 연결 경로 | 적합한 상황 |
|---|---|---|
| Rule | 처음 일치하는 적용 가능 규칙의 정책 실행 | 서비스별로 다른 출구를 쓰는 일상 환경 |
| Global | Clash에 들어온 모든 연결을 전역 그룹에 전달 | 규칙이 문제 원인인지 짧게 비교 |
| Direct | Clash에 들어온 모든 연결을 직접 연결 | 로컬 네트워크 검증 또는 프록시 일시 중단 |
모드는 이미 Clash에 들어온 트래픽에만 영향을 줍니다. 앱이 시스템 프록시를 전혀 읽지 않고 Connections에 기록도 없다면 Rule에서 Global로 바꿔도 갑자기 나타나지 않습니다. 시스템 프록시, 앱 프록시 또는 TUN부터 처리하세요.
Rule(규칙 모드): 처음 일치한 규칙으로 출구 결정
Rule은 Mihomo의 기본 실행 모드이며 직접 연결, 프록시, 거부, 여러 정책 그룹을 함께 쓰는 일상 환경에 적합합니다. 본래 "국내 직접 연결, 해외 프록시"를 뜻하지 않으며 실제 결과는 현재 설정의 rules, rule-providers와 순서에 따라 완전히 달라집니다.
Mihomo는 rules 맨 위에서 아래로 검사하고 요청이 첫 규칙에 맞으면 중단합니다. 프록시를 써야 할 도메인이 앞의 더 넓은 DIRECT 규칙에 먼저 맞으면 이후 규칙은 아무리 많아도 실행되지 않습니다. 목록 끝의 MATCH는 앞에서 일치하지 않은 연결을 처리하는 데 흔히 사용합니다.
Connections를 열어 방금 요청을 찾고 규칙 유형과 정책 그룹을 확인하세요. 인터페이스의 DOMAIN-SUFFIX, RULE-SET 또는 MATCH 표시로 어디서 결정되었는지 바로 알 수 있습니다. 감으로 모드를 반복해서 바꾸면 규칙 순서 문제를 오히려 찾기 어렵습니다.
rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,REJECT
- MATCH,DIRECT일상적으로 Rule을 사용할 때는 "이 연결에 어떤 규칙이 적용되었나"에 답할 수 있어야 합니다
실제 요청 하나 확인
Rule 모드 유지
주 정책 그룹에서 사용 가능함을 아는 노드 하나를 고정합니다.
대상 동작 다시 수행
같은 웹페이지를 열거나 같은 인터페이스를 새로 고치거나 같은 앱을 시작합니다.
Connections에서 해당 요청 찾기
도메인, 프로세스 또는 시각으로 방금 생긴 연결을 찾습니다.
규칙과 출구 읽기
DIRECT, REJECT 또는 특정 프록시 정책 그룹인지 확인합니다.
결과가 예상과 일치하면 Rule은 정상입니다. 특정 웹사이트가 실패할 때는 관련 규칙이나 정책 그룹만 수정하고 연결 하나 때문에 사이트 전체를 Global로 바꾸지 마세요.
Global(전역 모드): 제어 중인 연결을 GLOBAL 그룹에 전달
Global은 Mihomo에 이미 들어온 연결만 바꾸며 기기의 모든 앱을 자동으로 제어하지 않습니다. 이 모드로 전환한 뒤 GLOBAL 정책 그룹에서 현재 선택 항목이 구체적인 노드인지, 다른 정책 그룹인지, DIRECT인지 확인해야 합니다. 상단의 Global 표시만으로 실제 출구를 알 수 없습니다.
Global 모드에서는 먼저 GLOBAL 정책 그룹에서 구체적인 노드 하나를 선택하세요. 대상 요청이 Rule에서 DIRECT에 맞아 실패했지만 Global에서 해당 노드로 성공한다면 네트워크와 노드는 적어도 사용 가능하며 Rule의 일치 순서를 중점적으로 확인해야 합니다.
Global에서도 timeout이 발생하면 규칙만의 문제는 아닙니다. 노드, DNS, 로컬 네트워크를 비교하세요. 시험 후에는 Rule로 돌아가야 합니다. 시스템 업데이트, LAN, 국내 서비스처럼 원래 직접 연결하던 트래픽도 Global에서는 같은 출구로 전달될 수 있습니다.
Direct(직접 연결 모드): 커널을 거친 뒤 로컬 네트워크 출구 사용
Direct 모드는 Clash에 들어온 요청을 직접 연결합니다. 로컬에서 접근 가능한 웹사이트가 Direct에서는 성공하지만 프록시 정책에서 실패한다면 노드 또는 프록시 연결 문제일 가능성이 큽니다. Direct에서도 실패하면 로컬 DNS, 네트워크 또는 대상 서비스를 확인하세요.
Direct는 "Clash 끄기"와 완전히 같지 않습니다. 요청은 커널에 계속 들어올 수 있고 출구만 DIRECT를 선택합니다. 앱이 Clash를 거치는지는 페이지가 열리는지만 보지 말고 Connections에서 확인하세요.
- Direct에서는 성공하고 Rule에서는 프록시를 사용해 실패함
- 해당 프록시 정책의 노드와 규칙 배치가 적절한지 확인하세요.
- Direct와 Global 모두 실패함
- 로컬 네트워크와 프록시 로그를 각각 확인하고 결과를 모드 이름 탓으로 돌리지 마세요.
- 세 모드 모두 연결 기록이 없음
- 앱이 Clash를 우회했으므로 트래픽 진입점부터 수정하세요.
이전 클라이언트에 Script / 스크립트 모드가 있는 이유
일부 이전 Clash 클라이언트, 구형 커널 또는 특정 설정에서는 Script / 스크립트 모드로 일반 규칙보다 복잡한 판단을 처리했습니다. 현재 Mihomo 일반 설정 문서는 Rule, Global, Direct만 실행 모드로 나열하므로 Script를 모든 최신 클라이언트에 있는 네 번째 공통 모드로 설명해서는 안 됩니다.
이전 클라이언트에 Script가 보인다고 새 클라이언트에도 같은 이름의 옵션이 있다는 뜻은 아닙니다. 새 클라이언트에서 찾지 못해도 설치 실패가 아닙니다. 기존 설정을 이전할 때 스크립트가 실제로 어떤 도메인, 네트워크 또는 프로세스를 판단했는지 확인한 뒤 현재 커널의 기능에 맞춰 rules, rule-providers 또는 클라이언트 지원 덮어쓰기로 다시 작성하세요.
Script를 만났을 때 판단 방법
| 표시 위치 | 해석 방법 | 다음 단계 |
|---|---|---|
| 이전 클라이언트의 모드 메뉴 | 해당 버전 또는 커널이 제공하는 호환 기능 | 기존 환경 기록을 보관하고 해당 버전 문서와 대조 |
| 기존 설정의 스크립트 구간 | 사용자 지정 라우팅 로직이 포함되었을 수 있음 | 판단 조건을 먼저 이해한 뒤 이전 여부 결정 |
| 새 Mihomo 클라이언트에 Script가 없음 | 현재 세 가지 공통 실행 모드에 맞는 인터페이스 | 현재 커널에서 확인되지 않은 mode 값을 억지로 넣지 마세요 |
| Merge, 덮어쓰기 또는 JavaScript 페이지 | 클라이언트의 설정 처리 기능에 속함 | 커널 실행 모드와 혼동하지 마세요 |
세 가지 모드 선택 방법: 변수 하나만 바꿔 비교하세요
상황에 따른 실행 모드 선택
| 현재 목적 | 권장 모드 | 확인할 사항 |
|---|---|---|
| 일상적인 서비스별 트래픽 분기 | Rule | Connections의 일치 규칙, 정책 그룹, 실제 출구 |
| 규칙이 요청을 잘못된 출구로 보냈는지 판단 | 잠시 Global 사용 | GLOBAL 그룹 선택 및 다시 생성한 새 연결 |
| 로컬 네트워크의 직접 접근 가능 여부 판단 | 잠시 Direct 사용 | 로컬 DNS, 대상 접근성, 연결 기록 |
| 앱에 연결 기록이 전혀 없음 | 모드는 아직 바꾸지 않음 | 시스템 프록시, 앱 프록시, TUN 또는 모바일 VPN |
Rule은 실패하고 Global은 성공함
두 번의 Connections 규칙과 출구를 비교해 Rule 일치 조건을 수정하세요.
Global 페이지에 계속 DIRECT가 표시됨
상단 모드만 보지 말고 GLOBAL 정책 그룹의 현재 선택을 확인하세요.
Direct로 전환한 뒤 LAN이 복원됨
로컬 네트워크 범위 직접 연결 규칙을 추가하고 모드 전환에 계속 의존하지 마세요.
모드 전환 후에도 페이지 결과가 같음
재사용 연결을 닫고 다시 요청한 뒤 새 기록을 확인하세요.
비교가 끝나면 원래 계획한 모드로 돌아가 같은 동작을 반복하세요. Rule에서 올바른 정책에 맞고 결과도 정상이라면 Global을 "수정 방법"으로 유지할 필요가 없습니다.