Clash 규칙 라우팅 실전: 국내 직접 연결·해외 프록시 설정과 rules, rule-providers

먼저 라우팅 범위 확인하기: 규칙 모드, 트래픽 진입점과 출구

‘로컬 트래픽은 직접 연결하고 해외 트래픽은 프록시로 보낸다’는 설정은 세 가지로 나눠야 합니다. LAN 주소는 DIRECT로 보내고, 국내 사이트로 명확히 분류되는 트래픽은 도메인이나 IP 기준으로 직접 연결하며, 나머지는 프록시 그룹으로 보냅니다. 여기서 ‘로컬’은 라우터, NAS, 사내망 서비스 등을 뜻하며 ‘국내 웹사이트’와는 범위가 다릅니다. 두 대상을 구분해야 사내망에 접속할 때 원격 노드로 잘못 우회하는 일을 막을 수 있습니다.

이 문서의 예시는 mihomo 커널을 기준으로 합니다. Clash Nyanpasu는 GUI 클라이언트이며, 실제로 rules를 실행하는 것은 현재 구동 중인 커널입니다. 구버전 Clash는 일부 필드 지원 방식이 다릅니다. 특히 아래에서 사용하는 include-all을 포함한 mihomo 설정을 같은 이름의 모든 클라이언트에 그대로 적용하지 마세요.

• 프록시 모드: ‘규칙 / Rule’을 선택합니다. 전역 모드에서는 일반적인 규칙 목록에 따라 출구를 선택하지 않으며, 직접 연결 모드에서는 프록시를 기본 경로로 사용할 수 없습니다.
• 트래픽 진입점: 브라우저가 클라이언트의 프록시 포트를 실제로 사용하도록 설정하거나 TUN으로 트래픽을 가로채야 합니다. 시스템 프록시만으로는 모든 앱의 트래픽을 처리할 수 없습니다.
• 프록시 그룹 출구: 규칙이 프록시 그룹에 매칭되어도 사용 가능한 노드가 자동으로 선택되는 것은 아닙니다. 그룹에서 현재 선택된 항목도 확인하세요.
• 설정 출처: 현재 활성화된 구독이 무엇인지, 오버라이드나 병합 스크립트가 최종 규칙을 변경하는지 확인하세요.

현재 사용 중인 설정을 먼저 백업하세요. 구독 관리자가 업데이트 중 설정을 다시 생성할 수 있으므로, 클라이언트가 지원하는 영구 오버라이드 또는 병합 기능으로 사용자 규칙을 보존하고 최종 적용 결과를 확인해야 합니다. 임시로 생성된 파일만 수정해서는 안 됩니다.

rules 매칭 순서: 구체적인 예외를 먼저, MATCH는 마지막에

일반적인 rules 목록은 위에서 아래로 확인하며, 처음 매칭된 규칙의 정책을 적용하고 더 정확한 다음 규칙을 찾지 않습니다. 도메인 길이나 IP 대역 크기에 따라 규칙을 자동 정렬하는 기능도 없습니다. 예를 들어 사이트 전체를 포괄하는 접미사 규칙을 앞에 두면, 뒤에 있는 특정 서브도메인 예외는 적용될 기회가 없습니다.

접미사 규칙보다 도메인 예외를 먼저 적용하는 방법

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,프록시 출구
  - MATCH,프록시 출구

이 규칙에서는 example.com은 직접 연결하고 www.example.com은 프록시 출구로 보냅니다. 두 줄의 순서를 바꾸면 루트 도메인도 먼저 접미사 규칙에 매칭됩니다. 예시 도메인은 매칭 관계를 설명하기 위한 것이며, 실제 서비스 사이트를 설정에 추가하라는 뜻은 아닙니다.

no-resolve는 이 IP 규칙을 위해 도메인을 IP로 직접 해석하지 말라는 의미입니다. 연결 과정에서 발생하는 모든 DNS 조회를 차단한다는 뜻은 아닙니다. 연결에 대상 IP가 이미 포함되어 있다면 규칙은 해당 IP를 기준으로 계속 판단할 수 있습니다. LAN 대역 규칙에 사용하면 내부 주소를 확인할 때 불필요한 DNS 조회를 줄일 수 있습니다.

국내 직접 연결과 해외 프록시: 확인 가능한 설정 예시

아래는 기존 mihomo 설정에 병합할 설정 조각이며, 노드, DNS, 수신 포트가 포함된 전체 구독 설정이 아닙니다. 기존 proxies 또는 proxy-providers는 유지하고 프록시 그룹과 규칙을 병합하세요. 같은 이름의 최상위 필드가 이미 있다면 해당 필드를 수정해야 합니다. rules:를 중복해서 추가하면 안 됩니다.

mode: rule

proxy-groups:
  - name: 프록시 출구
    type: select
    include-all: true
    proxies:
      - DIRECT

rules:
  # 사용자 지정 예외: 도메인 정보를 확인할 수 있을 때 먼저 매칭
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT

  # 루프백, 사설 네트워크 및 링크 로컬 주소
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,169.254.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve

  # 국내 IP는 직접 연결하고 나머지는 프록시 그룹으로 전송
  - GEOIP,CN,DIRECT
  - MATCH,프록시 출구

노드를 선택한 다음 프록시 연결 확인하기

include-all: true를 설정하면 이 mihomo 프록시 그룹에 기존 노드와 프록시 제공자에 포함된 노드가 추가됩니다. 예시에서는 선택 항목으로 DIRECT도 유지합니다. 적용 후에는 ‘프록시 출구’ 그룹에서 사용 가능한 노드를 직접 선택해야 합니다. DIRECT가 선택된 상태라면 로그에 MATCH가 표시되어도 최종 연결은 직접 연결됩니다. 가져온 노드가 없다면 이 설정 조각만으로 프록시 연결이 만들어지지는 않습니다.

기존 설정에 사용 가능한 프록시 그룹이 있다면 기존 그룹을 유지하고 규칙의 ‘프록시 출구’를 해당 그룹의 정확한 이름으로 바꾸는 편이 간단합니다. 이름은 대소문자를 구분하며 공백도 이름의 일부입니다. 예시를 적용하기 위해 구독에 포함된 자동 선택 그룹을 삭제하지 마세요.

기본 라우팅 설정의 한계

• GEOIP,CN은 대상 IP의 데이터베이스상 위치를 판단합니다. 웹사이트의 언어, 회사 등록 국가 또는 최상위 도메인을 기준으로 하지 않습니다.
• 국내 서비스가 해외 CDN을 사용할 수도 있고, 해외 서비스에 국내 IP가 할당될 수도 있습니다. 따라서 도메인 규칙 세트로 라우팅 의도를 보완해야 합니다.
• GEOIP를 사용하려면 로컬 데이터베이스가 정상적으로 준비되어 있어야 합니다. 파일이 없거나 로드에 실패했다면 먼저 문제를 해결하세요. 규칙 로드 실패를 정상적인 기본 경로로 간주해서는 안 됩니다.
• 내부 도메인을 사용하려면 이름이 올바르게 해석되어야 합니다. 직접 연결 규칙을 지정해도 클라이언트에 기업 DNS가 추가되거나 NAS가 자동으로 검색되지는 않습니다.

여기서는 국내 IP를 판별할 때 도메인 해석이 필요한 경우를 허용하기 위해 GEOIP 규칙에 no-resolve를 추가하지 않았습니다. 그 대신 일부 연결에서 먼저 로컬 DNS 조회가 발생할 수 있습니다. 도메인 해석 경로를 엄격하게 제어하려면 DNS 정책도 함께 설계해야 합니다. ‘프록시 출구로 연결’한다고 해서 DNS까지 반드시 프록시를 통한다는 뜻은 아닙니다.

rule-providers 설정법: 원격 규칙 세트와 동작 유형

규칙이 많다면 도메인 목록을 메인 설정에서 분리할 수 있습니다. rule-providers는 규칙 세트의 출처, 형식, 업데이트 방식을 정의하고, RULE-SET은 규칙 목록에서 해당 세트를 참조합니다. 제공자만 정의하고 참조하지 않으면 연결 경로는 바뀌지 않습니다.

아래에서는 공개된 Loyalsoldier 직접 연결 도메인 규칙 세트를 이용해 HTTP 제공자를 설명합니다. 이 목록은 관리자가 정리한 직접 연결 권장 목록이며, 중국 지역을 엄격하게 구분하는 기준은 아닙니다. 적용하기 전에 목록 범위가 실제 사용 목적에 맞는지 확인하세요. 주소는 커널이 설정에 따라 규칙을 가져오는 데 사용되며, 웹페이지가 자동으로 요청하는 것은 아닙니다.

rule-providers:
  direct-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/direct.txt"
    path: ./ruleset/direct-domains.yaml
    interval: 86400

interval: 86400의 단위는 초이며, 24시간마다 업데이트를 확인한다는 뜻입니다. path는 커널 작업 디렉터리 아래의 로컬 캐시 파일 경로이지 현재 웹페이지 기준 경로가 아닙니다. 처음 로드할 때 원격 콘텐츠를 가져올 수 있거나 사용 가능한 캐시가 있어야 합니다. 다운로드에 실패해도 규칙을 건너뛰고 반드시 시작된다고 가정하지 마세요.

규칙 세트를 올바른 위치에 연결하기

앞 절의 사용자 지정 예외와 LAN 규칙은 유지하고, 그다음 GEOIP 규칙 앞에 아래 한 줄을 추가하세요. 여기서는 목록의 마지막 부분만 보여줍니다. 앞에 있는 내부망 규칙까지 덮어써서 삭제하지 마세요.

  - RULE-SET,direct-domains,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,프록시 출구

권장 순서는 ‘사용자 지정 예외 → LAN → 직접 연결 도메인 목록 → 국내 IP → 프록시 기본 경로’입니다. 직접 연결 목록에 포함된 도메인을 프록시로 보내려면 RULE-SET 앞에 해당 도메인을 지정하는 규칙을 추가하세요. MATCH 뒤에 예외를 두면 절대 적용되지 않습니다.

behavior와 파일 내용은 서로 일치해야 합니다

예를 들어 로컬 파일의 behavior: domain과 format: yaml은 다음과 같이 작성할 수 있습니다. 여기서 +.example.com은 루트 도메인과 하위 도메인에 매칭됩니다. 일반 rules에서 사용하는 3개 필드 형식으로 잘못 작성하지 마세요.

payload:
  - '+.example.com'
  - 'example.net'

classical 형식에서는 DOMAIN-SUFFIX,example.com과 같은 매칭 조건을 작성하며, 각 payload 항목 끝에 DIRECT를 추가하지 않습니다. 사용할 정책은 바깥쪽의 RULE-SET,규칙 세트 이름,정책에서 지정합니다. 파일 확장자만으로 실제 형식을 판단할 수는 없습니다. 위 원격 주소는 .txt로 끝나지만 내용은 YAML payload입니다.

세 가지 연결로 확인하기: 내부망, 국내 웹사이트, 프록시 기본 경로

설정을 저장했다고 해서 편집이 끝난 것일 뿐, 새 규칙이 연결에 적용되었다는 뜻은 아닙니다. 다시 불러온 뒤 클라이언트의 설정 화면에서 현재 활성화된 항목을 확인하고 연결 목록과 커널 로그를 점검하세요. 버전에 따라 화면 이름은 다를 수 있습니다. 모드 버튼만 확인하지 말고 연결에 적용된 규칙과 전체 출구 경로를 확인해야 합니다.

1. LAN 테스트: 라우터 주소가 실제로 192.168.1.1이라면 프록시 진입점을 통해 접속했을 때 192.168.0.0/16에 매칭되고 DIRECT로 표시되어야 합니다. 모든 가정용 네트워크의 게이트웨이가 이 주소라고 단정하지 마세요.
2. 국내 사이트 테스트: 국내 사이트에 새 연결을 한 번 생성하고 direct-domains 또는 GEOIP CN에 매칭되는지 확인하세요. MATCH가 표시된다면 먼저 대상 도메인이 목록에 있는지 확인한 다음, 해석된 IP의 위치를 확인하세요.
3. 프록시 기본 경로 테스트: 직접 연결 목록에 없는 해외 사이트에 접속했을 때 MATCH에 매칭되고, 출구 경로가 DIRECT에서 멈추지 않고 선택한 실제 노드로 이어져야 합니다.
4. 예외 규칙 테스트: 임시로 지정한 정확한 도메인을 대상으로 맨 위에 규칙을 추가하고 연결을 새로 만든 뒤, 규칙 세트보다 먼저 매칭되는지 확인하세요. 테스트가 끝나면 남겨둘 필요가 없는 임시 항목을 삭제합니다.

curl로 실제 프록시 포트 확인하기

실제 설정이 mixed-port: 7890이라면 아래 명령으로 HTTP 프록시 진입점을 명확히 거치는 연결을 만들 수 있습니다. 포트는 현재 적용 중인 설정을 기준으로 확인하세요. 7890이 모든 설치에서 고정으로 사용되는 것은 아닙니다. Windows PowerShell에서는 명령 별칭 문제를 피하려면 curl.exe를 사용할 수 있습니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

이 명령은 트래픽이 로컬 진입점을 실제로 통과하는지 확인하기 위한 것이며, 특정 사이트가 반드시 프록시를 사용해야 하는지 증명하지는 않습니다. 연결 목록에서 요청 시간, 대상 도메인, 매칭 규칙, 출구 경로를 함께 확인하세요. SOCKS만 지원하는 진입점이라면 해당 포트를 사용해야 합니다. socks5h://를 사용하면 도메인 해석을 프록시 측에 맡겨 테스트 도구가 로컬에서 먼저 DNS 조회를 하는 바람에 결과가 달라지는 일을 방지할 수 있습니다.

규칙을 변경해도 이미 설정된 TCP 연결의 출구가 다시 선택되는 경우는 드뭅니다. 브라우저 연결 풀, HTTP/2, QUIC이 기존 세션을 재사용할 수 있으므로 테스트하기 전에 관련 연결을 종료한 뒤 새 요청을 보내세요. 그렇지 않으면 규칙이 적용되지 않았다고 잘못 판단하기 쉽습니다.

라우팅이 적용되지 않을 때 단계별로 확인하기

프록시 그룹에 매칭되는데도 직접 연결되는 경우

프록시 그룹의 최종 출구를 펼쳐 확인하세요. 수동 선택 그룹에서 DIRECT가 선택되었을 수도 있고, 다른 선택 그룹을 중첩했는데 그 그룹의 최종 선택도 DIRECT일 수 있습니다. 전체 경로에 실제 프록시 노드가 표시되어야 해당 노드로 연결이 전달된 것입니다. 그룹 이름이 ‘프록시 출구’라고 해서 프록시 사용이 강제되지는 않습니다.

설정은 저장되지만 원격 규칙 세트를 사용할 수 없는 경우

로그에서 제공자 이름, HTTP 상태 코드, 파싱 오류를 확인하세요. 403은 서버가 요청을 거부했음을 뜻하고, 404는 대개 경로나 브랜치가 잘못되었음을 나타냅니다. HTML 오류 페이지가 반환되면 HTTP 요청이 완료되었더라도 유효한 규칙을 받은 것은 아닙니다. 구독의 프록시 노드 URL을 규칙 제공자에 입력하지 마세요. 데이터 형식이 서로 다릅니다.

브라우저는 정상인데 게임이나 명령줄 앱에는 규칙이 적용되지 않는 경우

먼저 연결 목록에 해당 연결이 표시되는지 확인하세요. 기록이 없다면 앱이 시스템 프록시를 사용하는지, 자체적으로 직접 연결하는지, TUN이 해당 트래픽을 실제로 가로채는지부터 점검하세요. TUN은 트래픽 진입 범위를 넓히는 기능이지 rules 순서를 자동으로 바로잡는 기능이 아닙니다. UDP 트래픽을 처리하려면 진입점, 커널, 노드 경로가 모두 UDP를 지원해야 합니다.

IP로는 직접 연결되지만 내부 도메인에 접속할 수 없는 경우

대개 도메인 해석을 확인해야 합니다. printer.home.arpa 레코드를 라우터나 기업 DNS에서 제공하나요? 앱은 시스템 해석기를 사용하나요, 아니면 자체 암호화 DNS를 사용하나요? 도메인이 올바른 내부 IP를 얻지 못한다면 DIRECT 규칙을 추가해도 DNS 문제는 해결되지 않습니다. 또한 .local은 mDNS와 관련된 경우가 많으므로 일반 유니캐스트 DNS 접미사처럼 취급하지 않는 편이 좋습니다.

구독 업데이트 후 사용자 규칙이 사라지는 경우

수정 사항이 영구적으로 저장되는 오버라이드 계층에 기록되었는지 확인하고 병합 방식을 점검하세요. 일부 방식은 배열에 항목을 추가하고, 일부는 배열 전체를 교체합니다. 사용자 규칙이 기존 MATCH 뒤에 추가되면 설정에 남아 있어도 실제로 매칭되지 않습니다. 업데이트할 때마다 목록 앞부분, RULE-SET 참조, 마지막 MATCH를 최소한 확인하세요.

라우팅을 관리할 때는 설명하기 쉬운 예외 규칙을 소수만 유지하고, 여러 도메인은 출처가 명확한 규칙 세트에 맡긴 뒤 연결 로그로 결과를 검증하세요. 기본 설정은 사용 가이드를 참고하세요. DNS, TUN, 커널 설정의 관계를 확인하려면 기술 참고 자료를 살펴보세요. 규칙이 많다고 더 정확해지는 것은 아닙니다. 트래픽 진입점, 규칙 순서, 최종 출구가 일치해야 안정적으로 라우팅할 수 있습니다.