Clash 설정 필드 가이드
YAML과 실제 적용 설정

1. YAML 구조와 설정의 범위

mihomo는 줄 단위로 실행하는 명령이 아니라 구조화된 설정을 읽습니다. 일반적으로 파일의 최상위에는 매핑이 오고, 그 아래에 공통 필드, DNS 설정, 프록시 노드 목록, 프록시 그룹 목록, 규칙 목록이 배치됩니다. 파일에서 필드를 작성한 순서가 적용 우선순위를 결정하는 경우는 드물지만, 목록의 순서는 동작을 바로 바꿀 수 있습니다. 대표적인 예가 규칙 목록입니다. 코어는 위에서 아래로 규칙을 확인하므로 규칙을 임의의 순서로 정렬해도 되는 설명 목록처럼 다루면 안 됩니다.

매핑, 목록, 들여쓰기

매핑에서는 콜론으로 필드와 값을 구분하고, 목록에서는 하이픈으로 여러 항목을 나타냅니다. 들여쓰기에는 공백을 사용하고, 단계마다 공백 두 칸으로 통일하는 것이 좋습니다. 탭 문자는 섞어 쓰지 마세요. 같은 단계의 필드는 맞춰 정렬하고, 하위 필드는 상위 필드보다 더 들여씁니다. 콜론 뒤에는 공백을 넣어야 하며, 영문 문장부호를 전각 콜론이나 한국어 쉼표로 바꾸면 안 됩니다. 편집기에 표시된 줄이 반드시 오류의 원인은 아닙니다. 앞줄에서 따옴표를 닫지 않아 파서가 다음 줄에서 오류를 표시할 수도 있습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

proxies: []

proxy-groups:
  - name: 기본 출구
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,기본 출구

이 예제는 설정 구조를 이해하기 위한 출발점입니다. 모든 트래픽이 최종적으로 직접 연결되므로 프록시 연결을 제공하지는 않습니다. proxies: []는 빈 목록을 뜻하며 필드에 빈 값을 지정한 것과는 다릅니다. 최상위의 dns는 매핑이고, nameserver는 그 안에 들어가는 목록입니다. 프록시 그룹 목록의 각 항목도 매핑이므로 하나의 파일 안에서 이 구조들이 번갈아 사용됩니다. 예제를 복사할 때는 관련 있어 보이는 한 줄만 가져오지 말고 전체 계층 구조를 유지하세요.

문자열 형식과 참조 관계

비밀번호, 이름, 경로 및 특수 문자가 포함된 값은 따옴표로 감싸는 것이 좋습니다. 특히 숫자처럼 보이는 비밀번호, 해시 기호, 콜론, 백슬래시에 주의하세요. 일반 스칼라 값의 해시 기호는 주석의 시작으로 해석될 수 있으며, Windows 경로를 큰따옴표 안에 넣으면 이스케이프 처리가 발생할 수 있습니다. 슬래시를 사용하거나 작은따옴표 문자열을 올바르게 쓰면 확인하기가 더 쉽습니다. 불리언 필드는 true 또는 false로 작성하세요. 모든 값을 일률적으로 따옴표로 감싸면 불리언 값이 문자열로 바뀔 수 있습니다.

노드 이름, 프록시 그룹 이름, 규칙의 대상 이름은 서로 참조합니다. 규칙에서 그룹을 참조한다면 그룹의 name과 공백 및 대소문자까지 완전히 일치해야 합니다. 이름에 쉼표는 가급적 넣지 마세요. 기존 규칙 형식은 쉼표로 매개변수를 구분하기 때문입니다. 노드를 삭제하거나 프록시 그룹 이름을 바꾸기 전에 다른 그룹과 규칙에서 해당 이름을 참조하는지 검색하세요. 설정 파싱에 성공해도 모든 참조가 연결된 것은 아닙니다. 참조 문제는 설정 검증이나 로드 과정에서 드러나는 경우가 많습니다.

원본 파일과 실제 적용 설정

구독 원본, 클라이언트의 로컬 설정, 코어가 실제로 불러오는 파일은 서로 다른 대상입니다. 클라이언트가 시작할 때 포트, DNS, TUN 필드를 다시 기록하거나 구독에 규칙을 추가할 수 있습니다. 임시 실행 파일을 직접 편집하면 다음 새로고침이나 재시작 때 변경 사항이 덮어써질 수 있습니다. 먼저 클라이언트의 설정 관리, 오버라이드 또는 병합 메뉴를 찾아 수정 내용이 어느 계층에 저장되는지 확인하고 최종 생성 결과를 살펴보세요. 화면에서 실제 적용 설정을 내보낼 수 없다면 로그와 보호된 제어 인터페이스를 이용해 주요 필드를 확인할 수 있습니다.

각 부분 예제는 해당 필드만 설명합니다. 이 장의 구조 예제를 제외한 나머지 조각을 그대로 완성된 설정으로 실행하지 마세요. 참조하는 노드, 프록시 그룹, 제공자가 최종 설정 안에 정의되어 있는지 먼저 확인해야 합니다.

YAML 앵커를 사용하면 반복을 줄일 수 있지만, 병합 키는 주로 매핑에 사용되며 규칙 목록 두 개를 자동으로 이어 붙이지 않습니다. 설정을 처음 관리한다면 복잡한 재사용보다 명시적으로 작성하는 편이 문제를 해결하기 쉽습니다. 추가를 표현하려고 같은 단계에서 dns나 rules를 중복 정의하지 마세요. 파서마다 중복 키를 처리하는 방식이 다를 수 있습니다. 필드를 하나로 정리한 다음 명확한 병합 절차를 사용하는 것이 안전합니다.

2. 포트, 모드 및 네트워크 트래픽 처리

공통 필드는 코어가 연결을 받는 방식, 아웃바운드 선택 방식, LAN 접근 허용 여부를 결정합니다. 변경하기 전에 세 가지 경로를 구분하세요. 앱이 프록시 리스닝 포트에 직접 연결하는 방식, 시스템 프록시가 시스템 설정을 따르는 앱을 해당 포트로 보내는 방식, TUN이 가상 네트워크 인터페이스로 라우팅 범위의 트래픽을 처리하는 방식입니다. 이 경로들은 함께 사용할 수 있지만 문제가 생기면 각각 따로 확인해야 합니다. 여러 트래픽 처리 방식을 동시에 켜면 문제가 어느 단계에 있는지 판단하기 어려워집니다.

리스닝 포트와 접근 범위

호환성 요구가 없다면 혼합 포트만 설정해도 됩니다. 여러 리스너를 사용하는 경우 포트를 각각 다르게 지정해야 합니다. port와 mixed-port가 같은 주소와 포트를 동시에 사용해서는 안 됩니다. 포트를 변경해도 프록시를 수동으로 설정한 브라우저, 터미널 및 다른 기기가 자동으로 변경되지는 않습니다. 로그에 주소가 이미 사용 중이라고 표시되면 포트를 계속 바꿔 충돌을 숨기기보다 다른 Clash 클라이언트, 이전 코어 프로세스 또는 로컬 서비스가 해당 리스닝 주소를 사용 중인지 먼저 확인하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

tun:
  enable: false
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

위 예제에서는 TUN을 명시적으로 끄고 앱에서 프록시를 지정하는 경로부터 확인합니다. TUN을 사용하려면 tun.enable을 true로 바꾸고 클라이언트에 가상 네트워크 어댑터 생성 및 라우팅 변경 권한이 있는지 확인하세요. stack의 사용 가능한 값은 플랫폼과 코어 기능에 따라 다릅니다. 이름만 보고 호환성을 판단할 수는 없습니다. 클라이언트가 이 필드를 직접 관리할 수도 있으므로 수동 설정 후에도 최종 실행 설정을 확인해야 합니다.

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

mode: rule은 규칙 목록에 따라 연결을 처리합니다. 전역 모드는 트래픽을 전역 프록시 그룹에 전달하고, 직접 연결 모드는 프록시 경로에 문제가 있는지 확인할 때 주로 사용합니다. 전역 모드로 바꿔도 모든 트래픽이 반드시 원격 노드를 거치는 것은 아닙니다. 전역 프록시 그룹에서 DIRECT를 선택할 수도 있습니다. 모드를 바꾼 뒤에는 실제로 선택된 그룹 구성원도 확인하세요. 기존 장기 연결은 이전 출구를 계속 사용할 수 있으므로 확인할 때 새 요청을 보내고, 필요하면 해당 연결을 닫은 뒤 다시 시도해야 합니다.

LAN 공유가 작동하려면 리스닝 설정, 호스트 방화벽, 네트워크 구성이 모두 허용해야 합니다. allow-lan만 바꿔서는 다른 기기의 연결이 보장되지 않습니다. 접속하는 기기에서는 자신의 루프백 주소가 아니라 호스트의 LAN 주소를 사용해야 합니다. 리스닝을 허용하기 전에 연결된 네트워크를 신뢰할 수 있는지 확인하고 필요하면 프록시 인증을 설정하세요. 프록시 인증은 프록시 접속을 보호하는 기능이며 제어 인터페이스의 접근 자격 증명과는 다릅니다. 서로 대체할 수 없으며 제어 인터페이스를 공용 네트워크에 직접 공개해서도 안 됩니다.

TUN과 IPv6의 범위

auto-route는 관련 경로를 자동으로 설정하고, auto-detect-interface는 아웃바운드 인터페이스를 찾는 데 도움을 줍니다. 이 옵션만으로 여러 네트워크 어댑터, 가상 머신 또는 다른 VPN과의 충돌을 모두 해결할 수는 없습니다. 연결이 반복되는 경우 프록시 서버로 향하는 아웃바운드 트래픽까지 다시 가로채는지, 다른 소프트웨어가 기본 경로를 계속 변경하는지 확인하세요. 데스크톱 시스템의 서비스 권한과 모바일 시스템의 VPN 권한은 서로 다른 방식이므로 한 플랫폼의 권한 설정 절차를 다른 플랫폼에 그대로 적용하면 안 됩니다.

최상위의 ipv6와 dns.ipv6는 서로 다른 설정 계층에 있습니다. 전자는 코어의 IPv6 사용에 영향을 주고, 후자는 DNS의 AAAA 레코드 처리에 영향을 줍니다. 문제를 확인할 때는 시스템에 사용할 수 있는 IPv6 경로가 있는지, 노드가 해당 아웃바운드를 지원하는지, DNS가 IPv6 주소를 반환하는지 함께 기록하세요. 스위치 하나만 끈 것으로 전체 연결 경로가 IPv4로 바뀌었다고 단정할 수는 없습니다. 연결 기록과 실제 DNS 응답을 바탕으로 필드를 조정하세요.

3. DNS와 Fake-IP 필드

DNS 설정은 접속 대상 도메인뿐 아니라 프록시 서버 주소를 조회하는 방식에도 영향을 줄 수 있습니다. 먼저 시스템이 어디에 질의하는지, 코어가 어떤 업스트림을 사용하는지, 업스트림 도메인의 초기 주소를 어떻게 구하는지, DNS 요청이 어느 경로로 나가는지 구분해야 합니다. 웹페이지가 열린다는 사실만으로 DNS 경로가 예상대로 동작한다고 볼 수는 없습니다. 앱이 캐시를 사용하거나 자체 암호화 DNS를 내장했을 수 있기 때문입니다. 새 DNS 요청부터 시작해 앱, 시스템, 코어의 조회 동작을 각각 확인하세요.

리스닝, 업스트림 및 초기 조회

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.com":
      - https://dns.alidns.com/dns-query

enable은 코어의 DNS 모듈을 켜고, listen은 DNS 서비스의 리스닝 주소를 지정합니다. 예제의 루프백 주소와 기본 포트가 아닌 값은 로컬 호출용입니다. 이 필드가 있다는 이유만으로 시스템의 모든 DNS 요청이 이 주소로 전달되지는 않습니다. 실제 트래픽 처리는 클라이언트 설정, 시스템 DNS 설정 또는 TUN의 DNS 하이재킹으로 이루어질 수 있습니다. TUN의 any:53도 앱이 임의의 암호화 DNS 서비스로 직접 보내는 요청까지 처리한다는 뜻은 아닙니다. 그런 요청은 대체로 일반적인 암호화 연결입니다.

nameserver는 일반 DNS 조회의 업스트림을 지정하고, default-nameserver는 암호화 DNS 서비스의 도메인을 먼저 조회해야 하는 경우처럼 초기 조회에 사용됩니다. proxy-server-nameserver는 프록시 서버 도메인을 조회합니다. 이를 사용하면 노드 도메인 조회가 프록시 연결에 의존하고, 프록시 연결은 다시 노드 도메인에 의존하는 순환을 줄일 수 있습니다. 예제에는 공용 DNS 서비스가 사용되었습니다. 실제 업스트림은 현재 네트워크에서 접속 가능한지와 개인정보 보호 요구에 따라 선택하세요.

Fake-IP와 실제 주소 조회

Fake-IP 모드에서는 앱에 주소 풀의 가상 주소를 반환하고, 코어는 해당 주소와 도메인의 매핑을 저장합니다. 이후 연결을 처리할 때 도메인 정보를 복원해 규칙을 적용합니다. 이를 통해 도메인 기반 판단 정보를 유지할 수 있지만, 앱이 받은 가상 주소와 연결 트래픽 모두 같은 코어를 거쳐야 합니다. 요청이 코어를 우회해 가상 주소로 직접 연결되거나 코어를 재시작한 뒤에도 앱이 이전 캐시를 사용하면 연결이 실패할 수 있습니다. 이 경우 노드 자체가 작동하지 않는다고 단정할 수는 없습니다.

fake-ip-filter는 지정한 도메인에 가상 주소를 사용하지 않도록 합니다. 예제에는 LAN에서 자주 쓰는 이름 접미사가 나와 있지만, 필터에 추가했다고 공용 DNS 업스트림이 내부 네트워크 레코드를 알게 되는 것은 아닙니다. 필요한 경우 DNS 정책으로 내부 DNS를 지정해야 합니다. LAN 기기 하나를 해결하려고 모든 도메인을 필터에 넣으면 기존 도메인 복원 경로가 달라질 수 있습니다. 먼저 실패하는 도메인을 확인하고 필요한 범위만 추가한 다음 앱과 시스템 캐시를 지우고 다시 테스트하세요.

redir-host 모드는 앱에 실제 조회 주소를 반환하고, 연결 단계에서 기존 정보를 바탕으로 트래픽을 처리합니다. Fake-IP와의 주요 차이는 주소 반환 및 도메인 연결 방식에 있습니다. 어느 한쪽이 더 빠르거나 안전하다고 단순히 볼 수는 없습니다. 실제 주소 표시, 특수한 LAN 검색 또는 앱 내부 주소 검사에 의존하는 경우에는 사용하는 트래픽 처리 방식과 함께 테스트해야 합니다. 원리를 더 알아보려면 Fake-IP와 redir-host의 차이를 확인하세요.

DNS 조회 정책과 트래픽 정책을 따로 확인

nameserver-policy는 도메인에 따라 DNS 업스트림을 선택하고, 규칙 목록은 연결 정보에 따라 아웃바운드를 선택합니다. 도메인을 특정 DNS 서버로 조회한다고 해서 해당 도메인에 접속할 때도 같은 프록시 정책을 사용하는 것은 아닙니다. DNS 업스트림 연결에도 규칙을 적용하려면 respect-rules를 검토할 수 있습니다. 다만 사용하기 전에 프록시 서버 도메인을 별도 경로로 조회할 수 있는지, 업스트림 도메인이 순환 의존성을 만들지 않는지 확인하세요. 여러 기능을 한꺼번에 적용한 뒤 실제 조회 경로를 추측하지 마세요.

DNS 응답이 바뀐 뒤에도 기존 연결과 앱 및 시스템 캐시에 이전 상태가 남아 있을 수 있습니다. 테스트할 때는 새 요청을 보내고 조회 도메인, 반환 주소, 적용된 DNS 정책, 최종 아웃바운드를 기록하세요. 캐시 차이를 설정 미적용으로 오해하지 않도록 주의해야 합니다.

fallback을 설정할 때는 관련 필터 조건도 확인하세요. 단순히 목록 순서대로 DNS 서버를 하나씩 시도하는 백업 목록이 아닙니다. 지역 판정이 포함된 경우에는 지리 데이터베이스의 가용성도 결과에 영향을 줍니다. 설정을 처음 다룬다면 접속이 확인된 일반 업스트림 하나와 별도의 노드 조회 경로를 먼저 유지하고, 정상 동작을 확인한 뒤 복잡한 정책을 추가하세요. 조회 시간이 초과되면 업스트림에 연결할 수 없는지, 초기 조회에 실패했는지, 트래픽 처리가 빠졌는지 구분해야 합니다. DNS 필드를 전부 바꾸는 것부터 시작하지 마세요.

4. 프록시 노드와 프로토콜 매개변수

proxies는 정책 그룹에서 사용할 수 있는 아웃바운드 노드 목록입니다. 각 항목에는 고유한 이름과 프로토콜 유형, 해당 프로토콜에 필요한 서버 및 인증 정보가 포함되어야 합니다. 프로토콜 필드를 임의로 바꿔 쓸 수는 없습니다. 비밀번호를 사용하더라도 Shadowsocks의 암호화 방식, Trojan의 TLS 매개변수, 다른 프로토콜의 사용자 ID는 서로 다른 구조입니다. 서로 다른 튜토리얼에서 비슷해 보이는 줄을 조합하지 말고 서버 제공자가 안내한 매개변수를 기준으로 작성하세요.

기본 필드와 프로토콜 설정 전체

proxies:
  - name: 예제-SS
    type: ss
    server: proxy.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: 예제-Trojan
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: proxy.example.com
    skip-cert-verify: false
    udp: true

예제의 예약 도메인과 테스트용 비밀번호는 실제 연결에 사용할 수 없습니다. 서비스 제공자가 안내한 전체 매개변수로 바꿔야 합니다. server에는 도메인이나 주소를 지정하고, port에는 원격 서비스의 리스닝 포트를 지정합니다. 로컬의 mixed-port와는 관계가 없습니다. name은 로컬에서 참조할 이름이며 원격 인증에는 사용되지 않습니다. 이름을 바꾸면 그룹에서 알아보기 쉬워질 수 있지만, 해당 이름을 사용하는 프록시 그룹도 함께 변경해야 합니다. 그렇지 않으면 노드가 있어도 선택할 수 없습니다.

Shadowsocks의 cipher는 서버 설정과 일치해야 합니다. 인증에 실패했다면 DNS 변경으로 해결되지 않는 경우가 많습니다. Trojan은 일반적으로 TLS를 사용하며, sni는 TLS 핸드셰이크에 쓰이는 서버 이름입니다. 연결 시간 초과만으로 접속 가능한 임의의 웹사이트 도메인을 입력하지 마세요. 주소로 서버에 연결하더라도 인증서가 특정 도메인으로 발급되었다면 실제 서비스 설정에 맞춰 이름을 지정해야 합니다. 주소, 포트, 인증 정보, TLS 신원은 서로 다른 계층이므로 각각 확인하세요.

TLS, 전송 계층 및 UDP

skip-cert-verify: false는 인증서 검증을 유지합니다. 인증서 오류가 발생하면 시스템 시간, 인증서 체인, 이름 일치 여부, 연결 대상이 실제로 예상한 서버인지 확인하세요. 검증을 끄면 오류 메시지는 사라질 수 있지만 연결 상대의 신원이 올바르다는 뜻은 아닙니다. 일부 프로토콜은 tls로 TLS를 켜지만 다른 프로토콜은 자체적으로 TLS를 포함합니다. 모든 유형에 같은 스위치가 적용된다고 가정하지 마세요. 지원하지 않거나 잘못된 계층의 필드는 명확한 오류 없이 무시될 수도 있습니다.

WebSocket, HTTP/2 또는 다른 전송 방식을 사용할 때는 서버 배포 설정과 전송 옵션이 일치해야 합니다. WebSocket 경로는 일반적으로 ws-opts.path에 지정하고, 추가 요청 헤더는 해당 headers 매핑에 넣습니다. 접속 주소, TLS 서버 이름, HTTP Host 헤더, 요청 경로가 서로 다를 수 있지만 그 차이는 실제 서버 구성에 따라야 합니다. 임의로 섞어 쓰지 마세요. 노드 유형만 올바르게 바꿔서는 전송 계층의 요구 사항을 충족할 수 없습니다.

udp: true는 노드에서 해당 UDP 트래픽을 처리하도록 허용합니다. UDP를 지원하지 않는 서버에 이 기능을 새로 추가하지는 않습니다. 웹페이지는 열리지만 음성 통화, 게임 또는 QUIC 연결이 실패한다면 앱의 트래픽 처리 경로, 코어의 프로토콜 지원, 원격 서버, 네트워크 중간 장비를 따로 확인하세요. 앱의 QUIC을 끄는 것은 원인을 찾기 위한 방법일 뿐 UDP가 복구되었다는 증거는 아닙니다. 테스트 결과에서 UDP 전달과 DNS 요청도 구분해야 합니다. 두 트래픽은 서로 다른 아웃바운드를 사용할 수 있습니다.

노드 가져오기와 민감한 정보 관리

구독 노드가 항상 proxies에 직접 표시되는 것은 아닙니다. 프록시 제공자를 통해 동적으로 불러올 수도 있습니다. 원본 공유 링크, 인코딩된 노드 목록, 완성된 Clash 설정은 서로 다른 형식이므로 파일 확장자만 바꾸면 YAML로 사용할 수 있는 것이 아닙니다. 가져오기에 실패하면 먼저 응답 본문이 로그인 페이지, 오류 페이지 또는 호환되지 않는 형식인지 확인한 다음 프로토콜 필드를 살펴보세요. 자세한 확인 순서는 구독 가져오기 실패 및 파싱 오류 자가 점검을 참고하세요.

설정 일부를 공유하기 전에 서버 정보, 비밀번호, 사용자 ID, 구독 주소, 접근 매개변수를 제거하세요. 노드 이름에 민감한 정보가 없더라도 전체 구독 링크로 계정에 접근할 수 있는 경우가 있습니다. 문제 해결에는 필드 이름과 계층, 프로토콜 유형, 오류 문구만으로 충분한 경우가 많으므로 인증 값을 공개할 필요는 없습니다. 자동 업데이트되는 구독이라면 인라인 노드를 장기간 직접 관리하지 않는 것이 좋습니다. 구독을 원본으로 유지하고 클라이언트가 지원하는 오버라이드 계층에서 로컬 규칙과 그룹 선택을 설정하세요.

노드 이름이 중복되면 참조 대상이 불분명해질 수 있으며, 여러 구독을 병합할 때 특히 자주 발생합니다. 두 번째 구독을 가져오기 전에 이름이 같은 노드나 프록시 그룹이 있는지, 제공자 경로가 겹치는지 확인하세요. 클라이언트에서 이름 접두사나 필터를 지원한다면 출처별로 일괄 적용하는 편이 노드마다 이름을 수동으로 바꾸는 것보다 낫습니다. 출처, 인증 매개변수, 정책 참조를 분리해 두면 한 항목을 업데이트할 때 나머지를 모두 다시 편집할 필요가 없습니다.

5. 프록시 그룹과 프록시 제공자

프록시 그룹은 노드나 다른 프록시 그룹을 묶어 규칙에서 참조할 아웃바운드 대상으로 만듭니다. 이는 출구를 선택하는 기능이지 연결이 어떤 서비스에 속하는지 판단하는 기능은 아닙니다. 일반적인 구성에서는 규칙이 서비스별 그룹을 가리키고, 서비스별 그룹은 수동 또는 자동 그룹을 선택하며, 자동 그룹은 제공자에서 노드를 가져옵니다. 이런 계층은 노드 변경이 규칙에 미치는 영향을 줄여주지만 순환 참조를 만들면 최종 출구를 결정할 수 없습니다.

수동 선택과 자동 테스트

proxy-providers:
  로컬 노드:
    type: file
    path: ./providers/local.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 자동 출구
    type: url-test
    use:
      - 로컬 노드
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 50

  - name: 기본 출구
    type: select
    proxies:
      - 자동 출구
      - DIRECT
    use:
      - 로컬 노드

여기서 providers/local.yaml 파일이 실제로 있어야 합니다. 루트에는 proxies 목록이 포함되어야 하며 그 안에 실제 노드를 작성하세요. 이전 장의 예제 노드는 구조 확인용으로만 사용할 수 있습니다. 경로는 보통 코어의 작업 디렉터리를 기준으로 해석되며, 클라이언트가 파일 접근 범위를 제한할 수도 있습니다. 파일을 찾지 못하면 현재 편집 중인 파일을 기준으로 경로를 추측하지 말고 실제 작업 디렉터리부터 확인하세요. 파일 제공자는 참조 관계를 설명하는 데 적합하며, 원격 구독에는 보통 HTTP 유형과 업데이트 주소를 사용합니다.

select는 사용자가 구성원을 직접 선택하고, url-test는 테스트 결과에 따라 사용 가능한 출구를 고릅니다. fallback은 구성원 순서대로 사용 가능한 출구를 찾고, load-balance는 선택한 방식에 따라 연결을 분산합니다. 자동 테스트 결과는 테스트 대상까지의 상태만 보여주며 모든 웹사이트, 스트리밍 서비스, 업무 서비스의 사용 가능 여부를 보장하지는 않습니다. 테스트 대상은 안정적으로 접속할 수 있어야 하며 특정 로그인 상태가 필요한 페이지는 가급적 상태 확인에 사용하지 마세요.

간격, 허용 범위 및 그룹 구성원

interval 예제의 단위는 초이고, tolerance는 자동 선택 시 허용하는 지연 시간 차이로 예제에서는 밀리초를 사용합니다. 허용 범위를 두면 결과가 조금씩 달라질 때 잦은 전환을 줄일 수 있지만, 불안정한 노드나 부적절한 테스트 대상을 해결하지는 못합니다. 상태 확인도 실제 네트워크 요청을 발생시키므로 구독 규모가 크다면 간격을 지나치게 짧게 설정하지 마세요. 클라이언트가 백그라운드나 절전 상태에서 작업을 조정할 수 있으므로 화면의 업데이트 시각만으로 각 테스트 요청이 제시간에 전송되었다고 볼 수는 없습니다.

proxies에는 명시적으로 지정한 구성원 이름을 나열하고, use에는 프록시 제공자 이름을 참조합니다. 두 필드는 같은 그룹에 함께 쓸 수 있지만 의미가 다릅니다. 전자는 이미 정의된 노드나 그룹을 참조하고, 후자는 제공자에 포함된 노드 목록을 가져옵니다. 제공자 상태 확인과 프록시 그룹 테스트도 서로 다른 계층에서 작동합니다. 같은 테스트 주소를 사용하더라도 결과와 실행 시점이 같다고 볼 수는 없습니다. 그룹이 비어 있다면 모든 노드가 작동하지 않는다고 단정하지 말고 제공자 로드 결과와 필터 조건부터 확인하세요.

중첩 그룹은 방향성이 있고 순환이 없어야 합니다. 예를 들어 서비스별 그룹은 기본 출구를 참조하고, 기본 출구는 자동 출구를 참조할 수 있지만 자동 출구가 다시 서비스별 그룹을 참조해서는 안 됩니다. 중첩이 너무 많으면 화면에 표시되는 현재 선택을 이해하기도 어려워집니다. 규칙 대상에서 최종 노드까지의 참조 경로를 먼저 그려보세요. 규칙이 제대로 적용되는데도 직접 연결된다면 가장 바깥쪽 그룹 이름만 보지 말고 각 단계에서 DIRECT를 허용하고 실제로 선택했는지 확인하세요.

원격 제공자와 업데이트 시 설정 유지

HTTP 유형 제공자에는 보통 url, path, 업데이트 간격이 필요합니다. 구독 주소는 접근 자격 증명의 일부이므로 공개 저장소나 공개 로그에 넣지 마세요. 캐시 경로는 고유하게 지정해야 합니다. 여러 출처가 같은 경로를 사용하면 서로의 데이터를 덮어쓸 수 있습니다. 자동 업데이트가 실패했다면 원격 요청 실패인지 로컬 캐시를 계속 사용할 수 있는지 구분하세요. 화면에 노드가 남아 있어도 최신 구독을 가져왔다는 뜻은 아니며, 캐시된 노드가 여전히 유효하다는 보장도 없습니다.

이름 필터를 사용한다면 정규식의 매칭 범위, 대소문자, 제공자 업데이트 후 이름 변경 여부를 확인하세요. 필터가 하나도 일치하지 않으면 자동 그룹에 선택할 노드가 없어집니다. 테스트 간격을 줄여도 해결되지 않습니다. 먼저 필터를 해제해 노드가 로드되는지 확인한 다음 범위를 조금씩 좁히세요. 그룹 선택을 저장하려면 profile.store-selected와 같은 클라이언트 또는 코어의 저장 기능이 필요합니다. 이 기능은 선택 상태를 저장할 뿐 구독 업데이트를 대신하거나 삭제된 노드를 복구하지는 않습니다.

프록시 그룹 이름을 안정적으로 유지하고 노드 출처를 업데이트할 수 있는 구조가 구독 전체를 복사하는 방식보다 관리하기 쉽습니다. 로컬 규칙은 안정적인 그룹 이름을 참조하고 제공자를 통해 노드를 업데이트하면 구독 변경이 규칙에 미치는 영향을 줄일 수 있습니다.

6. 규칙 문법과 매칭 순서

규칙 모드에서 rules는 순서대로 적용하는 매칭 목록입니다. 각 규칙은 보통 유형, 조건, 대상의 세 요소로 이루어지며 일부 유형은 추가 매개변수를 지원합니다. 먼저 일치한 규칙이 아웃바운드를 결정하고 이후 규칙은 더 이상 확인하지 않습니다. 따라서 규칙을 관리할 때는 개수보다 순서를 먼저 설계해야 합니다. 규칙 모음을 많이 추가한다고 트래픽 분류가 자동으로 정확해지는 것은 아닙니다. 조건이 겹치거나 너무 넓은 규칙을 앞에 두면 세부 정책이 가려질 수 있습니다.

도메인, 주소 및 기본 규칙

rules:
  - DOMAIN,printer.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,기본 출구
  - DOMAIN-KEYWORD,example,기본 출구
  - 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는 도메인 이름에 특정 키워드가 포함된 경우에 적용됩니다. 키워드 규칙은 범위가 넓어 관계없는 도메인까지 같은 정책에 포함할 수 있습니다. 서비스 범위가 명확하다면 정확한 도메인이나 접미사 규칙을 우선 사용하세요. 예제에서는 특정 도메인을 앞에 배치해 뒤에 있는 키워드 규칙이 먼저 적용되지 않도록 합니다. 규칙 대상은 실제로 존재하는 노드, 프록시 그룹 또는 내장 아웃바운드여야 합니다.

IP-CIDR은 대상 IPv4 주소 범위와 일치하고 IPv6 범위에는 IP-CIDR6을 사용합니다. no-resolve는 이 규칙을 평가할 목적으로 도메인 조회를 새로 시작하지 않도록 합니다. 연결 전체에 DNS가 필요 없다는 뜻도, 실제 대상 주소가 이미 있을 때 규칙을 적용할 수 없다는 뜻도 아닙니다. 사설 네트워크 직접 연결 규칙도 연결 정보에 따라 달라집니다. 특히 Fake-IP 모드에서는 가상 주소를 앱이 실제로 접속하는 서버 주소로 간주하면 안 됩니다.

규칙 모음과 동작 유형

rule-providers:
  로컬 도메인:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,로컬 도메인,DIRECT
  - MATCH,기본 출구

이 조각을 사용하려면 실제 규칙 파일이 필요하며, 파일 내용은 다음 예제와 같은 형식으로 작성할 수 있습니다. 도메인 유형 규칙 모음에는 도메인 항목만 넣고 각 항목 뒤에 프록시 그룹을 추가하지 않습니다. 규칙 대상은 기본 설정의 RULE-SET 항목에서 지정합니다. classical 유형은 규칙 유형을 포함한 항목을 사용하고, ipcidr 유형은 주소 범위를 사용합니다. 동작 유형, 파일 형식, 실제 내용이 서로 맞아야 합니다. 한 유형의 파일을 다운로드한 뒤 이름만 바꿔 다른 유형으로 읽게 할 수는 없습니다.

payload:
  - "+.example.com"
  - "printer.example.org"

RULE-SET에 지정한 제공자 이름은 rule-providers의 키와 일치해야 합니다. 로컬 경로나 원격 URL을 적는 곳이 아닙니다. 규칙 모음이 겹치는 경우에도 우선순위는 기본 규칙 목록의 위치에 따라 결정됩니다. HTTP 유형 규칙 제공자는 캐시와 업데이트 상태도 확인해야 합니다. 문제를 해결할 때 현재 로드된 규칙 항목과 업데이트 시각을 함께 기록하세요. 원격 업데이트에 성공해도 대상 도메인이 실제 규칙 모음에 포함되어 있다는 뜻은 아닙니다.

프로세스 규칙과 플랫폼별 차이

프로세스 이름, 경로, 앱 ID를 기준으로 하는 규칙은 플랫폼과 권한에 따라 달라지며 코어가 연결을 소유한 프로세스 정보를 가져올 수 있어야 합니다. 데스크톱에서 프로세스 규칙이 적용된다고 모바일 시스템에서도 같은 정보를 제공한다고 가정하면 안 됩니다. 로그에 예상한 프로세스 필드가 없다면 실행 권한과 클라이언트 지원 여부부터 확인하세요. 여러 플랫폼에서 사용할 설정에는 도메인 및 주소 규칙이 더 일관적입니다. 프로세스 규칙은 실제로 확인된 보조 조건으로 활용하고 유일한 트래픽 분류 기준으로 삼지 마세요.

GEOIP나 지리 기반 도메인 규칙 모음은 관련 데이터베이스와 로드 방식에 의존합니다. 데이터베이스 누락, 출처 변경, 업데이트 실패는 매칭 결과에 영향을 줄 수 있습니다. 규칙이 적용되지 않으면 규칙 문법을 의심하기 전에 대상 정보와 리소스 상태를 확인하세요. 도메인이 한 번 조회되어 나온 주소 하나를 서비스의 고정 주소로 간주해서도 안 됩니다. CDN, 지역별 조회, 서비스 이전으로 주소가 바뀔 수 있습니다. 정확한 제어가 필요하다면 도메인 범위를 관리하고 연결 기록으로 요청에 관련된 다른 도메인도 확인하세요.

MATCH는 기본 규칙이므로 일반적으로 마지막에 둡니다. 앞에 배치하면 뒤의 규칙이 적용될 기회를 잃습니다. 사용자 지정 예외는 예외를 덮어쓰는 규칙 모음보다 앞에 두되, 무조건 첫 줄에 배치할 필요는 없습니다. 설정을 바꾼 뒤에는 새 연결을 만들고 규칙 유형, 일치 조건, 프록시 그룹, 최종 노드를 확인하세요. 규칙이 제대로 적용되는데 접속이 실패한다면 중복 규칙을 계속 추가하지 말고 노드 또는 DNS 문제를 살펴보세요. 규칙 판단과 연결 경로의 정상 동작은 각각 따로 확인해야 합니다.

7. 구독 오버라이드와 설정 병합

구독은 보통 외부에서 관리되며, 로컬에서는 리스닝 포트, LAN 설정, DNS, 추가 규칙, 프록시 그룹 선택을 별도로 설정해야 합니다. 오버라이드는 로컬 설정을 독립된 계층에 저장하고 구독을 업데이트한 뒤 다시 적용하는 기능입니다. 구독 서버의 내용을 직접 수정하는 기능도 아니고 YAML에 정의된 통일 표준도 아닙니다. 클라이언트마다 매핑, 목록, 빈 값 처리 방식이 다를 수 있으므로 오버라이드 조각을 전체 객체로 작성할지 일부 필드만 작성할지 결정하기 전에 병합 규칙부터 확인하세요.

먼저 필드의 관리 주체를 확인

포트와 TUN은 클라이언트 설정 화면에서 관리되는 경우가 많고, 노드와 제공자는 주로 구독에서 가져옵니다. 서비스별 규칙은 구독과 로컬 추가 설정을 함께 반영할 수 있습니다. 같은 필드를 두 계층이 모두 관리한다면 최종 값은 설정 생성 순서에 따라 달라집니다. 화면의 스위치만 보고 원본 파일이 수정되었다고 단정하거나, 원본 파일에 값이 적혀 있다는 이유로 실행 중에도 덮어쓰이지 않았다고 판단하면 안 됩니다. 원본 구독, 로컬 오버라이드, 최종 실행 파일을 나란히 확인하고 주요 필드의 출처를 기록하세요.

매핑 병합과 목록 대체

다음은 DNS와 로그 설정을 조정하기 위한 부분 오버라이드 예제입니다. 기존 구독의 다른 DNS 필드가 유지되는지는 클라이언트가 재귀 병합을 사용하는지, 전체 대체를 사용하는지에 따라 달라집니다. 전체 대체 방식이라면 nameserver를 생략했을 때 DNS 설정이 불완전해질 수 있습니다. 적용하기 전에 병합 결과를 내보내거나 확인하세요. 저장에 성공했는지만으로 올바른 결과인지 판단하면 안 됩니다. 일부 클라이언트에는 별도의 DNS 오버라이드 스위치가 있으며, 이 기능을 켜면 일반 오버라이드에 지정한 같은 이름의 필드가 최종 설정의 출처가 아닐 수도 있습니다.

# 부분 오버라이드 예제; 병합 방식은 클라이언트에 따라 다릅니다.
log-level: info
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

목록은 매핑보다 더 주의해서 다뤄야 합니다. 규칙 두 개만 포함한 rules 목록을 일반 오버라이드에 넣으면 구독 규칙에 두 개를 추가하는 대신 전체 목록을 대체할 수 있습니다. 프록시 그룹 목록을 넣으면 구독의 기존 그룹이 삭제되어 여러 규칙의 참조가 무효가 될 수도 있습니다. 앞에 삽입할 규칙, 뒤에 추가할 규칙, 전용 병합 메뉴를 명시적으로 구분하는 클라이언트 기능을 우선 사용하세요. 목록 전체를 대체하는 방식만 지원된다면 전체 목록을 관리하고 구독 구조가 바뀔 때마다 동기화해야 합니다.

규칙을 추가할 때는 위치도 고려해야 합니다. 원본 구독의 마지막에 MATCH가 있는 경우가 많으므로 그 뒤에 도메인 예외를 추가하면 적용되지 않습니다. 예외를 사용하려면 해당 예외가 가로챌 수 있는 더 넓은 규칙보다 앞에 배치해야 합니다. 예외 대상이 새 로컬 그룹이라면 그룹과 구성원 출처도 최종 설정에 포함되어야 합니다. 규칙, 그룹, 제공자는 하나의 참조 경로를 구성합니다. 일부만 저장해서는 실제로 동작하는 로컬 설정이 되지 않습니다.

클라이언트별 차이와 업데이트 후 재확인

Clash Plus, Clash Verge Rev, FlClash 등은 구독 설정을 관리하는 메뉴가 서로 다릅니다. 같은 조각을 확인 없이 다른 클라이언트에서 재사용하지 마세요. 설정 관리, 오버라이드, 규칙 추가, 실행 설정과 관련된 메뉴를 찾아 설명을 확인한 다음 연결에 영향을 주지 않는 필드로 병합 방식을 시험하세요. 예를 들어 로그 수준만 조정해 실행 중 값이 바뀌는지 확인한 뒤 관찰 가능한 도메인 규칙을 추가하고, 마지막으로 DNS와 트래픽 처리 경로를 다루면 어떤 계층에서 차이가 생기는지 파악하기 쉽습니다.

구독을 업데이트하기 전에 로컬 오버라이드와 정상 작동하는 설정 사본을 저장하되, 자격 증명이 포함된 사본을 공개된 곳에 올리지 마세요. 업데이트 후에는 안정적인 그룹 이름이 남아 있는지, 제공자 이름이 바뀌었는지, 노드 필터 결과가 비어 있는지, 규칙 대상이 유효한지 확인하세요. 구독 변경은 노드 추가와 삭제뿐 아니라 그룹 계층이나 규칙 리소스도 바꿀 수 있습니다. 업데이트 후 문제가 생겼다면 반복해서 다시 가져오기보다 변경 전후의 구조를 비교하는 편이 효과적입니다. 첫 실행 점검은 최초 설치 및 초기 설정 체크리스트를 참고하세요.

클라이언트가 생성한 임시 실행 파일을 직접 관리하지 마세요. 유지해야 할 설정은 클라이언트가 지원하는 오버라이드 계층에 저장하고 복구할 수 있는 사본을 보관하세요. 구독을 한 번 새로고침한 뒤에도 변경 사항이 남아 있는지 다시 확인해야 합니다.

YAML의 & 앵커, 별칭, 매핑 병합은 클라이언트의 파일 간 병합 절차를 대체하지 않습니다. 이 기능들은 현재 YAML 문서를 파싱하는 동안 구조를 재사용할 뿐 외부 구독의 업데이트 방식을 자동으로 알지 못합니다. 중복된 최상위 키로 덮어쓰기를 구현하거나 빈 객체가 언제나 기존 설정을 지운다고 가정하지 마세요. 유지 관리가 쉬운 오버라이드는 가능한 한 작게 작성하고 바꿀 필드를 명시한 뒤 변경마다 결과를 확인할 단계를 마련해야 합니다.

8. 설정 검증과 문제 해결

설정 문제는 파일 파싱, 참조 연결, 리스닝 시작, DNS, 아웃바운드 연결, 규칙 판단 순서로 나누어 확인해야 합니다. 각 단계마다 실패 징후가 다르므로 모든 문제를 구독 오류로 볼 수는 없습니다. 로드에 실패하면 문법과 필드부터 확인하고, 로드는 성공했지만 트래픽이 없다면 트래픽 처리 설정을 확인하세요. 트래픽은 있지만 DNS 조회에 실패하면 DNS를, 조회는 성공하지만 원격 연결이 실패하면 노드를 확인합니다. 연결은 되지만 출구가 예상과 다르면 규칙과 그룹 선택을 확인하세요. 이 순서를 따르면 관련 없는 설정을 바꾸는 일을 줄일 수 있습니다.

정적 검사와 코어 검증

클라이언트 밖에서 파일을 관리한다면 편집기의 YAML 검사 기능으로 들여쓰기, 따옴표, 중복 키를 먼저 확인하세요. 일반 YAML 파싱에 성공했다는 것은 문법이 올바르다는 뜻일 뿐 프로토콜 필드와 참조까지 유효하다는 뜻은 아닙니다. 실제로 실행할 mihomo 코어로도 설정을 검증하고 가능한 한 클라이언트와 같은 코어를 사용하세요. 다른 코어로 검증하면 지원 필드 차이 때문에 잘못된 판단을 할 수 있습니다. 클라이언트에서 코어 명령을 실행할 방법이 없다면 검증을 위해 프로그램 파일을 임의로 교체하지 마세요.

# 별도의 테스트 디렉터리에서 확인하세요. 경로는 실제 파일 위치에 맞게 지정합니다.
mihomo -t -d ./mihomo-check -f ./config.yaml

# HTTP 프록시를 명시해 리스닝과 기본 요청 경로를 확인합니다.
curl -I --proxy http://127.0.0.1:7890 https://example.com

# 프록시 서버에서 대상 도메인을 조회해 SOCKS 요청 경로를 확인합니다.
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

# 이 문서의 예제에 나온 로컬 DNS 리스닝을 확인합니다.
nslookup example.com 127.0.0.1

마지막 DNS 명령은 시스템 도구의 기본 DNS 포트를 사용하며 앞에서 설정한 1053 포트에 직접 질의하지 않습니다. 로컬 표준 포트에서 DNS 서버를 실행하지 않는다면 다음 예제처럼 포트를 지정할 수 있는 도구를 사용하세요. 잘못된 포트로 조회해 시간 초과가 발생해도 코어의 업스트림에 연결할 수 없다는 뜻은 아닙니다. 명령 사용 가능 여부는 운영체제와 설치된 도구에 따라 달라집니다. 터미널에서 실제 curl 프로그램이 실행되는지도 확인하세요.

dig @127.0.0.1 -p 1053 example.com A

-t는 설정을 테스트하고, -d는 작업 디렉터리를 지정하며, -f는 설정 파일을 지정합니다. 설정이 참조하는 상대 경로 리소스는 지정한 작업 디렉터리에서 사용할 수 있어야 합니다. 테스트 중 제공자 파일이 없다고 해서 YAML 문법이 잘못된 것은 아닙니다. 정식으로 클라이언트를 실행할 때 작업 디렉터리가 다른지도 확인하세요. 같은 프록시 포트를 사용하는 코어를 두 번째로 실행해 테스트하면 안 됩니다. 새로운 포트 충돌이 생겨 원래 문제를 가릴 수 있습니다.

새 연결로 판단 경로 확인

먼저 프록시를 직접 지정한 요청으로 리스닝과 기본 아웃바운드를 확인하고, 그다음 시스템 프록시를 켠 뒤 마지막으로 TUN을 테스트하세요. 이렇게 하면 앱이 시스템 프록시를 따르는지와 코어 자체가 정상인지 분리할 수 있습니다. HTTP 요청 성공이 UDP, IPv6, 모든 앱의 정상 동작을 증명하지는 않으므로 실제 사용 사례별로 테스트해야 합니다. SOCKS에서 도메인을 로컬에서 조회하는지 프록시 서버에서 조회하는지에 따라 진단 결과가 달라집니다. 예제의 socks5h는 프록시 서버가 대상 도메인을 조회하도록 하므로 로컬 조회 경로와 비교할 수 있습니다.

연결 기록에서 대상 도메인이나 주소, 적용된 규칙, 최상위 프록시 그룹, 중첩 그룹 선택, 최종 노드를 순서대로 확인하세요. 규칙이나 그룹 선택을 바꾼 뒤에는 기존 연결을 재사용할 수 있는 페이지를 새로고침하는 데 그치지 말고 새 연결을 만드세요. 클라이언트에서 연결을 닫을 수 있다면 테스트 연결만 다시 만들고, 작업을 저장하지 않은 상태에서 모든 연결을 한꺼번에 끊지 마세요. DNS를 바꾼 경우 캐시도 고려해야 합니다. Fake-IP 주소가 바뀌었는데 앱이 이전 캐시를 사용하면 새 설정과 다른 결과가 나타날 수 있습니다.

로그 수준 조정과 최소 변경으로 복구

평소에는 적절한 로그 수준을 유지하고 문제를 확인할 때만 상세도를 높이세요. 먼저 최초 실패를 일으킨 오류를 확인한 다음 연쇄적으로 발생한 메시지를 살펴봅니다. 예를 들어 원격 도메인 조회 실패가 이후 모든 연결 시간 초과로 이어질 수 있습니다. 포트 점유는 보통 시작 단계에서 발생하고 TLS 신원 오류는 원격 핸드셰이크 단계에서 발생하므로 해결 방법이 다릅니다. 관련 필드는 mihomo 주요 로그 오류와 확인 순서를 참고하세요. 로그를 공유하기 전에 인증 정보와 구독 정보를 제거해야 합니다.

한 번에 한 종류의 변수만 바꾸고 변경 전 값, 변경 이유, 테스트 결과를 기록하세요. 문제가 생기면 클라이언트 재설치, 구독 변경, DNS 수정 등을 한꺼번에 하지 말고 가장 최근 변경부터 되돌리세요. 최소 직접 연결 설정은 작동하지만 전체 설정이 작동하지 않는다면 제공자, 프록시 그룹, 규칙, 트래픽 처리 기능을 하나씩 복구하세요. 처음 실패하는 모듈이 다음 조사 범위가 되는 경우가 많습니다. 최소 설정이 동작해도 제외한 원격 노드까지 정상이라는 뜻은 아닙니다.

최종 확인에는 설정 다시 불러오기, 클라이언트 재시작, 구독 새로고침을 각각 한 번 이상 포함해야 합니다. 이를 통해 설정 파싱, 저장된 설정 복구, 업데이트 후 오버라이드 유지 여부를 확인하세요. LAN 리스닝 범위, 제어 인터페이스 접근 범위, 로그 수준이 예상 상태로 돌아왔는지도 살펴보세요. 작업 순서를 다시 확인하려면 입문 가이드로 돌아가고, 클라이언트를 바꾸려면 설치 파일 페이지에서 운영체제에 맞는 파일을 선택하세요. 정상 작동 상태를 기준 설정으로 저장해 두면 이후 변경을 되돌릴 출발점이 생깁니다.