이 글의 목차
실제로 잘못된 경로를 사용하는 연결 하나에서 규칙을 시작하세요
규칙은 웹사이트 홈 제목이 아니라 실제 연결의 도메인, IP, 프로세스 같은 정보에 맞습니다. 한 페이지가 주 도메인, 로그인 도메인, 이미지 CDN, API를 동시에 요청할 수 있으므로 주소 표시줄만 보고 규칙 하나를 쓰면 페이지 일부만 고치는 경우가 많습니다.
노드를 고정하고 Rule 모드를 유지한 채 실패 동작을 반복해 Connections의 대상, 현재 일치 규칙, 출구를 기록하세요. 수정할 내용은 "이 연결이 왜 여기에서 먼저 일치했나"이며 인터넷의 규칙표 전체를 설정에 넣는 것이 아닙니다.
수정 전에 남길 네 항목
- 실패 연결의 완전한 도메인 또는 대상 IP
- 현재 표시된 규칙 유형과 내용
- 최종 사용 정책 그룹 또는 DIRECT
- 해당 연결이 실제로 사용해야 할 정책
Mihomo는 위에서 아래로 비교하고 첫 규칙에 맞으면 중단합니다
더 구체적인 규칙은 보통 넓은 규칙보다 앞에 둡니다. 아래에서는 api.example.com을 예시에 이미 정의된 "프록시 선택"으로 보내고 더 넓은 example.com 규칙은 DIRECT로 유지합니다. 마지막 MATCH가 앞에서 일치하지 않은 연결을 받습니다.
proxy-groups:
- name: 代理选择
type: select
include-all: true
proxies:
- DIRECT
rules:
- DOMAIN,api.example.com,代理选择
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,代理选择저장하고 설정을 다시 불러온 뒤 기존 페이지 연결을 닫고 새 요청을 시작하세요. Connections에 DOMAIN,api.example.com과 "프록시 선택"이 보이면 규칙과 순서가 함께 적용된 것입니다. 이전 결과가 계속 보이면 연결 재사용 또는 현재 Profile이 해당 수정 사항을 불러오지 않은 것일 수 있습니다.
같은 출처의 긴 목록에서만 rule-providers를 사용할 가치가 있습니다
로컬 도메인이 몇 개뿐이면 직접 규칙이 읽기 쉽습니다. 특정 프로젝트가 수십 개나 수백 개의 도메인 또는 IP를 관리하고 정기 업데이트해야 할 때 rule-providers로 데이터 소스와 주 설정을 분리하세요. 주 rules에서는 RULE-SET으로 provider를 참조하고 전체 그룹에 정책을 지정합니다.
provider는 규칙 데이터일 뿐 노드를 직접 선택하지 않습니다. 예시의 "RULE-SET,work-domains,프록시 선택"은 일치 결과를 이미 정의된 "프록시 선택"에 전달합니다. 자체 그룹 이름으로 바꾸면 proxy-groups와 rules 두 곳이 완전히 일치해야 합니다.
proxy-groups:
- name: 代理选择
type: select
include-all: true
proxies:
- DIRECT
rule-providers:
work-domains:
type: http
behavior: domain
format: yaml
url: https://rules.example.com/work.yaml
path: ./ruleset/work.yaml
interval: 86400
rules:
- RULE-SET,work-domains,代理选择
- MATCH,代理选择behavior는 파일 내용과 일치해야 합니다
rule-provider의 behavior
| 값 | 파일에 넣을 내용 | 적합하지 않은 내용 |
|---|---|---|
| domain | 도메인, 도메인 접미사 같은 도메인 집합 | IP 네트워크 범위 및 완전한 클래식 규칙 행 |
| ipcidr | IPv4 / IPv6 CIDR | DOMAIN, PROCESS-NAME 같은 조건 |
| classical | DOMAIN-SUFFIX,...처럼 유형이 포함된 완전한 규칙 | 순수 도메인만 관리할 때는 지나치게 장황함 |
format은 파일 인코딩 형태를 설명하며 yaml, text, mrs가 흔합니다. behavior와 format은 서로 다릅니다. 하나는 규칙 의미를 설명하고 다른 하나는 파일 저장 방식을 나타냅니다. 순수 도메인 텍스트를 ipcidr로 선언하면 다운로드는 성공해도 불러올 때 오류가 날 수 있습니다.
URL 접미사로 추측하지 말고 규칙 소스의 공식 형식 안내부터 확인하세요. 소스 파일 형식이 바뀐 뒤에도 클라이언트에 기존 캐시가 남을 수 있으며 로그의 provider 이름과 구문 분석 오류가 확인에 도움이 됩니다.
규칙 세트 업데이트 실패 시 url, interval, proxy, path를 확인하세요
- type
- http는 원격에서 업데이트하고 file은 로컬 파일을 읽으며 inline은 내용을 설정에 직접 넣습니다.
- url
- 원격 규칙 소스 주소입니다. 401, 403, 404, timeout은 HTTP 결과에 따라 처리하세요.
- interval
- 업데이트 간격의 단위는 초입니다. 지나치게 짧으면 요청만 늘고 규칙 정확도는 높아지지 않습니다.
- proxy
- 규칙 소스를 다운로드할 때 사용할 프록시를 지정합니다. 소스 사이트가 로컬에서 접근 가능하면 설정에 따라 직접 연결할 수도 있습니다.
- path
- 캐시 파일 경로입니다. Mihomo는 기본적으로 HomeDir 내부만 허용하며 외부 경로에는 SAFE_PATHS가 필요합니다.
provider 다운로드가 실패해도 기존 캐시를 계속 사용할 수 있으므로 "웹사이트가 열림"은 오늘 업데이트가 성공했다는 뜻이 아닙니다. provider의 이번 업데이트 시각과 로그를 확인하고 새 소스가 복원될 때까지 기존 캐시를 보관하세요. 규칙 파일 전체를 바로 삭제하지 마세요.
원격 구독은 덮어쓰이므로 사용자 지정 규칙은 덮어쓰기에 넣으세요
Profiles 디렉터리에 다운로드된 원격 YAML을 직접 편집하면 당장은 적용될 수 있지만 다음 구독 새로 고침에서 교체됩니다. Clash Verge Rev 같은 클라이언트는 원격 설정을 불러올 때 로컬 내용을 삽입하는 병합, 스크립트 또는 규칙 덮어쓰기 기능을 제공합니다. 메뉴는 버전마다 다르므로 현재 클라이언트의 Profile 덮어쓰기 페이지를 사용하세요.
우선 실행할 사용자 지정 규칙은 prepend 또는 같은 의미의 앞쪽 병합으로 구독의 넓은 규칙보다 앞에 넣어야 합니다. MATCH 뒤에 추가하면 파일에는 보여도 실행 중에는 절대 도달하지 않습니다.
prepend-rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,intranet.example,DIRECT다시 불러온 뒤 런타임 일치 결과를 확인하고 편집기에 해당 행이 있다는 사실만 보지 마세요
덮어쓰기 규칙 하나 검증
덮어쓰기 저장 및 활성화
사용 중인 원격 Profile에 연결되었는지 확인합니다.
설정 다시 불러오기
로그에 rule, provider 또는 proxy group 구문 분석 오류가 없어야 합니다.
기존 연결 닫기
브라우저가 수정 전에 만든 세션을 재사용하지 않게 합니다.
대상 동작 반복
Connections에서 새 규칙과 최종 정책을 읽습니다.
구독 수동 업데이트
업데이트 후 한 번 더 요청해 덮어쓰기가 사라지지 않았는지 확인합니다.
두 요청 모두 같은 사용자 지정 규칙에 맞아야 "현재 적용됨"과 "업데이트 후 유지됨"을 함께 입증할 수 있습니다. 편집기에서 문구를 검색할 수 있다는 사실만으로 Mihomo 실행 설정에 들어갔다고 볼 수 없습니다.
규칙이 적용되지 않으면 다운로드, 구문 분석, 참조, 순서의 네 계층을 확인하세요
provider download 401 / 403 / 404
원격 주소, 권한 또는 이전된 경로를 처리하세요. 규칙 구문은 아직 관여하지 않았습니다.
provider parse error
behavior, format, 소스 파일의 실제 내용을 대조하세요.
RULE-SET not found
rules의 참조 이름과 rule-providers 키 이름이 일치하지 않습니다.
proxy group not found
규칙 대상 그룹이 현재 구독에 없거나 이름이 바뀌었습니다.
규칙을 불러왔지만 항상 앞 규칙에 먼저 맞음
구체적인 규칙이 넓은 규칙과 MATCH보다 앞에 오도록 순서를 조정하세요.
구독 업데이트 후 사용자 지정 항목이 사라짐
원격 파일 직접 수정을 멈추고 현재 Profile에 연결된 덮어쓰기를 사용하세요.
추가한 모든 규칙은 실행 결과를 설명할 수 있어야 합니다
규칙이 많을수록 서로 가릴 가능성이 커집니다. 대상 도메인을 검증한 뒤 같은 페이지의 다른 연결도 예상대로 직접 연결되거나 프록시를 사용하는지 확인하세요. 규칙 세 개만 필요하다면 출처를 모르는 규칙 수만 개의 목록을 넣을 필요가 없습니다.
마지막에는 실행 결과를 한 문장으로 설명하세요. 어떤 연결이 어느 조건에 맞아 어느 정책 그룹으로 들어갔으며 구독 업데이트 후에도 같은지 적습니다. 설명할 수 없는 규칙은 당분간 추가하지 마세요. 이후 노드와 Profile 이름이 바뀌어도 관리하기 쉽습니다.
