Clash 설정 파일 가이드

YAML 구조와 설정 범위

Clash 설정은 순서대로 실행하는 명령어 목록이 아니라, 연결 수신·이름 확인·아웃바운드·라우팅 관계를 정의하는 구조화된 문서입니다. 최상위의 dns, proxies, proxy-groups, rules는 각각 맡은 역할이 있습니다. 이름 참조가 올바르고 데이터 형식이 맞아야 코어가 이 항목들을 연결할 수 있습니다. 익숙하지 않은 설정을 살펴볼 때는 먼저 최상위 필드를 확인하고, 규칙이 가리키는 대상 이름에서 프록시 그룹을 찾은 다음, 그룹이 참조하는 노드를 확인하세요. 파일 첫 줄부터 끝 줄까지 그대로 읽기만 하면 이런 의존 관계를 놓치기 쉽습니다.

맵, 목록, 들여쓰기

YAML은 들여쓰기로 부모와 자식의 관계를 나타냅니다. 공백 두 칸을 일관되게 사용하고 탭은 섞지 않는 것이 좋습니다. 콜론 뒤에 공백이 있으면 대개 키와 값의 구분이고, 하이픈 뒤에 공백이 있으면 목록 항목입니다. name이라는 키도 노드 아래에 있는지 프록시 그룹 아래에 있는지에 따라 의미가 달라집니다. 편집기의 자동 정렬 기능은 들여쓰기를 맞추는 데 도움이 되지만, 참조 관계가 올바른지는 판단하지 못합니다. 코드를 복사할 때는 상위 항목까지 확인해 dns 아래에 있어야 할 필드를 최상위에 잘못 넣지 않도록 하세요.

# 구조 예시: 목록의 각 항목은 별도의 프록시 그룹입니다
proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,수동 선택

문자열, 숫자, 불리언은 각각 올바른 형식으로 작성해야 합니다. 포트는 보통 숫자로, 켜기/끄기 값은 true 또는 false로 씁니다. 따옴표로 감싼 문자열을 사용하면 일부 파서는 거부하고 다른 파서는 변환할 수 있으므로 이런 차이에 기대지 마세요. 특수 문자가 포함되거나 앞에 0이 붙거나 다른 값으로 오인될 수 있는 텍스트는 따옴표로 감싸는 편이 안전합니다. 비밀번호도 따옴표로 감싸고, 작은따옴표나 큰따옴표가 포함되면 YAML 이스케이프 규칙에 따라 처리하세요. 일반 주석은 # 뒤에 씁니다. 단, 문자열 안의 샵 기호가 내용으로 처리되는지는 따옴표와 위치에 따라 달라집니다.

구독 원본, 편집 내용, 실행 설정 구분하기

데스크톱 클라이언트는 보통 파일 하나만 저장하지 않습니다. 원격 구독의 원본 텍스트, 로컬 편집 또는 오버라이드 내용, 그리고 코어에 전달되는 최종 실행 설정이 따로 있을 수 있습니다. 화면에 표시되는 포트, 시스템 프록시, TUN 설정도 클라이언트 설정을 통해 최종 결과에 반영될 수 있습니다. 구독 텍스트를 수정했다고 현재 실행 설정이 바뀌는 것은 아닙니다. 다시 불러오거나 구독을 전환하거나 오버라이드를 적용해야 변경 내용이 반영될 수 있습니다. 문제를 확인할 때는 선택한 설정 이름과 실제로 불러온 시간을 기록하세요. 이전 파일을 편집하면서 다른 설정의 연결 결과를 확인하는 일을 피할 수 있습니다.

최상위 필드의 순서는 보통 맵의 의미에 영향을 주지 않지만, 목록 순서는 동작을 바꿀 수 있습니다. 규칙은 목록 순서대로 적용되고, 수동 선택 그룹은 첫 번째 항목이 초기 선택에 영향을 줄 수도 있습니다. 서식 정리 도구의 '알파벳순 정렬'을 모든 목록에 적용하지 마세요. 중복 키도 위험합니다. 같은 계층에 dns나 rules가 두 번 나오면 도구에 따라 오류가 나거나 뒤에 나온 항목만 남을 수 있습니다. 내용을 합칠 때는 같은 키 아래에서 정리하세요. 설정 전체를 파일 끝에 그대로 붙여 넣으면 안 됩니다.

최소 구조와 설정 호환성

새 설정을 만들 때는 먼저 시작 가능한 최소 구성부터 만들고 노드, 그룹, 규칙을 하나씩 추가하세요. 어떤 구독을 한 클라이언트에서 가져올 수 있었다고 해서 다른 클라이언트도 같은 필드를 처리할 수 있다는 뜻은 아닙니다. 구형 코어는 최신 프로토콜이나 DNS 필드를 이해하지 못할 수 있고, 클라이언트가 일부 옵션을 걸러낼 수도 있습니다. 알 수 없는 필드가 있으면 현재 코어 문서와 로그부터 확인하세요. 안내를 없애려고 설정 블록을 무작정 지우면 안 됩니다. 해당 항목이 도메인 확인이나 아웃바운드 선택에 꼭 필요할 수 있습니다.

YAML 앵커와 별칭은 중복을 줄여 주지만 오버라이드 도구, 구독 변환기, 수동 검토를 복잡하게 만들 수 있습니다. 혼자 관리하는 작은 설정이라면 적당히 반복하더라도 각 부분을 독립적으로 이해할 수 있도록 작성하는 편이 낫습니다. 문제 해결을 위해 설정을 다른 사람에게 전달할 때는 계층, 필드 형식, 참조 관계를 유지하고 서버 주소, 비밀번호, 구독 링크만 바꾸세요. 노드나 그룹 이름을 통째로 지우면 오류 상황을 재현하기 어려워지고 문법 오류, 필드 호환성, 연결 실패를 구분하기 힘들어집니다.

포트, 프록시 모드, 트래픽 적용 범위

공통 필드는 코어가 연결을 수신할 위치, 라우팅 방식, 접근을 허용할 기기를 정합니다. 가장 흔한 실수는 수신 포트와 서버 포트를 혼동하는 것입니다. mixed-port는 로컬 앱이 프록시에 연결할 때 쓰는 진입 포트이고, 노드의 port는 원격 서버가 서비스를 제공하는 포트입니다. 두 값은 달라도 되며 같아야 할 이유도 없습니다. 로컬 수신 포트를 변경했다면 시스템 프록시와 앱 내부의 프록시 주소도 함께 확인하세요. 그렇지 않으면 코어는 정상 실행 중인데 앱은 이전 포트에 연결할 수 있습니다.

수신 설정의 용도

로컬 앱만 프록시를 사용한다면 보통 혼합 포트 하나면 충분합니다. HTTP, SOCKS, 혼합 포트를 모두 켤 필요는 없으며, 같은 주소의 같은 포트를 여러 수신 항목에서 사용해서도 안 됩니다. 주소가 이미 사용 중이라는 오류가 나면 다른 프록시 인스턴스나 백그라운드 서비스가 실행 중인지 먼저 확인하세요. 로컬 네트워크 접근 허용은 불리언 값 하나만 켜면 끝나는 문제가 아닙니다. 수신 주소, 시스템 방화벽, 접근 제어를 함께 고려해야 하며 신뢰할 수 없는 네트워크에 프록시 포트를 직접 노출해서는 안 됩니다.

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

규칙 모드, 전역 모드, 직접 연결

mode: rule은 트래픽을 규칙 목록에 따라 라우팅하고, 일치 결과에 따라 아웃바운드를 선택합니다. 전역 모드는 보통 전역 선택 항목으로 처리하며, 직접 연결 모드는 사용자 지정 규칙에 따라 프록시 노드를 선택하지 않습니다. 모드는 라우팅 방식이지 트래픽을 가로채는 방식이 아닙니다. 전역 모드를 선택해도 시스템 프록시, 앱 설정, TUN을 통해 들어오지 않은 트래픽이 저절로 코어에 전달되지는 않습니다. 반대로 규칙 모드에서 DIRECT 규칙이 일치하면 연결은 여전히 코어가 수신하며, 최종 아웃바운드만 직접 연결로 선택됩니다.

시스템 프록시는 운영체제의 앱 프록시 설정을 바꾸는 방식이며, 이를 따를지는 앱에 달려 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 수신하므로 적용 범위가 더 넓지만 권한, 라우팅 충돌, DNS 가로채기를 고려해야 합니다. TUN을 '더 강력한 전역 모드'로 생각하거나, 켜기만 하면 모든 네트워크 문제가 해결된다고 여기면 안 됩니다. 게임, 가상 머신, 컨테이너, 기업 VPN은 각각 트래픽 경로가 다릅니다. 활성화하기 전에 현재 상태를 저장하고 기본 경로와 DNS 설정을 되돌릴 방법을 확인하세요.

TUN과 클라이언트 설정의 역할

# TUN 예시: 활성화 전에 클라이언트 권한과 라우팅 환경을 확인하세요
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

위 예시는 자동 라우팅과 기존 DNS 요청을 가로채려는 설정을 보여 줍니다. 앱 자체의 암호화 DNS나 모든 플랫폼의 네트워크 스택까지 처리한다고 보장하지는 않습니다. 운영체제마다 가상 네트워크 인터페이스, 서비스 권한, 방화벽 요구 사항이 다르고 클라이언트가 해당 필드를 일괄 관리할 수도 있습니다. 화면의 설정과 파일 설정이 서로 덮어쓴다면 먼저 관리할 위치를 하나로 정하세요. 구체적인 활성화 방법은 입문 가이드를 참고하세요. 이 페이지에서는 필드 간 관계만 설명하며 클라이언트 동작을 확인하지 않은 채 네트워크 설정 블록 전체를 바꾸지 않도록 안내합니다.

일상적으로는 로그 수준을 info로 두고, 문제를 재현할 때만 상세도를 높이는 것이 좋습니다. 디버그 로그에는 대상 도메인, 연결 정보, 설정 경로가 포함될 수 있으므로 공유하기 전에 민감한 내용을 가리세요. 최상위의 ipv6와 DNS 안의 같은 이름 필드는 서로 다른 단계에 영향을 줍니다. 한쪽만 바꾸고 IPv6 경로를 모두 처리했다고 판단하지 마세요. 원격 제어 인터페이스를 사용할 때는 제어 영역과 프록시 영역의 차이도 이해해야 합니다. 관리 인터페이스는 상태를 변경하는 용도이지 일반 앱의 프록시 진입점이 아닙니다.

시작 프로그램 등록, 조용한 실행, 테마, 트레이 동작은 대부분 GUI 클라이언트의 환경 설정이며 모든 코어에 공통으로 적용되는 YAML 필드는 아닙니다. 설정을 옮길 때는 '네트워크 동작'과 '화면 동작'을 따로 기록하세요. 클라이언트 선택은 설치 파일 페이지에서 확인할 수 있습니다. 일반 사용자라면 우선 추천하는 Clash Plus를 살펴보고, 운영체제와 설정 호환성에 따라 Clash Verge Rev 등의 클라이언트를 선택하세요. 화면이 비슷하다는 이유만으로 설정 파일도 그대로 호환된다고 생각하면 안 됩니다.

DNS 필드와 도메인 확인 경로

DNS는 도메인을 IP 주소로 변환하지만 프록시 환경에서는 확인 단계가 여러 번 있을 수 있습니다. 앱이 먼저 직접 조회할 수 있고, 코어가 규칙에 필요한 대상 IP를 조회할 수도 있으며, 프록시 서버에 연결할 때 서버 도메인을 확인해야 할 수도 있습니다. 어떤 대상을 조회하는지 구분해야 브라우저에서는 접속되는데 명령줄에서는 실패하는 이유나 노드 도메인을 확인하지 못해 연결할 수 없는 이유를 파악할 수 있습니다. 암호화된 DNS 서버를 설정해도 모든 앱이 이를 사용하는 것은 아니며 라우팅에서 프록시 아웃바운드가 선택된다는 뜻도 아닙니다.

수신, 업스트림, 초기 도메인 확인

dns.enable은 코어의 DNS 기능을 켜고 끕니다. listen은 DNS 수신 주소, nameserver는 일반적인 조회에 사용할 업스트림을 지정합니다. 도메인 형식의 DoH 주소를 사용하려면 먼저 해당 업스트림의 주소를 알아내야 합니다. 이것이 초기 도메인 확인 문제입니다. default-nameserver는 이런 기초 조회에 사용할 수 있으므로 명확한 IP 주소를 지정하는 편이 좋습니다. 노드 서버 주소도 도메인이라면 proxy-server-nameserver로 조회 경로를 지정해 서버 도메인 확인과 대상 도메인 분기를 혼동하지 않도록 하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

이 예시는 필드 간 관계를 설명하며 모든 네트워크에 맞는 DNS 설정을 제시하는 것은 아닙니다. 업스트림에 연결할 수 있는지는 네트워크 환경에 따라 달라지므로 사용 전에 접근 가능한지 확인하세요. 코어가 1053 포트를 수신하도록 설정해도 시스템이 DNS 요청을 자동으로 이 주소에 보내지는 않습니다. 클라이언트나 시스템 네트워크 설정에서 연결해 줘야 하며, TUN 환경에서는 DNS 가로채기와 라우팅이 실제로 적용됐는지 확인해야 합니다. 앱 자체의 보안 DNS는 기존 포트를 통한 가로채기를 우회할 수 있으므로 문제 해결 시 별도로 기록하세요.

fake-ip와 실제 주소 확인

fake-ip 모드는 앱에 예약 주소 대역의 매핑 주소를 반환하고, 코어는 매핑을 통해 도메인을 복원해 연결을 처리합니다. 이 방식은 도메인 정보를 유지하는 데 도움이 되지만 트래픽이 계속 같은 코어를 거쳐야 합니다. 앱이 매핑 주소를 받은 뒤 프록시 경로를 우회하면 연결되지 않을 수 있습니다. 일부 로컬 네트워크 서비스, 장치 검색 프로토콜, 주소를 특별하게 처리하는 앱은 이런 응답과 맞지 않을 수 있으므로 필터 항목으로 필요한 도메인만 제외하세요. 앱 하나를 위해 모든 도메인을 제외하면 이 모드를 선택한 이유가 사라집니다.

redir-host는 보통 조회한 실제 주소를 반환합니다. fake-ip와 동작 방식이 다를 뿐, 모든 환경에서 더 안정적이라는 뜻은 아닙니다. 여러 도메인이 같은 실제 주소를 공유할 수 있고, 연결이 코어에 도달할 때 도메인 정보가 없으면 규칙 결과가 달라질 수 있습니다. 두 모드를 전환한 뒤에는 관련 앱의 캐시를 지우거나 연결을 다시 만들어야 합니다. 그렇지 않으면 이전 주소가 계속 관찰 결과에 영향을 줍니다. 예약 주소가 보인다고 곧바로 네트워크 오류라고 판단하지 말고, 실제 웹 서버 주소로 간주해 위치를 추정하지도 마세요.

도메인별 DNS 서버 지정

nameserver-policy는 특정 도메인의 조회 경로를 지정할 수 있어 사내 도메인, 가정 내 기기 이름, 명확한 DNS 요구 사항이 있는 서비스에 적합합니다. 이 설정은 '어디에 조회할지'를 정할 뿐 '연결이 어떤 아웃바운드를 사용할지'를 정하지 않습니다. 트래픽 경로를 바꾸려면 규칙도 설정해야 합니다. 내부 DNS 서버는 해당 로컬 네트워크나 VPN에서만 접근할 수 있는 경우가 많으므로 네트워크를 벗어난 뒤에도 계속 강제 사용하면 시간 초과가 발생합니다. 이런 설정을 관리할 때는 적용되는 네트워크를 기록하고 관련 없는 공용 DNS 서버에 내부 도메인을 보내지 않도록 하세요.

# 기존 dns 맵에 병합하고 최상위 dns를 중복 선언하지 마세요
dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

fallback과 필터 조건은 별도의 선택 방식입니다. 주 서버가 실패했을 때만 예비 서버를 사용한다고 단순하게 이해해서는 안 됩니다. 어떤 조회 결과를 받아들일지는 주소 범위나 관련 필터 설정에도 좌우될 수 있습니다. 명확한 요구 사항이 없다면 '설정을 완성하기 위해' DNS 서버를 여러 개 추가할 필요는 없습니다. 설정이 복잡할수록 캐시, 정책, 대체 경로 중 어디서 결과가 나왔는지 구분하기 어려워집니다. 먼저 사용할 수 있는 업스트림 하나만 설정하고 DNS 요청이 제대로 전달되는지 확인한 다음 정책을 하나씩 추가하는 편이 문제를 찾기 쉽습니다.

DNS 누수를 확인하려면 먼저 시스템이 처리할 요청, 코어에 전달할 요청, 프록시 서버가 처리할 요청을 구분한 뒤 실제 연결과 DNS 기록으로 검증하세요. 검사 사이트에 표시된 조회 위치는 한 번의 테스트 결과일 뿐 앱 동작을 확인하는 방법을 대신하지 못합니다. DNS는 정상인데 HTTPS 오류가 난다면 인증서 검증을 바로 수정하지 마세요. 프록시 사용 중 인증서 오류 해결을 참고해 시스템 시간, 신뢰 체인, 네트워크 환경을 확인하고 DNS 문제와 인증서 문제를 나눠 처리하세요.

프록시 노드 필드와 연결 매개변수

proxies는 정적 아웃바운드 정의 목록이며 각 항목은 구체적인 연결 방식을 설명합니다. 노드 이름은 프록시 그룹과 규칙에서 참조하고, 서버 주소·포트·프로토콜·인증 필드는 실제 연결 가능 여부를 결정합니다. 노드 이름에 특정 지역이 적혀 있어도 관리자가 붙인 라벨일 뿐 서버 위치나 연결 품질을 증명하지 않습니다. 연결 실패를 해결할 때는 표시 이름을 반복해서 바꾸기보다 실제 프로토콜과 서버 매개변수를 확인하세요. 이름을 바꾸면 참조 관계만 달라지고 원격 서버 문제는 해결되지 않습니다.

공통 필드와 프로토콜별 필드

대부분의 노드에는 name, type, server, port가 있지만 인증과 전송 필드는 프로토콜마다 달라 그대로 옮겨 쓸 수 없습니다. Shadowsocks는 암호화 방식과 비밀번호를 사용하며 다른 프로토콜은 사용자 이름, 식별자 또는 다른 TLS 매개변수가 필요할 수 있습니다. 같은 이름의 필드라도 프로토콜 구현에 따라 지원 여부가 다를 수 있습니다. 서버가 제공한 매개변수와 현재 코어의 지원 범위를 기준으로 설정하세요. 공유 링크의 모든 텍스트를 감으로 YAML에 옮기면 안 됩니다. 인코딩, 이스케이프, 선택 매개변수에는 각각 정해진 규칙이 있습니다.

# 구조 예시: 주소와 비밀번호는 설명용 가상 값입니다
proxies:
  - name: 예시 출구
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

위 예시는 정적 노드를 구성하는 기본 방법을 보여 주며 실제 연결에는 사용할 수 없습니다. udp: true는 해당 아웃바운드에서 관련 기능을 허용한다는 뜻이지 전체 연결 경로에서 UDP를 지원한다는 뜻은 아닙니다. 서버, 프로토콜, 라우팅, 앱 연결 방식에 따라 제한이 생길 수 있습니다. TCP 웹 페이지가 정상적으로 열린다고 음성 통화, 게임 등 UDP 기반 서비스도 작동한다고 볼 수 없습니다. 테스트할 때는 실제 앱과 같은 전송 경로를 사용하고 연결이 코어에 전달되는지, 대상 아웃바운드가 선택되는지, 서버가 요청을 받는지 각각 확인하세요.

TLS, 서버 이름, 전송 계층

TLS를 사용하는 프로토콜에는 servername 같은 서버 이름 필드가 자주 사용됩니다. 이 값은 핸드셰이크와 인증서 이름 확인에 쓰이며 로컬 표시 이름과 같지 않고 실제 연결에 사용하는 IP와도 다를 수 있습니다. 서버에서 특정 이름을 요구한다면 정확히 입력하세요. 오류를 피하려고 다른 도메인으로 바꾸면 안 됩니다. 인증서 오류가 나면 시스템 시간, 인증서 체인, 매개변수 일치 여부부터 확인하세요. 인증서 검증을 끄면 보안 경계가 달라지므로 일반적인 문제 해결 방법으로 사용해서는 안 되며 모든 기기에 배포하는 공용 설정에도 넣지 마세요.

전송 유형, 경로, 요청 헤더 등은 별도로 협상되는 설정입니다. 예를 들어 WebSocket 전송에서는 경로와 Host가 리버스 프록시 설정에 따라 달라질 수 있습니다. 하위 계층에서 TCP 연결이 된다고 이후 전송 핸드셰이크까지 성공하는 것은 아닙니다. 로그에 연결 초기화나 핸드셰이크 실패가 표시되면 서버가 제공한 정보와 하나씩 대조하세요. 도메인, 포트, 전송 유형을 한꺼번에 바꾸기보다 한 번에 변수 하나만 바꾸고 실패 로그를 남기는 편이 진단에 도움이 됩니다. 일시적인 네트워크 변동을 설정 수정 효과로 오해하는 일도 줄일 수 있습니다.

노드 제공자와 구독 형식

노드가 많다면 proxy-providers를 사용해 노드 데이터와 기본 설정을 분리할 수 있습니다. 제공자는 보통 proxies 목록이 포함된 YAML을 반환합니다. 임의의 공유 링크 모음이 아니며 완성된 Clash 설정과 같다고 볼 수도 없습니다. 제공자의 유형, 경로, 갱신 주기는 데이터를 가져오는 방법을 지정하고 프록시 그룹은 use로 제공자를 참조합니다. 가져오기에 실패하면 먼저 응답 내용이 예상한 형식인지 확인하세요. 로그인 페이지, 오류 메시지, HTML 페이지는 다운로드에 성공했더라도 올바른 노드 데이터가 아닙니다.

# 로컬 제공자: paths는 코어 작업 디렉터리와 클라이언트 제약에 맞게 설정하세요
proxy-providers:
  로컬 노드:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: 제공자 선택
    type: select
    use:
      - 로컬 노드

로컬 제공자를 사용하려면 실제 데이터 파일을 미리 준비해야 합니다. 경로는 보통 코어 작업 디렉터리를 기준으로 해석되며 클라이언트의 경로 제한도 영향을 줄 수 있습니다. 편집기에서 현재 열어 둔 폴더를 기준으로 한다고 가정하지 마세요. 원격 제공자에는 업데이트 실패, 캐시, 접근 인증 정보도 관련됩니다. 구독 링크 자체에 접근 권한이 포함되는 경우가 많으므로 민감 정보로 취급하세요. 스크린샷, 로그, 오류 내용을 공유할 때는 비밀번호뿐 아니라 전체 구독 주소와 쿼리 매개변수도 지워야 다른 사람이 같은 서비스 데이터를 가져가지 못합니다.

설정 전체에서 노드 이름은 고유하게 유지하고 프록시 그룹 이름이나 내장 아웃바운드 이름과 겹치지 않게 하는 것이 좋습니다. 일괄 이름 변경 후에는 모든 정적 참조도 함께 수정하세요. 제공자를 사용한다면 필터 표현식이 여전히 노드를 찾는지도 확인해야 합니다. 서비스 업데이트로 노드 이름이 바뀌거나 삭제될 수 있으므로 장기 규칙이 자주 바뀌는 노드 이름에 직접 의존하지 않도록 하세요. 규칙은 이름이 안정적인 프록시 그룹을 참조하고, 그룹이 노드 변경에 대응하도록 구성하면 업무 라우팅과 서버 목록을 따로 관리할 수 있습니다.

프록시 그룹 유형과 참조 관계

프록시 그룹은 '특정 트래픽이 어떤 출구를 쓸지'와 '현재 선택할 수 있는 노드가 무엇인지'를 분리해 줍니다. 규칙은 변경이 적은 그룹 이름을 계속 참조하고, 그룹 안의 노드 목록은 구독 업데이트에 따라 바뀔 수 있습니다. 프록시 그룹을 이해할 때는 유형, 후보 항목, 참조되는 위치를 함께 확인하세요. 자동 선택 그룹도 트래픽이 실제로 해당 그룹을 가리켜야 동작합니다. 화면에서 테스트 결과가 보인다고 모든 연결이 그 그룹을 사용한다는 뜻은 아닙니다. 최상위 수동 선택 그룹이 여전히 직접 연결을 선택했다면 하위 자동 그룹이 정상 작동해도 해당 트래픽 경로는 바뀌지 않습니다.

수동 선택, 자동 테스트, 장애 대체

select는 동작을 예측하기 쉬워 출구 변경에 민감한 로그인이나 업무용 트래픽에 적합합니다. url-test는 테스트 주소로 후보를 비교하지만 특정 요청의 결과를 측정할 뿐 실제 앱의 처리량을 뜻하지 않습니다. fallback은 후보 순서를 중시하므로 주 출구와 대체 출구를 구분할 때 적합합니다. 부하 분배를 설정한다고 한 파일이 모든 노드를 동시에 사용해 속도를 합산하는 것도 아닙니다. 분배 방식에 따라 세션 출구의 안정성도 달라질 수 있습니다. 자동화 수준을 성능 순위처럼 여기지 말고 업무에서 허용할 수 있는 범위에 맞춰 선택하세요.

중첩 구조와 추적 가능한 경로

# 기존 노드 설정에 병합해 사용하세요. 예시 출구가 실제로 존재해야 합니다
proxy-groups:
  - name: 업무 출구
    type: select
    proxies:
      - 예시 출구
      - 자동 선택
      - DIRECT

  - name: 자동 선택
    type: url-test
    proxies:
      - 예시 출구
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - MATCH,업무 출구

위 예시에서는 규칙이 '업무 출구'를 가리킨 뒤 사용자가 정적 노드, 자동 선택 그룹, 직접 연결을 선택합니다. 중첩 구조는 재사용에 도움이 되지만 깊어질수록 최종 출구를 파악하기 어려워집니다. 그룹 이름은 용도와 역할이 드러나도록 정하고 '기본값', '기타'처럼 모호한 이름을 반복하지 마세요. A 그룹이 B 그룹을 포함하고 B 그룹이 다시 A 그룹을 참조하는 순환 참조도 만들면 안 됩니다. 순환 참조는 대체 경로가 아니라 아웃바운드를 결정할 수 없는 의존성 오류입니다. 코어나 클라이언트가 설정을 바로 거부할 수 있습니다.

자동 테스트에 사용하는 url, interval, 허용 오차 매개변수는 서비스 동작에 맞춰 설정하세요. 테스트 대상에 연결할 수 없으면 정상인 노드도 한꺼번에 실패로 표시될 수 있으므로 테스트 한 번만 보고 노드를 삭제하지 마세요. 테스트가 너무 잦으면 연결과 모바일 기기의 백그라운드 사용량이 늘고, 너무 드물면 상태 변화가 늦게 반영됩니다. 테스트 주소는 단순하고 응답을 예측할 수 있는 것이 좋지만 실제 대상 서비스와 네트워크 경로가 다를 수 있습니다. 그 결과만으로 모든 웹사이트의 접속 상태를 추정하지 마세요.

제공자, 필터, 선택 상태 유지

그룹이 use로 노드 제공자를 참조하면 제공자 내용에 따라 후보 목록이 달라집니다. 이름 필터도 함께 사용한다면 표현식이 실제 노드 이름과 일치하는지, 업데이트 후 후보가 비는 경우는 없는지 확인하세요. 모든 분기 그룹을 하나의 취약한 이름 규칙에 의존하게 만들지 마세요. 서버에서 라벨을 바꾸면 전체 설정에서 선택 가능한 항목이 사라질 수 있습니다. 필터를 적용하기 전 테스트 설정에서 일치 결과를 확인한 다음 업무 그룹에 적용하세요. 복구를 위해 명확한 수동 선택 경로도 남겨 두는 것이 좋습니다.

클라이언트는 수동 선택을 기억할 수도 있지만 설정 전환, 이름 변경, 캐시 재생성 후 기본 항목으로 돌아갈 수도 있습니다. 그룹의 첫 번째 항목에 문서화되지 않은 암묵적인 보안 규칙을 맡기지 마세요. 업무에서 출구를 고정해야 한다면 설정을 불러오는 데 성공했는지만 확인하지 말고 업데이트 후 선택 상태도 점검하세요. 그룹 선택을 바꿔도 기존 연결이 모두 즉시 전환되지는 않습니다. 연결 재사용, 장시간 연결, 클라이언트 동작이 결과에 영향을 주므로 검증할 때는 새 요청을 만들어 실제 경로를 확인하세요.

모바일 기기에서 설정을 관리할 때는 불필요한 상태 확인을 줄이고 같은 제공자 확인과 그룹 내부 테스트를 각각 목적에 맞게 사용하세요. 모든 업무 그룹에서 같은 노드 목록을 전부 테스트하면 백그라운드 요청이 크게 늘 수 있습니다. 배터리 사용과 백그라운드 설정은 모바일 프록시 클라이언트의 배터리 소모와 백그라운드 설정을 참고하세요. 프록시 그룹은 출구 선택을 명확하게 만들기 위한 기능이지 모든 유형을 동원하기 위한 기능이 아닙니다. 두 단계로 충분히 설명되는 라우팅을 여러 겹의 선택 트리로 만들 필요는 없습니다.

규칙 문법, 순서, 규칙 집합

규칙 목록은 연결이 코어에 들어온 뒤 라우팅을 결정하는 과정입니다. 보통 위에서 아래로 확인하며 가장 먼저 일치한 규칙이 대상 아웃바운드를 정합니다. 모든 일치 결과를 종합해 점수를 매기거나 더 구체적인 규칙을 자동으로 앞으로 옮기지 않습니다. 규칙을 관리할 때는 개별 항목뿐 아니라 그 앞에 어떤 규칙이 있는지도 확인해야 합니다. '규칙이 적용되지 않는다'는 문제는 앞의 포괄적인 규칙이 이미 일치했거나 클라이언트가 다른 설정을 실행 중인 경우가 많습니다. 대상 웹사이트의 지역을 짐작해 규칙을 수정하기보다 연결 기록에서 일치한 항목을 먼저 확인하세요.

도메인, 주소, 최종 대체 규칙

# 업무 출구는 실제로 존재하는 프록시 그룹이어야 합니다
rules:
  - DOMAIN,service.example.com,업무 출구
  - DOMAIN-SUFFIX,example.net,업무 출구
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,업무 출구

DOMAIN은 도메인 하나를 정확히 일치시키고 DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인에 적용됩니다. 두 규칙 모두 전체 웹 주소를 대상으로 하지 않으므로 프로토콜, 경로, 쿼리 매개변수를 넣으면 안 됩니다. DOMAIN-KEYWORD는 키워드가 포함된 도메인을 찾아 적용 범위가 더 넓은 만큼 같은 문자열을 포함하는 다른 도메인까지 잘못 처리할 수 있습니다. 서비스 도메인을 정확히 알고 있다면 정확 일치나 접미사 규칙을 우선 사용하세요. 웹사이트 하나가 여러 리소스 도메인을 불러올 수도 있어 메인 페이지가 올바르게 일치해도 이미지, 로그인, API의 출구는 다를 수 있습니다.

IP-CIDR과 IP-CIDR6은 각각 IPv4와 IPv6 주소 대역을 처리합니다. no-resolve는 해당 규칙이 일치하는지 확인하려고 대상 도메인을 새로 조회하지 않도록 하는 옵션입니다. 직접 연결을 강제하거나 DNS를 차단하는 기능은 아닙니다. 연결에 대상 주소가 이미 있는 경우에는 주소 규칙이 계속 적용될 수 있습니다. 광범위한 주소 규칙을 도메인 규칙보다 앞에 두면 도메인 이름에 따라 처리하려던 연결이 라우팅 판단을 먼저 끝낼 수 있습니다. 규칙 순서는 유형별로 기계적으로 묶지 말고 우선순위가 드러나도록 정하세요.

규칙 일치는 확인 가능한 정보에 따라 달라집니다

도메인 규칙의 적용 여부는 코어가 대상 도메인을 알고 있는지에 달려 있습니다. 앱이 IP 주소로 직접 연결하거나 자체 조회 결과를 사용하거나 일부 트래픽 경로에서 도메인 정보가 사라지면 브라우저 프록시 요청과 결과가 달라질 수 있습니다. 지원되는 환경에서는 스니핑이 일부 정보를 보완할 수 있지만 모든 프로토콜에서 원래 도메인을 복원하는 기능은 아니며 암호화 보호를 우회하는 방법도 아닙니다. 문제를 확인할 때는 먼저 연결 기록에 도메인이 표시되는지 주소가 표시되는지 살펴보세요. 그 결과에 따라 도메인 규칙, 주소 규칙, DNS 또는 트래픽 적용 방식을 조정해야 합니다.

MATCH는 최종 대체 규칙으로 보통 목록 맨 아래에 둡니다. 이 규칙 뒤에 있는 일반 규칙은 일치할 기회를 얻지 못합니다. 내장 아웃바운드 DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. 사용자 지정 대상은 노드나 그룹 이름과 정확히 같아야 합니다. 대소문자를 틀리거나 보이지 않는 공백을 넣거나 이름 변경 후 참조를 수정하지 않으면 설정 불러오기에 실패할 수 있습니다. 거부 규칙을 관리할 때는 적용 범위를 특히 신중하게 지정하고 명확한 테스트 대상으로 먼저 확인하세요. 모호한 키워드를 규칙 전체에 바로 적용하지 마세요.

규칙 제공자와 데이터 동작

rule-providers:
  내부 도메인:
    type: file
    behavior: domain
    path: ./rules/internal.yaml

rules:
  - RULE-SET,내부 도메인,DIRECT
  - MATCH,업무 출구

# ./rules/internal.yaml 파일의 내용
payload:
  - "+.home.arpa"
  - "+.lan"

규칙 집합을 사용하면 많은 규칙을 기본 파일에서 분리해 업데이트하고 재사용하기 쉽습니다. behavior: domain의 데이터는 도메인 규칙이며, 주소 규칙 데이터와 클래식 규칙 데이터는 형식이 다릅니다. 기존 텍스트를 그대로 둔 채 동작 필드만 바꾸면 안 됩니다. 클래식 데이터에는 보통 매칭 조건을 넣고 기본 설정의 RULE-SET 규칙에서 대상 아웃바운드를 지정합니다. 모든 유형의 데이터에 전체 기본 설정 규칙을 그대로 넣지 말고 선택한 형식에 맞춰 확인하세요.

원격 규칙 업데이트에는 관리상 주의할 점도 있습니다. 원본에서 적용 범위가 추가되거나 삭제될 수 있고 캐시 때문에 이전 결과가 계속 사용될 수 있으며, 다운로드 실패 후 기존 파일만 남을 수도 있습니다. 규칙 집합의 출처와 용도를 기록하세요. 적용 범위가 크게 겹치는 규칙 집합 두 개가 서로 다른 목적지로 연달아 처리되는데 우선순위가 분명하지 않은 상황도 피해야 합니다. 노드 구독과 마찬가지로 파일 업데이트 성공은 데이터를 가져왔다는 뜻일 뿐 원하는 트래픽 처리가 이뤄졌다는 뜻은 아닙니다. 업데이트 후에는 적용되어야 하는 요청 하나와 적용되지 않아야 하는 요청 하나를 표본으로 확인해 범위가 달라지지 않았는지 점검하세요.

프로세스 규칙은 운영체제와 프로세스 식별 기능에 따라 달라지므로 여러 시스템에서 사용하는 설정의 유일한 분기 기준으로 삼지 않는 것이 좋습니다. 실행기, 자식 프로세스, 컨테이너 환경에 따라 앱 이름도 달라질 수 있습니다. Windows 스토어 앱의 연결 기록이 전혀 없다면 먼저 요청이 프록시 진입점까지 도달하는지 확인하세요. UWP 루프백 예외 설정을 참고하고, 트래픽이 코어에 들어오지 않는 상황에서 라우팅 규칙을 계속 추가하지 마세요. 규칙은 이미 수신된 연결만 처리할 수 있으며 진입 단계의 격리는 해결하지 못합니다.

구독 오버라이드, 병합, 업데이트 순서

구독 업데이트와 로컬 사용자 지정 설정은 서로 충돌하기 쉽습니다. 원격 구독은 노드, 프록시 그룹, 규칙을 제공하고 로컬 사용자는 포트를 고정하거나 내부 네트워크에 직접 연결하거나 특정 트래픽의 출구를 바꾸려 할 수 있습니다. 내려받은 구독 원본을 직접 수정하면 다음 업데이트에서 새로 생성된 내용으로 덮어써질 가능성이 큽니다. 원격 원본은 유지하고 클라이언트가 지원하는 오버라이드 기능에 로컬 설정을 작성한 뒤 최종 실행 설정에서 해당 변경 위치를 확인하세요. 편집기에서 저장됐는지만 확인해서는 안 됩니다.

최종 설정을 결정하는 주체부터 확인하세요

클라이언트마다 구독 다운로드, 파싱 및 변환, 설정별 오버라이드, 전역 오버라이드, GUI 설정 주입, 코어 로딩 등의 처리 과정이 다릅니다. 모든 클라이언트에 공통으로 적용되는 처리 순서를 제시할 수는 없습니다. 사용 중인 클라이언트에서 미리보기나 실행 설정을 확인하고 관찰 가능한 필드 하나로 결과를 검증하세요. 예를 들어 로그 수준만 바꾼 뒤 적용하고 최종 값을 확인할 수 있습니다. 해당 설정 위치가 현재 구독 생성 과정에 반영되는지 확인한 다음 복잡한 규칙과 DNS 설정을 옮기세요.

오버라이드는 고정된 YAML 문법이 아니라 클라이언트나 도구가 구현한 변환 과정입니다. 스칼라 값은 교체될 수 있고 맵은 재귀적으로 병합될 수 있으며 목록은 전체 교체, 추가, 앞에 삽입 중 하나로 처리될 수 있습니다. 구체적인 동작은 구현에 따라 달라집니다. '깊은 병합'을 사용해도 순서가 중요한 규칙 목록의 우선순위가 자동으로 해결되지는 않습니다. rules 블록이 두 개 있다고 자동으로 연결된다고 생각하지 마세요. 특정 클라이언트 전용 앞에 삽입하는 키를 코어 기본 필드인 것처럼 다른 클라이언트에 복사해서도 안 됩니다.

맵과 목록을 따로 확인하세요

# 원하는 최종 구조 예시이며 모든 클라이언트에서 통용되는 오버라이드 문법은 아닙니다
dns:
  enable: true
  nameserver:
    - https://dns.google/dns-query
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - MATCH,업무 출구

위 예시는 최종적으로 필요한 구조를 보여 줍니다. 오버라이드 도구가 dns 전체를 교체한다면 기존 수신 설정, 초기 조회, 필터 항목까지 삭제될 수 있습니다. 반대로 nameserver를 추가하면 제거하려던 업스트림이 남을 수도 있습니다. 규칙은 삽입 위치를 특히 확인해야 합니다. 사용자 지정 내부 네트워크 규칙을 먼저 일치하는 대체 규칙보다 앞에 두고, 이미 있는 MATCH 뒤에 추가하지 마세요. 최종 설정 미리보기에서는 필드 값과 목록 내 위치를 함께 확인해야 합니다. 검색으로 문자열이 있는지만 확인해서는 부족합니다.

참조 안정성과 충돌 처리

구독에서 생성한 그룹 이름을 사용자 지정 규칙이 참조하면 원본에서 이름을 바꿀 때 참조가 끊어집니다. 안정적인 이름의 로컬 업무 그룹을 규칙의 대상으로 만들고 업데이트되는 노드나 제공자를 참조하게 할 수 있습니다. 단, 사용 중인 오버라이드 방식이 해당 그룹을 안정적으로 만들고 유지할 수 있어야 합니다. 구독에 있는 그룹과 같은 이름의 그룹을 만들어 '덮어쓰기'만 하면 안 됩니다. 병합 방식에 따라 기존 항목이 교체되지 않고 이름이 중복될 수 있습니다. 항목을 교체해야 한다면 기존 항목을 명시적으로 삭제하거나 도구의 항목 변환 기능을 사용하고 최종 목록에서 이름이 하나만 있는지 확인하세요.

같은 구독이라도 플랫폼마다 기본값이 다를 수 있으므로 기기 간 오버라이드를 동기화할 때 로컬 환경 차이를 고려해야 합니다. DNS 수신 주소, 로컬 네트워크 대역, TUN 권한, 로컬 파일 경로는 보통 기기 환경에 따라 달라져 그대로 공유하기 어렵습니다. 사용자 지정 설정은 공통 업무 규칙과 기기별 설정으로 나누고 주석에 용도와 의존성을 적어 두세요. 그러면 컴퓨터나 클라이언트를 바꿔도 업무 설정의 목적은 유지하면서 진입점과 권한을 새 환경에 맞출 수 있습니다. 이전 실행 설정 전체를 새 구독 원본처럼 사용하지 않아도 됩니다.

스크립트 오버라이드는 또 다른 주석 형식이 아니라 전체 설정을 바꿀 수 있는 코드로 취급해야 합니다. 스크립트 오류로 설정 생성이 중단되거나 잘못된 객체 접근으로 필드가 삭제되거나 형식이 바뀔 수 있습니다. 변환 범위를 좁게 유지하고 입력이 비어 있거나 목록이 없거나 이름을 찾지 못한 경우를 어떻게 처리할지 정하세요. 규칙 하나를 추가하려고 노드 목록 전체를 다시 만들지 마세요. 불필요한 재작성은 구독 업데이트 후 장애 가능성을 키웁니다. 문제가 어느 단계에서 생겼는지 알 수 있도록 스크립트와 YAML을 따로 백업하세요.

업데이트 후 회귀 테스트와 이전 설정 이전

오버라이드를 마치면 한 번 이상 업데이트 테스트를 하세요. 먼저 백업한 다음 구독을 새로고침하고 실행 설정과 연결 경로를 확인해 사용자 지정 규칙, 그룹 선택, DNS 필드가 유지되는지 확인합니다. 수동 적용이 한 번 성공했다고 자동 업데이트 과정까지 올바르다는 뜻은 아닙니다. 업데이트 후 문제가 생기면 로컬 오버라이드를 잠시 끄고 원래 구독이 실행되는지 확인한 다음 각 설정을 단계별로 다시 적용하세요. 유지 관리가 중단된 클라이언트에서 이전할 때의 선택지는 Clash Verge Rev 이전 옵션 비교를 참고하세요. 이전 화면의 캐시 상태보다 설정의 목적을 유지하는 것이 중요합니다.

설정 검증, 문제 진단, 유지 관리

설정은 단계별로 검증하세요. 먼저 텍스트가 파싱되는지 확인하고, 다음으로 코어가 필드와 참조를 받아들이는지 확인합니다. 이어서 수신 진입점을 확인한 뒤 DNS 조회, 라우팅, 실제 서비스 동작을 검증하세요. 설정 테스트를 통과했다는 것은 현재 코어가 파일을 이해했다는 뜻일 뿐 서버에 연결할 수 있다거나 비밀번호가 맞다거나 대상 서비스에 접근할 수 있다는 뜻은 아닙니다. 웹페이지가 열렸어도 해당 요청 하나가 성공했다는 의미입니다. 로컬 네트워크, UDP, 백그라운드 앱, 구독 업데이트 등 다른 경로까지 확인해야 합니다. 테스트 입력, 기대 결과, 실제 관찰 내용을 명확히 기록하면 막연히 '정상'이라고 적는 것보다 도움이 됩니다.

오프라인 확인부터 실행 상태 점검까지

# Mihomo가 설치되어 있고 명령을 사용할 수 있는 경우, 설정이 있는 디렉터리에서 실행
mihomo -t -f ./config.yaml

# Windows PowerShell에서 실행 파일이 현재 디렉터리에 있는 경우
.\mihomo.exe -t -f .\config.yaml

이 명령은 실제로 코어 프로그램이 설치된 환경에서만 사용할 수 있습니다. GUI 클라이언트는 별도의 작업 디렉터리, 접근 제한 경로, 생성 파일을 사용할 수 있으므로 외부 코어로 실행 중인 인스턴스를 함부로 덮어쓰지 마세요. 로컬 제공자를 테스트할 때는 상대 경로와 작업 디렉터리가 일치하는지도 확인해야 합니다. 기본 파일의 문법이 올바르더라도 데이터 파일이 없으면 실패할 수 있습니다. 오류 메시지에는 필드, 이름, 줄 번호가 표시되는 경우가 많습니다. 의미 있는 첫 번째 오류부터 해결하세요. 이후 오류는 같은 계층 문제에서 이어진 결과일 수 있습니다.

테스트를 통과한 뒤에는 현재 클라이언트가 실제로 이 설정을 선택하고 불러왔는지 확인하세요. 로그의 로딩 결과, 수신 주소, 권한 오류를 살펴보세요. 포트 사용 중, TUN 장치 생성 실패, 구독 가져오기 실패는 서로 다른 단계의 문제이므로 모두 노드 사용 불가로 묶어서는 안 됩니다. 설정 로딩이 거부되어도 일부 클라이언트는 이전 상태를 유지할 수 있으므로 네트워크가 계속 된다고 새 설정이 적용된 것은 아닙니다. 방금 변경한 관찰 가능한 필드 하나를 대조하면 이전 상태를 새 결과로 오인하지 않을 수 있습니다.

요청의 최소 경로 확인

# HTTP 프록시 진입점을 명시해 앱이 시스템 프록시를 따르는지 여부를 배제
curl -I --proxy http://127.0.0.1:7897 https://example.com/

# SOCKS 진입점: h는 대상 도메인을 프록시 측에서 확인하도록 합니다
curl -I --proxy socks5h://127.0.0.1:7897 https://example.com/

이 명령은 지정한 프록시 진입점을 확인할 때 사용합니다. 예시 대상 서비스가 항상 특정 상태 코드를 반환한다고 보장하지는 않습니다. HTTP 오류 응답을 받는 경우와 프록시 연결 자체를 맺지 못하는 경우는 서로 다릅니다. 전자는 요청이 최소한 HTTP 서버에 도달했다는 뜻이고, 후자는 수신 상태, 프로토콜, 연결 경로를 확인해야 합니다. Windows에서 curl이 다른 명령의 별칭으로 지정되어 있다면 curl.exe를 호출해야 하는지 확인하세요. 명령 하나가 성공했다고 브라우저도 같을 것이라고 판단하지 마세요. 브라우저는 확장 기능, 자체 DNS, 기존 연결 풀을 사용할 수 있습니다.

되돌릴 수 있는 수정 절차 만들기

한 번에 한 계층만 수정하고 수정 전 파일과 간단한 설명을 보관하세요. 백업에는 기본 설정뿐 아니라 로컬 제공자, 규칙 데이터, 오버라이드 스크립트도 포함해야 합니다. 그렇지 않으면 기본 파일을 복원해도 이미 바뀐 데이터를 계속 참조할 수 있습니다. 파일 이름에는 용도와 저장 날짜를 표시할 수 있지만 민감한 구독 주소를 넣을 필요는 없습니다. 시스템 프록시, DNS, TUN을 변경했다면 사용 중지 후 원래 상태로 복원하는 방법도 기록하세요. 원격으로 접속 중인 기기의 기본 라우팅을 변경할 때는 특히 해당 프록시를 사용하지 않는 복구 경로를 준비해야 합니다.

문제를 재현할 때는 관련 없는 프록시 인스턴스를 끄고 고정된 테스트 대상을 사용해 직접 연결과 명시적 프록시 연결을 비교하세요. 특정 앱에서만 문제가 생긴다면 구독 전체를 바로 바꾸지 말고 해당 앱의 트래픽 적용 방식, DNS 확인 방식, 프로세스 경로를 기록하세요. 모든 노드가 동시에 실패하면 로컬 네트워크, DNS 업스트림, 테스트 대상을 확인합니다. 일부 노드만 실패하면 서버와 프로토콜 매개변수를 살펴보세요. 이 순서로 분기하면 불필요한 수정을 줄이고 로그와 실제 문제를 맞춰 볼 수 있습니다.

장기적으로는 더 이상 쓰지 않는 규칙 집합, 오래된 네트워크 대역, 이름이 바뀐 그룹 참조, 일시적인 문제 해결을 위해 추가한 예외도 정리해야 합니다. 구독이나 클라이언트를 업데이트한 뒤 이런 항목부터 확인하면 모든 웹페이지를 다시 테스트할 필요가 없습니다. 다른 사람에게 도움을 요청할 때는 민감 정보를 지운 최소 설정, 오류 문구, 트래픽 적용 방식, 기대한 경로를 제공하세요. 흔한 진입점 문제는 문제 해결을 참고하고, 첫 연결 문제라면 입문 가이드로 돌아가 안내 순서대로 확인하세요.