적용 범위부터 확인합니다: 구독 파일 직접 수정이 아닌 OpenClash 덮어쓰기입니다
이 글은 OpenClash에서 사용자 지정 라우팅 규칙 하나를 추가하는 작업만 다룹니다. 검증 범위는 OpenWrt LuCI, OpenClash 안정 버전 v0.47.156, Mihomo 코어입니다. Clash for Windows, Clash Verge Rev, FlClash, 단독 Mihomo 설정에 이 메뉴 경로를 그대로 적용하지 마십시오.
검증 전에 프록시 모드를 rule로 설정합니다. Mihomo는 rule 모드에서 일반 라우팅 규칙을 위에서 아래로 평가합니다. global과 direct 모드로는 사용자 지정 규칙 일치 여부를 증명할 수 없습니다. OpenClash v0.47.156 영문 UI에서 “Services → OpenClash → Overwrite Settings → Rules Setting”을 열고 “Custom Clash Rules”를 켜면 (Priority)와 (Extended) 편집기가 나타납니다. 주변 메뉴는 LuCI 언어 팩에 따라 달라질 수 있습니다.
구독 원본을 바꾸지 않습니다:OpenClash는 시작할 때 사용자 내용을 임시 실행 YAML에 주입합니다. 원본 구독 파일에 규칙을 직접 추가하지 않으므로 구독 업데이트 후에도 덮어쓰기 화면에서 관리하는 것이 올바릅니다.
우선과 확장은 최종 삽입 위치가 다릅니다
두 편집기 모두 YAML을 저장하지만 병합 위치는 다릅니다. 기본 템플릿은 객체와 최상위 rules: 배열을 권장하고, 같은 객체에 rule-providers: 또는 sub-rules:를 정의할 수 있습니다. v0.47.156은 루트 YAML 배열도 받지만 이 형식에는 규칙만 넣을 수 있습니다. rule-providers를 병합하려면 객체 형식과 배열형 rules가 함께 있어야 하며, rules 배열은 비어 있어도 됩니다. sub-rules도 객체 형식을 사용하지만 병합 시 rules 항목은 필수가 아닙니다.
| 영역 | 저장 파일 | v0.47.156 삽입 위치 | 적합한 용도 |
|---|---|---|---|
| 우선 (Priority) | /etc/openclash/custom/openclash_custom_rules.list | 최종 rules 배열 맨 위 | 구독 규칙보다 먼저 일치해야 하는 정확한 예외 |
| 확장 (Extended) | /etc/openclash/custom/openclash_custom_rules_2.list | 기존 규칙 중 DST-PORT,80을 포함한 마지막 항목 앞, 없으면 첫 MATCH/FINAL 앞, 그것도 없으면 두 글자 국가 코드가 있는 첫 GEOIP 규칙 앞, 모두 없을 때만 맨 뒤 | 구독 앞쪽의 세부 규칙을 유지하는 보충 규칙 |
v0.47.156의 포트 앵커는 부분 문자열로 검사합니다:DST-PORT,8080도 DST-PORT,80을 포함하므로 앵커가 될 수 있습니다. GEOIP 대체 앵커는 GEOIP,CN,...처럼 두 글자 국가 코드를 가진 규칙만 인식합니다. 업그레이드 후에는 병합 순서를 다시 확인하십시오.
확장이 항상 MATCH 뒤에 추가된다는 뜻은 아닙니다. 스크립트는 사용자 지정 규칙을 넣기 전에 원본 구독의 앵커를 기록합니다. 첫 일치 규칙이 사용되므로 우선 영역에 범위가 넓은 MATCH나 FINAL을 넣지 마십시오.
검증할 수 있는 우선 규칙 하나로 시작합니다
아래 예시는 특정 호스트 이름 하나의 트래픽을 DIRECT로 보냅니다. app.example.net은 자리표시자이므로 연결 로그에서 확인한 실제 호스트 이름으로 바꾸십시오. DIRECT는 Mihomo 내장 처리 대상이므로 사용자 지정 그룹 이름 오류를 첫 테스트에서 배제할 수 있습니다.
OpenClash 우선 규칙rules:
- DOMAIN,app.example.net,DIRECT
- 변경 전 현상을 재현하고 호스트 이름, 일치한 규칙, 선택된 정책 그룹을 기록합니다.
- 글 마지막의 명령으로 두 사용자 지정 규칙 파일을 백업합니다. 파일이 아직 없다면 스위치가 꺼져 있고 편집기가 비어 있었음을 기록합니다.
- 사용자 지정 규칙을 켜고 YAML을
Priority편집기에 붙여넣습니다. - 두 칸 들여쓰기를 유지하고 DNS, Fake-IP, 구독, 모드를 함께 바꾸지 않습니다.
Apply Settings를 한 번 눌러 저장과 검증 가능한 재시작을 진행합니다.
규칙 대상 이름은 정확히 존재해야 합니다:마지막 필드는 DIRECT, REJECT, GLOBAL, REJECT-DROP, PASS, COMPATIBLE 같은 지원 대상이거나 현재 프록시 그룹, 프록시, 하위 규칙 이름과 대소문자까지 일치해야 합니다. 모두 네트워크 출구를 뜻하는 것은 아닙니다. PASS는 다음 규칙을 계속 검사하고 REJECT는 요청을 거부합니다. 없는 대상은 건너뛰고 Skiped The Custom Rule Because Group & Proxy Not Found를 기록합니다.
구독 앞쪽 규칙 순서를 유지할 때만 확장 규칙을 사용합니다
확장 영역은 구독의 세부 규칙을 먼저 평가하고 사용자 지정 규칙으로 나중에 보완하려는 경우에 적합합니다. 아래는 별도 테스트입니다. 앞 절의 우선 항목을 제거하고, updates.example.net을 실제 도메인으로 바꾸십시오.
OpenClash 확장 규칙rules:
- DOMAIN-SUFFIX,updates.example.net,DIRECT
- 우선 테스트 항목을 제거하고 나머지 조건은 변경하지 않습니다.
- YAML을
Extended편집기에 붙여넣고Apply Settings를 누릅니다. - 실행 규칙에서 항목을 찾고 기존 규칙 중
DST-PORT,80을 포함한 마지막 항목, 첫MATCH/FINAL, 또는GEOIP,CN,...처럼 두 글자 국가 코드가 있는 첫 규칙과 비교합니다. - 실제 요청을 보내고 로그를 확인합니다. 더 위에 있는 구독 규칙이 먼저 일치하면 확장 항목은 실행되지 않습니다. 이는 정상적인 첫 일치 동작이지 저장 실패가 아닙니다.
확장 규칙은 병합된 위치로 판단합니다:편집기에 문자가 있는 것만으로는 충분하지 않습니다. 실행 규칙 순서와 실제 연결을 함께 확인하십시오.
적용 후 시작 로그, 병합 순서, 실제 요청을 각각 확인합니다
v0.47.156 영문 UI의 Commit Settings는 폼과 사용자 지정 규칙 파일을 저장하지만 OpenClash를 재시작하지 않습니다. Apply Settings는 저장하고 OpenClash를 활성화한 다음 재시작합니다. 즉시 테스트할 거라면 Apply를 한 번 실행하면 되며 Commit을 먼저 누를 필요는 없습니다.
- OpenClash가 실행 상태로 복귀하면 시작 로그의 첫 YAML, 규칙, 그룹 오류를 읽습니다.
- 실행 설정 또는 규칙 목록에서
DOMAIN,app.example.net,DIRECT가 예상 위치에 있는지 확인합니다. - 실제 클라이언트에서 해당 호스트 이름으로 접속한 뒤, 연결 로그의 규칙 유형, 값, 최종 처리 경로를 확인합니다.
- 관련 없는 사이트도 시험하여 나머지 구독 규칙이 기존처럼 동작하는지 확인합니다.
파일이 저장되었다는 사실만으로 로드를 증명할 수 없고, 실행 YAML에 보인다고 실제 요청의 일치를 증명할 수도 없습니다. 시작 결과, 병합 순서, 실제 연결이 모두 일치해야 검증이 완료됩니다.
규칙이 적용되지 않으면 모드와 YAML부터 확인합니다
| 증상 | 먼저 확인할 것 | 처리 방향 |
|---|---|---|
| 저장 후 변화 없음 | Commit Settings만 눌렀는지 | 짧은 재시작이 가능할 때 Apply Settings 실행 |
| 규칙은 있지만 일치하지 않음 | rule 모드와 위쪽의 선행 일치 규칙 | rule로 복귀하고 정확한 호스트 하나로 테스트 |
| YAML 오류 | 들여쓰기, 콜론, 목록 기호 | 기본 템플릿에서 rules 항목 하나만 추가 |
| Group & Proxy Not Found | 마지막 필드의 철자와 대소문자 | 존재하는 그룹 또는 지원되는 규칙 대상 사용 |
RULE-SET 미일치 | provider 정의, 다운로드, behavior 호환성 | 먼저 DOMAIN으로 경로를 증명한 후 provider 추가 |
두 YAML 파일은 rule-providers와 sub-rules도 정의할 수 있지만 동일한 이름은 병합 중 덮어쓰기 위험을 만듭니다. 최종 YAML을 비교하지 않고 온라인의 큰 provider 블록을 두 편집기에 모두 붙여넣지 마십시오. 이 글의 단일 호스트 테스트에 provider는 필요하지 않습니다.
한 번에 한 가지만 바꾸십시오:우선 규칙이 일치하지 않을 때 코어, DNS, Fake-IP, 노드, 구독을 함께 바꾸지 말고 모드, YAML, 규칙 대상 이름, 실제 호스트 순으로 확인합니다.
두 사용자 지정 규칙 파일을 백업하고 명확한 원복 경로를 남깁니다
첫 편집 전에 SSH로 두 파일을 백업합니다. 아래 명령은 원본이 있을 때만 복사하지만 같은 이름의 .bak를 덮어씁니다. 기존 백업이 있으면 새 파일 이름을 사용하십시오.
OpenWrt Shelltest -f /etc/openclash/custom/openclash_custom_rules.list && cp /etc/openclash/custom/openclash_custom_rules.list /root/openclash_custom_rules.list.bak
test -f /etc/openclash/custom/openclash_custom_rules_2.list && cp /etc/openclash/custom/openclash_custom_rules_2.list /root/openclash_custom_rules_2.list.bak
백업 내용을 확인한 뒤 존재하는 백업을 원래 경로로 복사하려면 다음 명령을 사용합니다.
OpenWrt Shell · 복원test -f /root/openclash_custom_rules.list.bak && cp /root/openclash_custom_rules.list.bak /etc/openclash/custom/openclash_custom_rules.list
test -f /root/openclash_custom_rules_2.list.bak && cp /root/openclash_custom_rules_2.list.bak /etc/openclash/custom/openclash_custom_rules_2.list
LuCI에서 이전 텍스트를 복원하거나 사용자 지정 규칙을 끄는 방법도 있습니다. 그다음 Apply Settings로 실행 설정을 다시 만듭니다. SSH로 백업을 복원했다면 LuCI 페이지를 새로 고쳐 텍스트를 확인한 뒤 적용하여 오래된 브라우저 폼이 파일을 다시 덮어쓰지 않게 합니다. 구독을 삭제하거나 생성된 임시 실행 YAML을 장기 설정 원본으로 직접 수정할 필요는 없습니다.
완료 기준:YAML이 해석되고, 삽입 위치가 우선/확장 선택과 맞고, 규칙 대상 이름이 존재하며, OpenClash가 정상 재시작하고, 실제 요청이 예상 처리 또는 경로를 사용하며, 기존 두 파일을 복원할 수 있어야 합니다.
OpenClash 및 Mihomo 관련 플랫폼과 클라이언트는 사이트의 다운로드 페이지에서 확인할 수 있습니다. 클라이언트 교체는 병합 규칙 순서와 연결 로그 검증을 대신하지 않습니다.
공식 자료와 버전 범위
- OpenClash v0.47.156 공식 릴리스
- OpenClash v0.47.156 덮어쓰기 화면 소스
- OpenClash v0.47.156 공식 중국어 간체 UI 번역
- OpenClash v0.47.156 사용자 지정 규칙 병합 소스
- OpenClash v0.47.156 우선 사용자 지정 규칙 템플릿
- OpenClash v0.47.156 확장 사용자 지정 규칙 템플릿
- Mihomo 공식 라우팅 규칙 문서
- Mihomo 공식 기본 설정 문서
버전 번호, 파일 이름, 화면 문구는 업데이트로 바뀔 수 있습니다. 작업 전에 연결된 공식 문서를 확인하세요.