Clash 설정 파일 가이드: YAML·DNS·정책 그룹·규칙

1. YAML 구조와 설정 로드

설정 파일과 실행 상태 구분하기

Clash 설정 파일에는 수신 대기 포트, DNS 해석 방식, 사용 가능한 프록시와 트래픽 선택 규칙이 담깁니다. 노드 목록과 같은 의미가 아닙니다. 노드만 있고 정책 그룹과 규칙이 없다면 원하는 방식으로 트래픽을 분리하기 어려울 수 있습니다. GUI 클라이언트는 설정을 가져오고 저장한 뒤 실행하며, 커널은 생성된 설정을 읽어 연결을 처리합니다. 편집기에서 보는 구독 원본, 클라이언트가 저장한 로컬 설정, 커널이 실제로 읽는 파일은 서로 다른 단계의 내용일 수 있습니다.

수정하기 전에 클라이언트의 설정 화면에서 현재 활성화된 항목을 확인한 다음, 편집, 실행 설정 보기 또는 설정 폴더 열기와 같은 메뉴를 찾으세요. 클라이언트마다 메뉴 이름은 다를 수 있지만, 수정이 적용될 파일을 확인한다는 점은 같습니다. 파일 이름만으로 판단하지 마세요. config.yaml이라는 파일도 캐시나 시작 템플릿일 수 있습니다. 수정한 내용이 적용되지 않았다면 먼저 설정을 다시 불러왔는지 확인하고, 곧바로 해당 항목이 작동하지 않는다고 단정하지 마세요.

들여쓰기, 매핑, 목록

YAML은 들여쓰기로 상하위 관계를 표현합니다. 각 단계에 공백 두 칸을 사용하고 탭은 피하는 것이 좋습니다. 콜론 뒤에는 공백 하나를 두어 키와 값을 구분하고, 목록 항목은 하이픈 뒤에 공백을 둡니다. 최상위의 dns, proxies, proxy-groups, rules는 각각 별도의 섹션입니다. 들여쓰기가 잘못되어도 구문 분석은 통과하면서 항목이 엉뚱한 계층에 들어갈 수 있습니다. 따라서 구문 검사만으로는 충분하지 않으며 구조가 의도한 대로인지도 확인해야 합니다.

# 로컬 직접 연결 기본 설정: 구조와 수신 대기 포트 확인
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

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

rules:
  - MATCH,Proxy

이 설정에는 원격 프록시 노드가 없고 정책 그룹에는 내장된 DIRECT만 있으므로 모든 트래픽이 최종적으로 직접 연결됩니다. 복잡한 구독 설정을 배제하는 데는 유용하지만 원격 프록시 서비스의 작동 여부를 확인할 수는 없습니다. 노드를 추가한다면 노드 이름을 정책 그룹에도 넣고 규칙이 해당 그룹을 가리키는지 확인해야 합니다. proxies 섹션에 항목 하나만 추가해도 기존 트래픽이 자동으로 그 노드를 선택하는 것은 아닙니다.

문자열, 불리언 값, 중복 키

포트 번호는 보통 정수로 입력하고, 스위치는 true 또는 false로 설정합니다. 샵 기호, 콜론 뒤 공백, 특수 접두사가 포함되거나 다른 자료형으로 잘못 인식될 수 있는 문자열은 따옴표로 감싸는 것이 좋습니다. 비밀번호도 문자열로 취급하세요. 적절한 위치의 샵 기호는 주석을 뜻하며 주석은 실행에 반영되지 않습니다. 규칙의 쉼표는 규칙 문자열 내부 문법의 일부이지 YAML의 키·값 구분자가 아니므로, 규칙 전체를 임의로 여러 항목으로 나누면 안 됩니다.

같은 매핑 계층에 동일한 키를 중복해서 정의하지 마세요. 앞에서 dns를 정의한 뒤 파일 끝에 다시 dns를 추가하는 방식은 안정적인 병합 방법이 아닙니다. 파서가 오류를 내거나 둘 중 하나만 남길 수 있습니다. 하위 항목은 하나의 매핑 안에 넣으세요. 노드 이름, 정책 그룹 이름과 참조 문자열도 정확히 일치해야 합니다. 전각 공백, 끝에 붙은 공백, 대소문자 차이만으로도 참조 대상을 찾지 못할 수 있습니다.

되돌릴 수 있는 편집 절차 만들기

먼저 기존 설정을 복사해 두고 기능 하나만 수정한 뒤 저장하고 다시 불러와 로그를 확인하세요. 클라이언트에 설정 검사 기능이 있다면 우선 사용하세요. 명령줄 커널을 사용한다면 아래 명령으로 구조를 검사할 수 있습니다. 프로그램 이름과 경로는 실제 기기에 맞게 바꿔야 합니다. 이 검사는 네트워크 연결 테스트를 대신하지 않으며 노드 인증 정보가 올바르다는 것을 보장하지도 않습니다. 검사에 실패하면 처음 나타난 명확한 오류부터 해결하세요. 뒤따르는 오류는 앞선 문제로 인해 연쇄적으로 발생했을 수 있습니다.

mihomo -t -f ./config.yaml

이 문서는 mihomo에서 자주 사용하는 설정을 기준으로 합니다. 원본 Clash, 과거 포크 버전, GUI 클라이언트마다 호환성 차이가 있을 수 있으므로 현재 커널용 설정이 모든 클라이언트에서 지원된다고 가정해서는 안 됩니다. 커널과 인터페이스 프로젝트를 먼저 확인하려면 Clash, Clash Meta, mihomo의 생태계 관계를 살펴본 뒤 필요한 항목을 선택하세요.

2. 포트, 모드, 공통 설정

수신 대기 포트와 트래픽 진입 경로

port는 HTTP 프록시 수신 대기 포트, socks-port는 SOCKS 프록시 수신 대기 포트입니다. mixed-port는 하나의 포트에서 두 종류의 프록시 요청을 모두 받습니다. 일반적인 데스크톱 환경에서는 혼합 포트만 설정해도 충분한 경우가 많지만, 다른 진입점의 필요 여부는 사용하는 앱에 따라 달라집니다. 포트 번호는 로컬 진입점이지 원격 노드 서버의 포트가 아닙니다. 브라우저가 로컬 프록시에 연결되면 커널이 정책에 따라 실제 원격 출구를 선택합니다.

항목	용도	수정 시 주의사항
`mixed-port`	HTTP와 SOCKS 혼합 진입점	시스템 프록시와 앱 포트를 함께 변경
`allow-lan`	LAN 기기의 접속 허용 여부	수신 주소와 방화벽도 확인
`mode`	실행 모드 선택	규칙 모드에서만 rules에 따라 분기
`log-level`	로그 상세 수준 설정	문제 해결 후 일반 수준으로 복구
`external-controller`	제어 인터페이스 수신 주소	프록시 트래픽 진입점과는 별개

포트를 변경했다면 클라이언트의 시스템 프록시 설정이나 앱 내부 프록시 주소도 함께 변경해야 합니다. 주소가 이미 사용 중이라는 오류는 다른 프로세스가 같은 수신 포트 조합을 사용 중이거나 기존 커널 프로세스가 종료되지 않았다는 뜻일 수 있습니다. 실행 중인 클라이언트와 로그를 확인하고 중복 프로세스를 종료한 뒤 포트 변경 여부를 결정하세요. 포트만 바꾸고 시스템 프록시 주소를 그대로 두면 커널은 정상적으로 시작되지만 웹 페이지가 열리지 않을 수 있습니다.

세 가지 모드는 네트워크를 켜고 끄는 스위치가 아닙니다

mode: rule은 규칙 순서에 따라 연결 경로를 결정하고, global은 전역 정책을 사용하며, direct는 커널이 받은 연결을 직접 연결합니다. 여기서 대상은 항상 커널에 들어온 트래픽이지 기기의 모든 네트워크 요청이 아닙니다. 규칙 모드를 켜더라도 시스템 프록시, 앱 프록시 또는 적절한 트래픽 처리 방식을 설정하지 않으면 브라우저 요청이 커널에 들어오지 않을 수 있습니다. 그러면 규칙이 일치하는 기록도 나타나지 않습니다.

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

profile:
  store-selected: true

예제는 수신 대기를 로컬로 제한하고 정책 그룹 선택 상태를 저장합니다. 클라이언트에 따라 시작할 때 GUI 옵션을 기준으로 해당 항목을 다시 쓸 수 있으므로, 화면에 표시되는 모드와 구독 원문이 다르면 최종 실행 설정을 확인하세요. 모드를 바꿔도 기존 연결이 다시 만들어지지 않을 수 있습니다. 변경된 선택을 확인하려면 새 요청을 보내고, 필요하다면 클라이언트의 연결 화면에서 기존 연결을 종료하세요. 세 모드의 차이는 규칙·전역·직접 연결 모드 안내에서 확인할 수 있습니다.

LAN 공유와 제어 인터페이스

allow-lan: true를 설정하면 다른 기기에서 접속할 수 있지만, bind-address, 시스템 방화벽, 연결된 네트워크의 격리 설정도 함께 확인해야 합니다. 로컬 기기에서만 사용할 때는 비활성화하는 편이 접근 범위를 관리하기 쉽습니다. 휴대폰이나 다른 컴퓨터와 공유해야 한다면 클라이언트가 실행 중인 기기의 LAN 주소를 접속 대상으로 사용하세요. 다른 기기 자신의 루프백 주소를 사용하면 안 됩니다. 신뢰할 수 있는 접속 출처로 제한하고 필요에 따라 프록시 인증도 설정하세요.

external-controller는 패널이나 클라이언트가 호출하는 관리 인터페이스로, 혼합 프록시 포트와는 용도가 다릅니다. 관리 인터페이스에서는 정책을 바꾸거나 연결 정보를 확인할 수 있으므로 보통 루프백 주소에 바인딩하고 인증은 클라이언트에서 관리해야 합니다. 웹 페이지가 열리지 않는다고 제어 포트를 시스템 프록시 주소에 입력하지 마세요. 공용 네트워크에 직접 노출해서도 안 됩니다. 프록시 진입점 인증과 제어 인터페이스 인증은 서로 다른 방식이며 대체할 수 없습니다.

로그, IPv6, 트래픽 처리 범위

평상시에는 info 수준으로 사용하고 문제를 진단할 때만 상세 수준을 높였다가 해결 후 되돌리는 것이 좋습니다. 로그가 너무 많으면 확인하기 어렵고 방문 도메인이나 연결 정보가 포함될 수 있으므로 공유하기 전에 구독 주소와 민감한 내용을 삭제하세요. 최상위 ipv6와 DNS 섹션의 같은 이름 스위치는 적용 범위가 다릅니다. 하나만 수정하고 기기 전체에서 IPv6가 꺼졌다고 판단해서는 안 되며, 시스템 네트워크 설정도 별도로 확인해야 합니다.

TUN은 가상 네트워크 어댑터, 라우팅, 권한, DNS 하이재킹이 관련된 별도의 트래픽 처리 진입점이며 혼합 포트를 설정했다고 자동으로 작동하지 않습니다. 데스크톱 클라이언트, 모바일 운영체제 인터페이스, 서버 명령줄 환경은 권한 설정 방법도 서로 다릅니다. 처음 설정할 때는 일반 프록시 진입점부터 작동시킨 뒤 TUN을 별도로 확인하세요. 권한이나 라우팅 문제가 발생해도 이미 확인된 연결 경로를 유지할 수 있어 여러 계층을 동시에 수정했을 때보다 원인을 찾기 쉽습니다.

3. DNS 및 Fake-IP 설정

도메인을 누가 해석하는지 먼저 확인하기

DNS 설정은 커널이 도메인을 주소로 변환하는 방법과 도메인·연결 간 관계를 유지하는 방식을 정합니다. 브라우저, 운영체제, 앱 자체, 커널이 각각 DNS 해석에 관여할 수 있으므로 dns.enable: true를 설정해도 기기의 모든 요청이 커널로 전달되는 것은 아닙니다. 시스템 프록시 환경에서는 일부 도메인이 프록시 요청과 함께 전달될 수 있고, TUN에서는 DNS 하이재킹과 시스템 라우팅을 함께 설정해야 하는 경우가 많습니다. 앱 자체의 암호화 DNS는 다른 경로를 사용할 수도 있습니다.

dns.listen은 커널 DNS 서비스의 수신 주소이며 상위 DNS 서버가 아닙니다. 로컬의 높은 포트에서 대기하도록 설정해도 시스템이 이를 자동으로 찾지는 않습니다. 클라이언트나 네트워크 설정에서 DNS 질의를 해당 주소로 보내야 합니다. 아래 예제는 항목 간 관계를 설명하며 TUN 트래픽 처리 설정은 포함하지 않습니다. 예제의 암호화 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
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"

Fake-IP로 도메인 연결 정보 유지하기

enhanced-mode: fake-ip는 앱에 매핑용 주소를 반환합니다. 이후 커널은 매핑 정보를 이용해 도메인을 복원하고 정책을 선택합니다. 이 주소는 대상 웹사이트의 실제 서버 주소가 아니므로 시스템 조회 결과에 표시되어도 DNS 오염을 뜻하지 않습니다. 중요한 점은 이후 연결이 매핑 정보를 보유한 커널로 다시 전달되는지 여부입니다. 한 인스턴스가 DNS 요청을 처리하고 다른 인스턴스가 연결을 받으면 주소는 존재해도 정상적으로 접속하지 못할 수 있습니다.

fake-ip-range는 주소 할당 범위이지 원격 노드 주소가 아니며, 프록시 우회 목록에 추가하라는 대역도 아닙니다. 로컬 네트워크, 가상 어댑터 또는 다른 도구의 라우팅과 충돌한다면 전체 경로를 점검해야 합니다. 우연히 비어 있는 것처럼 보이는 대역으로 임의 변경하지 마세요. DNS 모드를 바꾸거나 커널을 재시작해도 앱에 이전 매핑이 남아 있을 수 있습니다. 새 연결을 만들고 필요하면 앱과 시스템의 관련 캐시를 지운 뒤 변경 효과를 확인하세요.

fake-ip-filter에는 매핑 주소를 반환하기에 적합하지 않은 도메인을 지정합니다. 일부 LAN 이름이나 실제 주소가 필요한 서비스가 예입니다. 목록에 추가해도 해당 연결이 반드시 직접 연결되는 것은 아니며 실제 출구는 규칙이 결정합니다. 필터 범위가 지나치게 넓으면 많은 도메인의 해석 경로가 바뀌어 문제 해결이 어려워집니다. 특정 서비스에서 오류가 발생하면 먼저 실제 주소가 필요한지 확인한 뒤 가능한 한 구체적인 도메인을 추가하세요. 모든 도메인을 한꺼번에 제외하지 마세요.

상위 DNS, 부트스트랩, 노드 도메인 해석

default-nameserver는 주로 DNS 상위 서버의 도메인을 해석하는 데 사용합니다. 암호화 DNS 주소에 연결할 IP 주소가 아직 없는 상황을 해결하는 역할입니다. nameserver는 일반 질의에 사용할 상위 서버이며 두 항목을 이름만 보고 완전히 같은 후보 목록으로 취급해서는 안 됩니다. 상위 서버 주소에 도메인이 포함되어 있다면 네트워크 시작 단계에서 사용할 수 있는 부트스트랩 DNS가 필요합니다. 부트스트랩 단계에서 실패하면 뒤이어 암호화 DNS 연결도 이루어지지 않을 수 있습니다.

원격 프록시 노드의 서버 주소가 도메인인 경우 노드 도메인의 해석 경로도 고려해야 합니다. mihomo에는 노드 서버 해석에 사용할 상위 서버를 지정하는 proxy-server-nameserver 등의 항목이 있습니다. DNS 서비스에 접속하는 트래픽을 프록시로 보내면서 프록시 연결도 같은 DNS 서비스로 노드 주소를 알아내야 한다면 순환 의존이 생길 수 있습니다. 먼저 별도로 접속 가능한 경로를 통해 노드 도메인을 해석한 뒤 다른 DNS 질의를 프록시로 보내도록 설정하는 편이 안정적입니다.

nameserver-policy를 사용하면 도메인이나 지원되는 패턴에 따라 DNS 상위 서버를 지정할 수 있습니다. 내부 도메인과 공용 도메인에 서로 다른 해석기가 필요한 경우에 유용합니다. 이 항목은 DNS 질의의 경로를 정할 뿐 비즈니스 트래픽의 출구를 정하지 않습니다. 실제 트래픽은 rules가 결정합니다. 규칙과 연동되는 DNS 옵션을 사용하기 전에 프록시 서버의 해석 경로가 완성되어 있는지 확인하세요. DNS 정책과 트래픽 정책이 서로를 참조해 순환하지 않도록 주의해야 합니다.

증상에 따라 DNS 문제 범위 좁히기

LAN 서비스만 실패하면 필터 목록과 내부 DNS 서버부터 확인하세요. 모든 도메인이 실패한다면 상위 서버에 접속할 수 있는지, 수신 포트에 질의가 들어오는지 살펴보세요. 주소는 얻었지만 연결에 실패한다면 규칙과 출구를 확인하세요. 모든 시간 초과를 Fake-IP 탓으로 돌리지 마세요. 잘못된 포트, 노드 인증 실패, 원격 서버의 연결 거부도 비슷하게 보일 수 있습니다. 연결됨으로 표시되지만 웹 페이지가 열리지 않을 때 점검할 항목을 참고해 진입점, DNS, 출구를 따로 확인하세요.

4. 프록시 노드와 프로토콜 설정

공통 항목과 프로토콜별 항목 구분하기

proxies는 정적 노드 목록이며 각 항목은 하나의 원격 연결 방식을 설명합니다. 공통 항목으로는 표시 이름 name, 프로토콜 유형 type, 서버 주소 server, 원격 수신 포트 port가 있습니다. 여기의 포트는 서비스 제공자가 지정하며 로컬 혼합 포트와는 관련이 없습니다. 이름은 정책 그룹에서 노드를 참조하는 데 사용하고, 서버 항목은 실제 연결 대상입니다. 구독 링크나 관리 패널 로그인 주소를 서버 항목에 넣지 마세요.

프로토콜마다 인증 및 전송 항목이 다르므로 서로 바꿔 쓸 수 없습니다. Shadowsocks는 보통 암호화 방식과 비밀번호를 사용하고, Trojan은 비밀번호를 사용하며 TLS에 의존합니다. 다른 프로토콜에는 사용자 식별자, 플로우 표시자, 특정 전송 매개변수가 필요할 수 있습니다. 서비스 제공자가 안내한 프로토콜에 맞는 항목을 입력하세요. type만 다른 값으로 바꾼다고 기존 노드가 다른 프로토콜로 변환되는 것은 아닙니다. 설정을 불러오는 데는 성공해도 핸드셰이크가 실패할 수 있습니다.

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

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

위 예제는 항목 작성 방법을 보여주기 위한 것으로 도메인과 비밀번호는 실제 연결에 사용할 수 없습니다. 특히 흔히 보안 포트로 쓰이는 번호라는 이유만으로 서비스의 프로토콜이나 암호화 방식을 추측하지 마세요. 서버는 사용자 지정 포트에서도 동작할 수 있습니다. 중요한 것은 클라이언트와 서버의 프로토콜, 인증, 전송, TLS 설정이 서로 일치하는지입니다. 인증 정보는 신뢰할 수 있는 서비스 설정에서 확인하고, 공유 화면을 보고 누락된 항목을 추측하지 마세요.

TLS 이름과 서버 주소

서버 주소는 연결 대상을 정하고 TLS 이름은 핸드셰이크와 인증서 이름 검증에 사용됩니다. 두 값은 같을 수도 있고, 서버 측 요구에 따라 다를 수도 있습니다. Trojan 예제의 sni를 연결이 실패한다는 이유만으로 흔히 쓰이는 웹사이트 도메인으로 바꾸지 마세요. servername처럼 다른 항목 이름을 사용하는 프로토콜은 해당 프로토콜의 정의에 따라 설정해야 합니다. 커널이 알아서 처리할 것이라고 기대하며 모든 TLS 이름 항목을 한꺼번에 추가하지 마세요.

skip-cert-verify: false는 인증서 검증을 유지한다는 뜻입니다. 인증서 오류가 발생하면 먼저 기기 시간, 서버 이름, 인증서 유효성, 서비스 제공자의 설정을 확인하세요. 검증을 끄면 오류 메시지가 달라질 수 있지만 서버를 확인하기 위한 보호 기능을 우회하게 되므로 일반적인 해결 방법으로 사용해서는 안 됩니다. 사설 환경에서 인증서를 배포하는 경우에는 적절한 클라이언트 설정을 정하기 전에 인증서 신뢰 체인을 어떻게 구성할지 확인하세요.

전송 계층, UDP, DNS 해석 경로

일부 프로토콜에는 network, ws-opts, grpc-opts 같은 전송 설정도 필요합니다. 경로, 요청 헤더, 서비스 이름은 서버 측 설정에 포함되므로 도메인이 같다는 이유만으로 생략할 수 없습니다. WebSocket 경로는 일반 웹페이지 주소와도 다릅니다. 핸드셰이크에 실패하면 먼저 서비스 제공자가 안내한 원본 설정과 대조해 구독 변환, 복사, 클라이언트 가져오기 과정에서 전송 설정이 누락되지 않았는지 확인하세요.

udp: true는 노드가 해당 UDP 트래픽을 처리하도록 허용한다는 뜻이지만 전체 연결 경로가 UDP를 지원한다고 보장하지는 않습니다. 앱 진입점, 트래픽 처리 방식, 원격 프로토콜, 서버 설정, 네트워크 방화벽이 모두 결과에 영향을 줍니다. 웹 페이지는 열리지만 음성 통화나 게임이 작동하지 않는다면 트래픽이 커널에 들어오는지와 원격 출구가 필요한 전송을 지원하는지 각각 확인하세요. 노드의 UDP 스위치만 반복해서 바꾸지 마세요. UDP 기반 프록시 프로토콜은 하위 네트워크에서 해당 연결을 허용해야 할 수도 있습니다.

노드 서버에 도메인을 사용한다면 원격 연결을 시작하기 전에 도메인 해석이 끝나야 합니다. 로그에 노드 이름은 올바르게 표시되지만 서버 주소 해석에 실패하면 DNS 장으로 돌아가 노드 해석용 상위 서버를 확인하세요. 주소에 연결한 뒤 인증 거부가 발생한다면 비밀번호와 프로토콜을 점검하세요. 오류를 해석, 연결, 핸드셰이크, 인증, 실제 요청 단계로 나누어 확인하면 노드가 작동하지 않는다고 막연히 판단하는 것보다 도움이 되며 서비스 제공자에게 상황을 설명하기도 쉽습니다.

노드 관리와 정보 보안

같은 이름의 노드가 여러 개 있으면 참조 관계가 모호해지고 구독 업데이트 후 이전 이름이 남기 쉽습니다. 정적 목록에서는 각 노드 이름을 고유하게 유지하고 이름을 바꾼 뒤 정책 그룹과 규칙 참조도 확인하세요. 노드를 대량으로 동적으로 관리하려면 뒤에서 설명하는 프록시 제공자를 사용하는 편이 목록 전체를 수동으로 복사하는 것보다 낫습니다. 클라이언트를 바꾸려면 다운로드 페이지에서 운영체제에 맞는 항목을 선택하세요. 일반적인 GUI 클라이언트로는 Clash Plus를 우선 고려하고, 필요한 프로토콜이 실제 커널에서 지원되는지 먼저 확인하세요.

5. 정책 그룹과 출구 선택

정책 그룹으로 노드를 묶어 참조하기

proxy-groups는 규칙에서 사용할 안정적인 대상 이름을 제공합니다. 규칙은 계속 Proxy를 가리키고 사용자는 그룹 안에서 노드를 바꿀 수 있으므로 도메인 규칙을 하나씩 수정할 필요가 없습니다. 그룹 후보에는 실제 노드, 다른 정책 그룹, 내장 정책을 넣을 수 있습니다. 방향이 있는 참조 그래프라고 생각하면 이해하기 쉽습니다. 요청이 규칙에 일치한 다음 그룹으로 전달되고, 현재 선택을 따라 최종 출구를 찾습니다. 모든 그룹이 같은 연결을 동시에 처리하는 것은 아닙니다.

select는 수동 선택 방식으로, 전체 진입점이나 업무용 환경 또는 출구를 명시적으로 고정해야 하는 서비스에 적합합니다. url-test는 탐지 결과에 따라 후보를 자동 선택하고, fallback은 후보 순서대로 사용할 수 있는 항목을 찾으며, load-balance는 지원되는 방식에 따라 연결을 분배합니다. 자동 그룹이 모든 사용자에게 적합한 기본값은 아닙니다. 출구 변경을 허용할지, 세션을 유지해야 하는지, 노드가 같은 서비스 환경에서 제공되는지 등을 고려해 선택하세요.

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 자동 선택
      - DIRECT

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

rules:
  - MATCH,Proxy

예제는 앞 장에서 정의한 두 노드에 의존하므로 정책 그룹만 따로 복사해서는 실행할 수 없습니다. 탐지 주소는 노드 서버도 아니고 실제 웹사이트의 완전한 대체 테스트 대상도 아닙니다. 현재 네트워크에서 해당 주소에 접속할 수 없다면 모든 후보가 사용 불가로 잘못 판단될 수 있습니다. 사용 환경에 적합하고 응답이 안정적인 탐지 대상을 고르세요. 앱 페이지의 로딩 시간으로 그룹의 선택 결과를 판단하지 말고, 탐지 요청이 의도한 노드를 거쳐 처리되는지도 확인해야 합니다.

자동 탐지 항목의 실제 작동 방식

interval은 보통 탐지 간격을 초 단위로 설정하며, tolerance는 자동 선택에서 작은 응답 차이 때문에 선택이 자주 바뀌는 일을 줄이는 데 사용합니다. 탐지 간격이 짧을수록 좋은 것은 아닙니다. 탐지를 너무 자주 하면 요청과 전력 소모가 늘어나므로 특히 모바일 기기에서는 주의하세요. 일부 자동 그룹은 지연 탐지 같은 옵션도 지원합니다. 실제 동작은 그룹 유형과 커널 구현에 따라 다르므로 사용하지 않는 모든 그룹이 같은 간격으로 계속 탐지한다고 기대해서는 안 됩니다.

탐지에 성공했다는 것은 노드가 해당 탐지 대상에 접속할 수 있다는 뜻일 뿐, 모든 웹사이트와 프로토콜, 계정 세션이 정상 작동한다는 보장은 아닙니다. 특정 서비스가 지역, 로그인 상태, 출구 제한의 영향을 받는다면 새 연결을 만들어 실제 서비스에서 확인하세요. 자동 선택으로 출구가 바뀌어도 기존 연결은 이전 경로를 유지할 수 있습니다. 같은 시간에 여러 출구가 관찰되더라도 설정 충돌이 아니라 연결 수명 차이에 따른 정상적인 현상일 수 있습니다.

그룹 중첩과 참조 제한

중첩 그룹은 수동 선택과 자동 선택을 분리할 때 유용합니다. 예를 들어 전체 진입점에서 자동 그룹과 직접 연결 중 하나를 선택하고, 자동 그룹 내부에서는 노드를 선택할 수 있습니다. 두 그룹이 서로를 참조하거나 한 그룹이 자기 자신을 후보로 지정하지 않도록 하세요. 순환 참조가 발생합니다. 이름 오류를 점검할 때는 규칙 대상부터 시작해 대상 그룹, 후보 그룹, 최종 노드가 존재하는지 차례로 확인하고 실제 연결 가능한 최종 항목까지 따라가세요.

use를 사용하면 프록시 제공자에서 정책 그룹 후보를 가져올 수 있고, filter로 이름을 필터링할 수 있습니다. 필터 표현식은 매칭 조건이지 노드 분류 태그가 아닙니다. 구독에서 이름을 바꾸면 기존 필터가 더 이상 일치하지 않아 후보가 없어질 수 있습니다. 자동 그룹에 후보가 없다면 먼저 제공자가 로드되었는지와 필터가 지나치게 엄격하지 않은지 확인하세요. 탐지 간격부터 늘리지 마세요. 관리할 때는 필터를 잠시 해제해 후보가 있는지 확인한 뒤 조건을 하나씩 좁히세요.

선택 저장이 모든 트래픽 고정을 뜻하지는 않습니다

profile.store-selected는 수동 그룹의 선택을 저장하는 데 사용할 수 있지만, 클라이언트마다 자체 상태 저장 방식을 사용할 수 있습니다. 설정 업데이트 후 그룹 이름이 바뀌면 이전 선택이 새 그룹과 연결되지 않을 수 있고, 선택된 노드가 삭제되면 다른 항목으로 전환될 수도 있습니다. 특정 서비스의 출구를 고정하려면 안정적인 그룹 이름과 노드 이름을 유지하고 해당 서비스 규칙을 일반 규칙보다 앞에 두세요. 전체 그룹의 선택만 보지 마세요. 더 구체적인 규칙이 별도의 그룹을 가리킬 수 있습니다.

내장된 DIRECT는 직접 연결, REJECT는 연결 거부를 뜻하며 수동으로 정의할 원격 노드가 아닙니다. 직접 연결을 자동 탐지 그룹에 넣으면 탐지가 쉽게 성공해 계속 선택될 수 있으므로, 원래 프록시를 사용하려던 목적에서 벗어나지 않는지 고려하세요. 자동 선택 결과가 불확실하다면 먼저 수동 그룹에서 작동이 확인된 노드를 선택해 실제 서비스가 복구되는지 확인하세요. 그다음 자동 정책을 하나씩 다시 적용하면 노드 문제와 그룹 로직 문제를 구분할 수 있습니다.

6. 규칙 문법과 매칭 순서

위에서 아래로 확인하며 처음 일치한 규칙에서 멈춥니다

rules는 순서가 있는 규칙 목록입니다. 커널은 목록의 위에서부터 연결을 확인하고, 처음 일치한 규칙의 정책을 적용한 뒤 다음 규칙은 확인하지 않습니다. 따라서 특정 도메인 규칙은 앞쪽에 두고 범위가 넓은 주소 규칙은 뒤쪽에 두며, 마지막에는 일치하지 않은 트래픽을 처리하는 MATCH를 둡니다. 기본 처리 규칙을 맨 앞에 두면 뒤의 여러 규칙이 작동하지 않습니다. 구문 검사는 통과해도 실제 분기 결과가 예상과 완전히 달라질 수 있습니다.

일반적인 규칙은 규칙 유형, 매칭 대상, 대상 정책의 세 부분으로 구성되며 영어 쉼표로 구분합니다. MATCH에는 매칭 대상이 없으므로 대상 정책만 입력합니다. 대상은 노드, 정책 그룹 또는 내장 정책일 수 있지만 커널에서 찾을 수 있어야 합니다. 이름에 전각 문장 부호나 눈에 보이지 않는 공백이 들어가거나 복사 과정에서 따옴표가 추가되면 참조에 실패할 수 있습니다. 규칙 목록은 기능별로 나누고 짧은 주석을 붙이면 나중에 관리하기 편합니다.

rules:
  # LAN 이름과 사설 주소
  - DOMAIN-SUFFIX,lan,DIRECT
  - 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

  # 예제 도메인을 Proxy로 전달
  - DOMAIN-SUFFIX,example.com,Proxy

  # 사용 가능한 지리 정보 데이터베이스 필요
  - GEOIP,CN,DIRECT

  # 일치하지 않은 모든 연결
  - MATCH,Proxy

도메인 규칙과 주소 규칙

DOMAIN은 도메인 전체를 일치시키므로 단일 호스트를 처리할 때 적합합니다. DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 함께 일치시킵니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드를 찾아 범위가 더 넓고, 대상이 아닌 도메인까지 일치할 수 있습니다. 이름이 비슷하다는 이유만으로 짧은 키워드를 사용해 서비스를 전부 처리하려고 하지 마세요. 하나의 서비스가 여러 도메인에 의존할 수도 있으므로 홈페이지가 예상한 규칙과 일치한다고 해서 로그인, 이미지, API 요청도 같은 출구를 사용한다는 뜻은 아닙니다.

IP-CIDR은 주소 대역으로 매칭하며, IPv6 대역에는 보통 IP-CIDR6을 사용합니다. 처음에 도메인으로 요청이 들어오는 서비스에서는 주소 규칙이 적용되려면 DNS 해석이 필요할 수 있습니다. 끝에 붙이는 no-resolve는 해당 주소 규칙을 위해 해석을 새로 시작하지 않도록 하는 옵션입니다. 이미 존재하는 대상 주소를 지우거나 해당 연결이 다른 해석 과정을 절대 거치지 않게 하는 것은 아닙니다. 모든 규칙에 기계적으로 붙이면 주소 매칭에 기대한 동작이 달라질 수 있습니다.

GEOIP와 GEOSITE는 관련 데이터 리소스가 필요하므로 사용 전에 커널이 필요한 데이터를 불러왔는지 확인하세요. 지역이나 사이트 유형은 데이터 관리자가 정한 분류이며 서비스의 소유 관계, 실제 서버 위치, 접속 결과를 영구적으로 보장하지 않습니다. 분류가 실제 업무에 맞지 않으면 범위가 넓고 서로 충돌하는 규칙을 여러 개 추가하기보다 앞쪽에 더 정확한 도메인 규칙을 넣으세요.

프로세스 규칙과 요청 출처 정보의 범위

mihomo는 프로세스 이름이나 경로를 기준으로 하는 규칙도 지원하지만, 프로세스 정보를 얻을 수 있는지는 운영체제, 권한, 트래픽 처리 방식, 조회 설정에 따라 다릅니다. 로컬 데스크톱 앱은 프로세스를 식별할 수 있어도 LAN의 다른 기기에서 들어온 프록시 요청에는 해당 기기의 전체 프로세스 정보가 전달되지 않는 경우가 많습니다. 규칙 문법이 올바른데도 일치하지 않는다면 규칙 유형이 지원되지 않는다고 단정하기 전에 연결 로그에 매칭에 필요한 정보가 실제로 있는지 확인하세요.

앱 이름과 실제 연결을 시작하는 프로세스 이름이 다를 수 있습니다. 브라우저 보조 프로세스, 업데이트 서비스, 백그라운드 구성 요소가 각각 연결을 만들 수 있으므로 창 제목만 보고 프로세스 규칙을 작성하지 마세요. 업무용 앱의 출구를 고정해야 한다면 먼저 명확한 서비스 도메인으로 동작을 확인한 다음, 남은 연결에 프로세스 규칙을 적용할 수 있는지 검토하세요. 복잡한 논리 규칙은 기본 분기가 검증된 뒤에 추가하고, 개별 테스트가 가능한 단순한 조건을 남겨 두세요.

연결 기록으로 규칙 확인하기

확인할 때는 먼저 규칙 모드인지 확인하고 클라이언트의 연결 또는 로그 화면을 연 다음 대상에 새 요청을 보내세요. 어떤 규칙이 일치했으며 최종 정책 경로가 무엇인지 확인합니다. 웹 페이지가 열리는지만 봐서는 규칙에 따라 프록시를 사용했는지, 직접 연결했는지, 기존 연결을 재사용했는지 알 수 없습니다. 규칙을 바꾼 뒤에도 새 연결을 만들어야 합니다. 필요하다면 대상 앱의 장기 연결을 종료하세요. 기존 연결이 이전 출구를 계속 사용하는 상황을 규칙이 갱신되지 않은 것으로 오해하지 않도록 주의하세요.

잘못된 규칙에 일치하면 먼저 위쪽에 더 넓은 규칙이 있는지, 다음으로 도메인이 예상한 정보에서 전달되었는지, 마지막으로 대상 그룹에서 무엇을 선택했는지 확인하세요. 전체 설정을 전역 모드로 바꾸는 것을 영구적인 해결책으로 삼지 마세요. 전역 모드는 규칙 경로와 출구 중 어느 쪽에 문제가 있는지 구분하는 데만 도움이 됩니다. 전역 모드는 작동하지만 규칙 모드가 실패한다면 일치 기록을 따라 구체적인 규칙을 수정하세요. 모드 차이는 프록시 모드 안내를 참고하세요.

규칙 집합 안에서도 순서는 중요하며, 주 설정에서 규칙 집합을 참조하는 위치에 따라 다른 규칙보다 먼저 적용될지가 달라집니다. 개인 예외를 관리할 때는 변경 가능성이 낮은 규칙 몇 개를 공용 규칙 집합보다 앞에 두고 마지막에 명확한 기본 규칙을 유지하세요. 규칙을 하나 추가할 때마다 기존의 어떤 항목을 덮어쓸지 고려해야 합니다. 특히 키워드, 지역, 전체 포트 조건은 주의하세요. 정확한 도메인으로 해결할 수 있다면 네트워크 전체나 모든 앱으로 범위를 넓힐 필요가 없습니다.

7. 프록시 제공자와 외부 규칙 집합

업데이트 리소스를 주 설정과 분리하기

proxy-providers는 프록시 제공자를 선언하고 rule-providers는 규칙 집합을 선언합니다. 두 항목 모두 자주 바뀌는 내용을 주 설정에서 분리할 수 있지만 데이터 형식이 다릅니다. 전체 구독 파일을 규칙 집합으로 사용할 수 없고 도메인 목록을 노드 목록으로 사용할 수도 없습니다. 주 설정에서는 리소스 위치, 로드 방법, 참조 방법을 지정하고 리소스 자체에서는 노드나 규칙을 제공합니다. 참조 관계가 올바르게 구성되어야 실제 실행에 반영됩니다.

처음 문제를 확인할 때는 먼저 로컬 파일을 사용해 형식과 참조가 올바른지 확인한 뒤 원격 업데이트를 연결하는 것이 좋습니다. 이렇게 하면 네트워크 다운로드 실패와 내용 파싱 실패를 구분할 수 있습니다. 로컬 경로는 커널의 작업 디렉터리와 클라이언트의 경로 제한을 기준으로 해석되므로 현재 편집기에서 연 파일 위치와 다를 수 있습니다. 일부 클라이언트는 파일을 자체 설정 폴더로 복사하므로 원본을 수정해도 자동 동기화되지 않습니다. 실행 설정에서 최종적으로 어느 경로를 가리키는지 확인하세요.

# 주 설정의 관련 설정 부분
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: Proxy
    type: select
    use:
      - local-nodes

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,Proxy

프록시 제공자 파일에는 자체 proxies 목록이 있어야 합니다. 서버가 전체 설정을 반환하는 경우 제공자로 읽을 수 있는지는 내용과 커널의 처리 방식에 따라 달라집니다. 모든 최상위 설정이 함께 적용된다고 가정하지 마세요. 제공자는 노드 데이터만 담당하도록 구성하는 것이 가장 안전합니다. 제공자에서 노드 이름이 바뀌면 수동 선택과 필터 표현식에도 영향을 주므로 업데이트 후 성공 알림만 볼 것이 아니라 그룹 후보도 다시 확인하세요.

# ./providers/nodes.yaml
proxies:
  - name: "예시 SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

규칙 집합의 동작은 실제 내용과 맞아야 합니다

behavior: domain은 도메인 데이터를, ipcidr은 주소 대역을, classical은 기존 규칙 유형 형식을 처리하는 데 적합합니다. format은 YAML이나 지원되는 텍스트·바이너리 형식처럼 실제 파일 형식을 지정합니다. 동작 방식과 파일 형식은 서로 다른 기준입니다. 확장자가 YAML처럼 보인다고 해서 내용이 도메인 규칙에 맞는다고 단정하지 마세요. 파싱 오류가 나면 설정 이름만 바꾸지 말고 실제 데이터 파일을 열어 확인하세요.

# ./rules/direct.yaml
payload:
  - "example.org"
  - "+.example.net"

위 도메인 데이터는 도메인 규칙 집합에 적합한 형식으로 작성했으며, 점 앞에 더하기 기호가 붙은 항목은 도메인과 하위 도메인을 포함합니다. classical을 사용한다면 데이터에는 도메인 접미사 규칙처럼 규칙 유형과 매칭 조건을 작성하는 것이 일반적입니다. 출구 정책은 주 설정의 RULE-SET 참조에서 지정합니다. 정책이 포함된 규칙 전체를 데이터 파일에 그대로 옮기면 대상이 중복 지정되거나 형식 오류가 발생할 수 있으므로 변환 전에 필요한 동작을 확인하세요.

원격 업데이트는 URL만 설정하면 되는 것이 아닙니다

HTTP 유형의 제공자를 사용할 때는 보통 다운로드 주소, 저장 경로, 업데이트 간격도 설정해야 합니다. 간격은 초 단위로 지정하는 경우가 많습니다. 주소가 예상한 리소스 본문을 반환해야 합니다. 로그인 페이지, 접근 안내, 오류 문서가 반환되면 네트워크 요청은 성공으로 표시되어도 내용을 파싱하지 못할 수 있습니다. 구독 주소에 개인 인증 정보가 포함될 수도 있으므로 본인 설정에만 저장하고 스크린샷, 공개 저장소, 공개 오류 보고서에 올리지 마세요.

각 리소스에 별도의 캐시 경로를 사용해 두 제공자가 같은 파일을 덮어쓰지 않도록 하세요. 원격 업데이트가 실패했을 때 커널이 캐시를 계속 사용할 수 있는지는 캐시의 존재 여부와 유효성, 클라이언트 관리 방식에 따라 다릅니다. 새 기기에는 이전 캐시가 없으므로 오랫동안 사용한 기기와 시작 실패 양상이 다를 수 있습니다. 한 기기에서 당장 사용할 수 있다고 해서 구독 서버에 문제가 없다고 판단해서는 안 됩니다.

프록시 제공자의 상태 확인은 제공자에 포함된 노드의 접속 가능 여부를 검사합니다. 정책 그룹의 자동 선택 탐지와 관련은 있지만 완전히 같은 기능은 아닙니다. 여러 계층에서 고빈도 검사를 동시에 켜면 탐지 요청이 중복될 수 있습니다. 먼저 어떤 계층이 업데이트를 담당하고, 어떤 계층이 상태를 검사하며, 어떤 계층이 노드를 선택하는지 파악한 뒤 적절한 간격을 설정하세요. 원격 리소스 다운로드가 프록시를 거치는지도 고려해야 합니다. 시작 시 프록시 노드가 아직 로드되지 않았는데 해당 노드가 있어야 리소스를 다운로드할 수 있다면 순환 의존이 생길 수 있습니다.

업데이트 오류를 두 유형으로 나눠 해결하기

로그에 요청 시간 초과, 도메인 해석 실패, 인증서 오류가 있다면 리소스를 가져오는 경로부터 확인하세요. 본문을 가져온 뒤 항목이나 데이터 오류가 발생했다면 내용 형식을 점검하세요. 두 번째 유형의 오류에 네트워크 초기화를 반복하거나 첫 번째 유형의 오류에서 규칙 집합 동작을 무작정 바꾸지 마세요. 구독을 가져오는 다양한 상황은 구독 업데이트 실패 및 자동 업데이트 설정을 참고하세요. 수정 후에는 다시 불러와 규칙이 일치하는지 확인해야 합니다. 다운로드 완료 여부만 확인해서는 안 됩니다.

8. 구독 덮어쓰기, 병합, 문제 해결

원본 설정, 덮어쓰기, 최종 설정 구분하기

구독을 업데이트하면 원본 파일을 다시 가져오는 경우가 많으므로 구독 캐시를 직접 수정하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다. 덮어쓰기는 개인 설정을 별도 계층으로 저장하고 클라이언트가 실행 설정을 생성할 때 적용하기 위한 기능입니다. 이 과정은 주로 GUI 클라이언트에서 처리되며 모든 커널에 공통 덮어쓰기 스위치가 있는 것은 아닙니다. Clash Plus, Clash Verge Rev, FlClash를 사용할 때는 각각의 설정 관리 메뉴와 병합 방식을 확인하세요. 한 클라이언트용 스크립트를 다른 클라이언트에 그대로 복사해서는 안 됩니다.

일반적인 구조에서는 원격 구독이 노드와 기본 규칙을 제공하고, 클라이언트가 수신 포트와 제어 인터페이스 등의 실행 설정을 추가하며, 개인 덮어쓰기가 DNS, 정책, 예외 규칙을 조정합니다. 실제 적용 순서는 클라이언트가 결정하며 여러 덮어쓰기를 차례대로 적용할 수도 있습니다. 특정 편집 화면의 내용이 아니라 최종 실행 설정을 기준으로 확인하세요. 화면에서 설정이 덮어써진다면 각 계층을 정리하고 해당 항목을 마지막으로 쓴 계층을 찾으세요.

매핑 병합과 목록 교체는 다릅니다

스칼라 값은 보통 새 값으로 바뀌고, 매핑은 재귀적으로 병합되며, 목록은 통째로 교체되거나 추가되거나 별도 규칙으로 처리될 수 있습니다. 이러한 동작은 YAML 파일 형식이 클라이언트에 일괄 지정하는 것이 아닙니다. 특히 rules, proxies, proxy-groups에서 전체 교체를 자동 추가로 잘못 이해하면 구독 규칙이나 노드가 모두 사라질 수 있습니다. 저장하기 전에 현재 설정 메뉴가 완성된 설정 파일을 받는지, 변경 사항만 담은 부분 설정을 받는지 확인하세요.

# 덮어쓰려는 항목을 나타낼 뿐이며 일반적인 덮어쓰기 파일 형식은 아닙니다
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

profile:
  store-selected: true

위 예제는 변경하려는 내용을 표현하기 위한 것으로, 그대로 붙여 넣어 사용할 수 있는지는 클라이언트의 덮어쓰기 안내에 따라 다릅니다. 해당 메뉴가 dns 매핑 전체를 교체한다면 기존 상위 서버와 필터 목록이 지워질 수 있습니다. 재귀 병합을 사용한다면 지정하지 않은 항목이 유지될 수도 있습니다. 작업 후 최종 DNS 섹션을 확인해 상위 서버 설정이 남아 있는지 점검하세요. 짧은 예제를 모든 구독에 적용할 수 있는 범용 설정으로 취급하지 말고 중복된 최상위 키로 병합을 흉내 내지도 마세요.

규칙을 넣을 위치를 명확히 정하기

개인 규칙을 추가할 때는 앞에 삽입할지 뒤에 추가할지 구분해야 합니다. 정확한 예외 규칙은 보통 공용 규칙보다 앞에 두고, 기본 처리 규칙은 마지막에만 둡니다. 클라이언트가 목록 끝에 추가하는 기능만 제공한다면 기존 MATCH 뒤에 개인 도메인 규칙을 붙여도 저장만 될 뿐 실행되지 않습니다. 클라이언트가 지원하는 앞쪽 삽입 기능이나 전체 목록 교체 기능을 사용하고 실행 설정에서 실제 위치를 확인하세요. 목록을 다시 만들 때는 계속 필요한 기존 규칙을 보존해야 합니다.

노드와 정책 그룹에도 참조 순서에 따른 제약이 있습니다. 새 규칙이 참조하는 그룹이 존재해야 하고, 그룹이 참조하는 노드나 제공자를 불러올 수 있어야 합니다. 노드를 삭제하기 전에 관련 참조부터 제거하세요. 이름 변경은 표시 이름만 바꾸는 일이 아니라 참조를 함께 옮기는 작업입니다. 구독 자동 업데이트 후 대상을 찾지 못한다면 개인 규칙이 이전 그룹 이름을 사용하고 있을 수 있습니다. 고정된 개인 그룹 이름을 중간 계층으로 사용하면 상위 노드 이름 변경의 영향을 줄일 수 있지만 후보가 유효한지는 여전히 확인해야 합니다.

네 단계로 수정 사항 검증하기

1단계는 파싱 확인입니다. 들여쓰기, 자료형, 중복 키, 미지원 항목으로 시작이 실패하는지 확인합니다. 2단계는 참조 확인입니다. 규칙 대상, 정책 그룹 후보, 제공자 이름, 리소스 경로가 존재하는지 살펴봅니다. 3단계는 트래픽 처리 확인입니다. 요청이 현재 커널에 들어오는지, 시스템 프록시 포트가 일치하는지, TUN 권한과 라우팅이 정상인지 확인합니다. 4단계는 네트워크 확인입니다. 노드 DNS 해석, 원격 연결, TLS, 인증, 대상 서비스가 차례대로 작동하는지 살펴봅니다. 앞 단계를 건너뛰지 말고 한 단계씩 진행하세요.

설정은 불러올 수 있지만 요청이 로그에 전혀 나타나지 않는다면 먼저 앱 프록시와 트래픽 처리 진입점을 확인하세요. 요청은 기록되지만 잘못된 정책을 사용한다면 규칙 순서와 그룹 선택을 점검합니다. 정책은 맞는데 연결되지 않는다면 노드와 DNS를 확인하세요. 로그의 오류 발생 시간도 중요합니다. 이전 기록이 이번 수정의 실패를 뜻하지는 않습니다. 설정을 다시 불러온 뒤 시간을 확인하고 새 테스트 요청을 보내 해당 요청의 기록을 살펴보세요. 노드를 여러 번 바꾼 다음 한꺼번에 로그를 확인하는 것보다 원인을 파악하기 쉽습니다.

시스템 절전, 네트워크 전환, 클라이언트 비정상 종료 이후에는 시스템 프록시 설정이 남았는지, 가상 네트워크 어댑터가 복구되었는지, 이전 커널이 포트를 계속 사용 중인지도 확인해야 합니다. 다른 클라이언트로 전환하기 전에 기존 인스턴스를 종료해 두 프로그램이 동시에 트래픽을 처리하지 않도록 하세요. 플랫폼 설치와 권한 문제를 설정 항목에서 반복해서 수정하려 하지 마세요. 다시 설치해야 한다면 클라이언트 다운로드 페이지로 이동하고, 처음부터 연결을 복구하려면 빠른 시작 안내를 다시 따라가세요.

재현 가능한 복구 기록 남기기

수정을 마친 뒤에는 수정 전 설정 사본, 변경 목적, 검증 결과만 남겨도 충분합니다. 이전 캐시를 전부 복사할 필요는 없습니다. 문제가 발생하면 가장 최근 변경을 되돌려 복구되는지 확인한 다음 항목별로 다시 적용하세요. 문제 해결 정보를 공유할 때는 사용한 클라이언트, 커널 종류, 트래픽 처리 방식, 오류가 발생한 단계, 민감한 정보를 삭제한 관련 설정을 제공하세요. 전체 구독을 공개하지 마세요. 어떤 요청이 어떤 규칙에 일치했고 어느 단계에서 실패했는지 설명하면 단순히 인터넷이 안 된다고 하는 것보다 원인을 찾기 쉽습니다.