먼저 두 가지를 구분하세요: 트래픽이 코어로 들어오는지, 들어온 뒤 어떤 경로로 나가는지
Clash의 규칙·전역·직접 연결은 아웃바운드 결정 모드이지, 트래픽을 가져오는 세 가지 방식이 아닙니다. 시스템 프록시, 앱의 수동 프록시 설정, TUN은 연결을 코어로 전달하고, 모드는 전달된 연결의 다음 경로를 결정합니다. 코어에 들어오지 않은 연결은 전역 모드로 바꿔도 자동으로 프록시를 거치지 않습니다.
예를 들어 시스템 프록시 설정을 따르는 브라우저는 요청을 로컬 프록시 포트로 보낼 수 있지만, 시스템 프록시를 사용하지 않는 게임의 연결은 물리 네트워크 인터페이스를 통해 직접 나갈 수 있습니다. 두 상황이 함께 발생하면 Clash의 ‘전역’ 모드는 이미 가져온 연결에만 적용됩니다. TUN을 사용하면 가져오는 범위를 넓힐 수 있지만, 라우팅·제외 항목·권한·플랫폼 구현에 따라 달라집니다.
아래 내용은 일반적인 Clash 및 Clash.Meta(이후 mihomo로 이름 변경) 코어의 모드 개념을 기준으로 합니다. GUI 클라이언트마다 메뉴를 ‘모드’, ‘프록시 모드’, ‘아웃바운드 모드’ 등으로 다르게 표시할 수 있습니다. 버튼 위치와 번역 명칭은 일정하지 않으므로 현재 활성화된 모드, 연결 기록, 실제 아웃바운드 경로를 기준으로 판단하세요.
세 가지 모드 비교: 규칙에 따른 판단, 통합 아웃바운드, 직접 연결
| 모드 및 설정값 | 가져온 연결의 처리 방식 | 주요 사용 사례 |
|---|---|---|
규칙: rule |
규칙 목록과 대조한 뒤 일치하는 규칙이 지정한 정책으로 전달 | 일상적인 웹 브라우징, 중국 본토·해외 트래픽 분리, 로컬 네트워크 예외 |
전역: global |
일반적인 라우팅 규칙을 따르지 않고 GLOBAL 정책으로 전달 |
노드 확인, 규칙 문제 비교, 임시로 출구 통일 |
직접 연결: direct |
일반적인 라우팅 규칙을 따르지 않고 DIRECT 사용 |
로컬 네트워크 점검, 직접 연결을 통한 임시 복구 |
규칙 모드라고 해서 모든 트래픽이 프록시를 거치는 것은 아닙니다
규칙은 프록시 노드, 프록시 그룹, DIRECT 또는 REJECT를 지정할 수 있습니다. 따라서 규칙 모드에서는 프록시 연결뿐 아니라 직접 연결과 연결 거부도 가능합니다. 실제 접속 경로는 어떤 규칙과 일치했는지, 해당 규칙이 지정한 프록시 그룹에서 어떤 항목을 선택했는지에 따라 달라집니다.
전역 모드라고 해서 모든 기기의 트래픽을 가져오는 것은 아닙니다
전역 모드는 일반적으로 이미 가져온 연결을 내장된 GLOBAL 선택 그룹으로 전달합니다. 해당 그룹에서 프록시 노드를 선택해야 연결이 그 노드를 통해 나갑니다. DIRECT를 선택했다면 실제 연결은 여전히 직접 연결입니다. ‘전역’이라는 표시만으로 출구가 바뀌었다고 판단할 수 없으므로 전역 정책의 선택 결과도 확인해야 합니다.
직접 연결 모드라고 해서 클라이언트가 종료되는 것은 아닙니다
직접 연결 모드에서도 시스템 프록시나 TUN이 활성화된 상태일 수 있으며, 코어가 연결과 DNS를 계속 처리할 수도 있습니다. 바뀌는 것은 아웃바운드 정책이 직접 연결로 설정된다는 점입니다. 클라이언트가 네트워크에 미치는 영향을 완전히 배제하려면 트래픽을 가져오는 기능을 별도로 끄고 시스템 프록시와 라우팅 설정 등이 원래대로 복구됐는지 확인하세요. 직접 연결 버튼만 누르는 것으로는 충분하지 않습니다.
규칙 모드: 규칙 순서에 따라 직접 연결할 대상을 결정
일반 규칙 목록은 위에서 아래로 확인하며, 일치하는 규칙을 찾으면 해당 정책을 적용합니다. 구체적인 도메인 예외는 포괄적인 조건보다 앞에 두고, 최종 대체 규칙인 MATCH는 마지막에 둡니다. 구독에 포함된 노드 수만으로 규칙이 충분한지 알 수는 없습니다. 프록시 노드, 프록시 그룹, 규칙 목록은 서로 별개의 구성 요소입니다.
아래는 설정 예시이며, 단독으로 가져올 수 있는 완전한 구독 파일이 아닙니다. 기존 설정에 ‘노드 선택’이라는 프록시 그룹이 정의되어 있다고 가정합니다. 실제로 사용할 때는 설정에 존재하는 정책 이름으로 바꾸고 기존 노드와 DNS 등 다른 필드는 유지하세요.
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,노드 선택DOMAIN-SUFFIX,example.com은example.com과 그 하위 도메인에 일치합니다. 예시로 든 도메인이므로 특정 사이트 목록을 나타내는 것은 아닙니다.- 세 가지 사설 IPv4 대역은 로컬 네트워크 직접 연결을 설명하기 위한 예시입니다. 모든 로컬 주소와 IPv6, 루프백 주소, 특수 용도 대역을 포함하지는 않습니다.
no-resolve는 이 IP 규칙에 맞추려고 도메인을 새로 조회하지 않는다는 뜻입니다. 연결에 대상 IP가 이미 있으면 해당 IP를 기준으로 규칙과 대조할 수 있습니다.GEOIP,CN은 IP 지리 데이터베이스를 기준으로 판단합니다. ‘중국어 사이트 전체’를 뜻하지 않으며, 중국 본토의 모든 서비스를 정확히 식별한다고 보장하지도 않습니다.MATCH는 앞선 규칙에 일치하지 않은 연결을 받아 ‘노드 선택’ 프록시 그룹으로 전달해 실제 출구를 결정합니다.
전역 모드: 노드 확인 및 라우팅 비교에 활용
전역 모드는 문제를 진단할 때 확인해야 할 변수를 하나 줄여 줍니다. 일반 라우팅 규칙을 잠시 건너뛰고 테스트 연결을 하나의 아웃바운드 정책으로 보냅니다. 하지만 만료된 구독, 잘못된 인증 정보, 접속할 수 없는 노드, DNS 오류를 해결해 주지는 않으며 모든 앱이 정상 작동한다고 보장하지도 않습니다.
- 먼저 규칙 모드에서 접속에 실패한 도메인과 현재 프록시 그룹에서 선택한 노드를 기록하세요.
- 전역 모드로 바꾼 뒤
GLOBAL에서 같은 노드를 선택하세요. 모드와 노드를 동시에 변경하지 않도록 합니다. - 해당하는 기존 연결을 종료한 다음 같은 대상에 다시 접속하세요. 브라우저의 기존 장기 연결은 이전 아웃바운드 경로를 계속 사용할 수 있습니다.
- ‘연결’ 또는 ‘로그’ 페이지에서 새 연결이 실제로 코어에 들어왔는지, 아웃바운드 경로에 예상한 노드가 포함됐는지 확인하세요.
같은 노드가 전역 모드에서는 작동하지만 규칙 모드에서는 실패한다면, 구독을 바로 바꾸기보다 일치한 규칙과 정책 그룹 선택, 대체 규칙부터 확인하세요. 두 모드에서 모두 실패한다면 노드 연결 상태, 인증, DNS 조회, 대상 서비스 상태를 점검하세요. 이는 문제를 좁혀 가기 위한 방향일 뿐이며, 최종 판단에는 로그도 함께 확인해야 합니다.
임시로 출구를 통일할 때의 장단점
전역 모드를 사용하면 가져온 로컬 네트워크 연결, 소프트웨어 다운로드, 동영상 트래픽까지 프록시 노드로 전달되어 데이터 사용량과 지연 시간이 늘어날 수 있습니다. 사내 네트워크, NAS, 라우터 관리 페이지에 접속하지 못할 수도 있습니다. 대부분은 프록시를 거치고 일부는 직접 연결해야 하는 환경이라면 전역 모드를 반복해서 전환하기보다 규칙 모드에 명확한 예외를 추가하는 편이 좋습니다.
직접 연결 모드: 로컬 네트워크와 내부 기기 접속 확인
직접 연결 모드로 확인할 수 있는 것은 간단합니다. 원격 프록시 노드를 거치지 않고 현재 네트워크에서 대상에 접속할 수 있는지 살펴보는 것입니다. 예를 들어 로컬 네트워크 프린터에 접속하거나, 로컬 포털 인증 문제를 진단하거나, 중국 본토 서비스에 접속되는지 비교할 때 유용합니다. 대상에 접속하려면 프록시가 필요한 경우 직접 연결로 바꾼 뒤 접속에 실패해도 클라이언트 오류라고 단정할 수 없습니다.
로컬 네트워크 기기에 접속할 수 없을 때 확인할 순서
- 먼저
192.168.1.1처럼 기기의 실제 IP 주소로 접속해 보세요. 흔히 쓰이는 예시 주소이므로 현재 게이트웨이나 기기에 설정된 주소를 사용해야 합니다. - IP 주소로는 접속되지만 기기 이름으로는 안 된다면 DNS, 검색 도메인, 이름 검색 기능을 확인하세요.
.local은 mDNS를 사용하는 경우가 많으므로 일반 DNS 규칙만으로 판단할 수 없습니다. - 직접 연결 모드에서는 접속되지만 규칙 모드에서는 안 된다면 사설 대역 트래픽이 프록시 정책으로 잘못 전달되는지, 앞쪽에 먼저 일치하는 규칙이 있는지 확인하세요.
- 두 모드에서 모두 실패한다면 Wi-Fi 클라이언트 격리, 기기 방화벽, 서브넷 차이, 다른 VPN과의 라우팅 충돌을 점검하세요.
TUN이 켜져 있다면 ‘TUN으로 들어온 뒤 DIRECT로 나가는 경로’와 ‘라우팅 제외로 TUN에 들어오지 않는 경로’를 구분해야 합니다. 두 경로는 서로 다릅니다. 회사 VPN이나 특수한 내부 네트워크를 사용하는 경우에는 클라이언트가 지원하는 방식에 따라 트래픽 제외 항목을 설정하세요. 여러 라우팅 설정을 한꺼번에 바꾸면 문제를 추적하기 어려워집니다.
시스템 프록시, TUN, 모드 설정을 조합하는 방법
모드와 트래픽을 가져오는 방식은 각각 별도로 조합할 수 있습니다. 시스템 프록시와 규칙 모드는 프록시 설정을 따르는 데스크톱 앱에 적합합니다. TUN과 규칙 모드를 함께 사용하면 시스템 프록시 설정을 따르지 않는 연결도 더 많이 처리할 수 있습니다. TUN과 전역 모드를 함께 사용해도 네트워크가 반드시 작동하는 것은 아닙니다. 노드의 UDP 지원 여부, DNS 경로, 운영체제 라우팅 설정이 결과에 영향을 줍니다.
| 사용 상황 | 우선 선택할 모드 | 확인할 항목 |
|---|---|---|
| 일상적인 웹 브라우징과 자주 쓰는 앱 | 규칙 모드 | 앱이 시스템 프록시를 사용하는지, 규칙이 예상한 정책을 지정하는지 |
| 브라우저는 작동하지만 게임은 안 되는 경우 | 먼저 트래픽이 들어오는지 확인한 뒤 필요하면 TUN 사용 | 게임 연결이 기록에 표시되는지, 노드와 클라이언트가 필요한 UDP 트래픽을 지원하는지 |
| 특정 도메인의 라우팅이 잘못된 것으로 의심되는 경우 | 전역 모드로 잠시 비교 | 같은 노드로 새 연결을 만들어 테스트 |
| NAS, 라우터, 사내 네트워크 | 규칙 모드에 직접 연결 예외 추가 | 대상 주소, DNS, 라우팅, 다른 VPN과의 충돌 |
프록시 포트를 직접 설정할 때는 클라이언트에 표시된 값을 사용하세요. 예를 들어 설정에 mixed-port: 7890이 명시되어 있을 때만 앱에서 해당 로컬 혼합 프록시 포트를 사용해야 합니다. 127.0.0.1:7890이 모든 클라이언트에서 통용되는 고정 주소는 아닙니다. external-controller의 제어 인터페이스 포트를 브라우저 프록시 설정에 입력하지 말고, 로컬 수신 포트를 원격 노드 포트와 혼동하지 마세요.
모드를 바꿔도 문제가 계속될 때: 연결 기록으로 진단
Clash의 모드 전환은 일반적으로 이후에 만들어지는 새 연결에 적용됩니다. 브라우저의 연결 재사용, 동영상의 장시간 연결, 다운로드 작업, 앱 내부 DNS 캐시 때문에 결과가 달라지지 않은 것처럼 보일 수 있습니다. 테스트 전에 기존 설정을 기록하고, 한 번에 변수 하나만 바꿔 같은 대상에 다시 접속하세요.
- 연결 기록에 대상이 없음: 트래픽이 코어로 들어오는지부터 확인하세요. 시스템 프록시가 켜져 있는지, 앱 자체 프록시 설정이 있는지, TUN이 정상적으로 시작됐는지 살펴봅니다.
- 규칙 모드에서 DIRECT와 일치함: 일치 조건이 예상대로인지 확인하세요. 프록시를 사용해야 한다면 해당 규칙이나 규칙 순서를 수정하고 노드만 바꾸지 마세요.
- 규칙이 프록시 그룹과 일치했지만 직접 연결됨: 그룹과 하위 그룹에서
DIRECT를 선택했는지 확인하세요. 그룹 이름만 보고 판단하면 안 됩니다. - 전역 모드에서도 실패함:
GLOBAL에서 실제로 무엇을 선택했는지 확인한 뒤 노드 핸드셰이크, 인증 실패, 연결 시간 초과 등의 로그를 살펴보세요. - 도메인 접속은 실패하지만 IP 경로에는 응답이 있음: DNS를 추가로 확인하세요. HTTPS에는 인증서와 SNI도 관련되므로 IP 주소로 웹페이지를 여는 것만으로 도메인 접속 테스트를 완전히 대체할 수 없습니다.
처음 설정하는 경우 설치 및 설정 가이드를 참고하세요. 클라이언트별 시스템 프록시, TUN, 플랫폼 지원 여부는 클라이언트 비교에서 확인할 수 있습니다. 지원 기능은 클라이언트와 코어에 따라 다르므로 ‘Clash’라는 이름만으로 판단할 수 없습니다.