FlClash 설정 필드 완벽 가이드

YAML 구조 개요: 계층을 먼저 보고 필드를 확인하기

루트 객체, 매핑과 시퀀스

mihomo 설정 파일의 루트 계층은 하나의 YAML 매핑입니다. 매핑은 “키, 콜론, 값”으로 구성되며, 예를 들어 mode: rule처럼 작성합니다. 시퀀스는 하이픈으로 시작하고 proxies, proxy-groups, rules에서 자주 사용됩니다. 계층은 전적으로 들여쓰기로 표현하므로 같은 계층의 필드는 동일한 깊이로 들여써야 합니다. 일반적으로 공백 두 칸을 사용하고 탭은 사용하지 않습니다. YAML은 두 칸이나 네 칸 중 하나를 강제하지 않지만, 같은 계층의 들여쓰기 깊이가 달라지면 데이터 구조가 바뀝니다. 파서가 즉시 오류를 낼 수도 있고 필드가 잘못된 부모 객체에 들어갈 수도 있습니다. 후자는 발견하기 더 어렵습니다. 파일은 로드되지만 특정 옵션이 계속 적용되지 않기 때문입니다.

스칼라 값에는 문자열, 숫자, 불리언과 null 값이 있습니다. 포트를 7890으로 쓰면 숫자이고, true와 false는 불리언입니다. 노드 이름, 도메인과 모드는 일반적으로 문자열입니다. 콜론, 샵, 대괄호, 중괄호 또는 앞뒤 공백이 포함된 문자열은 따옴표로 감싸는 것이 좋습니다. 따옴표 없는 문자열에서 샵은 주석의 시작으로 해석되므로 비밀번호나 이름에 샵이 포함되면 반드시 따옴표를 사용해야 합니다. YAML은 대소문자를 구분하므로 Rule, RULE과 rule은 서로 다른 값입니다. 필드 이름도 문서에 정의된 철자를 사용해야 하며, UI에 표시되는 한글 이름으로 설정 키를 대신할 수는 없습니다.

# config.yaml의 일반적인 루트 구조
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query

proxies:
  - name: "예시 노드"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-user"
    password: "your-password"

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "예시 노드"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,노드 선택
  - MATCH,DIRECT

필드 작성 순서와 트래픽 처리 순서는 다르다

YAML 매핑은 의미상 작성 순서에 의존하지 않으므로 dns를 proxies 앞이나 뒤에 배치해도 일반적으로 결과가 달라지지 않습니다. 하지만 사람이 읽기 위해서는 일정한 구조가 필요합니다. 공통 설정, DNS, 인바운드 리스너, 프록시 노드, 프록시 제공자, 정책 그룹, 규칙 제공자와 규칙 순서로 배치하는 것을 권장합니다. 실제 순서가 중요한 것은 시퀀스입니다. rules는 위에서 아래로 매칭하며 첫 번째로 일치한 뒤 중단됩니다. 정책 그룹의 노드 순서는 기본 항목이나 자동 선택 시 후보 순서에 영향을 줍니다. 오버라이드 단계에서는 같은 이름의 객체가 교체될 수도 있습니다.

참조 관계는 완결되어야 합니다. 규칙 끝의 정책 이름은 proxy-groups에 존재하거나 DIRECT, REJECT 같은 내장 정책이어야 합니다. 정책 그룹이 참조하는 노드 이름은 proxies의 노드, 이미 정의된 다른 정책 그룹 또는 use로 가져온 프록시 제공자와 일치해야 합니다. 이름을 바꿀 때는 정의부만 수정하지 말고 정책 그룹과 규칙도 함께 확인해야 합니다. 한글, 공백과 문장 부호도 이름의 일부입니다. “노드 선택”과 “노드 선택 ”은 서로 다른 문자열로 처리됩니다.

앵커, 별칭과 고급 YAML 작성법

YAML은 앵커와 별칭을 지원하므로 여러 곳에서 같은 매개변수 집합을 재사용할 수 있습니다. 예를 들어 여러 노드에 udp, skip-cert-verify 같은 필드를 공유할 수 있습니다. 다만 구독 변환기, 오버라이드 엔진과 그래픽 편집기가 복잡한 YAML 기능을 보존하는 정도는 서로 다릅니다. UI에서 저장하면 앵커가 일반 필드로 펼쳐질 수 있고, 일부 병합 키가 다시 직렬화될 수도 있습니다. 여러 기기에서 장기간 관리해야 한다면 명확한 명시적 필드를 우선하세요. 앵커는 수동 관리하는 독립 파일에는 적합하지만 자주 원격 업데이트되는 구독 본문에는 적합하지 않습니다.

주석도 그래픽 UI 저장이나 구독 업데이트 후 사라질 수 있습니다. 중요한 유지보수 설명을 구독 캐시에만 남기지 말고, 규칙의 의도와 출처를 별도 문서에 기록하거나 사용자 정의 내용을 안정적인 오버라이드 파일에 넣으세요. FlClash는 설정을 로드하고 관리하며, mihomo 커널은 실제 필드를 해석합니다. “UI에는 보이지만 커널이 사용하지 않는” 상황이 발생하면 원본 구독 텍스트만 확인하지 말고 먼저 실행 로그의 파싱 안내를 확인한 뒤 최종 적용 설정을 점검해야 합니다.

공통 필드: 포트, LAN, 모드와 로그

리스닝 포트의 역할 나누기

port는 HTTP 프록시 리스닝 포트이고, socks-port는 SOCKS5 프록시 리스닝 포트입니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS5를 모두 받습니다. 데스크톱 환경에서는 일반적으로 mixed-port만 활성화하면 시스템 프록시와 여러 앱이 하나의 진입점을 공유하기 편리합니다. 여러 리스닝 필드를 함께 사용할 수 있지만 포트 번호가 서로 충돌하거나 다른 프로그램에서 사용 중이어서는 안 됩니다. FlClash UI가 포트를 할당하는 경우 수동 설정의 값이 클라이언트에 의해 다시 덮어써질 수 있습니다. 문제를 확인할 때는 편집기의 원래 숫자만 보지 말고 최종 리스닝 주소와 실행 로그를 확인하세요.

redir-port, tproxy-port 등의 필드는 투명 프록시 경로를 위한 것으로, 일반적으로 Linux 방화벽 규칙, 라우터 환경 또는 특정 트래픽 가로채기 방식에서 사용됩니다. 일반 데스크톱 사용자는 “더 완벽하게” 보이도록 모든 포트를 동시에 켤 필요가 없습니다. 포트는 트래픽을 받는 진입점일 뿐 시스템 라우팅을 자동으로 바꾸지 않습니다. 시스템 프록시 모드에서는 운영체제가 프록시를 지원하는 앱을 HTTP 또는 SOCKS 포트로 보내야 합니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 더 넓은 트래픽을 가로채며, 두 방식은 필요한 권한과 적용 범위, 문제 해결 방법이 다릅니다.

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: strict

allow-lan과 리스닝 범위

allow-lan은 LAN 기기가 이 기기의 프록시 포트에 연결할 수 있는지 제어합니다. false로 설정하면 본인 기기의 앱만 사용하는 데스크톱 설정에 흔히 적합합니다. true로 설정한 뒤에는 리스닝 주소를 올바르게 지정하고 운영체제 방화벽이 해당 포트를 허용하는지도 확인해야 합니다. 이 필드는 다른 기기에 게이트웨이나 프록시 주소를 자동으로 설정하지 않으며 접근 제어를 대신하지도 않습니다. LAN에 프록시를 제공해야 한다면 고정된 내부 주소를 사용하고 신뢰할 수 있는 네트워크 대역으로 제한하며 인증을 설정하세요. 리스닝 포트를 인터넷에 직접 노출하지 마세요.

bind-address는 리스닝 바인딩 범위를 결정합니다. 와일드카드 주소는 사용 가능한 인터페이스에서 리스닝하고, 구체적인 주소는 지정한 네트워크 카드로 진입점을 제한합니다. 모바일 기기에서 Wi‑Fi와 셀룰러 네트워크를 전환하면 인터페이스가 바뀌어 기존 바인딩 주소가 무효화될 수 있습니다. LAN 공유에서 “본인 기기에서는 되지만 다른 기기는 연결을 거부함”이 발생하면 allow-lan, 바인딩 주소, 방화벽, 동일한 네트워크 대역 여부와 프록시 유형 입력을 차례로 확인하세요. 연결은 되지만 대상 사이트에 접근할 수 없다면 정책 그룹, DNS와 아웃바운드 노드를 계속 점검합니다.

세 가지 실행 모드

mode: rule은 규칙 목록에 따라 트래픽의 목적지를 결정하며 일상 설정의 기본 모드입니다. global은 트래픽을 전역 정책으로 보내 노드 사용 가능 여부를 임시로 확인할 때 적합하고, direct는 직접 연결하여 문제가 프록시 경로에서 비롯되었는지 빠르게 판단할 때 유용합니다. 모드 전환은 규칙을 삭제하지 않고 결정 진입점만 바꿉니다. 문제 해결 중 글로벌 모드는 정상인데 규칙 모드만 이상하다면 규칙 매칭이나 정책 참조가 잘못되었을 가능성이 큽니다. 직접 연결도 이상하다면 로컬 네트워크, DNS 또는 시스템 가로채기 상태를 확인하세요.

log-level의 대표 값은 silent, error, warning, info와 debug입니다. 일상적인 사용에는 info면 충분한 경우가 많고, 규칙 매칭, DNS 조회나 핸드셰이크 문제를 찾을 때만 일시적으로 debug로 높이면 됩니다. 상세 로그는 출력량을 크게 늘리고 대상 도메인이나 노드 주소 같은 실행 정보를 포함할 수 있으므로 문제를 해결한 뒤 평소 수준으로 되돌리세요. 로그의 첫 번째 오류가 뒤따르는 연쇄 오류보다 중요한 경우가 많으므로 설정 로드, 리스너 시작, DNS 초기화와 프록시 핸드셰이크 순서로 읽는 것이 좋습니다.

지연 시간 측정, 동시 연결과 프로세스 식별

unified-delay는 지연 시간 테스트 기준을 통일하여 서로 다른 프록시 유형의 결과를 비교하기 쉽게 합니다. 측정 결과는 테스트 URL과 현재 네트워크 조건에서 한 번 연결한 성능을 나타내며, 모든 사이트에 고정적으로 적용되는 지연 시간이 아닙니다. tcp-concurrent는 대상 주소의 여러 후보 연결을 동시에 시도할 수 있어 듀얼 스택이나 다중 주소 환경에서 연결 대기 시간을 줄일 수 있지만 추가 연결 시도가 발생합니다. 네트워크가 제한적이거나 라우터 리소스가 부족하거나 연결 수를 엄격히 관리해야 한다면 끄고 비교 테스트를 진행하세요.

find-process-mode는 커널이 연결에 속한 프로세스를 확인하는 방식을 결정합니다. 프로세스 규칙은 운영체제 기능과 실행 권한에 의존하므로 플랫폼마다 지원 수준이 다릅니다. Android, macOS, Windows와 Linux는 프로세스 경로, 패키지 이름과 권한을 표현하는 방식이 다르므로 같은 프로세스 규칙이 모든 플랫폼에서 완전히 동일하다고 가정해서는 안 됩니다. 도메인이나 IP만으로 분류할 수 있다면 네트워크 계층 조건을 우선 사용하세요. 앱별 분류가 꼭 필요할 때만 대상 플랫폼에서 프로세스 이름을 확인하세요.

DNS 필드: 해석 경로, Fake-IP와 트래픽 분류 일관성

DNS 설정은 단순히 “해석 속도”만 해결하지 않는다

프록시 환경에서 DNS는 도메인 해석, 규칙 판단, 노드 서버 주소 해석과 요청이 의도한 경로를 우회하지 않도록 하는 역할을 동시에 맡습니다. dns.enable로 커널 DNS 모듈을 활성화하면 조회가 설정한 업스트림으로 전달될 수 있지만, 모든 조회가 커널로 넘어가는지는 TUN, 시스템 DNS 설정이나 앱 자체 동작에도 좌우됩니다. 브라우저가 별도의 암호화 DNS를 사용하거나 일부 앱이 주소를 캐시하고 고정 IP로 직접 요청할 수도 있습니다. 해석 결과와 규칙이 맞지 않으면 먼저 조회 경로를 그려 보세요. 앱은 누구에게 묻는지, 커널은 어떤 업스트림을 사용하는지, 노드 서버 도메인은 누가 해석하는지, 최종 연결은 어떤 규칙에 매칭되는지를 확인해야 합니다.

nameserver는 일반 도메인 조회에 사용하는 주요 DNS 서버 목록입니다. default-nameserver는 암호화 DNS 서버 자체의 도메인을 해석할 때 주로 사용됩니다. “DNS 서버에 연결하려면 먼저 DNS 서버의 도메인을 해석해야 하는” 순환 의존을 피하기 위해 보통 직접 접근 가능한 IP 형식의 서버를 넣습니다. proxy-server-nameserver는 프록시 노드 서버 도메인만 별도로 해석하여 노드 주소와 일반 서비스 도메인의 경로를 분리할 수 있습니다. direct-nameserver는 명확한 직접 연결 도메인에 별도 해석 경로를 제공할 수 있습니다. 모두 설정해야 하는지는 실제 네트워크 토폴로지에 따라 결정하며 필드가 많다고 안정적인 것은 아닙니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://dns.google/dns-query
    - tls://1.1.1.1
  proxy-server-nameserver:
    - https://dns.google/dns-query
  respect-rules: true

Fake-IP와 Redir-Host의 차이

enhanced-mode: fake-ip는 먼저 앱에 예약 주소 풀의 매핑 주소를 반환하고, 커널이 그 매핑을 바탕으로 원래 도메인을 복원해 규칙을 판단합니다. 앱이 대상 IP만 네트워크 계층에 전달하더라도 커널이 도메인 정보를 유지할 수 있어 도메인 규칙과 스니핑을 함께 사용하기가 더 직접적입니다. fake-ip-range는 매핑 주소 풀을 지정하며 로컬 실제 네트워크, 컨테이너 네트워크나 기업 VPN 대역과 겹치면 안 됩니다. 내부 주소 충돌이 발생하면 모든 연결이 실패하기보다 특정 네트워크 대역만 접근할 수 없는 형태로 나타날 수 있습니다.

redir-host는 전통적인 실제 주소 해석에 더 가깝습니다. 앱이 대상 도메인의 실제 IP를 받고 커널이 확보된 정보를 바탕으로 트래픽을 처리합니다. Fake-IP를 허용하지 않는 일부 기기 검색, LAN 서비스나 특수 프로토콜에는 더 직관적일 수 있지만, 이후 연결 단계에서 도메인 정보가 사라질 수 있어 규칙 판단이 DNS 캐시와 스니핑에 더 의존합니다. 모드는 앱 호환성과 규칙 정확성을 기준으로 선택해야 하며 특정 방식을 보편적인 정답으로 볼 필요는 없습니다. 대부분의 문제는 먼저 Fake-IP를 사용하고, 호환되지 않는 도메인만 필터 목록에 추가해 해결할 수 있습니다.

fake-ip-filter는 설명 가능한 수준으로 유지하기

필터 목록의 도메인은 Fake-IP 매핑을 우회하고 실제 해석 결과를 받습니다. LAN 검색, 시간 동기화, STUN, 일부 게임 플랫폼과 기기 설정 과정에서는 필터가 필요할 수 있습니다. 추가하기 전에 명확한 증상과 검증 방법이 있어야 합니다. 예를 들어 Fake-IP에서만 앱이 같은 네트워크의 기기를 찾지 못하다가 해당 도메인을 추가한 뒤 복구되는 경우입니다. 광범위한 최상위 도메인이나 와일드카드 규칙을 필터에 함부로 넣지 마세요. 많은 요청이 실제 주소 해석으로 돌아가 도메인 규칙의 관찰 가능성이 낮아지고, 기기마다 동작이 달라질 수 있습니다.

정확한 도메인, 한 단계 와일드카드와 접미사 매칭은 서로 구분해야 합니다. 필드마다 와일드카드 의미를 지원하는 범위가 다를 수 있으므로 규칙 목록의 DOMAIN-SUFFIX 문법을 필터 목록에 그대로 복사할 수는 없습니다. 수정 후 앱의 DNS 캐시를 지우고 연결을 다시 만든 다음 로그에서 조회가 예상한 업스트림으로 들어가는지 확인하세요. 웹페이지만 새로 고치면 브라우저 연결 풀과 이전 캐시를 계속 사용해 “설정이 바뀌지 않았다”고 오해할 수 있습니다.

규칙 분류와 DNS 업스트림 선택

respect-rules는 가능한 경우 DNS 요청이 규칙 체계를 따르도록 합니다. 하지만 이를 사용하려면 DNS에 지정한 프록시 정책이 해석 전에 연결될 수 있어야 하며, 재귀 의존을 피해야 합니다. 예를 들어 프록시 노드 서버가 도메인으로 지정되어 있고 암호화 DNS 연결도 해당 프록시를 거쳐야 한다면, 노드 도메인은 proxy-server-nameserver 또는 직접 접근 가능한 부트스트랩 해석기로 먼저 해석해야 합니다. 설계할 때는 “노드 주소 해석”과 “서비스 도메인 해석”을 분리하고, 가장 낮은 계층에 아직 연결되지 않은 프록시에 의존하지 않는 해석 경로를 하나 이상 남겨 두세요.

nameserver-policy는 도메인별로 특정 업스트림을 선택할 수 있어 기업 내부 도메인, LAN 서비스 또는 해석 출처를 고정해야 하는 영역에 적합합니다. 정책 범위는 최대한 좁게 유지하세요. 명확한 접미사를 먼저 매칭하고 일반 nameserver를 대체 경로로 남기는 방식이 좋습니다. 같은 도메인이 여러 정책에 동시에 매칭될 수 있다면 우선순위와 최종 로그를 확인해야 합니다. 규칙 제공자로 관리하는 도메인 집합을 사용할 때는 규칙 집합의 동작과 DNS 정책 필드가 해당 참조 방식을 지원하는지도 확인하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query
  nameserver-policy:
    "+.internal.example":
      - 192.0.2.53
    "geosite:private":
      - system
  direct-nameserver:
    - system
  direct-nameserver-follow-policy: true

일반적인 장애는 계층별로 나눠 볼 수 있습니다. 도메인이 전혀 해석되지 않으면 DNS 리스너, 업스트림 접근성과 인증서 시간을 확인하세요. 해석은 되지만 연결되지 않으면 규칙 정책과 노드를 확인합니다. 노드 도메인만 실패하면 부트스트랩 해석과 proxy-server-nameserver를 확인하세요. LAN 기기에 문제가 있으면 Fake-IP 주소 풀 충돌과 필터 항목을 점검합니다. 간헐적으로 새 결과와 이전 결과가 섞이면 시스템, 브라우저와 커널 캐시를 삭제하세요. 더 자세한 장애 처리 경로는 자주 묻는 질문의 DNS 및 연결 분류에서 확인할 수 있습니다.

프록시 노드 필드: 공통 속성, 프로토콜 매개변수와 전송 계층

모든 노드는 이름, 유형과 서버에서 시작한다

proxies는 수동으로 작성하는 노드 시퀀스입니다. 각 노드에는 최소한 고유한 name, 프로토콜 type, 서버 server와 포트 port가 필요하며, 여기에 프로토콜별 인증 필드를 추가합니다. 노드 이름은 정책 그룹과 규칙이 참조하는 기본 키이므로 안정적으로 유지해야 합니다. 구독 업데이트로 제공자가 이름을 바꾸면 수동 정책 그룹에 끊어진 참조가 생길 수 있습니다. 따라서 동적 노드 이름을 정책 그룹에 대량으로 고정하기보다 프록시 제공자와 필터 규칙으로 자동 구독을 구성하는 편이 적합합니다.

server는 IP 또는 도메인일 수 있습니다. 도메인은 서버 이전에 유리하지만 노드 주소 해석 경로가 안정적이어야 합니다. IP는 한 번의 해석을 줄일 수 있지만 주소 변경을 자동으로 따라가지 못합니다. udp는 노드가 UDP를 처리할지 제어하지만 실제 사용 가능 여부는 프로토콜, 서버와 네트워크 경로에도 달려 있습니다. interface-name이나 라우팅 마크 계열 필드는 다중 네트워크 카드 환경에서 연결을 특정 출구에 묶을 수 있지만, 모바일 기기에서 네트워크를 바꾸면 동작하지 않을 수 있습니다. 여러 출구가 꼭 필요한 경우가 아니라면 플랫폼 종속 필드를 여러 기기에서 공유하는 설정에 고정하지 마세요.

proxies:
  - name: "업무용 SOCKS"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-user"
    password: "your-password"
    udp: true

  - name: "예시 HTTP"
    type: http
    server: gateway.example.net
    port: 8443
    username: "your-user"
    password: "your-password"
    tls: true
    skip-cert-verify: false

TLS 필드와 서버 신원

TLS를 지원하는 프로토콜에는 일반적으로 tls, servername, skip-cert-verify, ALPN이나 핑거프린트 관련 옵션이 포함됩니다. servername은 TLS 핸드셰이크의 서버 이름으로, 서버 인증서와 배포 설정에 맞아야 하며 임의로 입력하는 위장 도메인과는 다릅니다. skip-cert-verify: true는 인증서 유효성 검사를 건너뛰므로 명확하게 통제된 테스트 환경에서만 사용해야 합니다. 일반 설정에서는 검증을 유지하고 시스템 시간, 인증서 체인, 서버 이름이나 중간 네트워크 간섭을 수정하세요. 연결 로그에 인증서 이름 불일치가 표시되면 검증을 끄기 전에 구독 매개변수부터 확인해야 합니다.

WebSocket, gRPC, HTTP/2 등의 전송 매개변수는 일반적으로 각 프로토콜의 해당 옵션 안에 중첩됩니다. 경로, Host, 서비스 이름과 요청 헤더는 서버와 일치해야 합니다. 비슷해 보이는 필드라도 계층이 다를 수 있습니다. 예를 들어 WebSocket 경로를 노드 루트에 적는다고 자동으로 적용되지 않습니다. 다른 클라이언트의 설정을 옮길 때는 한글 라벨만 보고 항목을 복사하지 말고 mihomo가 지원하는 노드 구조를 대조하세요. 서비스 제공자가 생성한 구독이라면 서버 요구 사항을 확인하기 전에는 원래 전송 매개변수를 유지하는 것이 좋습니다.

일반적인 프로토콜 필드는 서로 바꿔 쓸 수 없다

Shadowsocks 노드의 핵심 필드는 cipher와 password입니다. Trojan은 비밀번호, TLS 서버 이름과 전송 매개변수를 중심으로 구성합니다. VMess는 일반적으로 uuid, 암호화 옵션과 전송 설정이 필요합니다. VLESS는 UUID가 필요하며 flow, Reality 또는 기타 확장 필드를 포함할 수 있습니다. Hysteria2와 TUIC에는 UDP 기반 전송, 혼잡 제어 또는 대역폭 매개변수도 관련됩니다. 각 프로토콜은 고유한 구조에 맞춰 입력해야 합니다. 한 프로토콜의 인증 필드를 다른 프로토콜에 넣어도 호환 계층이 생기지 않으며, 대개 무시되거나 로드에 실패합니다.

프로토콜 기능은 mihomo 커널이 제공하고, FlClash는 설정 관리와 크로스 플랫폼 UI를 제공합니다. 커널에 특정 필드가 존재한다고 해서 모든 플랫폼의 시스템 네트워크 조건이 같은 것은 아닙니다. 예를 들어 UDP 기반 프로토콜은 공용 Wi‑Fi, 기업 네트워크나 통신사 경로의 제한을 받을 수 있습니다. TUN 권한과 백그라운드 실행도 모바일 환경에 영향을 줍니다. 노드를 확인할 때는 먼저 간단한 연결성 테스트를 수행한 다음 핸드셰이크 로그를 확인하세요. 노드 속도 측정 실패가 반드시 구독 만료를 뜻하지는 않습니다. 테스트 주소에 접근할 수 없거나 DNS가 준비되지 않았거나 UDP가 제한되었거나 정책이 순환하는 경우에도 실패할 수 있습니다.

노드 이름, 민감한 필드와 공유 범위

노드 설정에는 서버 주소와 인증 정보가 포함되므로 공개 질문 페이지에 그대로 붙여 넣으면 안 됩니다. 문제를 확인할 때는 필드 구조를 유지하되 주소를 proxy.example.com으로 바꾸고 비밀번호나 UUID는 명확한 테스트 값으로 대체하세요. 프로토콜 유형, 계층과 불리언 필드는 남겨 두는 것이 좋습니다. 오류 한 줄만 잘라서 문맥을 숨기지 마세요. 많은 문제는 들여쓰기나 부모 필드에서 발생합니다. 공개 텍스트에 구독 URL도 남기지 마세요. 구독 링크에는 보통 접근 자격 증명 역할이 있으므로 유출되었다면 게시물에서 삭제하는 것만으로는 부족하고 서버에서 재설정해야 합니다.

같은 이름의 노드는 정책 참조와 UI 선택을 불확실하게 만듭니다. 수동 설정에서는 이름을 고유하게 유지해야 합니다. 여러 프록시 제공자의 노드를 합칠 때는 오버라이드 단계에서 출처 접두사나 접미사를 추가할 수 있습니다. 이름 필터에 정규 표현식을 사용할 때는 괄호, 더하기 기호와 기타 메타문자를 고려하세요. 먼저 소수의 노드로 필터 표현식을 검증한 뒤 전체 구독에 적용합니다. 그래픽 클라이언트를 다시 선택해야 한다면 다운로드 센터에서 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등의 플랫폼별 선택지를 확인할 수 있으며, Clash Plus가 모든 플랫폼의 우선 추천 진입점입니다.

정책 그룹 필드: 선택, 자동 테스트, 장애 조치와 체인 참조

정책 그룹은 규칙과 노드 사이의 결정 계층이다

proxy-groups는 노드, 내장 동작과 다른 정책 그룹을 참조 가능한 아웃바운드 집합으로 구성합니다. 규칙은 특정 노드를 직접 적기보다 “노드 선택”, “자동 선택”, “해외 트래픽” 같은 안정적인 정책 이름을 가리키는 것이 일반적입니다. 이렇게 하면 구독 노드가 바뀌어도 그룹의 후보만 갱신하면 되며 전체 규칙을 다시 작성할 필요가 없습니다. 각 그룹에는 최소한 name과 type이 필요합니다. 후보는 proxies에 명시하거나 use로 프록시 제공자를 참조합니다.

select는 사용자가 후보를 직접 선택할 수 있어 최상위 전체 진입점으로 적합합니다. 후보에는 특정 노드, 자동 테스트 그룹과 DIRECT를 함께 넣을 수 있습니다. 그룹의 첫 번째 항목은 일반적으로 기본값의 의미를 가지지만, 클라이언트가 이전 선택을 저장할 수도 있으므로 순서를 바꿔도 현재 선택이 즉시 바뀌지 않을 수 있습니다. “규칙은 올바른 그룹에 매칭됐지만 잘못된 노드를 사용함”을 점검할 때는 정책 그룹의 현재 선택과 저장된 상태를 함께 확인하세요.

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "자동 선택"
      - "장애 조치"
      - "업무용 SOCKS"
      - DIRECT

  - name: "자동 선택"
    type: url-test
    proxies:
      - "업무용 SOCKS"
      - "예시 HTTP"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

  - name: "장애 조치"
    type: fallback
    proxies:
      - "업무용 SOCKS"
      - "예시 HTTP"
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

url-test, fallback과 load-balance

url-test는 일정한 간격으로 테스트 URL에 요청을 보내 결과에 따라 적절한 후보를 선택합니다. interval은 테스트 간격이며 너무 짧으면 노드와 기기에 부담을 줍니다. tolerance는 전환 허용 범위를 제공해 작은 수치 변동으로 회선이 자주 바뀌는 것을 막습니다. lazy를 사용하면 그룹이 사용되지 않을 때 능동 테스트를 줄일 수 있습니다. 테스트 URL은 안정적이고 응답이 작으며 대상 네트워크에서 접근 가능해야 하고 실제 연결 경로를 대표해야 합니다. 가장 낮은 지연 시간은 해당 테스트 대상에 요청을 빠르게 연결했다는 뜻일 뿐, 대역폭과 패킷 손실, 대상 사이트까지의 경로가 항상 최적이라는 의미는 아닙니다.

fallback은 후보 순서대로 사용 가능한 항목을 선택하므로 주 노드를 우선 사용하다가 실패하면 전환하려는 상황에 적합합니다. 모든 요청을 균등하게 분배하지 않으며 기존 장시간 연결이 끊김 없이 이동한다고 보장하지도 않습니다. load-balance는 여러 후보에 연결을 분산하며 일관성 해시나 라운드 로빈이 흔히 사용됩니다. 로그인 세션이나 출발지 주소에 민감한 서비스에서는 라운드 로빈을 신중하게 사용해야 합니다. 같은 업무의 서로 다른 연결이 다른 출구로 나갈 수 있기 때문입니다. 세션 안정성이 필요하다면 일관성 기반 방식이나 수동 선택이 일반적으로 더 제어하기 쉽습니다.

프록시 제공자와 동적 후보

노드가 원격 구독에서 제공될 때 proxy-providers로 노드 데이터, 업데이트 주기와 상태 확인을 독립적으로 관리하고 정책 그룹에서는 use로 제공자를 참조할 수 있습니다. 원격 노드가 추가되거나 삭제되어도 정책 그룹에서 이름을 하나씩 수정할 필요가 없습니다. 제공자의 filter, exclude-filter나 오버라이드 규칙으로 이름, 지역, 프로토콜 또는 용도에 따라 필터링할 수 있지만, 필터는 상위 제공자의 이름 품질에 의존합니다. 이름이 불안정하다면 여러 조건으로 계층화하고 필터링하지 않은 전체 그룹을 확인용 진입점으로 남기는 방법이 더 안정적입니다.

상태 확인과 정책 그룹 테스트는 기능이 겹칩니다. 제공자 수준의 상태 확인은 노드의 기본 사용 가능 여부를 판단하고, 정책 그룹의 url-test는 후보를 결정합니다. 두 계층 모두 간격을 지나치게 짧게 설정하면 중복 트래픽이 발생합니다. 기기 성능이 제한적이거나 노드가 많다면 제공자 확인 주기를 늘리고 자주 사용하는 자동 그룹이 더 신속한 테스트를 담당하게 하세요. 모든 노드가 동시에 사용할 수 없음으로 표시되면 테스트 URL, DNS와 네트워크 진입점을 먼저 확인하고 곧바로 모든 노드가 만료되었다고 판단하지 마세요.

proxy-providers:
  remote-main:
    type: http
    url: "https://subscription.example.com/your-token"
    path: ./providers/remote-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "구독 노드"
    type: select
    use:
      - remote-main

  - name: "자동 구독"
    type: url-test
    use:
      - remote-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

체인 참조에서는 순환을 피해야 한다

정책 그룹은 다른 정책 그룹을 참조하여 “서비스 분류 그룹 → 전체 선택 그룹 → 자동 테스트 그룹 → 노드” 계층을 만들 수 있습니다. 예를 들어 스트리밍 그룹을 단독으로 선택하거나 전체 선택 그룹으로 폴백할 수 있습니다. 하지만 어떤 참조 체인도 자기 자신으로 돌아가서는 안 됩니다. A가 B를 참조하고 B가 다시 A를 참조하면 순환이 생겨 최종 아웃바운드를 결정할 수 없습니다. 복잡한 설정에서는 하위 노드 그룹, 자동 그룹, 전체 선택 그룹과 서비스 그룹을 의존 순서대로 배치하고 이름에 역할을 드러내세요.

내장 정책 DIRECT는 직접 연결을, REJECT는 요청 거부를 의미합니다. 두 정책은 정책 그룹의 후보로 넣거나 규칙 끝에 직접 작성할 수 있습니다. 최상위 선택 그룹에 DIRECT를 넣으면 임시로 프록시를 우회하기 쉽지만 잘못 선택할 위험도 커집니다. 고정된 기기용 설정이라면 명확한 규칙에 직접 연결을 맡기고 모든 서비스 그룹에 반복해서 제공할 필요는 없습니다. 거부 정책은 연결할 필요가 없는 대상을 처리하는 데 사용하며, 범위가 너무 넓으면 페이지 리소스가 누락되거나 앱 기능이 오작동할 수 있으므로 좁은 규칙부터 시작하세요.

규칙 제공자: 분리, 업데이트와 동작 유형

대규모 규칙 목록을 주 설정에서 분리하는 이유

rule-providers는 독립적으로 로드하고 업데이트할 수 있는 규칙 집합을 선언하는 데 사용합니다. 주 설정에는 제공자 이름, 출처, 캐시 경로, 업데이트 주기와 동작 유형만 남기고 RULE-SET 규칙으로 참조합니다. 광고 차단, LAN 직접 연결, 특정 서비스와 지역 도메인 등 서로 다른 역할을 분리할 수 있어 주 파일의 길이를 줄이고 개별 업데이트도 쉬워집니다. 규칙 집합은 정책 그룹이 아니라 매칭 조건만 제공합니다. 매칭 후 어떤 정책으로 보낼지는 주 설정의 RULE-SET,제공자 이름,정책 이름이 결정합니다.

제공자의 일반적인 type은 http 또는 file입니다. 원격 유형에는 url, 로컬 캐시 path와 업데이트 interval이 필요하고, 로컬 유형은 기기에 있는 파일을 읽습니다. 캐시 경로는 서로 고유하게 설정하여 두 제공자가 같은 파일을 덮어쓰지 않게 하세요. 원격 업데이트에 실패하면 커널은 보통 기존 캐시를 계속 사용하지만, 처음 로드할 때 캐시가 없으면 규칙 집합을 사용할 수 없을 수 있습니다. 중요한 직접 연결 규칙은 소수의 내장 규칙으로 보완하고, 기본 네트워크 연결 전체를 아직 다운로드되지 않은 원격 파일 하나에 의존시키지 마세요.

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: https://rules.example.com/private-domain.yaml
    interval: 86400

  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: https://rules.example.com/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-network,DIRECT,no-resolve
  - MATCH,노드 선택

behavior는 규칙 데이터의 해석 방식을 결정한다

domain 동작은 도메인 집합에 사용하며 데이터에는 일반적으로 전체 도메인, 도메인 접미사 또는 지원되는 도메인 표현식이 들어갑니다. ipcidr은 IPv4와 IPv6 네트워크 대역에 사용합니다. classical은 규칙 집합의 각 항목에 DOMAIN-SUFFIX, IP-CIDR, PROCESS-NAME 같은 기존 규칙 유형을 포함할 수 있습니다. 동작 유형은 파일 내용과 일치해야 합니다. 규칙 유형 접두사가 있는 classical 파일을 domain으로 선언해도 접두사가 자동으로 제거되거나 변환되지 않으며, 대개 로드에 실패하거나 아무 항목도 매칭되지 않습니다.

동작 유형을 선택할 때는 가능한 한 가장 좁은 모델을 우선 사용하세요. 순수 도메인 목록에는 domain, 순수 네트워크 대역 목록에는 ipcidr을 사용하고, 여러 조건을 섞어야 할 때만 classical을 선택합니다. 명확한 동작 유형은 커널 최적화에 도움이 되고 규칙에 DNS 해석이 필요한지도 판단하기 쉽게 합니다. classical이 더 많은 형식을 담을 수 있다고 모든 규칙을 하나의 거대한 파일에 넣지는 마세요. 역할과 데이터 유형별로 나누면 매칭 문제를 더 직접적으로 확인할 수 있습니다.

규칙 집합 파일 형식과 데이터

YAML 규칙 집합은 일반적으로 payload를 루트 키로 사용하고 그 아래에 규칙 시퀀스를 둡니다. domain 동작에서는 접미사 표현이 루트 도메인과 하위 도메인을 매칭할 수 있으며, 정확한 도메인은 지정한 호스트만 매칭합니다. ipcidr 동작에서는 표준 CIDR 네트워크 대역을 작성해야 합니다. classical 동작에서는 전체 규칙 조건을 작성하지만 규칙 집합 항목에 최종 정책을 덧붙이지 않습니다. 정책은 주 설정에서 참조할 때 지정합니다. 같은 규칙 집합을 서로 다른 정책에 연결할 수도 있습니다. 예를 들어 업무 설정에서는 직접 연결하고 여행 설정에서는 프록시로 보낼 수 있습니다.

# private-domain.yaml
payload:
  - "+.lan"
  - "+.local"
  - "router.example"
  - "intranet.example.org"

# private-network.yaml
payload:
  - "10.0.0.0/8"
  - "172.16.0.0/12"
  - "192.168.0.0/16"
  - "127.0.0.0/8"
  - "::1/128"
  - "fc00::/7"

format은 원격 파일의 실제 형식과 일치해야 합니다. 파일 확장자만으로는 충분하지 않으므로 다운로드 후 본문 구조와 응답 내용을 확인하세요. 원격 주소가 로그인 페이지, 요청 제한 안내나 HTML 오류 페이지를 반환하면 파일은 저장되더라도 규칙 집합으로 파싱할 수 없습니다. 로그에 규칙 집합 형식 오류가 나타나면 브라우저에서 URL이 열리는지만 보지 말고 최종 응답을 확인해야 합니다. 인증이 필요한 비공개 규칙 집합은 자격 증명 갱신과 기기 간 동기화도 고려하고, 실제 접근 정보를 공개 설정 예시에 붙여 넣지 마세요.

업데이트 주기, 캐시와 원자성

interval은 업데이트 간격을 초 단위로 표시합니다. 규칙 내용이 하루에 한 번 바뀐다면 몇 분마다 가져올 필요가 없습니다. 잦은 업데이트는 네트워크 요청과 상위 서버 부담을 늘리고 일시적인 장애에서 오류가 반복되기 쉽습니다. 원격 파일에는 안정적인 캐시를 사용하고 로컬에서는 마지막으로 파싱 가능한 버전을 계속 사용하며 업데이트 실패를 로그에 기록하는 방식이 적절합니다. 규칙 출처를 수정한 뒤에는 수동 업데이트를 실행하거나 해당 캐시를 삭제해 확인할 수 있지만, 모든 제공자 캐시를 한꺼번에 삭제하지는 마세요. 하나의 파일 문제가 모든 규칙 집합의 동시 사용 불가로 확대될 수 있습니다.

규칙 집합 업데이트와 주 설정 업데이트는 하나의 트랜잭션이 아닙니다. 주 설정이 아직 다운로드되지 않은 제공자를 먼저 참조하면 일시적으로 규칙이 없을 수 있습니다. 원격 규칙 내용이 호환되지 않게 바뀐 경우에도 다음 주기 업데이트 후에야 문제가 드러날 수 있습니다. 중요한 설정에는 사설 네트워크 직접 연결과 최종 MATCH 같은 짧은 주 규칙 폴백을 남기고, 외부 집합은 적절한 위치에 배치하세요. 규칙 출처는 명확하고 역할이 단일하며 되돌릴 수 있어야 합니다. 출처가 불분명한 대형 집합은 서로 덮어써 특정 도메인이 간헐적으로 잘못된 정책을 사용할 수 있습니다.

규칙 문법: 위에서 아래로 매칭하고 첫 일치에서 종료

규칙의 기본 구조

rules는 순서가 있는 시퀀스입니다. 기존 규칙은 일반적으로 규칙 유형, 매칭 내용, 대상 정책과 선택적 매개변수로 구성되며 쉼표로 구분합니다. 예를 들어 DOMAIN-SUFFIX,example.org,노드 선택은 example.org를 접미사로 갖는 도메인을 “노드 선택”으로 보냅니다. 커널은 첫 항목부터 아래로 확인하고 매칭되면 더 이상 진행하지 않습니다. 따라서 규칙 설계의 핵심은 개별 규칙이 맞는지만이 아니라 더 좁은 범위의 규칙이 더 넓은 규칙보다 앞에 있는지입니다.

MATCH에는 매칭 내용이 필요하지 않으며 일반적으로 마지막에 작성해 앞에서 매칭되지 않은 모든 트래픽을 받습니다. 중간에 배치하면 뒤의 규칙은 실행될 기회를 얻지 못합니다. 규칙 대상은 정책 그룹, 특정 노드나 내장 동작일 수 있지만 유지보수 안정성을 위해 보통 정책 그룹을 가리킵니다. 노드 이름이 바뀌어도 정책 그룹이 유효한 후보를 제공한다면 규칙을 수정하지 않아도 전체 결정 체인이 유지됩니다.

rules:
  # 정확한 도메인을 우선
  - DOMAIN,api.example.org,DIRECT
  # 그 다음 전체 도메인 접미사 처리
  - DOMAIN-SUFFIX,example.org,노드 선택
  # 키워드 범위가 더 넓으므로 뒤에 배치
  - DOMAIN-KEYWORD,example,노드 선택
  # 사설 네트워크는 직접 연결
  - 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,fc00::/7,DIRECT,no-resolve
  # 최종 폴백
  - MATCH,노드 선택

도메인 규칙의 범위 차이

DOMAIN은 전체 도메인만 매칭하므로 별도로 처리해야 하는 API, 로그인 진입점이나 특정 호스트에 적합합니다. DOMAIN-SUFFIX는 한 도메인과 하위 도메인을 매칭하므로 서비스를 통째로 분류할 때 적합합니다. DOMAIN-KEYWORD는 도메인에 키워드가 포함되었는지 판단하므로 범위가 더 넓고 오탐도 쉽게 발생합니다. 짧은 키워드가 관련 없는 도메인에도 들어갈 수 있기 때문입니다. 정확한 도메인이나 접미사를 사용할 수 있다면 먼저 키워드로 범위를 넓히지 마세요.

도메인 규칙이 매칭에 참여할 수 있는지는 커널이 연결에 해당하는 도메인을 알고 있는지에 달려 있습니다. 시스템 프록시는 보통 도메인을 직접 제공합니다. Fake-IP는 매핑 관계를 유지할 수 있고, 대상 IP만 있는 투명 연결은 DNS 캐시나 스니핑이 필요할 수 있습니다. 로그에 IP만 표시된다고 도메인 규칙이 매칭되지 않는 원인이 반드시 규칙 철자에 있는 것은 아닙니다. DNS가 커널에서 처리되는지, 해당 프로토콜에 스니핑이 적용되는지와 앱이 고정 주소에 직접 연결하는지를 확인해야 합니다.

IP, Geo와 no-resolve

IP-CIDR와 IP-CIDR6는 대상 주소에 따라 네트워크 대역을 매칭합니다. 규칙 끝의 no-resolve는 이 IP 규칙을 실행하기 위해 도메인을 추가로 해석하지 않도록 하여 불필요한 조회와 규칙 단계의 부작용을 줄입니다. 대상 IP가 이미 있는 연결은 바로 판단할 수 있습니다. 사설 네트워크 대역과 로컬 주소는 보통 앞쪽에서 직접 연결 처리하여 LAN 기기 트래픽이 원격 프록시로 전달되지 않게 해야 합니다.

지리 데이터베이스 관련 규칙은 로컬 데이터 파일과 업데이트 상태에 의존합니다. 도메인 분류와 IP 지리적 소속은 서로 다른 데이터 출처입니다. 하나의 서비스 도메인이 전 세계에 분산된 주소로 해석될 수 있으므로 IP 지역만으로 서비스 분류를 대신할 수 없습니다. Geo 계열 규칙을 사용할 때는 적용 범위를 이해하고 핵심 서비스에는 명확한 도메인 규칙을 남기세요. 데이터베이스를 로드하지 못하면 관련 규칙이 적용되지 않을 수 있지만 일반 DOMAIN과 IP-CIDR 규칙은 계속 작동할 수 있습니다. 로그에서 구분할 단서를 확인하세요.

프로세스, 네트워크와 논리 조합

PROCESS-NAME, PROCESS-PATH 등의 프로세스 규칙은 데스크톱 앱별 분류에 적합하지만 시스템 권한과 플랫폼 구현에 의존합니다. Android에서는 패키지 이름이나 시스템이 제공하는 앱 식별 방식이 더 흔하고 iOS의 시스템 제한도 다릅니다. Windows와 Unix 계열에서 프로세스 경로 표현은 완전히 다르므로 하나의 절대 경로를 공유할 수 없습니다. 크로스 플랫폼 설정에 프로세스 규칙이 꼭 필요하다면 모든 플랫폼의 경로를 하나의 기본 파일에 섞지 말고 기기별 오버라이드로 주입하세요.

mihomo가 지원하는 논리 규칙은 여러 조건을 조합해 “모두 충족”, “하나라도 충족” 또는 “특정 항목 제외”를 표현할 수 있습니다. 조합 능력이 강할수록 읽기와 문제 해결의 비용도 커집니다. 실제 관리에서는 예외를 규칙 순서로 표현하는 것을 우선하세요. 소수의 제외 항목을 먼저 작성하고 일반 규칙을 뒤에 둡니다. 순서만으로 명확하게 표현할 수 없거나 여러 조건이 반드시 동시에 충족되어야 할 때만 논리 조합을 사용하세요. 복잡한 표현식에는 주석과 반복 테스트할 수 있는 대상 도메인을 함께 남겨야 몇 달 뒤에도 원래 의도를 파악하기 쉽습니다.

안정적인 규칙 순서 템플릿

설명 가능한 일반적인 순서는 로컬 기기와 LAN 예외, 명시적 거부 항목, 핵심 서비스의 정확한 규칙, 서비스 도메인 규칙 집합, 지역 또는 네트워크 규칙, 최종 폴백입니다. 순서가 절대적인 정답은 아니지만 각 계층이 왜 다음 계층보다 앞서야 하는지 설명할 수 있어야 합니다. 특정 정확한 도메인을 직접 연결해야 한다면 해당 도메인을 포함하는 프록시 접미사 규칙보다 앞에 배치해야 합니다. 특정 하위 도메인을 프록시로 보내야 한다면 전체 부모 도메인 직접 연결 규칙보다 앞에 배치해야 합니다.

규칙을 검증할 때 한 번 웹페이지를 여는 것에 의존하지 마세요. 브라우저가 기존 연결을 재사용하거나 DNS가 캐시를 사용할 수 있습니다. 수정 후에는 관련 연결을 닫고 필요한 캐시를 정리한 다음 로그의 대상, 규칙 유형과 정책 이름을 확인하세요. 로그에는 올바른 규칙이 표시되지만 출구가 다르다면 정책 그룹을 따라가며 점검해야 합니다. 로그에 도메인이 표시되지 않으면 DNS와 스니핑 계층으로 돌아가세요. 규칙 문제, 정책 선택 문제와 노드 연결 문제는 계층별로 판단해야 합니다.

오버라이드와 병합: 구독 업데이트 후에도 로컬 설정 유지하기

원본 구독, 생성 설정과 최종 설정

원격 구독은 상위 데이터 소스입니다. FlClash로 가져온 뒤 파싱, 오버라이드와 커널 호환 처리를 거쳐 최종 실행 설정이 만들어질 수 있습니다. 구독 캐시를 직접 편집하면 즉시 적용되는 것처럼 보여도 다음 업데이트에서 새 내용으로 교체되는 경우가 많습니다. 안정적으로 관리하려면 상위에서 담당하는 노드 데이터와 로컬에서 담당하는 정책을 분리하세요. 구독은 노드와 기본 그룹을 제공하고, 로컬 오버라이드는 포트, DNS, 그룹 구조, 규칙과 기기별 차이를 담당하게 합니다. 문제가 생기면 원본 구독이 올바른지, 오버라이드가 예상대로 실행되었는지와 최종 설정을 커널이 받아들였는지를 구분해 확인해야 합니다.

오버라이드는 단순한 텍스트 이어 붙이기가 아닙니다. 매핑 필드, 시퀀스 필드와 같은 이름의 객체에는 서로 다른 전략이 필요합니다. 매핑은 키를 바꾸거나 재귀적으로 병합할 수 있고, 시퀀스는 전체 교체, 앞부분 삽입, 뒷부분 추가 또는 이름 기준 처리가 가능합니다. 현재 도구의 병합 의미를 모른다면 먼저 mode 수정처럼 결과를 확인하기 쉬운 필드 하나로 테스트하세요. 그다음 최종 설정을 확인합니다. DNS 전체, 수십 개의 규칙과 여러 정책 그룹을 한 번에 추가하면 오류 발생 시 어떤 병합 방식이 원인인지 찾기 어렵습니다.

매핑 교체와 시퀀스 추가의 차이

원래 설정에 완전한 dns 매핑이 있고 로컬 오버라이드에는 dns.enable: true만 있다고 가정해 보겠습니다. 재귀 병합이면 기존 nameserver 같은 하위 항목이 유지되지만, 전체 교체라면 enable만 남을 수 있습니다. 두 결과 모두 특정 “오버라이드” 정의에는 부합하므로 FlClash의 현재 오버라이드 유형과 최종 미리보기를 기준으로 판단해야 합니다. 중요한 DNS 구간을 완전히 제어해야 한다면 부분 병합에 의존하기보다 원하는 전체 구조를 명시하는 편이 안정적입니다.

rules는 순서가 있는 시퀀스입니다. 간단한 추가는 MATCH 앞에 보충 규칙을 올바른 위치로 넣을 때 적합하지만, 원래 목록이 MATCH로 끝난다면 새 규칙을 맨 뒤에 추가해도 절대 매칭되지 않습니다. 앞부분 삽입은 LAN 예외와 정확한 덮어쓰기에 적합하고, 전체 교체는 규칙 체계를 완전히 직접 관리할 때 적합합니다. 정책 그룹 시퀀스를 이름 기준으로 병합할 때도 같은 이름의 그룹이 교체되는지, 확장되는지 또는 중복 객체가 생기는지 확인해야 합니다. 같은 이름의 그룹이 두 개 생기면 UI와 참조 결과를 판단하기 어려워집니다.

# 기본 설정: base.yaml
mixed-port: 7890
mode: rule

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,노드 선택

# 로컬 오버라이드 대상: override.yaml
log-level: info
ipv6: false

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query

규칙 삽입 위치를 명확히 지정하기

구독에 사용자 정의 규칙을 추가할 때는 먼저 예외인지, 일반 분류인지, 폴백인지 판단하세요. 예외 규칙은 보통 앞부분에 삽입하고, 서비스 규칙은 더 포괄적인 집합보다 앞에 배치하며, 폴백 규칙은 마지막에만 둡니다. 스크립트 오버라이드를 지원한다면 원래 목록에서 MATCH의 인덱스를 찾은 뒤 그 앞에 새 규칙을 삽입할 수 있습니다. MATCH를 찾지 못했을 때는 안내를 기록하고 보완할지 결정해야 하며, 조용히 맨 뒤에 추가한 후 구조가 올바르다고 가정해서는 안 됩니다.

중복 제거는 전체 행의 텍스트만 비교해서는 안 됩니다. 두 규칙이 같은 조건에 매칭되지만 서로 다른 정책을 가리킨다면 중복이 아니라 충돌입니다. 같은 도메인의 정확한 규칙과 접미사 규칙도 중복이 아닙니다. 먼저 규칙 유형과 매칭 내용으로 충돌을 식별한 다음 로컬 우선순위에 따라 유지할 위치를 결정하세요. 자동 삭제 전에는 검토 가능한 결과를 출력해야 합니다. 규모가 작은 사용자 정의 규칙은 과도한 자동화보다 명시적이고 읽기 쉽게 유지하는 편이 낫습니다.

기기별 차이는 가장 바깥 계층에 둔다

여러 플랫폼에서 설정을 공유할 때 노드, 정책 그룹과 대부분의 도메인 규칙은 함께 사용할 수 있습니다. 반면 TUN, 프로세스 경로, 네트워크 인터페이스, LAN 리스닝과 시스템 DNS 가로채기는 기기별 차이가 큽니다. 플랫폼과 무관한 기본 계층을 유지하고 Windows, macOS, Android와 Linux에는 가벼운 기기별 오버라이드를 적용하는 것을 권장합니다. 그러면 특정 플랫폼을 맞추기 위해 다른 플랫폼이 인식하지 못하거나 필요로 하지 않는 필드를 하나의 파일에 넣지 않아도 됩니다.

예를 들어 데스크톱에서는 프로세스 규칙이 필요할 수 있지만 Android에서는 앱 기능에 맞춘 처리가 더 적합합니다. Linux 라우터는 투명 프록시 포트를 사용할 수 있고, 일반 Windows 데스크톱은 mixed-port 또는 TUN만 필요할 수 있습니다. macOS 네트워크 확장에는 시스템 승인이 필요하며 설정 필드만으로 권한 승인을 대신할 수 없습니다. 플랫폼 설치와 권한이 관련된 경우 빠른 시작과 macOS 네트워크 확장 설정 안내를 확인하고 YAML만으로 시스템 요구 사항을 우회하려 하지 마세요.

구독 업데이트 후 확인 목록

업데이트가 끝나면 먼저 구독을 성공적으로 가져왔는지 확인하고, 노드 수와 이름 구조가 예상대로 바뀌었는지 점검하세요. 그런 다음 오버라이드에 오류가 없었는지, 최종 설정에 DNS, 정책 그룹과 규칙이 여전히 존재하는지 확인합니다. 마지막으로 커널을 시작하고 리스닝, DNS 초기화, 규칙 제공자와 프록시 제공자 로드 상태를 관찰하세요. 설정이 로드된 뒤에는 정책 그룹의 현재 선택도 확인해야 합니다. 상위 구독에서 노드가 삭제되면 저장된 이전 선택이 무효화되거나 폴백될 수 있습니다.

자동 업데이트 실패를 간격을 계속 줄이는 방식으로 해결해서는 안 됩니다. 구독 주소가 유효한지, 네트워크가 프록시를 거쳐야 하는지, DNS가 구독 서버를 해석할 수 있는지, 업데이트 요청이 프록시 순환을 만드는지와 클라이언트가 백그라운드에서 시스템 제한을 받는지를 확인하세요. 관련 내용은 Clash 구독 업데이트 실패 및 자동 업데이트 설정에서 확인할 수 있습니다. 클라이언트 프로젝트의 유지보수가 중단되어 마이그레이션해야 한다면 설정 내보내기와 클라이언트 마이그레이션 체크리스트를 참고하세요.

되돌릴 수 있는 유지보수 방식

한 번에 역할이 명확한 설정 구간 하나만 수정하고 이전에 정상 작동한 파일을 보관하세요. 이름에는 기본 계층, DNS 계층, 규칙 계층과 기기 계층처럼 용도와 플랫폼을 드러낼 수 있지만 동적 날짜나 임시 상태를 정책 이름에 넣지는 마세요. 규칙 참조가 자주 바뀌기 때문입니다. 업데이트 전 현재 정책 선택을 기록하고, 업데이트 후 핵심 도메인, LAN 접근, DNS 경로와 프록시 대상 하나를 확인하세요. 테스트 범위에는 직접 연결과 프록시 트래픽을 모두 포함해야 하며 웹페이지가 열리는지만 확인해서는 안 됩니다.

오버라이드가 점점 설명하기 어려워진다면 패치를 계속 추가할 것이 아니라 정리해야 한다는 뜻입니다. 더 이상 사용하지 않는 규칙 출처를 삭제하고 역할이 겹치는 정책 그룹을 합치며 기기 전용 필드를 기본 계층에서 분리하세요. 각 외부 제공자의 용도도 기록해야 합니다. 설정 매뉴얼의 목표는 사용할 수 있는 모든 필드를 빽빽하게 채우는 것이 아니라 모든 요청이 “진입점, DNS, 규칙, 정책 그룹, 노드” 경로를 따라 명확하게 설명되도록 하는 것입니다. 기본 설정을 완료했다면 빠른 시작으로 돌아가 연결을 검증하거나 자주 묻는 질문에서 증상별 문제 해결을 계속 진행하세요.