고급 설정 예상 읽기 시간 12분

Clash 사용자 지정 규칙 문법 완벽 가이드: 매칭 순서·우선순위·규칙 덮어쓰기

자주 쓰는 규칙 유형, 위에서 아래로 적용되는 매칭 방식, 최종 규칙의 위치와 사용자 지정 규칙이 적용되지 않을 때 확인할 사항을 정리합니다.

Clash의 규칙 시스템은 새 연결을 어떤 정책 그룹, 프록시 노드 또는 직접 연결 동작으로 보낼지 결정합니다. 대부분의 ‘규칙이 적용되지 않음’ 문제는 문법 자체가 완전히 잘못되어서가 아니라, 연결이 더 앞선 규칙에 먼저 매칭되었거나 수정 내용이 구독 갱신으로 교체되는 파일에 저장되었거나 테스트 트래픽이 현재 실행 중인 커널로 들어가지 않았기 때문에 발생합니다.

규칙을 읽을 때는 도메인, 대상 IP, 프로세스, 포트와 네트워크 프로토콜을 서로 다른 매칭 조건으로 구분해야 합니다. 규칙 목록은 ‘더 구체적으로 보이는’ 항목을 기준으로 자동 정렬되지 않으며, 한 줄이 더 길다고 우선순위가 높아지지도 않습니다. 실제 판단은 보통 rules 목록을 위에서 아래로 따라가며 진행되고, 처음 매칭되는 순간 해당 규칙의 정책을 즉시 적용합니다. 이후 규칙은 해당 연결의 판단에 참여하지 않습니다.

매칭 모델: 연결이 특정 규칙에 도달하는 과정

애플리케이션이 접속을 시작하면 Clash 또는 mihomo 커널은 대상 정보를 확보해야 합니다. 브라우저 프록시 요청에서는 커널이 보통 대상 도메인을 직접 확인할 수 있습니다. 반면 일부 투명 프록시나 TUN 트래픽에서는 먼저 대상 IP를 얻은 뒤 DNS 매핑, 스니핑 결과와 연결 메타데이터를 조합해 도메인을 복원할 수 있습니다. 이용 가능한 정보가 다르면 같은 규칙 집합도 연결 방식에 따라 서로 다른 매칭 결과를 보일 수 있습니다.

규칙 목록에 특정 전체 도메인에 대한 직접 연결 규칙, 해당 도메인의 접미사에 대한 프록시 규칙, 마지막 최종 규칙이 순서대로 있다고 가정해 보겠습니다. 전체 도메인에 접속하면 첫 번째 규칙이 이미 매칭되므로 접미사 규칙은 실행되지 않습니다. 접미사 규칙을 앞에 두면 전체 하위 도메인 범위를 먼저 처리하게 되어 뒤에 있는 전체 도메인 예외가 작동하지 않습니다. 따라서 규칙을 작성할 때는 보통 범위가 좁은 예외를 범위가 넓은 규칙보다 앞에 배치합니다.

rules:
  - DOMAIN,updates.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,노드 선택
  - MATCH,최종 처리

위 예시에서는 updates.example.com이 직접 연결되고, example.com을 접미사로 사용하는 나머지 도메인은 ‘노드 선택’으로 전달되며, 남은 연결은 ‘최종 처리’로 넘어갑니다. 여기서 ‘노드 선택’과 ‘최종 처리’는 설정에 실제로 존재하는 정책 그룹 이름이어야 합니다. 이름에 포함된 한글, 공백과 대소문자는 proxy-groups 정의와 정확히 일치해야 합니다.

규칙 매칭과 노드 사용 가능 여부는 별개의 단계입니다

규칙 매칭은 연결을 어디로 보낼지만 결정하며, 정책 그룹에서 선택한 노드가 반드시 작동한다는 뜻은 아닙니다. 예를 들어 로그에 연결이 이미 ‘노드 선택’으로 매칭되었는데도 페이지가 열리지 않는다면 정책 그룹의 현재 선택, 노드 연결 상태, DNS 응답, TLS 핸드셰이크 또는 상위 네트워크에 문제가 있을 수 있습니다. 반대로 노드 속도 측정이 정상이라고 해서 사용자 지정 도메인 규칙이 매칭되었다는 뜻도 아닙니다. 속도 측정 주소와 실제 접속 대상은 대개 다르므로 별도로 확인해야 합니다.

자주 쓰는 규칙 문법과 적용 범위

일반적인 규칙은 쉼표로 구분하는 형식을 사용합니다. 첫 번째 항목은 규칙 유형, 중간 항목은 매칭 대상, 그다음은 대상 정책이며, 마지막에는 해당 유형이 지원하는 추가 매개변수가 올 수 있습니다. 지원되는 규칙 유형은 커널과 클라이언트 버전에 따라 완전히 같지 않으며, 특히 프로세스, 인바운드, 규칙 집합과 논리 조합 관련 기능에서 차이가 있습니다. 편집하기 전에 클라이언트가 기존 Clash 커널을 사용하는지 Clash Meta(mihomo) 커널을 사용하는지 확인하고, 해당 커널의 설정 문서와 실행 로그를 기준으로 판단하세요.

DOMAIN: 정확한 도메인

DOMAIN은 지정한 전체 호스트 이름만 매칭하므로 단일 예외를 설정할 때 적합합니다. 해당 도메인의 다른 하위 도메인까지 자동으로 포함하지는 않습니다. 예를 들면 다음과 같습니다.

- DOMAIN,api.example.com,DIRECT

이 규칙은 api.example.com과 매칭되지만 img.api.example.com과는 매칭되지 않습니다. 한 사이트가 메인 사이트, API, 이미지와 다운로드 등 여러 하위 도메인을 함께 사용한다면 각각 작성하거나 도메인 전체 범위를 포함하는 접미사 규칙을 사용해야 합니다.

DOMAIN-SUFFIX: 도메인 접미사

DOMAIN-SUFFIX은 특정 도메인과 그 하위 도메인을 매칭하며, 사이트 단위 라우팅에 적합합니다.

- DOMAIN-SUFFIX,example.com,노드 선택

example.com, www.example.com과 더 깊은 하위 도메인까지 포함할 수 있습니다. 접미사 규칙은 범위가 넓으므로 그중 특정 업데이트 도메인만 직접 연결하려면 해당 DOMAIN 예외를 접미사 규칙보다 앞에 배치해야 합니다.

DOMAIN-KEYWORD: 도메인 키워드

DOMAIN-KEYWORD는 도메인에 지정한 텍스트가 포함되어 있는지 확인합니다. 짧게 작성할 수 있지만 예상보다 넓은 범위에 잘못 매칭되는 경우가 많습니다. 예를 들어 music이라는 키워드는 서로 관련 없는 여러 도메인과 매칭될 수 있습니다. 대상 도메인의 구조가 자주 바뀌면서도 안정적인 특징이 있는 경우가 아니라면 정확한 도메인이나 도메인 접미사를 우선 사용하세요.

- DOMAIN-KEYWORD,example,노드 선택

IP-CIDR 및 IP-CIDR6: 대상 주소 대역

IP-CIDR은 IPv4 주소 대역을, IP-CIDR6은 IPv6 주소 대역을 매칭합니다. 사설 네트워크, 고정 서비스 주소와 명확하게 공지된 네트워크 대역에 적합합니다.

- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR6,fd00::/8,DIRECT,no-resolve

no-resolve는 이 IP 규칙을 매칭할 때 IP를 얻기 위해 도메인을 추가로 조회하지 않는다는 뜻입니다. 기존 대상 IP만 확인하면 되는 사설 주소 대역 등에 자주 사용됩니다. 이 매개변수를 추가할지는 규칙의 목적에 따라 결정해야 합니다. 도메인 연결을 해석한 뒤 특정 IP 대역 판단에도 참여시키려면 모든 IP 규칙에 기계적으로 no-resolve를 붙여서는 안 됩니다.

GEOIP, GEOSITE 및 규칙 데이터

GEOIP은 대상 IP가 속한 지리 데이터베이스 분류를 기준으로 매칭하고, mihomo에서는 일반적으로 GEOSITE을 사용해 도메인 집합을 분류하기도 합니다. 이러한 규칙은 클라이언트가 불러온 지리 데이터 파일에 의존하며 데이터 버전에 따라 매칭 결과도 달라집니다. 넓은 범위를 분류하는 데는 적합하지만 모든 도메인과 주소가 영구적으로 같은 분류에 남는다는 뜻은 아닙니다. 안정적인 예외가 필요하다면 분류 규칙보다 앞에 정확한 규칙을 추가하세요.

- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,노드 선택

기존 Clash 계열이 GEOSITE 문법이나 데이터 로드 방식을 동일하게 지원한다고 보장할 수는 없습니다. 설정 검사에서 알 수 없는 규칙 유형이라고 표시되면 들여쓰기를 계속 바꾸기보다 먼저 커널의 지원 범위를 확인하세요.

포트, 네트워크 프로토콜 및 프로세스 규칙

DST-PORT는 대상 포트에 따라 라우팅하고, NETWORK는 TCP와 UDP를 구분합니다. 프로세스 규칙은 프로그램 이름이나 경로로 매칭할 수 있지만 운영체제 권한, 커널 구현과 클라이언트가 관련 메타데이터를 제공하는지에 따라 달라집니다. 모바일 운영체제, 제한된 샌드박스와 일부 투명 프록시 환경에서는 커널이 프로세스 정보를 안정적으로 가져오지 못할 수 있습니다.

- DST-PORT,22,업무 회선
- NETWORK,UDP,저지연 회선
- PROCESS-NAME,example.exe,DIRECT

포트 규칙은 신중하게 배치해야 합니다. 443처럼 일반적인 포트는 다양한 서비스가 함께 사용하므로 도메인 규칙보다 앞에 두면 거의 모든 HTTPS 연결이 먼저 처리될 수 있습니다. 프로세스 규칙도 프로그램 이름만으로 보안 경계를 판단해서는 안 됩니다. 애플리케이션이 다른 시스템 프로세스를 호출해 연결을 생성할 수 있기 때문입니다.

순서와 우선순위: 더 정확한 규칙도 적용되지 않는 이유

규칙 목록에는 자동으로 계산되는 ‘정확도 우선순위’가 없습니다. DOMAIN이 앞에 있는 DOMAIN-SUFFIX을 자동으로 이기는 것도 아니며, 작은 IP 대역이 앞의 큰 대역보다 자동으로 우선되지도 않습니다. 앞선 규칙의 조건이 충족되면 현재 연결은 더 아래로 내려가지 않습니다. 따라서 사용자 지정 목록은 보통 ‘명확한 예외, 구체적인 분류, 넓은 범위의 집합, 지리 분류, 최종 처리’ 순서로 구성합니다.

  1. 로컬 및 필수 직접 연결 예외: 로컬 네트워크 주소, 라우터 관리 도메인, 사내 네트워크 또는 직접 연결이 명시된 업데이트 서비스입니다.
  2. 정확한 도메인 및 프로세스 예외: 뒤에 오는 접미사 규칙, 규칙 집합 또는 지리 분류를 덮어쓸 때 사용합니다.
  3. 사이트 단위 접미사 규칙: 안정적인 하위 도메인 그룹을 하나의 정책으로 전달합니다.
  4. 규칙 집합: 대규모 도메인, 주소 대역 또는 서비스 분류를 관리합니다.
  5. GEOIP, GEOSITE 등 넓은 범위의 판단: 앞선 규칙에 포함되지 않은 연결을 처리합니다.
  6. MATCH 최종 처리: 아직 매칭되지 않은 나머지 트래픽을 받아 목록 마지막에 배치합니다.

MATCH는 남은 연결과 매칭하므로 그 뒤의 일반 규칙은 실제 실행 중 적용될 기회가 거의 없습니다. 일부 오래된 설정은 비슷한 최종 처리 의미로 FINAL을 사용하지만, 커널마다 허용하는 이름이 다를 수 있습니다. 설정을 마이그레이션할 때는 텍스트만 바꾸지 말고 먼저 설정 검사를 실행한 뒤 커널 로그를 확인하세요.

하나의 도메인에서도 여러 연결이 발생할 수 있습니다

웹 페이지 접속은 단일 요청이 아닙니다. 기본 문서, 정적 리소스, 동영상, 통계 API와 서드파티 로그인은 서로 다른 도메인에서 제공될 수 있으며, HTTP/3는 UDP를 사용할 수도 있습니다. 메인 도메인이 원하는 정책에 매칭되었다고 해서 페이지의 모든 연결이 같은 경로를 사용한다는 뜻은 아닙니다. 사이트 문제를 확인할 때는 주소창의 도메인에 규칙 하나만 추가하지 말고 연결 목록이나 로그에서 실제로 실패한 호스트 이름, 대상 포트, 네트워크 프로토콜과 매칭 규칙을 확인해야 합니다.

DNS 결과가 IP 규칙 확인에 미치는 영향

도메인 규칙은 커널이 파악한 호스트 이름을 기준으로 판단하고, IP 규칙은 대상 주소에 의존합니다. 애플리케이션이 암호화된 DNS를 직접 사용하거나 캐시된 IP에 바로 연결하거나 TUN 스니핑으로 도메인을 복원하지 못하면 로그에 IP만 표시될 수 있습니다. 이때 도메인 규칙에는 매칭에 필요한 정보가 없을 수 있습니다. 반대로 fake-ip 모드에서는 커널이 가상 주소와 도메인 사이의 매핑을 유지하므로 연결 화면에 표시된 주소만 보고 실제 상위 서버의 IP를 판단할 수 없습니다. DNS 모드, 로그의 도메인 필드와 최종 규칙 이름을 함께 확인해야 합니다.

규칙 집합과 RULE-SET: 대규모 설정 나누기

규칙이 많을 때는 mihomo 등의 커널에서 rule-providers로 외부 규칙 집합을 정의한 다음 기본 규칙 목록에서 RULE-SET으로 참조할 수 있습니다. 이렇게 하면 도메인 분류, 주소 대역과 기본 설정을 분리해 관리할 수 있습니다. 규칙 집합이 자동으로 더 높은 우선순위를 얻는 것은 아닙니다. 기본 rules 목록에서 참조된 위치가 여전히 매칭 시점을 결정합니다.

rule-providers:
  work-services:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/work-services.yaml
    url: https://example.com/rules/work-services.yaml
    interval: 86400

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - RULE-SET,work-services,업무 회선
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

behavior는 집합 콘텐츠의 구성 방식을 나타냅니다. 일반적인 값으로 classical, domain, ipcidr가 있습니다. classical 집합에는 유형이 포함된 규칙 항목을 넣을 수 있고, 도메인 집합과 주소 대역 집합은 각각 해당 형식에 맞는 내용이어야 합니다. 집합을 domain으로 선언해 놓고 완전한 classical 규칙 문자열을 넣으면 제공자가 다운로드에는 성공하더라도 파싱에 실패하거나 설정 검사 단계에서 바로 오류가 발생할 수 있습니다.

원격 집합에는 업데이트 시각, 캐시 경로와 네트워크 접근성도 영향을 줍니다. 처음 시작할 때 집합이 아직 다운로드되지 않았는데 현재 설정이 집합에 의존하면 클라이언트가 초기화 실패를 표시할 수 있습니다. 문제를 확인할 때는 제공자 상태, 마지막 업데이트 시각과 파싱 오류를 확인해야 하며, 집합 URL이 브라우저에서 열리는지만 테스트해서는 안 됩니다. URL에 접근할 수 있다는 것은 파일을 다운로드할 수 있다는 뜻일 뿐, 콘텐츠 형식이 현재 커널의 요구 사항에 맞는다는 뜻은 아닙니다.

여러 집합이 겹칠 때 적용 결과를 결정하는 방법

두 규칙 집합에 같은 도메인이 포함되거나 주소 대역이 겹칠 수 있습니다. 결과를 결정하는 것은 집합의 업데이트 시각이나 항목 수가 아니라 기본 규칙 목록에서 두 RULE-SET 참조가 배치된 순서입니다. 공개 집합을 덮어써야 한다면 먼저 로컬의 정확한 예외를 배치하고, 그다음 자체 소규모 집합을 참조한 뒤, 마지막에 더 넓은 공개 집합을 참조할 수 있습니다.

rules:
  - DOMAIN,build.example.com,DIRECT
  - RULE-SET,my-exceptions,전용 회선
  - RULE-SET,public-services,노드 선택
  - MATCH,최종 처리

이 구조는 대형 공개 집합을 그대로 복사해 수정하는 것보다 관리하기 쉽습니다. 예외가 명확하게 드러나고 공개 집합이 업데이트되어도 전체 파일을 다시 병합할 필요가 없기 때문입니다.

구독 업데이트, 덮어쓰기 및 설정 영구 적용

많은 데스크톱 및 모바일 클라이언트는 원격 구독을 로컬 설정 파일로 다운로드합니다. 이 생성 파일을 직접 편집하면 즉시 적용될 수 있지만 다음 자동 업데이트, 수동 새로 고침 또는 구독 전환 시 변경 내용이 새 콘텐츠로 교체되는 경우가 많습니다. 안정적으로 사용하려면 클라이언트가 제공하는 덮어쓰기, 병합, 확장 스크립트 또는 로컬 설정 기능을 이용해 사용자 지정 규칙을 구독 파일과 분리해 저장하세요.

클라이언트마다 ‘앞쪽 규칙’, ‘뒤쪽 규칙’과 ‘병합 규칙’을 처리하는 방식이 다릅니다. 앞쪽 규칙은 구독 규칙보다 먼저 적용되어야 하므로 정확한 예외에 적합합니다. 뒤쪽 규칙을 구독에 포함된 MATCH 뒤에 추가하면 실제 효과가 없습니다. 덮어쓰기 화면을 사용한 뒤에는 최종 생성 설정이나 실행 로그를 열어 규칙이 원하는 위치에 실제로 삽입되었는지 확인하세요.

정책 그룹 이름도 의존 항목입니다

사용자 지정 규칙에서 ‘업무 회선’을 참조한다면 최종 설정에도 같은 이름의 정책 그룹이 존재해야 합니다. 구독 제공자가 그룹 이름을 바꾸거나 클라이언트가 설정을 변환하거나 병합 스크립트가 정책 그룹 이름을 변경하면 규칙이 존재하지 않는 대상을 가리켜 로드에 실패할 수 있습니다. 보다 안정적인 방법은 사용자 지정 정책 그룹도 같은 영구 적용 방식을 통해 주입하고, 자주 바뀌는 표시 이름에 의존하지 않는 것입니다.

수정 후 실행 중인 설정을 다시 불러와야 합니다

YAML 파일을 저장했다고 해서 실행 중인 커널이 새 규칙을 즉시 사용하는 것은 아닙니다. 일부 클라이언트는 자동으로 다시 불러오지만, 일부는 적용 버튼을 누르거나 설정을 다시 선택하거나 커널을 재시작해야 합니다. 다시 로드되었는지 확인하려면 설정 업데이트 시각, 커널 로그와 연결 상세 정보의 규칙 변화를 확인하세요. 이미 연결된 장시간 연결은 생성 당시의 경로를 계속 사용할 수 있으므로 테스트할 때는 관련 애플리케이션 연결을 닫고 페이지를 새로 고치거나 기존 연결이 종료될 때까지 기다려야 합니다.

사용자 지정 규칙이 적용되지 않을 때 단계별 점검

문제 해결은 ‘현재 실제로 무엇이 실행 중인가’를 확인하는 것부터 시작해 매칭 조건을 차례로 점검해야 합니다. DNS를 반복해서 변경하거나 TUN을 전환하거나 노드를 바꾸거나 클라이언트를 재설치하면 여러 변수가 동시에 생겨 오히려 원인을 파악하기 어려워집니다. 다음 순서는 도메인 규칙, IP 규칙과 규칙 집합에서 발생하는 대부분의 문제에 적용할 수 있습니다.

  1. 올바른 설정을 사용 중인지 확인하세요.

    클라이언트에서 현재 선택된 구독 또는 설정 이름과 마지막 로드 시각을 확인하세요. 설정 사본이 여러 개라면 수정한 파일이 커널이 현재 읽는 파일인지 확인해야 합니다.

  2. 먼저 설정을 검사하세요.

    클라이언트의 설정 검사 결과와 커널 시작 로그를 확인하세요. YAML 들여쓰기, 쉼표 구분, 알 수 없는 규칙 유형, 중복 키, 규칙 집합 파싱 실패와 존재하지 않는 정책 그룹을 중점적으로 살펴보세요.

  3. 트래픽이 Clash로 들어오는지 확인하세요.

    시스템 프록시가 꺼져 있거나 애플리케이션이 프록시를 우회하거나 앱 자체의 프록시 설정이 시스템 설정을 덮어쓰거나 TUN이 시작되지 않으면 연결이 규칙 엔진을 통과하지 않습니다. 연결 목록에 테스트 트래픽이 전혀 보이지 않는다면 먼저 트래픽을 가로채는 방식을 확인해야 합니다.

  4. 실제로 매칭된 규칙을 확인하세요.

    연결 상세 정보나 로그에서 대상 도메인, 대상 IP, 프로세스, 포트, 네트워크 프로토콜, 규칙 유형과 정책 이름을 찾으세요. 앞쪽의 넓은 규칙에 매칭되었다면 같은 도메인을 반복해서 추가하지 말고 순서를 조정해야 합니다.

  5. 도메인 및 IP 조건이 확인 가능한지 점검하세요.

    로그에 IP만 표시되면 도메인 규칙에 필요한 매칭 정보가 없을 수 있습니다. 이미 도메인 규칙에 매칭되었다면 뒤에 있는 IP 규칙을 계속 의심할 필요가 없습니다. DNS 모드, 스니핑 설정과 애플리케이션 동작을 함께 확인하세요.

  6. 정책 그룹의 현재 선택을 확인하세요.

    규칙이 올바른 정책 그룹으로 전달된 뒤 그룹에서 현재 선택된 항목이 특정 노드인지, 자동 테스트 그룹인지, 직접 연결인지 또는 거부 동작인지 확인하세요. 정책 그룹 선택 오류와 규칙 순서 오류는 겉으로 같은 결과로 나타날 수 있습니다.

  7. 기존 연결과 캐시를 제외하세요.

    테스트 애플리케이션의 기존 연결을 닫고 필요한 경우 앱의 DNS 캐시를 비운 다음 새 연결을 시작하세요. 규칙은 주로 연결을 설정하는 단계에서 판단되므로 이미 존재하는 세션은 목록을 수정해도 자동으로 다시 매칭되지 않습니다.

  8. 구독을 새로 고친 뒤 결과를 확인하세요.

    구독을 한 번 수동으로 업데이트해 사용자 지정 규칙이 여전히 존재하고 위치가 바뀌지 않았는지 확인하세요. 새로 고친 뒤 사라진다면 클라이언트가 지원하는 덮어쓰기 또는 병합 기능으로 옮겨야 합니다.

전체 설정보다 최소한의 테스트가 원인 파악에 유리합니다

수천 개의 규칙을 사용하는 경우 충분히 정확하고 결과가 분명한 테스트 규칙 하나를 임시로 추가해 목록 앞부분에 배치할 수 있습니다. 예를 들어 테스트 도메인을 별도 정책 그룹으로 보내고 새 연결의 매칭 기록을 확인하세요. 테스트가 끝나면 진단용으로만 남은 라우팅 항목이 장기간 유지되지 않도록 해당 규칙을 삭제해야 합니다.

rules:
  - DOMAIN,test.example.com,진단 회선
  - RULE-SET,main-services,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,최종 처리

가장 앞에 둔 정확한 규칙에도 매칭 기록이 나타나지 않는다면 먼저 트래픽이 현재 커널을 통과하는지, 도메인이 실제 요청과 일치하는지, 설정이 정상적으로 다시 로드되었는지를 확인하세요. 이 규칙은 매칭되지만 원래 규칙이 매칭되지 않는다면 네트워크 하위 설정을 먼저 바꾸지 말고 규칙 위치, 유형과 대상 정보를 비교하세요.

관리하기 쉬운 규칙 목록: 작동에서 검토 가능한 구성으로

장기적으로 사용할 설정은 규칙 수만 늘리는 데 집중해서는 안 됩니다. 범위가 넓은 규칙을 추가할 때마다 어떤 상황을 포함하는지, 왜 현재 위치에 배치했는지, 기존 집합과 겹치지 않는지를 설명할 수 있어야 합니다. 예외가 적은 사용자라면 정확한 도메인 규칙과 안정적인 최종 처리를 구성하는 편이 출처가 비슷한 대형 집합 여러 개를 쌓는 것보다 판단하기 쉽습니다.

  • 로컬 네트워크, 사내 네트워크와 장치 관리 주소를 명확한 직접 연결 영역에 배치하세요.
  • 단일 도메인 예외를 해당 접미사, 키워드와 규칙 집합보다 앞에 배치하세요.
  • 도메인 분류를 일반 포트 규칙으로 대신하지 마세요. 특히 80, 443과 같은 일반 포트를 너무 앞에서 매칭하지 않아야 합니다.
  • 규칙 집합의 콘텐츠와 일치하는 behavior를 선택하고 업데이트 및 파싱 상태를 정기적으로 확인하세요.
  • MATCH가 마지막에 있고 대상 정책 그룹이 실제로 존재하는지 확인하세요.
  • 클라이언트의 덮어쓰기 기능으로 개인화 규칙을 저장해 구독 생성 파일에 직접 의존하지 마세요.
  • 수정 후 설정을 다시 로드하고 새 연결을 사용해 로그의 실제 매칭 항목을 확인하세요.
  • mihomo로 마이그레이션하거나 클라이언트를 변경할 때는 규칙 유형과 확장 문법의 지원 여부를 다시 확인하세요.

명확한 규칙 설정은 위에서 아래로 각 단계를 설명할 수 있어야 합니다. 어떤 예외를 먼저 처리하고 어떤 분류로 넘어가며 남은 트래픽을 마지막에 무엇이 처리하는지를 보여줘야 합니다. 처음 매칭되는 규칙, 정보의 확인 가능 여부, 최종 설정과 정책 그룹 상태라는 네 가지 점검 포인트를 기억하면 대부분의 규칙 덮어쓰기 문제에서 로그를 통해 직접적인 단서를 찾을 수 있습니다.

구독 가져오기, 시스템 프록시, TUN과 DNS의 관계를 더 익히고 있다면 사이트의 사용 안내서와 설정 가이드를 계속 확인해 보세요. 규칙은 라우팅만 결정하며, 실제 연결을 완성하려면 클라이언트의 트래픽 가로채기 방식, DNS 설정과 정책 노드가 함께 작동해야 합니다.

Clash 다운로드