Clash 설정 파일 가이드: YAML, DNS, 프록시 그룹 및 규칙 필드

YAML 구조와 설정의 범위

요약: 설정 파일은 서로 참조하는 객체의 집합이지, 순서와 관계없이 나열하는 설정 목록이 아닙니다. 최상위 필드는 수신, 해석, 전달 동작을 정하고, 노드는 연결 출구를 제공하며, 프록시 그룹은 출구 선택을 구성하고, 규칙은 요청을 적절한 정책으로 보냅니다. 낯선 설정을 살펴볼 때는 먼저 이 네 계층이 모두 있는지 확인하고 이름이 서로 일치하는지 점검하세요. 한 줄의 문법이 올바르다고 해서 전체 파일이 예상대로 작동하는 것은 아닙니다. 예를 들어 규칙이 존재하지 않는 프록시 그룹을 참조한다면 들여쓰기가 정확해도 제대로 설정을 사용할 수 없습니다.

최상위 매핑, 목록과 중첩 구조

YAML은 들여쓰기로 계층 관계를 표현합니다. 공백 두 칸으로 통일하고 탭은 사용하지 않는 것이 좋습니다. dns: 아래의 enable은 DNS 하위 필드이므로 최상위 mode와 같은 위치에 맞추면 원래 의미를 유지할 수 없습니다. 하이픈으로 시작하는 항목은 목록 요소입니다. 같은 노드의 name, type, server는 동일한 매핑 계층에 있어야 합니다. 콜론 뒤에는 보통 공백이 필요하며, 영문 콜론을 전각 문장 부호로 바꾸면 안 됩니다. 편집기의 세로 들여쓰기 안내선은 공백을 눈으로 세는 것보다 믿을 만합니다.

# 단독으로 불러올 수 있는 직접 연결 구조 예시. 원격 프록시 노드는 포함하지 않습니다
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 예제는 구조를 설명할 뿐, 프록시 기능을 제공하지 않습니다. PROXY 그룹에는 DIRECT만 있으므로 최종 연결은 직접 연결됩니다. 실제로 사용할 때는 유효한 노드나 노드 제공기를 프록시 그룹에 연결하세요. 빈 목록 []은 필드는 있지만 항목이 아직 없다는 뜻으로, 필드 자체를 삭제한 것과 다릅니다. 설정을 확장할 때는 먼저 불러올 수 있는 기본 구조를 유지하고 한 번에 한 종류의 객체만 추가하세요. 문제가 생겨도 어떤 변경에서 오류가 발생했는지 파악하기 쉽습니다.

문자열, 불리언 값과 이름 참조

포트와 간격은 보통 숫자로 작성하고, 스위치에는 true 또는 false를 사용하세요. 한국어로 '켜기'라고 입력하면 안 됩니다. 노드 이름과 비밀번호, 콜론이나 샵 기호가 포함된 문자열은 매핑이나 주석으로 잘못 해석되지 않도록 따옴표로 감싸는 것이 좋습니다. 작은따옴표 문자열 안에 작은따옴표를 넣으려면 두 번 입력해야 합니다. 큰따옴표 안의 백슬래시는 이스케이프 문자로 처리될 수 있습니다. Windows 경로가 포함된 값을 복사할 때는 특히 주의하세요. 작은따옴표를 사용하면 의도치 않은 이스케이프를 줄일 수 있습니다. 주석은 읽기 편하게 해줄 뿐 필드 적용 순서를 바꾸지는 않습니다.

하나의 매핑에서 dns나 rules를 중복 정의하지 마세요. 파서에 따라 중복 키를 처리하는 방식이 다릅니다. 로드를 거부하는 파서가 있는가 하면 나중 값을 남기는 파서도 있으므로 중복 키를 병합 수단으로 사용하면 안 됩니다. 프록시 이름도 고유하게 유지하고 대소문자, 공백, 기호를 원래대로 참조해야 합니다. 노드 이름을 바꿨다면 프록시 그룹에서도 이름을 수정하세요. 그룹 이름을 바꾼 경우에는 규칙의 대상과 해당 그룹을 참조하는 다른 그룹도 함께 수정해야 합니다.

파일, Profile과 실행 설정

클라이언트의 Profile은 설정 출처와 관리 정보를 담으며, 로컬 파일이나 원격 구독을 가리킬 수 있습니다. 구독을 갱신한 뒤 저장된 내용이 커널이 최종적으로 사용하는 설정과 다를 수 있습니다. 클라이언트가 이후에 포트 설정을 적용하거나 규칙을 병합하거나 스크립트를 실행할 수 있기 때문입니다. 문제를 확인할 때는 '구독 원본', '로컬 편집본', '실행 설정'을 구분하세요. 다운로드 캐시의 파일만 수정하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다. 선택되지 않은 Profile만 수정하면 현재 연결에는 영향을 주지 않습니다.

설정을 저장하기 전에 되돌릴 수 있는 사본을 만들고 현재 선택된 Profile을 기록하세요. 일반 텍스트 편집기에서 UTF-8로 저장하고, 서식 있는 텍스트 형식이나 전각 공백, 자동으로 바뀐 따옴표를 사용하지 않도록 주의하세요. 파일 확장자는 클라이언트가 형식을 인식하는 데 도움을 줄 수 있지만, 웹페이지 내용을 .yaml로 바꾼다고 설정 파일이 되는 것은 아닙니다. 가져온 뒤 HTML, 로그인 안내 또는 구독 사용량 안내가 보인다면 들여쓰기를 고치기 전에 먼저 설정 출처를 확인하세요. 여러 설정을 전환하고 유지하는 방법은 Profile과 여러 설정 관리를 참고하세요.

포트, 수신 주소와 트래픽 진입점

요약: 수신 포트는 진입점만 만들며 모든 앱의 트래픽을 자동으로 프록시로 보내지는 않습니다. 앱이 해당 진입점에 직접 연결하거나 시스템 프록시, 투명 전달 등의 기능이 트래픽을 커널로 보내야 합니다. 가장 흔히 사용하는 mixed-port는 같은 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받아 데스크톱 앱에 통일된 주소를 입력하기 좋습니다. port와 socks-port는 각각 HTTP와 SOCKS 진입점을 따로 만듭니다. 진입점을 분리해야 하는 경우에만 각각 활성화해 불필요한 수신 항목이 늘어나지 않게 하세요.

포트 선택과 사용 중인 포트 확인

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

이 예제는 로컬 기기에서만 접속할 수 있으며 단일 기기에서 시작하기에 적합합니다. 포트 번호는 성능 설정도, 노드 서버 포트도 아닙니다. 로컬 수신 포트를 바꾸면 브라우저, 터미널과 직접 프록시를 설정한 다른 앱에서도 주소를 함께 변경해야 합니다. 여러 수신 필드에 같은 포트를 할당하거나 두 프록시 클라이언트가 같은 주소와 포트를 사용하게 하지 마세요. 커널에서 주소가 이미 사용 중이라는 메시지가 표시되면 이전 프로세스를 종료하거나 수신 설정을 바꾼 뒤 다시 불러오세요. 노드를 계속 바꿔도 로컬 바인딩 실패는 해결되지 않습니다.

필드	역할	확인할 사항
`mixed-port`	HTTP와 SOCKS 공용 진입점	앱의 프로토콜과 주소 설정이 올바른지
`port`	독립 HTTP 프록시 진입점	원격 노드 포트와 혼동하지 않기
`socks-port`	독립 SOCKS 프록시 진입점	앱이 SOCKS를 지원하는지
`allow-lan`	LAN 기기의 접속 허용 여부	수신 주소와 방화벽 설정
`bind-address`	프록시 진입점의 바인딩 주소	루프백 주소인지 LAN 인터페이스인지

Windows에서는 Get-NetTCPConnection -LocalPort 7890으로 해당 TCP 수신을 확인할 수 있습니다. Linux에서는 ss -lntp, macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을 사용하세요. 일부 프로세스 정보는 더 높은 권한이 있어야 표시됩니다. 결과를 볼 때는 주소, 포트, 프로세스를 함께 확인하세요. 숫자만 같다고 프록시가 실행 중이라고 판단하면 안 됩니다. 루프백 주소에서만 수신하는 서비스는 다른 기기에서 직접 접속할 수 없습니다.

로컬 프록시와 LAN 공유

같은 LAN에 있는 다른 기기에서도 사용하려면 접근 범위를 이해한 뒤 allow-lan을 활성화하고 바인딩 주소가 해당 인터페이스를 포함하도록 설정하세요. 연결할 기기에는 클라이언트가 실행 중인 컴퓨터의 LAN 주소를 입력해야 합니다. 해당 기기 자체의 127.0.0.1을 입력하는 것이 아닙니다. 로컬 방화벽, 무선 액세스 포인트의 기기 간 통신 차단, 서로 다른 서브넷의 라우팅이 접속 가능 여부에 영향을 줍니다. 먼저 로컬 진입점으로 접속되는지 확인한 다음 LAN 기기에서 테스트하면 커널 오류와 네트워크 격리 문제를 구분할 수 있습니다.

프록시 인증과 노드 인증은 서로 다른 기능입니다. 전자는 로컬 진입점을 사용할 수 있는 사람을 제한하고, 후자는 원격 서비스 연결에 사용됩니다. 진입점 인증을 활성화하면 접속 앱도 해당 기능을 지원하고 사용자 이름과 비밀번호를 입력해야 합니다. 일부 시스템 프록시 설정 화면에서는 이 정보를 모두 입력할 수 없으므로 앱 자체의 프록시 설정을 사용해야 할 수 있습니다. 공유가 안 된다고 문제 해결을 위해 방화벽 규칙을 모두 끈 채로 두지 마세요. 필요한 인터페이스, 출발지 주소와 포트만 지정해 확인하세요.

시스템 프록시, 터미널과 TUN의 차이

시스템 프록시는 보통 시스템 설정을 따르는 앱에 진입점 주소를 알려주는 기능이며, 모든 프로그램이 이 설정을 읽는 것은 아닙니다. 명령줄 도구는 환경 변수나 자체 매개변수에 의존하는 경우가 많습니다. 아래 명령으로 HTTP 프록시를 명시하면 환경 변수 문제를 커널 문제로 오해하지 않을 수 있습니다. 테스트에 성공해도 해당 요청이 지정한 진입점을 통과했다는 뜻일 뿐, 다른 앱도 연결되었거나 모든 도메인의 분기가 올바르다는 뜻은 아닙니다.

curl --proxy http://127.0.0.1:7890 https://example.com/

TUN은 가상 네트워크 인터페이스 진입점으로, 시스템 권한, 라우팅, DNS 처리와 기존 네트워크 소프트웨어에 영향을 받습니다. 일반 수신 포트를 연다고 반드시 필요한 기능은 아닙니다. 프록시를 지원하지 않는 앱을 사용하거나 더 광범위한 트래픽 처리가 필요할 때만 클라이언트 문서를 확인해 활성화하세요. 시스템 프록시는 작동하지만 터미널에서 실패한다면 브라우저와 명령줄을 따로 점검하는 방법을 읽어보세요. 클라이언트를 고를 때는 먼저 다운로드 페이지에서 Clash Plus를 확인하고, 플랫폼과 필요한 기능에 따라 다른 클라이언트와 비교하세요.

프록시 모드, 로그와 제어 인터페이스

요약: mode는 전달 정책을 선택하는 방식을 정하며 노드를 만들거나 앱의 트래픽을 가져오지는 않습니다. 규칙 모드는 규칙 목록을 사용하고, 전역 모드는 전역 정책의 선택 항목을 사용하며, 직접 연결 모드는 대상에 직접 연결합니다. 모드를 바꾸기 전에 트래픽이 커널에 들어오는지, 사용할 수 있는 정책이 실제로 있는지 확인하세요. 전역 모드로 바꿔도 수신 실패, 빈 구독, 원격 서버 접속 불가 문제는 해결되지 않습니다. 규칙 선택 경로와 관련된 문제인지 판단하는 데 도움이 될 뿐입니다.

rule, global, direct

mode: rule
log-level: info
ipv6: false

rule은 도메인, 주소와 앱 요구에 따라 장기간 트래픽을 분기할 때 적합합니다. global은 일반 규칙 선택을 건너뛰고 전역 정책의 현재 선택 항목을 사용하므로 클라이언트의 전역 그룹에서 무엇을 선택했는지도 확인해야 합니다. 직결을 선택했다면 전역 모드에서도 프록시로 연결되지 않습니다. direct는 프록시 출구를 사용하지 않는 연결을 확인할 때 씁니다. 어떤 모드도 시스템 진입점 설정을 대신하지 않습니다. 커널에 들어오지 않은 앱은 모드를 바꿔도 경로가 달라지지 않습니다.

테스트할 때는 한 번에 변수 하나만 바꾸세요. 예를 들어 특정 사이트에 연결되지 않는다면 노드와 DNS를 그대로 두고 규칙 모드에서 전역 모드로만 바꾼 뒤 다시 연결합니다. 전역 모드에서는 되지만 규칙 모드에서 실패한다면 규칙 매칭과 대상 그룹을 확인하세요. 두 모드 모두 실패하면 노드와 DNS를 점검합니다. 노드와 모드, DNS를 한꺼번에 바꾸고 문제가 해결되더라도 어느 변경이 효과가 있었는지 알기 어렵습니다. 기존 연결은 이전 출구를 계속 사용할 수 있으므로 테스트할 때는 기존 연결을 종료한 뒤 확인하세요.

값	정책 출처	주요 용도
`rule`	`rules`에서 처음으로 일치하는 항목	필요에 따라 트래픽 분기 규칙 관리
`global`	전역 정책의 현재 선택 항목	규칙 경로의 영향을 분리해 확인
`direct`	직접 연결	로컬 네트워크와 비교

문제 확인에 log-level 활용하기

info는 주요 실행 정보를 일상적으로 기록하기에 적합합니다. 특정 요청을 추적해야 한다면 잠시 debug로 바꾸세요. warning과 error는 출력이 점점 줄어들고, silent는 문제를 확인할 근거가 부족해집니다. 로그 수준을 바꿔도 노드 속도가 빨라지지는 않으며 상세 로그는 출력 부담을 늘릴 수 있습니다. 재현 가능한 작업을 잠시 확인한 뒤에는 일상적인 수준으로 되돌려 불필요한 데이터가 계속 쌓이지 않도록 하세요.

로그는 단계별로 나눠서 읽으세요. 설정을 파싱하는 중 발생한 오류는 파일 내용을, 수신 단계의 실패는 로컬 주소와 권한을, 요청 진입 후의 DNS 오류는 DNS 경로를 가리킵니다. 연결 시도나 핸드셰이크가 실패했다면 대상 출구와 프로토콜 매개변수를 확인해야 합니다. 같은 시간 초과라도 DNS 조회, TCP 연결, TLS 핸드셰이크 중 어디서 발생했는지에 따라 점검 대상이 다릅니다. 영어 오류 메시지 한 줄만 보고 모든 필드를 한꺼번에 바꾸지 마세요.

재현에 필요한 기록에는 현재 Profile, 모드, 매칭된 규칙, 선택된 정책과 오류가 발생한 시간대가 포함되어야 합니다. 로그를 공유하기 전에는 구독 주소, 인증 정보, 개인 도메인과 LAN 구성 등 민감한 내용을 지우세요. 더 자세한 로그 읽기 순서는 실행 로그와 자주 발생하는 오류 비교를 참고하세요. 로그에 대상 요청 자체가 없다면 실행되지도 않은 규칙을 살펴보는 대신 진입점부터 다시 확인하세요.

제어 인터페이스는 프록시 진입점이 아닙니다

external-controller는 클라이언트나 대시보드에서 커널을 관리하기 위한 인터페이스입니다. 상태 조회, 정책 전환, 일부 실행 설정 변경에 사용할 수 있지만 브라우저의 HTTP 프록시 주소로 입력하는 기능은 아닙니다. 데스크톱 클라이언트는 보통 이 인터페이스와 인증 정보를 직접 관리하므로 구독에서 임의로 덮어쓰지 않는 것이 좋습니다. 커널을 직접 실행한다면 루프백 주소에 바인딩하세요. 원격 관리가 꼭 필요할 때는 인증과 네트워크 접근 제한을 함께 설정하고 관리 포트를 일반 LAN 공유 포트처럼 취급하지 마세요.

최상위 ipv6는 커널의 IPv6 사용 동작에 영향을 주고, DNS 아래의 같은 이름 필드는 DNS 설정에 해당합니다. 한쪽만 바꾼 뒤 전체 네트워크 스택의 동작을 단정할 수는 없습니다. IPv6 사용 여부는 로컬 네트워크, 프록시 서비스와 앱 요구를 함께 고려해 결정하세요. IPv6를 끄는 것을 고정된 최적화 방법으로 삼으면 안 됩니다. 특정 주소 종류에서만 연결이 실패한다면 주소 해석 결과와 실제 연결 경로를 각각 살펴본 뒤 해당 계층의 필드를 조정하세요.

DNS, Fake-IP와 이름 해석 경로

요약: DNS 설정은 앱의 조회, 커널의 이름 해석, 노드 도메인 해석을 모두 포함하므로 서버 주소 하나만 봐서는 충분하지 않습니다. 앱은 시스템 DNS를 사용하거나 자체적으로 암호화된 조회를 보낼 수 있습니다. 커널도 대상이나 노드에 연결하기 위해 이름을 해석할 수 있습니다. 따라서 nameserver를 바꿔도 모든 조회가 해당 목록을 거치는 것은 아닙니다. 요청이 어디서 발생하고 누가 받으며 결과를 누가 사용하는지 먼저 파악한 뒤 수신 설정, DNS 처리 또는 상위 서버 선택을 바꿀지 결정하세요.

활성화와 수신 설정의 기본 관계

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:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

이 설정 조각은 로컬 DNS 수신을 만들지만 시스템 DNS를 자동으로 변경하지 않습니다. 일반적인 시스템 DNS 설정에서는 비표준 포트를 지정할 수 없는 경우가 많으므로 시스템 주소를 루프백으로 바꾼다고 조회가 자동으로 1053 포트로 전달되지는 않습니다. 클라이언트의 DNS 처리 기능, TUN 연동 기능 또는 별도의 명시적 전달 방식이 필요합니다. 기기에 이미 DNS 서비스가 있다면 수신 주소와 포트가 충돌하는지 먼저 확인하세요. 그래야 로드 실패를 상위 DNS 서버 접속 불가로 오해하지 않습니다.

default-nameserver는 DNS 서버 자체의 도메인을 해석할 때 사용할 수 있습니다. 도메인을 먼저 해석해야 하는 상황을 해결하는 데 도움이 되며, 보통 직접 연결 가능한 IP 주소를 지정합니다. nameserver는 기본 상위 DNS 서버 목록입니다. 접속 가능 여부는 네트워크 연결과 해당 출구 설정에 달려 있습니다. 암호화 DNS를 사용하면 조회 전송 방식은 바뀌지만 조회가 반드시 프록시를 거친다는 뜻은 아니며 현재 네트워크에서 원격 서버에 연결된다는 보장도 없습니다. 상위 서버를 많이 추가한다고 결과가 더 정확해지는 것은 아니므로 먼저 확인하기 쉬운 구성으로 시작하세요.

fake-ip와 redir-host의 차이

fake-ip는 조회에 합성 주소를 할당하고 도메인과 주소의 대응 관계를 관리합니다. 합성 주소로 연결할 때 도메인을 복원해 처리합니다. 도메인 정보를 유지하는 데 도움이 되지만 DNS 조회와 이후 트래픽이 같은 처리 경로를 거쳐야 합니다. 앱이 합성 주소를 받은 뒤 커널을 거치지 않고 직접 연결하면 연결되지 않는 경우가 많습니다. redir-host는 실제 해석 결과를 반환하며 호환 경로도 다릅니다. 두 모드를 단순한 속도 설정으로 이해하면 안 됩니다.

fake-ip-filter는 지정한 도메인이 합성 주소 처리 과정을 거치지 않게 합니다. LAN 서비스 검색이나 실제 주소에 연결해야 하는 앱을 처리할 때 유용합니다. 예제의 LAN 도메인 접미사는 시작점일 뿐 모든 환경에 적용되는 완전한 목록이 아닙니다. 도메인을 필터링해도 직결 규칙이 자동으로 추가되거나 올바른 LAN DNS가 지정되지는 않습니다. 프린터, 내부 도메인 또는 로컬 서비스에 문제가 생기면 필터 범위를 넓히고 끝내지 말고 도메인 해석 출처, 반환 주소와 연결 경로를 함께 확인하세요.

도메인별 상위 DNS 지정과 조회 루프 방지

nameserver-policy를 사용하면 특정 도메인의 상위 DNS 서버를 지정할 수 있습니다. 예를 들어 내부 도메인은 LAN DNS 서버에 전달할 수 있습니다. 정책 키의 매칭 문법은 커널이 지원하는 범위에 맞춰야 합니다. 모든 규칙 표현식을 그대로 복사해 넣을 수 있는 두 번째 rules 필드가 아닙니다. proxy-server-nameserver는 프록시 노드 도메인을 해석할 때 사용하며, 출구 연결에 필요한 기본 DNS 조회를 따로 관리하는 데 적합합니다. 노드 서버 자체의 이름을 해석할 수 없다면 대상 웹사이트의 DNS가 정상이어도 프록시 연결은 성립하지 않습니다.

respect-rules처럼 트래픽 분기 규칙에 따라 DNS 출구를 선택하는 옵션을 활성화하기 전에 노드 도메인의 독립적인 해석 경로를 설계하세요. DNS 요청이 프록시를 통해야 하는데 프록시를 연결하는 데 바로 그 DNS 요청이 필요한 경우 루프가 발생할 수 있습니다. 규칙 기반 DNS 전송, 여러 상위 서버, 복잡한 필터와 다단계 대체 설정을 한꺼번에 추가하지 마세요. 먼저 기본 상위 DNS 서버에 접속할 수 있는지 확인하고 조건을 하나씩 추가하면서 로그에서 해석과 연결 단계가 이어지는지 확인하세요.

fallback과 관련 필터 설정은 언제나 작동하는 예비 버튼이 아닙니다. 결과 선택은 필터 조건의 영향을 받으므로 다른 네트워크의 주소 범위와 지역 설정을 그대로 복사하면 예상과 다른 결과가 나올 수 있습니다. 문제를 확인할 때는 조회 도메인, 응답 주소, 사용한 상위 서버와 연결에 적용된 정책을 기록하세요. 일부 앱에서만 실패한다면 앱 내장 DNS가 시스템 설정을 우회하는지도 확인해야 합니다. 증상별 간단한 답변은 모든 DNS 옵션을 한꺼번에 켜기보다 FAQ에서 확인하세요.

프록시 노드 필드와 노드 제공기

요약: 노드 필드는 서버에서 제공한 프로토콜 매개변수와 하나씩 일치해야 합니다. 이름이 비슷하다고 서로 바꿔 쓸 수 있는 것은 아닙니다. proxies는 노드 객체 목록입니다. 일반적인 공통 필드에는 이름, 유형, 서버 주소와 포트가 있으며 인증, 암호화, 전송 방식과 TLS 필드는 프로토콜마다 다릅니다. 구독 가져오기에 성공했다는 것은 클라이언트가 설정 구조를 받아들였다는 뜻일 뿐 서버 주소에 접속할 수 있거나 인증 및 핸드셰이크 매개변수가 올바르다는 뜻은 아닙니다.

공통 필드와 프로토콜 전용 필드

# 구조 예시: example.com과 인증 값은 필드를 설명하기 위한 예시입니다
proxies:
  - name: 예시 출구
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-username"
    password: "your-password"
    udp: true

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 예시 출구
      - DIRECT

이 예제는 SOCKS5 노드를 프록시 그룹에서 참조하는 방식을 보여줄 뿐 실제 프록시 서비스를 제공하지 않습니다. name은 로컬 식별자입니다. 이름을 바꿔도 서버는 바뀌지 않지만 다른 위치의 참조에는 영향을 줍니다. server는 원격 주소이고 port는 서버의 수신 포트입니다. 로컬 mixed-port로 대체할 수 없습니다. 사용자 이름과 비밀번호는 실제 서비스에서 제공한 값을 사용하세요. 서버가 해당 인증 방식을 사용하지 않는다면 필드를 채우기 위해 임의로 추가하지 마세요.

type에 따라 이후 필드를 해석하는 방식이 달라집니다. Shadowsocks의 암호화 방식과 비밀번호, VMess 또는 VLESS의 사용자 ID, Trojan의 인증과 TLS, 다른 프로토콜의 전송 매개변수는 각각 요구 사항이 다릅니다. 한 노드에 여러 프로토콜의 필드를 섞어 호환성을 시도하면 안 됩니다. 알 수 없는 필드 오류가 표시되면 현재 커널이 해당 프로토콜과 필드를 지원하는지 먼저 확인하고 구독 형식도 살펴보세요. 오류 필드를 전부 지우는 방식으로 해결하면 안 됩니다. 필요한 전송 매개변수를 삭제하면 설정은 불러와도 연결되지 않을 수 있습니다.

TLS, 전송 계층과 UDP

TLS를 사용하는 노드에는 서버 이름, 애플리케이션 계층 프로토콜 협상, 인증서 관련 옵션이 포함될 수 있습니다. 서버 이름은 보통 핸드셰이크와 인증서 검증에 사용되며 연결 주소와 반드시 같지는 않습니다. 주소, TLS 이름, WebSocket 요청 헤더의 호스트 필드는 각각 다른 역할을 할 수 있으므로 서버가 제공한 조합대로 설정하세요. 접속 가능한 웹사이트 도메인을 이 항목에 임의로 넣지 마세요. 주소가 정상처럼 보여도 해당 서버가 핸드셰이크를 받아준다는 뜻은 아닙니다.

인증서 검증에 실패하면 시스템 시간, 서버 이름, 인증서 유효기간과 서버 설정을 확인하세요. 검증을 건너뛰면 원격 서버의 신원을 확인하는 기능이 약해지므로 일반적인 해결책으로 장기간 사용하면 안 됩니다. WebSocket, gRPC 등 전송 방식에는 일치하는 경로, 서비스 이름 또는 요청 헤더도 필요합니다. 어느 한 계층이라도 일치하지 않으면 연결이 종료될 수 있습니다. 문제를 확인할 때는 서버에서 받은 원본 매개변수를 비교용으로 보관하세요. 클라이언트 화면에 보이는 노드 이름만 비교해서는 안 됩니다.

udp: true는 해당 노드에서 UDP 기능을 사용할 수 있게 한다는 뜻이며 UDP를 지원하지 않는 서버에 기능을 추가하지는 않습니다. 앱 진입점, 프록시 그룹, 노드 프로토콜과 원격 서비스까지 전체 경로가 필요한 트래픽을 지원하는지도 확인하세요. 웹페이지는 열리지만 게임이나 음성 통화가 실패한다면 TCP와 UDP를 먼저 구분해야 합니다. 한 번의 HTTP 테스트만으로 모든 앱이 정상이라고 판단할 수 없습니다. 반대로 UDP를 사용할 수 없어도 일반 HTTPS 요청까지 반드시 실패하는 것은 아닙니다.

proxy-providers와 전체 구독의 차이

# 제공기 조각: 로컬 파일이 미리 있어야 하며 proxies 목록을 포함해야 합니다
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - local-nodes
    proxies:
      - DIRECT

proxy-providers를 사용하면 노드 출처를 별도로 관리하고 프록시 그룹에서 use로 제공기를 참조할 수 있습니다. 제공기 이름을 일반 노드 목록에 넣는 방식이 아닙니다. 파일 기반 출처는 실제 파일이 있어야 하고 내용이 제공기 형식에 맞아야 합니다. 네트워크 기반 출처에는 올바른 주소, 저장 위치와 업데이트 설정이 필요합니다. 전체 Profile에는 보통 DNS, 규칙과 그룹도 포함됩니다. 전체 구독 원본을 노드만 담긴 제공기 파일로 사용할 수 있다고 단정하지 말고 출처가 지원하는 출력 형식을 확인하세요.

제공기를 가져오는 데 성공하는 것과 제공기에 포함된 노드에 연결할 수 있는 것은 별도로 확인해야 합니다. 전자는 다운로드 경로와 콘텐츠 형식에 달렸고, 후자는 프로토콜과 출구에 달려 있습니다. 서버가 로그인 페이지, 오류 문구 또는 빈 목록을 반환하면 구독 인증, 유효기간과 응답 내용을 먼저 확인하세요. 구독 링크에는 접근 정보가 포함될 수 있으므로 공개 로그나 온라인 변환 도구에 붙여넣지 마세요. 모든 노드 연결에 실패한다면 구독부터 출구까지 단계별로 점검하는 순서에 따라 오류가 발생한 구간을 확인하세요.

클라이언트에서 특정 유형의 노드를 편집할 수 있는지와 커널이 해당 필드를 지원하는지는 별개의 문제입니다. Clash Plus, Clash Verge Rev, FlClash 등의 클라이언트를 고를 때는 현재 사용 중인 커널과 가져오기 기능도 확인하세요. UI에 필드가 표시되지 않아도 적용될 수 있고, UI에서 입력할 수 있어도 서버가 받아들인다는 뜻은 아닙니다. 노드를 관리할 때는 신뢰할 수 있는 출처의 원본 매개변수를 유지하고 프록시 정책과 규칙은 주변 설정에서 조정하세요. 인증 정보를 직접 수정하는 일은 최소화하는 것이 좋습니다.

프록시 그룹, 자동 선택과 참조 관계

요약: 프록시 그룹은 출구 선택기입니다. 규칙이 그룹을 가리켜도 최종 노드는 그룹에서 현재 선택된 정책에 따라 결정됩니다. proxy-groups는 여러 노드, 다른 그룹 또는 제공기를 하나로 구성합니다. 설계할 때는 수동 출구 선택, 자동 선택, 장애 조치 등 사용자에게 필요한 결정을 먼저 정한 다음 그룹 유형을 선택하세요. 모든 유형을 설정에 쌓아 둔다고 안정성이 자동으로 높아지지는 않습니다. 오히려 실제 출구를 파악하기 어려워질 수 있습니다.

select와 중첩 프록시 그룹

# 직접 연결 그룹은 불러올 수 있는 구조를 보여주기 위한 예시입니다. 실제 노드는 필요에 따라 추가하세요
proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

  - name: PROXY
    type: select
    proxies:
      - 수동 선택
      - DIRECT

rules:
  - MATCH,PROXY

select는 사용자가 직접 또는 제어 인터페이스를 통해 현재 항목을 정하므로 출구를 고정해야 하는 앱에 적합합니다. 이 예제에서는 규칙이 먼저 PROXY를 가리키고, 이후 '수동 선택' 그룹을 거쳐 DIRECT로 연결될 수 있습니다. 실제 접속 경로를 확인할 때는 이 참조 관계를 따라가세요. 그룹 이름은 식별자일 뿐 동작을 보장하지 않습니다. 이름이 '자동'인 그룹도 유형이 select라면 노드를 자동으로 테스트하고 선택하지 않습니다.

그룹이 서로를 참조하는 순환 구조는 피하세요. 예를 들어 A 그룹이 B 그룹을 참조하고 B 그룹이 다시 A 그룹을 참조하는 경우입니다. 이름은 용도와 출처가 드러나게 구분하세요. 용도별 그룹은 업무, 미디어, 기본 출구 등으로 만들고 출처별 그룹은 제공기에 따라 구성할 수 있습니다. 그러면 구독 노드가 갱신되어도 모든 규칙을 함께 수정할 필요가 없습니다. 그룹 계층을 지나치게 깊게 만들지 마세요. 몇 단계만 따라가도 최종 출구를 설명할 수 있어야 합니다. 그렇지 않으면 UI에 선택된 이름이 표시되어도 실제 경로를 알기 위해 계층을 하나씩 펼쳐야 합니다.

url-test, fallback과 load-balance

url-test는 테스트 결과를 바탕으로 후보 출구를 선택하므로 자동 전환을 허용할 수 있는 연결에 적합합니다. fallback은 후보 순서와 사용 가능 여부를 중시하므로 특정 출구를 우선 사용하다 실패하면 다음 출구로 전환하고 싶을 때 알맞습니다. load-balance는 정책에 따라 연결을 여러 후보에 배분하는 방식이지 다운로드 연결 하나의 대역폭을 합산하는 기능은 아닙니다. 로그인, 결제 또는 세션처럼 출구 IP가 안정적이어야 하는 작업에서는 출구가 바뀔 수 있는 그룹을 신중하게 사용하세요.

# 조각 예시: local-nodes 제공기가 proxy-providers에 정의되어 있어야 합니다
proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - local-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

예제의 interval은 테스트 간격이고 tolerance는 작은 차이 때문에 자주 전환되는 것을 줄이는 설정입니다. 실제 노드 속도 측정값은 아닙니다. 테스트 주소는 현재 네트워크와 출구에서 안정적으로 접속할 수 있고 연결 테스트에 적합한 응답을 제공해야 합니다. 테스트 주소에 접속하지 못해도 해당 노드가 모든 대상에 사용할 수 없다는 뜻은 아닐 수 있습니다. 실제 앱 요청과 교차 확인하고 테스트 결과 한 열만으로 모든 서비스의 정책을 결정하지 마세요.

유형	주요 선택 방식	주의할 점
`select`	수동 선택	현재 선택 항목이 저장되는지 확인
`url-test`	테스트 결과에 따라 선택	테스트 결과는 실제 처리량이 아닙니다
`fallback`	순서대로 사용 가능한 항목 선택	우선순위를 신중하게 설정해야 합니다
`load-balance`	정책에 따라 연결 분배	세션 전체에서 출구가 고정된다는 보장이 없습니다

후보 목록, 필터와 테스트 범위

proxies에는 노드나 프록시 그룹 이름을 직접 지정하고, use로 노드 제공기를 참조합니다. 두 출처를 함께 사용할 수 있지만 중복되거나 후보 목록이 비지 않도록 주의하세요. filter 같은 이름 필터를 사용할 때는 정규식이 제공기 이름이 아니라 실제 노드 이름과 일치하는지 확인해야 합니다. 구독 제공자가 이름을 바꾸면 이전에 동작하던 필터가 갑자기 빈 목록을 만들 수 있습니다. 자동 그룹에 노드가 표시되지 않으면 먼저 제공기 내용을 확인하고 필터 결과를 살펴본 뒤 테스트 설정을 점검하세요.

상태 확인은 지정한 테스트 대상에 조건에 맞게 요청을 보낼 수 있는지를 알려줄 뿐 모든 프로토콜과 목적지에서의 노드 성능을 평가하지 않습니다. 테스트를 자주 병렬로 실행하면 연결이 추가로 발생하므로 모바일 네트워크, 저전력 기기나 데이터 제한이 있는 서비스에서는 특히 주의하세요. 제공기와 프록시 그룹 양쪽에서 상태 확인을 설정하면 테스트가 중복될 수 있습니다. 사용 가능 여부를 판단하기에 충분한 빈도만 유지하고 UI 데이터를 계속 갱신하려고 간격을 지나치게 줄이지 마세요.

규칙이 가리키는 용도별 그룹은 가능한 한 안정적으로 유지하고 노드 교체는 그룹 내부에서 처리하세요. 같은 사이트가 간헐적으로 다른 출구를 사용한다면 자동 그룹의 전환 여부, 앱이 여러 연결을 만들었는지, 도메인에 따라 규칙 경로가 달라지는지 먼저 확인한 뒤 서버 문제를 살펴보세요. 출구를 계속 고정해야 하는 작업에는 별도의 수동 그룹을 만들어 일상적인 자동 선택과 분리하는 것이 좋습니다. 플랫폼별 클라이언트 그룹 선택 화면은 클라이언트 선택 가이드에서 플랫폼 요구 사항과 함께 비교할 수 있습니다.

규칙 문법, 매칭 순서와 규칙 세트

요약: 규칙은 목록 위에서 아래로 처리되며 처음 일치하는 규칙이 이번 트래픽 분기를 결정합니다. 문구가 길다고 우선순위가 자동으로 높아지는 것은 아닙니다. rules를 관리할 때는 구체적인 예외를 일반 규칙보다 앞에 두고 마지막에 기본 규칙을 배치하세요. 규칙을 추가하기 전에 도메인, 대상 주소, 출발지 주소, 프로세스 중 어떤 정보를 기준으로 매칭할지 정해야 합니다. 규칙에서 사용할 수 있는 정보는 진입점과 시스템 환경에 따라 다르므로 모든 연결에 도메인과 프로세스 이름이 있다고 가정하면 안 됩니다.

도메인 규칙과 대상 정책

# 조각 예시: PROXY 프록시 그룹이 미리 정의되어 있어야 합니다
rules:
  - DOMAIN,login.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-KEYWORD,internal,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

DOMAIN은 도메인 전체와 일치하고 DOMAIN-SUFFIX는 도메인 접미사와 해당 하위 도메인에 일치합니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 판단합니다. 키워드 규칙은 범위가 넓어 관련 없는 도메인까지 포함할 수 있으므로 정확한 매칭이 필요하면 전체 도메인이나 접미사를 우선 사용하세요. 입력할 때 https://, 경로 또는 포트를 붙이지 마세요. 이 값들은 URL의 다른 부분이며 도메인 규칙이 매칭할 대상이 아닙니다.

규칙의 마지막 항목은 대상 정책으로, 내장 동작이나 이미 정의된 노드 또는 그룹을 지정할 수 있습니다. 안정적으로 관리하려면 구독 업데이트에 따라 이름이 바뀔 수 있는 노드 대신 용도별 그룹을 규칙에서 가리키는 것이 일반적입니다. DIRECT는 직접 연결을 뜻하고 REJECT는 요청을 거부합니다. 정책 이름은 정의한 이름과 정확히 일치해야 합니다. 그룹 이름을 잘못 적은 것은 규칙이 '매칭되지 않은' 문제가 아니라 설정 참조 오류이므로 로드 검증 단계에서 처리해야 합니다.

주소 매칭과 no-resolve

IP-CIDR은 IPv4 네트워크에 매칭하고 IPv6 네트워크에는 해당하는 IP-CIDR6을 사용합니다. 요청이 도메인으로 들어왔는데 규칙 판단에 실제 주소가 필요하면 커널이 이름을 해석할 수 있습니다. 끝에 붙이는 no-resolve는 해당 주소 규칙을 위해 도메인을 직접 해석하지 않도록 합니다. 이미 대상 주소가 있는 연결의 매칭을 막거나 DNS를 전역으로 끄는 옵션은 아닙니다. 모든 주소 규칙에 무조건 추가하면 기존 트래픽 분기 결과가 달라질 수 있습니다.

GEOIP는 주소 데이터베이스를 기준으로 분류하므로 결과는 데이터베이스 내용과 업데이트 여부에 달려 있습니다. 도메인 분류에 흔히 사용하는 GEOSITE에는 관련 리소스와 커널 지원이 필요합니다. 예제의 지역별 직결 설정은 문법을 보여주기 위한 것이며 모든 네트워크에 적용되는 기본 정책은 아닙니다. 데이터베이스 분류는 서비스의 실제 위치와 같지 않으며 대상에 접속할 수 있다는 보장도 하지 않습니다. 기업 네트워크, 여러 지역에 걸친 서비스와 자체 운영 주소는 단일 분류에 의존하지 말고 실제 요구에 맞춰 예외를 설정하세요.

rule-providers와 RULE-SET

# 파일이 미리 있어야 하며 내용 형식이 behavior에 맞아야 합니다
rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,PROXY

규칙 제공기를 사용하면 업데이트되는 매칭 항목을 별도 파일로 관리하고 주 설정에서 RULE-SET으로 참조할 수 있습니다. behavior는 파일 내용이 도메인, 주소 대역, 기존 규칙 표현식 중 무엇인지 지정합니다. 파일 확장자만 보고 판단하면 안 됩니다. YAML 형식의 도메인 제공기는 보통 payload 아래에 도메인 매칭 항목을 나열합니다. 기존 규칙 형식의 규칙 세트에는 해당 규칙 표현식을 사용하며, 각 줄에 주 설정의 대상 정책을 반복해서 적지 않습니다.

규칙 세트 파일을 정상적으로 다운로드한 뒤에도 형식과 동작 설정이 일치하는지 확인해야 합니다. 일반 텍스트 도메인 목록을 YAML로 해석하거나 전체 규칙 목록을 도메인 형식으로 처리하면 오류나 예상치 못한 결과가 발생합니다. 네트워크 규칙 출처에는 업데이트 요청의 연결 가능 여부와 캐시 파일 쓰기 권한도 영향을 줍니다. 업데이트가 실패하면 사용할 수 있는 캐시는 보존하면서 다운로드 문제를 확인하세요. 다른 부분도 정상인 주 설정 전체를 바로 초기화할 필요는 없습니다.

연결 기록으로 규칙 추적하기

새 규칙을 검증할 때는 새 연결을 만들고 요청 도메인, 매칭된 규칙과 최종 정책을 기록하세요. 브라우저 페이지는 기본 도메인 외에도 로그인, 정적 리소스와 API 도메인에 동시에 요청할 수 있습니다. 페이지 일부만 표시된다면 각 연결을 따로 확인해야 하며 주소창의 도메인에 규칙 하나를 추가하는 것만으로 해결되지 않을 수 있습니다. 연결 기록에 IP 주소만 남았다면 앱이 직접 이름을 해석하는지, DNS 요청이 커널에 들어오는지, 현재 진입점이 도메인 정보를 유지하는지 살펴보세요.

프로세스 규칙은 플랫폼, 권한과 진입점의 영향을 받습니다. 같은 설정을 다른 기기에서 사용해도 동일한 프로세스 메타데이터를 얻지 못할 수 있으므로 여러 플랫폼에서 유일한 판단 기준으로 삼지 마세요. 규칙을 하나씩 점검할 때는 가장 먼저 매칭될 수 있는 규칙을 찾고, 그룹의 선택 항목을 확인한 뒤 출구를 검증하세요. 규칙 모드에서는 실패하지만 전역 모드에서는 정상이라면 광범위한 키워드 규칙을 한꺼번에 추가하기보다 이 경로를 점검하는 편이 낫습니다. 임시 예외가 효과가 있었다면 범위를 좁히고 용도를 기록하세요.

구독 덮어쓰기, 설정 병합과 로드 검증

요약: 유지 가능한 사용자 설정은 원격 업데이트로 대체될 구독 원본과 분리하고 최종 실행 설정을 기준으로 검증해야 합니다. 클라이언트에는 보통 덮어쓰기, 병합, 확장 설정이나 스크립트 기능이 있지만 이는 클라이언트가 설정을 생성하는 방식일 뿐 모든 클라이언트에서 통용되는 YAML 표준은 아닙니다. 다른 클라이언트로 옮길 때는 적용 순서와 병합 동작을 다시 확인하세요. 이름이 '덮어쓰기'인 파일 하나를 복사한다고 결과까지 같아지는 것은 아닙니다.

스칼라, 매핑과 목록의 병합 차이

mode, mixed-port 같은 스칼라 필드는 나중에 설정된 값이 앞선 값을 덮어쓰는 경우가 많습니다. dns 같은 매핑은 키별로 병합되거나 통째로 교체될 수 있습니다. rules, proxies 같은 목록은 교체, 앞에 추가 또는 뒤에 추가될 수 있습니다. 구체적인 동작은 클라이언트 문서와 생성된 결과를 기준으로 확인해야 합니다. 기능 이름이 '병합'이라는 사실만으로 기존 노드나 규칙이 유지되는지는 알 수 없습니다.

# 개념 예시: 규칙 앞에 추가하는 기능을 지원하는 클라이언트의 덮어쓰기 진입점 전용입니다
# 두 번째 최상위 rules로 바로 이어 붙이면 안 됩니다
rules:
  - DOMAIN,work.example.com,DIRECT

클라이언트가 이 내용을 기존 규칙과 통째로 교체하면 구독 규칙이 모두 사라질 수 있습니다. 기존 MATCH 뒤에 추가하면 새 규칙은 아예 매칭될 기회가 없을 수 있습니다. 클라이언트에서 지원하는 규칙 앞에 추가 기능을 선택하거나 스크립트에서 순서를 직접 구성한 다음 최종 목록을 확인하세요. DNS 병합도 마찬가지입니다. 상위 서버 목록을 수정할 때 다른 하위 필드가 유지되는지 확인하세요. 주소 하나를 바꾸려다 수신 설정과 모드까지 지울 수 있습니다.

적용 순서와 이름의 안정성 확인

간단한 출처 기록을 작성하세요. 구독에서 제공하는 노드와 규칙, 클라이언트 전역 설정이 제어하는 포트, 덮어쓰기로 추가하는 DNS와 예외, 스크립트가 프록시 그룹을 다시 수정하는지 등을 기록합니다. 여러 진입점에서 같은 필드를 수정한다면 한 곳으로 통합하는 것이 좋습니다. 실행 모드가 계속 원래대로 돌아오거나 저장한 포트가 바뀌고 규칙이 업데이트 때마다 사라지는 경우에는 편집기가 저장하지 못한 것이 아니라 이후 설정 생성 단계가 앞선 결과를 덮어썼을 수 있습니다.

사용자 규칙이 참조하는 프록시 그룹에는 안정적인 이름을 사용하고 구독 업데이트 후에도 그룹이 만들어지는지 확인하세요. 사용자 그룹이 특정 노드를 직접 참조하는데 서비스 제공자가 정기적으로 이름을 바꾸면 업데이트 후 후보를 찾지 못할 수 있습니다. 고정된 용도별 그룹을 통해 제공기나 클라이언트의 노드 목록을 연결하는 편이 안전합니다. 스크립트를 수정하기 전에는 대상 필드의 유형도 확인하세요. 모든 구독에 같은 목록 구조가 있다고 가정하면 안 됩니다. 객체가 없을 때는 일부 설정만 생성하지 말고 원인을 알 수 있는 오류를 표시해야 합니다.

문법 검사, 로드 검사와 실제 연결

# mihomo 명령줄 프로그램이 설치된 환경에서 사용
mihomo -t -f ./config.yaml

명령줄 테스트는 설정 파싱과 초기화 문제를 찾는 데 도움이 됩니다. 실제 실행 환경과 실행 디렉터리, 리소스 경로와 권한을 최대한 일치시키세요. 참조된 제공기 파일, 지역 데이터베이스나 다른 리소스가 없으면 YAML 문법이 올바르더라도 실패할 수 있습니다. 데스크톱 클라이언트에서는 현재 환경과 다른 커널 프로그램의 결과를 대신 사용하지 말고 해당 클라이언트의 설정 검사 기능을 우선 사용하세요. 검사를 통과해도 설정을 불러올 수 있는 상태일 뿐 원격 노드에 연결된다는 뜻은 아닙니다.

전체 검증은 세 단계로 진행하세요. 먼저 설정이 선택되어 정상적으로 불러와졌는지 확인하고, 다음으로 진입점이 수신 중이며 앱 요청이 들어오는지 확인한 뒤, 마지막으로 DNS, 규칙, 그룹 선택과 원격 핸드셰이크를 살펴봅니다. 각 단계에서 재현 가능한 요청 하나를 기준으로 기록하세요. 설정을 바꿨는데 기존 연결만 이전 경로를 유지한다면 새 연결을 만드세요. 새 요청이 전혀 기록되지 않으면 진입점으로 돌아가고, 올바른 정책이 기록되었는데 핸드셰이크가 실패한다면 노드 매개변수와 서버 상태를 확인하세요.

자주 발생하는 문제의 복구 순서

설정에서 바로 오류가 발생하면 마지막 변경을 되돌린 뒤 들여쓰기, 중복 키, 누락된 참조와 필드 유형을 확인하세요. 설정은 불러왔지만 접속할 수 없다면 직결 연결과 지정한 프록시를 이용한 요청을 먼저 비교하고 실제로 어떤 정책이 적용되는지 살펴보세요. 두 문제를 한꺼번에 다루면 안 됩니다. 자동 업데이트 직후에만 문제가 생겼다면 업데이트 전후의 노드 이름, 제공기 형식과 규칙 대상을 비교하세요. 특정 클라이언트에서만 재현된다면 덮어쓰기 순서, 커널 기능과 시스템 권한도 확인해야 합니다.

문제가 해결되면 어떤 트래픽에 예외가 필요한지, 특정 DNS 경로를 사용하는 이유, 어떤 규칙 앞에 다른 규칙을 배치해야 하는지 등을 주석이나 관리 기록에 남기세요. 실제 인증 값은 기록하지 말고 임시 우회 방법을 장기 기본 설정으로 사용하지 마세요. 처음 사용하는 경우 입문 가이드를 따라 전체 연결 경로를 설정하는 것을 권장합니다. UI 조작 문제는 FAQ에서 확인하고, 클라이언트를 바꿀 때는 클라이언트별 플랫폼 다운로드에서 선택하세요. 새 환경의 검증이 끝날 때까지 기존 설정을 보관하세요.