Clash 규칙·전역·직접 연결 모드 선택 가이드: 트래픽 분기 이해하기

세 가지 모드: 코어에 들어온 트래픽의 출구 결정

일상적인 사용에는 규칙 모드를 우선 선택하세요. 특정 사이트의 트래픽 분기 문제를 확인할 때는 잠시 전역 모드로 전환하고, 로컬 네트워크에서 직접 접속할 수 있는지 비교할 때는 직접 연결 모드를 사용하면 됩니다. 세 모드는 속도 단계가 아니라 Clash 또는 Clash Meta(mihomo)가 이미 가로챈 연결을 서로 다른 방식으로 라우팅하는 모드입니다.

먼저 두 단계를 구분하세요. 시스템 프록시와 TUN은 트래픽을 코어로 보내고, 규칙·전역·직접 연결 모드는 코어에 들어온 트래픽의 출구를 결정합니다. 전역 모드로만 전환해도 원래 시스템 프록시를 사용하지 않는 게임이 자동으로 프록시를 거치지는 않습니다. TUN을 켰다고 해서 모든 연결이 원격 노드를 사용하는 것도 아닙니다.

규칙 모드: 먼저 일치하는 규칙이 우선이며, 가장 세밀한 규칙이 우선되는 것은 아닙니다

규칙 모드에서 코어는 대상 도메인, 대상 IP, 포트, 플랫폼 지원 여부에 따라 사용할 수 있는 프로세스 정보 등 현재 연결에서 확인 가능한 정보를 바탕으로 규칙을 매칭합니다. 조건에 맞는 규칙을 하나 찾으면 해당 규칙이 지정한 정책을 적용하고, 더 ‘정확한’ 규칙이 있는지 아래로 계속 확인하지 않습니다.

순서가 있는 규칙 살펴보기

아래는 규칙 순서를 설명하기 위한 설정 예시이며, 완전한 구독 설정은 아닙니다. 웹 출구 정책 그룹이 설정에 이미 있어야 합니다. example.com은 예시 도메인이므로 실제로 분기할 도메인으로 바꿔 사용하세요.

mode: rule

rules:
  - DOMAIN,account.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,웹 출구
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,웹 출구

• account.example.com은 첫 번째 규칙과 일치하므로 직접 연결됩니다.
• docs.example.com은 첫 번째 규칙에는 일치하지 않지만 두 번째 규칙에 일치하므로 ‘웹 출구’로 전달됩니다.
• 대상 주소가 192.168.1.20인 연결은 세 번째 규칙과 일치합니다. 일반적으로 로컬 네트워크 기기에 접속할 때 사용합니다.
• 앞선 규칙에 하나도 일치하지 않은 연결은 마지막 MATCH에 걸려 ‘웹 출구’로 전달됩니다.

두 번째 규칙을 첫 번째 규칙보다 앞에 놓으면 계정 도메인도 접미사 규칙에 포함되어 첫 번째 규칙으로 처리할 수 없게 됩니다. 따라서 계정이나 업무 시스템처럼 범위가 좁은 예외 규칙은 넓은 범위의 도메인 규칙보다 앞에 두고, 기본 처리용 MATCH는 맨 마지막에 배치하세요.

규칙의 대상은 정책 그룹일 수도 있으며, 노드로 한정되지 않습니다

DIRECT는 직접 연결 정책이고 REJECT는 연결 거부 정책입니다. ‘웹 출구’와 같은 이름은 보통 정책 그룹을 가리킵니다. 정책 그룹이 다른 정책 그룹을 가리킬 수도 있으며, 마지막에야 특정 노드나 직접 연결로 이어집니다. 로그에 특정 그룹이 표시되더라도 원격 노드를 사용 중이라고 단정하지 말고 그룹 안에서 현재 선택된 항목을 확인하세요.

no-resolve는 해당 IP 규칙을 위해 도메인 조회를 새로 시작하지 않는다는 뜻입니다. 연결에 사용할 수 있는 대상 IP가 이미 있으면 IP 규칙을 매칭할 수 있지만, 도메인만 있고 사용 가능한 IP가 없다면 별도의 조회로 매칭 조건을 얻을 수 없습니다. 설정 전체의 DNS를 ‘끄는’ 옵션은 아닙니다.

전역 모드와 직접 연결 모드: 비교 점검용이지, 트래픽 가로채기 스위치가 아닙니다

전역 모드에서는 GLOBAL의 실제 선택 항목을 확인하세요

전역 모드로 전환한 다음 클라이언트의 프록시 또는 정책 그룹 화면에서 GLOBAL이 현재 무엇을 선택했는지 확인하세요. DIRECT가 선택되어 있으면 트래픽은 계속 직접 연결됩니다. 다른 그룹을 선택했다면 그 그룹이 최종적으로 어떤 노드를 사용하는지도 확인해야 합니다. 전역 모드가 작동하지 않는 노드를 복구하거나 노드에서 지원하지 않는 UDP 전달 기능을 보완해 주지는 않습니다.

유용한 비교 방법은 같은 노드를 유지한 채 규칙 모드에서 전역 모드로 전환하고, 문제가 있는 사이트에 새로 연결하는 것입니다. 전역 모드에서는 접속되지만 규칙 모드에서는 안 된다면 매칭된 규칙과 그룹 내 선택 항목을 먼저 확인하세요. 두 모드 모두 접속되지 않는다면 노드, DNS, 트래픽이 코어로 들어오는 경로, 대상 서비스 상태를 점검하세요. 이 결과는 원인 범위를 좁히는 데 도움이 될 뿐, 한 번 접속해 본 것만으로 원인을 확정할 수는 없습니다.

직접 연결 모드에서도 로컬 프록시 진입점은 유지될 수 있습니다

직접 연결 모드에서도 브라우저가 요청을 로컬 프록시 포트로 보내고, 이후 코어가 대상에 직접 접속할 수 있습니다. 이는 ‘시스템 프록시 끄기’, ‘TUN 끄기’, ‘클라이언트 종료’와는 다릅니다. 로컬 리스너, DNS 설정, 트래픽 가로채기 방식이 계속 작동할 수 있습니다.

프록시 가로채기를 완전히 종료하려면 먼저 클라이언트에서 시스템 프록시 또는 TUN을 끈 다음 프로그램을 종료하세요. 그렇지 않으면 시스템이 더 이상 요청을 받지 않는 로컬 포트를 계속 가리켜, 클라이언트를 종료한 뒤 브라우저도 인터넷에 연결되지 않을 수 있습니다. 문제를 확인할 때는 ‘코어를 통한 직접 연결’을 시험하는지, ‘코어를 거치지 않는 시스템 네트워크’를 시험하는지 분명히 구분하세요.

시스템 프록시와 TUN: 먼저 트래픽이 코어에 들어오는지 확인

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에서 주로 사용합니다. 브라우저는 보통 이 설정을 따르지만, 게임이나 자체 네트워크 스택을 사용하는 프로그램, 일부 명령줄 도구는 그렇지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 IP 트래픽을 가로채 더 많은 앱을 지원할 수 있습니다. 다만 라우팅 제외 설정, 다른 VPN, 권한, DNS 구성의 영향을 받습니다.

1. 먼저 트래픽 가로채기 방식을 확인하세요: 클라이언트에서 시스템 프록시 또는 TUN이 활성화되어 있는지 확인합니다. 클라이언트마다 메뉴 이름이 다를 수 있으므로 ‘규칙 모드가 선택됨’을 ‘시스템 프록시가 켜짐’으로 착각하지 마세요.
2. 그다음 새 연결을 만드세요: 테스트 사이트를 열거나 게임 서버에 다시 연결하면서 클라이언트의 ‘연결’ 화면을 확인합니다. 해당 대상이 표시되면 트래픽이 코어에 들어왔다는 중요한 근거가 됩니다.
3. 마지막으로 아웃바운드 경로를 확인하세요: 일치한 규칙, 정책 그룹, 최종 출구를 확인합니다. 노드 목록의 지연 시간은 해당 테스트 결과일 뿐, 브라우저가 그 노드를 사용 중이라는 증거는 아닙니다.

웹 서핑·게임·업무 상황별 모드 선택

게임 지연 시간은 노드 테스트만으로 판단할 수 없습니다

클라이언트의 지연 시간 테스트는 보통 설정에 지정된 테스트 주소에 요청을 보내며, 게임 서버까지의 왕복 시간과는 다릅니다. 테스트에 성공해도 UDP를 지원하지 않거나 서버 지역이 맞지 않거나 트래픽이 코어에 들어오지 않아 게임이 연결되지 않을 수 있습니다. 실제 게임 연결 기록과 게임 내 네트워크 지표를 확인하고, 전역 모드를 게임 가속 버튼처럼 사용하지 마세요.

업무용 직접 연결은 도메인과 DNS를 함께 고려해야 합니다

내부 서비스는 조직 내부에서만 조회할 수 있는 도메인을 사용할 수 있습니다. DOMAIN-SUFFIX 직접 연결 규칙을 추가해도 공용 DNS에서 해당 도메인을 조회할 수 있다는 보장은 없습니다. 이 경우 조직에서 제공하는 DNS와 VPN 구성을 함께 사용하세요. 도메인 조회부터 실패했다면 노드 선택을 계속 바꿔도 도움이 되지 않습니다.

포트와 연결 기록으로 모드 적용 여부 확인하기

아래에서는 127.0.0.1:7890을 사용해 명시적 프록시 연결을 테스트합니다. 7890은 예시 포트이며 모든 클라이언트에서 사용하는 고정 포트가 아닙니다. 먼저 현재 적용 중인 설정이나 클라이언트의 포트 설정에서 HTTP 프록시 포트 또는 혼합 포트를 확인한 뒤 명령을 수정하세요. 클라이언트가 SOCKS 포트만 제공한다면 여기의 HTTP 프록시 명령을 그대로 사용할 수 없습니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com/

macOS와 Linux에서는 터미널에서 위 명령을 사용할 수 있습니다. Windows PowerShell에서는 명령 앞부분을 curl.exe로 바꾸면 일부 환경에서 같은 이름의 별칭이 매개변수 해석에 영향을 주는 문제를 피할 수 있습니다. 연결 시간 제한은 10초, 전체 요청 제한은 20초입니다. 테스트 설정일 뿐 노드 성능을 보장하지는 않습니다.

1. 규칙 모드를 선택하고 명령을 한 번 실행한 다음 example.com의 연결 기록을 확인해 적용된 규칙과 최종 아웃바운드 경로를 기록합니다.
2. 전역 모드로 전환한 뒤 GLOBAL이 예상한 노드를 사용하는지 확인하고 명령을 다시 실행해 아웃바운드 경로를 비교합니다.
3. 직접 연결 모드로 전환한 뒤 명령을 다시 실행하고 DIRECT로 연결되는지 확인합니다.
4. 비교를 마치면 규칙 모드로 되돌리고, 발견한 잘못된 규칙은 지속 설정에서 수정하세요. 전역 모드로 우회한 상태를 계속 유지하지 마세요.

명시적 프록시 테스트로 확인할 수 있는 것은 ‘이 요청이 지정된 로컬 포트를 통해 코어에 들어왔다’는 점입니다. 시스템 프록시나 TUN이 다른 앱까지 처리하는지는 확인할 수 없습니다. 대상 서버에서 HTTP 응답을 받았다면 응답 가능한 서버까지 요청이 도달한 것이지만, 실제 출구는 연결 기록으로 확인해야 합니다. 일부 서비스는 HEAD 요청을 거부하므로 응답 상태 코드만으로 노드 문제라고 판단할 수 없습니다.

자주 발생하는 오판과 해결 방법

모드를 바꿔도 웹페이지가 달라지지 않는 것처럼 보이는 경우

모드 변경은 일반적으로 새로 생성되는 연결에 영향을 줍니다. 브라우저가 HTTP/2, HTTP/3 또는 다른 장기 연결을 재사용하면 기존 연결의 출구가 바로 바뀌지 않을 수 있습니다. 관련 페이지를 닫고 요청을 다시 보내세요. 필요하면 클라이언트의 연결 화면에서 해당 연결을 종료할 수 있습니다. 같은 재사용 연결에서 계속 새로고침한 뒤 모드 변경이 적용되지 않았다고 판단하지 마세요.

규칙을 수정했는데 구독을 업데이트하면 원래대로 돌아가는 경우

구독 다운로드로 생성된 설정을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 클라이언트에서 제공하는 오버라이드, 병합 또는 지속 규칙 기능을 우선 사용하고 새 규칙이 삽입되는 위치도 확인하세요. 규칙이 MATCH 뒤에 추가되면 설정을 불러올 수는 있어도 기본 규칙에 이미 일치한 연결에는 적용되지 않습니다.

전역 모드에서는 접속되지만 규칙 모드가 직접 연결을 선택하는 경우

모든 규칙을 바로 삭제하지 말고 대상 연결에 실제로 어떤 규칙이 적용됐는지 먼저 확인하세요. 흔한 원인으로는 넓은 범위의 접미사 규칙이 도메인을 먼저 매칭하는 경우, 정책 그룹에서 DIRECT를 선택한 경우, 규칙 세트의 적용 범위가 예상과 다른 경우가 있습니다. 필요한 좁은 범위의 예외 규칙을 해당하는 넓은 규칙보다 앞에 두고 새 연결로 다시 테스트하세요.

일상적인 설정을 마친 뒤에는 규칙 모드를 유지하는 편이 로컬 서비스, 로컬 네트워크, 원격 프록시를 함께 다루기 좋습니다. 구독 가져오기와 트래픽 가로채기 방법은 입문 가이드를, 설정 구조와 규칙을 확인하려면 전체 문서를 참고하세요.