라우팅 실전 예상 읽기 시간 13분

Clash 규칙 기반 트래픽 라우팅 실전: 국내외 트래픽을 위한 YAML 설정

일반적인 지역별 트래픽 분기 요구를 중심으로 정책 그룹, 규칙 순서, 최종 대체 규칙과 설정 검증 방법을 단계별로 설명합니다.

국내 직접 연결과 해외 프록시의 라우팅 모델부터 정하기

Clash의 규칙 모드는 모든 규칙을 동시에 실행하지 않습니다. 위에서부터 연결 정보를 확인하다가 조건에 맞는 첫 번째 규칙을 찾으면 즉시 추가 매칭을 중단합니다. 국내외 트래픽을 설정할 때 결과를 결정하는 핵심은 세 가지입니다. 규칙이 무엇을 식별하는지, 매칭 후 어느 정책 그룹으로 보낼지, 그리고 아무 규칙에도 매칭되지 않을 때 어떤 규칙으로 처리할지입니다.

관리하기 쉬운 기본 모델은 보통 네 단계로 나눕니다. 첫 번째 단계에서는 LAN 주소, 루프백 주소와 로컬 서비스를 처리해 라우터, 프린터, 네트워크 저장 장치 또는 개발 환경에 접속할 때 프록시를 거치지 않도록 합니다. 두 번째 단계에는 회사 내부 도메인, 다운로드 사이트 또는 특정 애플리케이션 API처럼 동작을 명확히 지정해야 하는 도메인을 배치합니다. 세 번째 단계에서는 도메인 집합과 IP 지역 데이터를 사용해 넓은 범위의 지역 트래픽을 처리합니다. 네 번째 단계에서는 MATCH로 앞에서 식별하지 못한 연결을 받습니다.

  1. LAN 및 사설 주소: DIRECT로 보내 로컬 장치 간 정상적인 통신을 유지합니다.
  2. 명시적 도메인 규칙: 실제 요구에 따라 직접 연결, 프록시 또는 차단으로 처리하며 지역 규칙보다 우선합니다.
  3. 국내 지역 트래픽: 도메인 규칙 집합, GEOIP 또는 mihomo의 GEOSITE로 판단할 수 있습니다.
  4. 미매칭 트래픽: 일반적으로 해외 트래픽 정책 그룹으로 보내며, 특정 프록시 노드를 직접 지정하지 않습니다.

여기서 ‘로컬’은 두 가지 개념을 구분해야 합니다. 하나는 LAN 내부의 사설 주소이고, 다른 하나는 직접 연결하려는 국내 인터넷 트래픽입니다. 전자는 고정된 네트워크 대역으로 안정적으로 식별할 수 있지만, 후자는 도메인만 확인되는 경우도 있고 최종적으로 CDN 주소에 연결될 수도 있습니다. 따라서 도메인 판단과 IP 판단을 함께 사용해야 합니다.

정책 그룹은 경로를 선택하고, 규칙은 트래픽을 그곳으로 보냅니다

규칙 끝의 대상 필드는 DIRECT, REJECT 또는 정책 그룹 이름으로 지정할 수 있습니다. 장기간 사용할 설정이라면 해외 트래픽을 특정 프록시 노드가 아닌 정책 그룹으로 보내는 것이 좋습니다. 구독 업데이트에 따라 노드 이름은 바뀔 수 있지만 정책 그룹 이름은 안정적으로 유지할 수 있으므로 규칙을 반복해서 수정할 필요가 없습니다.

다음 조각은 자주 사용하는 정책 그룹 세 가지를 보여 줍니다. ‘해외 트래픽’은 사용자가 직접 선택하는 진입점으로, 자동 테스트 그룹이나 직접 연결을 선택할 수 있습니다. ‘자동 선택’은 후보 노드를 주기적으로 테스트하고, ‘미분류 트래픽’은 지역 규칙에 매칭되지 않은 연결을 처리합니다. 이 예시는 구독에 airport라는 프록시 제공자가 이미 존재한다고 가정합니다. 실제 사용 시에는 현재 설정의 provider 이름으로 바꿔야 합니다.

proxy-groups:
  - name: 해외 트래픽
    type: select
    proxies:
      - 자동 선택
      - DIRECT

  - name: 자동 선택
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: 미분류 트래픽
    type: select
    proxies:
      - 해외 트래픽
      - DIRECT

select 그룹은 사용자의 현재 선택을 자동으로 바꾸지 않으므로 경로를 안정적으로 제어해야 하는 경우에 적합합니다. url-test는 테스트 결과에 따라 후보 노드 중 응답이 빠른 노드를 선택하지만, 측정 지연 시간은 테스트 주소의 응답 상태일 뿐 모든 사이트의 실제 다운로드 속도를 의미하지는 않습니다. 모바일 네트워크가 자주 변한다면 interval을 적절히 늘려 반복 테스트를 줄일 수 있습니다.

노드를 proxies 목록에 직접 작성했다면 노드 이름은 공백과 대소문자를 포함해 구독 설정과 완전히 일치해야 합니다. use를 사용할 때는 이름이 proxy-providers 아래의 키와 일치해야 합니다. 두 방식 중 무엇을 사용할지는 클라이언트와 커널의 기능에 따라 선택할 수 있지만, provider 이름을 일반 노드 목록에 잘못 입력해서는 안 됩니다.

규칙 순서: 구체적인 조건을 먼저, 지역 판단과 최종 대체 규칙은 나중에

Clash는 첫 번째 매칭 규칙을 적용하므로 하나의 도메인이 여러 규칙에 동시에 해당할 수 있습니다. 예를 들어 files.example.cn은 완전한 도메인 규칙과 DOMAIN-SUFFIX,example.cn에 모두 해당할 수 있으며, 어느 규칙이 적용되는지는 앞에 배치된 규칙에 따라 달라집니다. 설정할 때는 ‘예외 규칙, 애플리케이션 규칙, 도메인 지역 규칙, IP 지역 규칙, 최종 대체 규칙’ 순서로 구성할 수 있습니다.

순서 규칙 유형 용도
1 DOMAIN 하나의 전체 도메인에 대한 예외 경로 처리
2 DOMAIN-SUFFIX 동일한 주 도메인과 하위 도메인 처리
3 DOMAIN-KEYWORD 키워드 매칭을 보완하되 적용 범위는 제한
4 GEOSITE 또는 도메인 규칙 집합 관리되는 도메인 집합에 따라 지역 분류
5 IP-CIDR、GEOIP 연결 대상이 IP로 확인된 경우 판단
6 MATCH 앞에서 매칭되지 않은 모든 연결 처리

DOMAIN-KEYWORD는 적용 범위가 넓습니다. 키워드가 너무 짧으면 이름은 비슷하지만 용도가 전혀 다른 도메인까지 매칭될 수 있습니다. 전체 도메인이나 접미사로 표현할 수 있다면 더 정확한 규칙을 우선 사용하세요. 프로세스 규칙도 신중하게 사용해야 합니다. PROCESS-NAME은 운영체제와 커널에서 프로세스 정보를 가져와야 하므로 일부 플랫폼, 컨테이너 환경 또는 일반 시스템 프록시만 활성화한 경우 프로세스 식별 결과가 일관되지 않을 수 있습니다.

MATCH는 규칙 목록의 마지막에 있어야 합니다. 중간에 배치하면 뒤의 규칙은 실행될 기회를 영원히 잃습니다. ‘국내 지역은 직접 연결하고 나머지는 프록시로 보낸다’는 목표라면 마지막에 보통 MATCH,미분류 트래픽을 작성합니다. 이렇게 하면 새 도메인, 지리 데이터가 없는 주소와 분류할 수 없는 연결에도 명확한 처리 경로가 생깁니다.

국내외 트래픽을 위한 YAML 규칙 작성법

다음은 비교적 보수적인 규칙 예시입니다. 먼저 루프백 주소와 일반적인 사설 네트워크 대역을 직접 연결하고, 지정된 도메인을 처리한 뒤 국내 도메인과 IP 데이터를 기준으로 직접 연결을 시도하며, 남은 트래픽은 정책 그룹으로 보냅니다. 이 조각은 Clash Meta（mihomo）에서 흔히 사용하는 설정에 적합합니다. 이전 버전의 원본 Clash 커널을 사용한다면 클라이언트가 GEOSITE를 지원하는지 확인하고, 필요하면 호환되는 rule-provider 도메인 규칙 집합으로 교체하세요.

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,local,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-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve

  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN,api.example.net,해외 트래픽

  - GEOSITE,CN,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,미분류 트래픽

no-resolve를 IP 규칙 끝에 자주 넣는 이유

규칙 매칭이 IP 유형에 도달했을 때 현재 연결에 도메인만 있다면 일부 구현은 대상 IP를 얻기 위해 DNS 조회를 시작할 수 있습니다. no-resolve를 추가하면 매칭을 위해 이 규칙이 추가 DNS 조회를 발생시키지 않습니다. 따라서 규칙 처리 단계에서 발생하는 조회를 줄이고, 해석 경로 차이로 대기 시간이 늘어나는 것도 방지할 수 있습니다.

다만 no-resolve가 Clash가 DNS를 완전히 무시한다는 뜻은 아닙니다. 연결 자체는 현재 DNS 모드에 따라 도메인을 처리해야 합니다. 이 옵션은 해당 IP 규칙의 매칭 동작만 제한합니다. Fake-IP 모드에서는 도메인이 보통 예약 주소로 먼저 매핑되며, 커널은 도메인 정보를 유지한 채 도메인 규칙을 실행할 수 있습니다. 실제 연결을 수립할 때 설정에 따라 대상 주소를 다시 해석합니다.

GEOIP,CN,DIRECT로 모든 국내 지역 웹사이트를 처리할 수 있을까

GEOIP를 유일한 판단 기준으로 사용할 수는 없습니다. 웹사이트는 글로벌 CDN, 클라우드 서비스 또는 지역 간 트래픽 분산을 사용할 수 있어 동일한 도메인도 네트워크에 따라 서로 다른 주소를 반환할 수 있습니다. 일부 국내 서비스가 해외 주소를 사용할 수도 있고, 해외 서비스가 국내 지역에 노드를 배치할 수도 있습니다. 따라서 도메인 규칙은 일반적으로 GEOIP보다 앞에 배치해야 합니다. 알려진 서비스는 먼저 도메인으로 분류하고, 나머지 연결에 IP 지리 데이터를 보완적으로 적용하세요.

지리 데이터베이스는 커널이나 클라이언트와 함께 업데이트해야 합니다. 데이터베이스가 오래되면 새로 할당된 주소 대역이 잘못된 지역으로 분류될 수 있습니다. ‘같은 웹사이트가 기기마다 다른 정책을 사용하는’ 상황에서는 YAML뿐 아니라 GeoIP, GeoSite 데이터 버전과 DNS 응답 결과도 비교해야 합니다.

rule-provider로 대량의 도메인 관리하기

규칙이 늘어난 뒤에는 수천 개의 도메인을 기본 설정의 rules에 모두 넣지 않는 것이 좋습니다. mihomo와 규칙 제공자를 지원하는 Clash 클라이언트는 rule-providers를 통해 별도 규칙 파일을 불러온 다음, 규칙 목록에서 RULE-SET으로 참조할 수 있습니다. 기본 설정에는 우선순위만 남기고 구체적인 항목은 규칙 파일에서 관리하세요.

rule-providers:
  regional-direct:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/regional-direct.yaml
    url: https://rules.example.net/regional-direct.yaml
    interval: 86400

rules:
  - RULE-SET,regional-direct,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,미분류 트래픽

behavior: domain은 도메인 항목만 포함하는 규칙 집합에 적합합니다. 완전한 규칙 문법을 포함한다면 보통 classical을 사용하고, IP 네트워크 대역만 포함한다면 ipcidr을 사용할 수 있습니다. 규칙 파일의 내용은 behavior와 일치해야 하며, 그렇지 않으면 로드에 실패하거나 항목이 매칭되지 않을 수 있습니다. 원격 규칙 집합에는 로컬 path도 설정해 클라이언트가 다운로드 결과를 캐시할 수 있도록 하세요.

DNS, 시스템 프록시와 TUN 모드가 라우팅 결과에 미치는 영향

규칙을 올바르게 작성해도 실제 연결 경로는 트래픽을 가로채는 방식의 영향을 받습니다. 시스템 프록시를 활성화하면 일반적으로 시스템 프록시 설정을 따르는 애플리케이션만 Clash로 들어옵니다. 일부 게임, 명령줄 도구, 가상 머신 또는 직접 연결을 생성하는 프로그램은 시스템 프록시를 우회할 수 있습니다. TUN 모드를 활성화하면 커널이 더 넓은 범위의 IP 트래픽을 인계받을 수 있으므로 같은 규칙이 ‘더 많은 연결에 매칭되는’ 것처럼 보일 수 있습니다.

TUN 모드는 지역 규칙을 대신하지 않습니다. TUN은 트래픽이 커널로 들어오는 방식을 해결하고, 규칙은 들어온 트래픽이 어떤 경로로 갈지를 결정합니다. 애플리케이션 트래픽이 애초에 Clash를 거치지 않는다면 GEOIP, MATCH 또는 정책 그룹을 수정해도 결과는 바뀌지 않습니다. 문제를 확인할 때는 먼저 연결 패널에서 대상 연결이 나타나는지 확인한 다음 어떤 규칙에 매칭되었는지 살펴보세요.

DNS 역시 관찰 결과를 바꿀 수 있습니다. redir-host를 사용하면 규칙 판단이 실제 해석 주소에 더 의존할 수 있고, Fake-IP를 사용하면 커널이 더 이른 단계에서 도메인 정보를 유지할 수 있어 도메인 규칙이 적용되기 쉬워집니다. LAN 장치 이름, 프린터 도메인, 기업 내부 DNS와 실제 IP에 의존하는 일부 애플리케이션은 해당 도메인을 Fake-IP 제외 목록에 추가한 뒤 실제 요구에 맞춰 직접 연결 규칙을 보완할 수 있습니다.

클라이언트에서 IPv6를 동시에 활성화했는데 규칙이 IPv4 사설 대역만 포함한다면 LAN IPv6 연결이 최종 프록시 정책으로 넘어갈 수 있습니다. 네트워크 환경에 맞춰 IP-CIDR6 규칙을 추가하고 선택한 프록시 노드가 필요한 IPv6 연결을 지원하는지 확인하세요. IPv6를 완전히 끄면 일시적으로 현상이 달라질 수 있지만, 모든 환경의 고정 해결책이라기보다 원인을 파악하는 단계로 사용하는 편이 적절합니다.

설정 검증: 문법 검사부터 규칙 매칭 기록까지

YAML은 들여쓰기에 민감합니다. 목록 항목 앞의 공백, 콜론 뒤의 공백과 이름 인용 방식이 로드 결과에 영향을 줄 수 있습니다. 정책 그룹 이름에는 한글이나 공백을 사용할 수 있지만, 규칙 대상은 정책 그룹 이름과 글자 단위로 일치해야 합니다. 수정이 끝나면 먼저 클라이언트의 설정 검사 기능을 사용하세요. 명령줄에서 mihomo를 실행한다면 설정 디렉터리를 대상으로 테스트할 수도 있습니다.

mihomo -t -d /etc/mihomo

테스트 통과는 설정을 해석할 수 있다는 뜻일 뿐, 모든 규칙이 예상대로 작동한다는 의미는 아닙니다. 다음 순서로 검증하는 것이 좋습니다.

  1. 설정을 다시 불러온 뒤 정책 그룹이 표시되는지, 프록시 제공자와 규칙 집합에 업데이트 오류가 없는지 확인합니다.
  2. 라우터 관리 주소나 LAN 장치에 접속해 연결 기록에 DIRECT가 표시되는지 확인합니다.
  3. 도메인 규칙에 명시적으로 추가한 사이트에 접속해 매칭된 규칙 이름과 대상 정책을 확인합니다.
  4. 국내에서 자주 사용하는 사이트에 접속해 도메인 규칙과 GEOIP 규칙이 각각 적용되는지 관찰합니다.
  5. 명시적 규칙에 작성하지 않은 해외 사이트에 접속해 최종적으로 MATCH가 ‘미분류 트래픽’으로 보내는지 확인합니다.
  6. ‘해외 트래픽’에서 노드를 바꾼 뒤 다시 연결해 정책 그룹의 선택이 새 연결에 영향을 주는지 확인합니다.

테스트할 때는 새 연결을 만들어야 합니다. 이미 존재하는 TCP, QUIC 또는 장시간 연결은 이전 경로를 계속 사용할 수 있어 정책 그룹을 바꿔도 즉시 이동하지 않습니다. 해당 탭이나 애플리케이션의 연결을 닫고 다시 접속해야 더 신뢰할 수 있는 결과를 얻을 수 있습니다. 브라우저가 DNS를 캐시하거나 연결을 재사용할 수도 있으므로 필요하면 클라이언트 연결 패널에서 기존 연결을 종료하세요.

로그의 규칙 이름은 ‘웹페이지가 열리는지’보다 진단에 더 유용합니다. 페이지 로딩 실패는 노드, DNS, TLS, 대상 서버 또는 네트워크 경로에서 발생할 수 있습니다. 먼저 매칭된 규칙과 대상 정책을 확인해야 문제가 규칙 계층에 있는지 프록시 경로에 있는지 판단할 수 있습니다.

자주 발생하는 라우팅 이상과 점검 순서

국내 사이트가 프록시로 연결되는 경우

먼저 연결 기록의 대상 호스트와 매칭 규칙을 확인하세요. MATCH에 바로 매칭된다면 앞의 도메인 집합과 GEOIP가 해당 대상을 처리하지 못한 것입니다. 안정적인 도메인에는 DOMAIN-SUFFIX 규칙을 추가하거나 GeoSite 및 GeoIP 데이터를 업데이트할 수 있습니다. 연결 기록에 IP만 표시된다면 DNS 모드, 애플리케이션이 IP로 직접 연결하는지 여부와 도메인 스니핑 관련 설정을 확인하세요.

해외 사이트가 직접 연결되는 경우

범위가 지나치게 넓은 직접 연결 규칙이 있는지 확인하세요. 예를 들어 너무 짧은 DOMAIN-KEYWORD, 잘못된 도메인 접미사 또는 앞쪽에 배치된 MATCH,DIRECT가 원인일 수 있습니다. 정책 그룹에서 현재 DIRECT를 수동으로 선택한 상태인지도 확인해야 합니다. 규칙이 ‘해외 트래픽’에 매칭되었다고 해서 반드시 프록시를 사용하는 것은 아닙니다. 해당 정책 그룹 안에서 직접 연결이 선택되어 있을 수도 있습니다.

LAN 장치에 접속할 수 없는 경우

사설 네트워크 대역 규칙이 최종 대체 규칙보다 앞에 있는지 확인하고, LAN에서 실제로 사용하는 주소 대역도 점검하세요. 일반적인 가정용 네트워크는 192.168.0.0/16인 경우가 많지만, 사무실 네트워크, 가상 네트워크와 컨테이너는 10.0.0.0/8 또는 172.16.0.0/12를 사용할 수 있습니다. 장치 이름으로 접속한다면 로컬 DNS, mDNS 또는 검색 도메인이 원격 해석 경로의 영향을 받지 않는지도 확인해야 합니다.

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

구독으로 생성된 기본 설정을 직접 편집하면 클라이언트가 구독을 업데이트할 때 파일을 다시 작성하는 경우가 많습니다. 사용자 지정 내용은 클라이언트가 지원하는 오버라이드, Merge 또는 스크립트 설정으로 옮기세요. 안정적인 규칙을 직접 관리하는 rule-provider에 넣는 방법도 있습니다. 업데이트 순서는 구독 노드 업데이트, 오버라이드 로드, 규칙 집합 업데이트와 설정 검사 순서로 유지하는 것이 좋습니다.

규칙은 올바르지만 애플리케이션 연결 기록이 없는 경우

대개 규칙 순서의 문제가 아니라 트래픽이 Clash로 들어오지 않은 것입니다. 시스템 프록시가 활성화되어 있는지, 애플리케이션이 프록시 설정을 따르는지, 터미널에 프록시 환경 변수가 설정되어 있는지, TUN 모드가 정상적으로 시작되었는지 확인하세요. TUN을 사용할 때는 라우팅 충돌, 권한, 다른 VPN 소프트웨어와 가상 네트워크 인터페이스 상태도 점검해야 합니다. 먼저 연결이 패널에 표시되도록 한 뒤 매칭된 규칙을 분석하세요.

관리하기 쉬운 설정을 위한 최종 점검 목록

  • LAN 및 루프백 주소 규칙이 지역 규칙보다 앞에 있습니다.
  • 구체적인 도메인 규칙이 광범위한 키워드 및 GEOIP 규칙보다 앞에 있습니다.
  • 규칙이 쉽게 바뀌는 노드 이름이 아니라 고정된 정책 그룹을 참조합니다.
  • MATCH가 규칙 목록의 마지막에만 있으며 명확한 최종 대체 정책을 가리킵니다.
  • 도메인 규칙 집합과 IP 규칙 집합의 behavior가 콘텐츠 형식과 일치합니다.
  • IPv4, IPv6, DNS 모드와 트래픽 인계 방식이 현재 네트워크 환경에 맞습니다.
  • 구독 내용과 개인 오버라이드를 분리했으며, 업데이트 후 문법 및 매칭 테스트를 다시 실행할 수 있습니다.

지역 라우팅에는 모든 네트워크에 영구적으로 적용할 수 있는 단 하나의 규칙이 없습니다. 더 신뢰할 수 있는 방법은 먼저 명확한 네 단계 구조를 만들고 연결 기록을 바탕으로 소수의 예외를 보완하는 것입니다. 정책 그룹 이름이 안정적이고 규칙 순서를 읽기 쉬우며 최종 대체 동작이 명확하다면 구독 노드와 지리 데이터가 업데이트되어도 설정 유지 비용을 낮게 유지할 수 있습니다.

Clash 다운로드