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

01 YAML 구조와 참조 관계

Clash 설정은 순서대로 실행되는 명령어가 아니라 네트워크 동작을 정의하는 데이터입니다. 파일 최상위에는 보통 수신 포트, 실행 모드, DNS 설정, 노드 목록, 프록시 그룹, 규칙을 함께 둡니다. 커널은 파일을 읽은 뒤 각 객체를 구성하고, 연결에 일치하는 규칙에 따라 출구를 선택합니다. 따라서 파일이 저장되었다고 노드 연결까지 성공한 것은 아니며, 문법이 올바르더라도 모든 이름의 참조가 유효하다는 보장은 없습니다.

들여쓰기로 필드의 계층을 구분합니다

YAML은 공백 들여쓰기로 계층을 표현합니다. 두 칸으로 통일하고 탭은 사용하지 않는 것이 좋습니다. 콜론 뒤에 일반 값을 쓸 때는 공백을 하나 두고, 목록 항목은 하이픈 뒤에 공백을 넣어 시작합니다. 같은 계층의 필드는 들여쓰기를 맞춰야 합니다. 편집기에서 한 칸만 어긋나 보여도 최상위 규칙 목록이 DNS 객체 안에 들어가 필드가 무시되거나 유형 오류가 날 수 있습니다. 눈으로 추측하기보다 공백 표시 기능을 켜서 확인하세요.

# 단독으로 불러올 수 있는 최소 직접 연결 설정이며 프록시 노드는 포함하지 않습니다
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

위 예제는 설정이 정상적으로 로드되는지 확인하는 용도입니다. 모든 연결이 직접 연결되므로 프록시 출구는 사용하지 않습니다. 빈 목록은 []로 작성하며, 항목이 없다는 뜻이지 필드 자체가 빠졌다는 뜻은 아닙니다. 편집기나 디렉터리 권한 문제를 확인 중이라면 먼저 이 최소 파일로 로드 과정을 점검한 뒤 노드와 프록시 그룹을 하나씩 추가하세요. 처음부터 전체 구독과 외부 규칙, 오버라이드 스크립트를 한꺼번에 연결하지 마세요.

문자열, 불리언, 목록

불리언은 true 또는 false로, 포트는 정수로 작성하세요. 노드 이름과 규칙 문자열은 필요에 따라 따옴표로 감싸면 됩니다. 이름에 콜론, 샵(#) 또는 특수 문자가 포함되면 특히 주의해야 합니다. 샵은 주석으로 인식될 수 있고, 콜론 뒤에 공백이 오면 매핑 구분자로 처리될 수 있습니다. 숫자로만 된 비밀번호도 문자열로 유지되도록 따옴표로 감싸는 것이 좋습니다.

여러 줄 형식은 읽기 쉽고, 중괄호를 사용하는 한 줄 매핑은 더 간결하지만 둘 다 같은 객체를 표현할 수 있습니다. 이 페이지에서는 필드의 소속을 한눈에 파악할 수 있도록 여러 줄 형식을 우선합니다. YAML 바깥을 Markdown 코드 펜스로 한 번 더 감싸지 마세요. 웹페이지의 예제 표시용 마크업은 설정 내용이 아닙니다. 복사할 때는 코드 본문만 가져오고, 파일은 서식 있는 문서가 아닌 일반 텍스트로 저장하세요.

이름이 참조를 이어 줍니다

노드의 name은 프록시 그룹에서 참조하고, 프록시 그룹의 name은 다시 규칙에서 참조합니다. 참조할 때는 이름 전체가 일치해야 하므로 공백, 대소문자, 문장 부호를 그대로 유지하세요. 프록시 그룹 이름을 바꾼 뒤 규칙의 대상 이름을 수정하지 않으면 로드 과정에서 프록시를 찾을 수 없다는 오류가 날 수 있습니다. 이런 오류는 규칙 대상에서 거슬러 올라가며 확인하세요. 같은 이름의 프록시 그룹을 찾은 다음 그룹에 포함된 항목이 모두 존재하는지 점검합니다.

최상위에 같은 키를 중복해서 쓰지 마세요. rules를 두 번 적어도 자동으로 합쳐지지 않고, dns를 두 번 적어도 자동 병합되지 않습니다. 파서에 따라 중복 키를 거부하거나 한 항목만 남길 수 있습니다. 규칙을 추가하려면 기존 목록을 수정하고, 구독 구조를 유지해야 한다면 클라이언트가 명시적으로 지원하는 오버라이드 기능을 사용하세요. YAML 자체는 여러 내용을 이어 붙이려는 의도를 알아서 처리하지 않습니다.

구독을 다룰 때는 원본과 실행 설정을 구분해야 합니다. 구독을 다운로드한 뒤 클라이언트가 포트 오버라이드, DNS 오버라이드 또는 규칙 병합을 추가로 적용할 수 있습니다. Profiles의 원본 파일을 수정해도 반영되지 않는다면 커널이 읽지 않은 것이 아니라 뒤 단계의 설정이 다시 덮어썼을 수 있습니다. 먼저 현재 활성 설정의 이름과 출처를 기록하고, 이후에는 실제 실행 설정과 로그를 기준으로 변경 결과를 확인하세요.

02 포트, 모드 및 접근 범위

포트 필드는 원격 서버가 아니라 클라이언트가 이 컴퓨터에서 연결을 받는 위치를 지정합니다. 브라우저나 명령줄 프로그램이 이 진입점으로 요청을 보내야 커널이 규칙에 따라 트래픽을 분류할 수 있습니다. 포트를 바꿔도 이전 포트를 사용하던 프로그램의 설정이 자동으로 모두 변경되지는 않습니다. Windows 시스템 프록시, 별도 브라우저 설정, 터미널 환경 변수에 주소가 각각 저장될 수 있으므로 하나씩 확인하세요.

별도 수신 포트와 통합 수신 포트

필드	용도	헷갈리기 쉬운 점
`port`	HTTP 프록시 진입점	CONNECT 터널을 지원한다고 해서 HTTP 웹사이트만 이용할 수 있다는 뜻은 아닙니다.
`socks-port`	SOCKS 프록시 진입점	애플리케이션이 SOCKS를 지원해야 합니다. 포트가 같다는 이유만으로 HTTP 프록시처럼 사용하면 안 됩니다.
`mixed-port`	HTTP와 SOCKS가 함께 사용하는 진입점	진입점에서 프로토콜을 판별하더라도 애플리케이션에는 올바른 프록시 유형을 지정해야 합니다.
`allow-lan`	로컬 네트워크 접근 허용 여부	수신 주소와 운영체제 방화벽 설정에도 영향을 받습니다.

# 로컬 컴퓨터에서 사용하는 공통 필드 예제
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

로컬 네트워크에서 공유할 필요가 없다면 로컬에서만 접근하도록 설정하면 됩니다. 위 예제의 수신 주소와 접근 옵션은 로컬 사용에 맞춰져 있습니다. 휴대폰이나 다른 컴퓨터에서도 사용하려면 Allow LAN만 켜서는 안 됩니다. 해당 네트워크 인터페이스를 포함하는 수신 주소를 지정하고, 방화벽에서 신뢰할 수 있는 네트워크의 접근을 허용해야 합니다. 다른 기기에는 자기 자신의 루프백 주소가 아니라 이 컴퓨터의 로컬 네트워크 주소를 입력하세요.

수신 실패는 포트가 이미 사용 중일 때 자주 발생합니다. 클라이언트가 중복 실행 중이라면 먼저 종료한 뒤 포트를 점유한 프로세스를 확인하세요. 여러 포트를 계속 바꾸면서 애플리케이션 설정을 동기화하지 못하는 상황은 피해야 합니다. Windows 터미널에서 아래 명령을 실행하면 해당 포트의 수신 항목과 프로세스 번호를 확인할 수 있습니다. 이 명령은 점유 프로세스를 찾는 용도입니다. 번호가 보인다고 바로 프로세스를 종료하지 말고, 먼저 작업 관리자에서 프로그램 이름과 용도를 확인하세요.

netstat -ano | findstr :7890

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

mode: rule은 규칙 순서에 따라 출구를 결정하며 일상적인 트래픽 분류에 적합합니다. 전역 모드는 연결을 전역 정책에 맡기지만, 트래픽이 먼저 커널에 들어와야 합니다. 직접 연결 모드는 이미 커널이 처리하는 연결을 대상에 직접 보냅니다. 모드는 시스템 전체의 트래픽을 가로채는 스위치가 아닙니다. 규칙 모드에서 전역 모드로 바꿔도 시스템 프록시를 전혀 사용하지 않는 프로그램이 갑자기 프록시를 이용하지는 않습니다.

General의 System Proxy는 클라이언트가 Windows 시스템 프록시를 설정하는 기능이며 YAML의 실행 모드와는 별개입니다. 일반적으로 시스템 프록시를 따르는 프로그램에 영향을 줍니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 가로채며, 이를 위해 커널과 권한, 서비스 지원이 필요합니다. 구형 Clash for Windows의 Service Mode와 TUN Mode를 현재 Mihomo 클라이언트의 기능과 같은 버튼 위치나 방식으로 이해해서는 안 됩니다.

로그와 제어 인터페이스를 혼동하지 마세요

log-level은 일상적인 사용이라면 info면 충분하고, 문제를 조사할 때는 잠시 debug로 높일 수 있습니다. 디버그 로그에는 대상 도메인, 연결 정보, 설정 파일 경로가 포함될 수 있으므로 공유하기 전에 구독 주소와 인증 정보, 개인 접속 기록을 삭제하세요. 로그가 많다고 원인을 더 빨리 찾는 것은 아닙니다. 문제를 한 번 재현한 뒤 모든 출력을 오래 수집하기보다 시간순으로 해당 연결을 찾는 편이 효과적입니다.

외부 제어 인터페이스는 클라이언트 UI나 대시보드에서 커널을 관리하는 용도이며, 애플리케이션의 인터넷 접속을 위한 프록시 진입점이 아닙니다. external-controller를 설정해야 한다면 먼저 루프백 주소에 바인딩하세요. 원격 접근이 꼭 필요하다면 별도의 인증과 접근 제한을 마련해야 합니다. 제어 인터페이스 포트를 브라우저 프록시 설정에 입력하지 말고, 로컬 네트워크 기기를 연결하려고 관리 인터페이스까지 네트워크 전체에 공개하지 마세요.

최상위의 ipv6와 DNS 모듈의 IPv6 옵션은 적용 범위가 다릅니다. 한 필드를 꺼도 시스템 네트워크 어댑터에서 IPv6가 비활성화되는 것은 아니며, 모든 애플리케이션의 조회 경로가 바뀌는 것도 아닙니다. 특정 네트워크에서만 일부 대상에 연결할 수 없다면 시스템 주소, DNS 응답, 규칙 일치 여부, 출구 연결을 확인하세요. 모든 문제를 포트나 프록시 스위치 하나의 탓으로 돌리지 마세요.

이 장의 필드를 변경한 뒤에는 먼저 커널이 정상적으로 수신 중인지 확인하고, 애플리케이션의 프록시 주소를 점검한 다음 모드와 출구를 검증하세요. 이 순서대로 확인하면 진입점에 접근할 수 없는 문제와 원격 연결 실패를 구분할 수 있습니다. 관련 설정 방법은 시스템 프록시 사용 안내를 참고하세요. 클라이언트를 종료한 뒤에도 인터넷이 연결되지 않는다면 FAQ에서 시스템 프록시 설정이 남았을 때의 해결 방법을 확인할 수 있습니다.

03 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"
    - "localhost"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enable은 커널의 DNS 모듈을 활성화하고, listen은 서비스 수신 주소를 지정합니다. 위 예제는 루프백 주소와 특권 포트가 아닌 포트를 사용해 테스트하기 편하지만, Windows의 모든 DNS 요청을 자동으로 변경하지는 않습니다. 일반적으로 시스템 네트워크 어댑터의 DNS 설정에는 서버 주소만 입력할 수 있으므로 이 사용자 지정 포트가 포함된 문자열을 그대로 지정할 수 없습니다. DNS 요청을 완전히 가로채려면 클라이언트 또는 TUN 설정도 필요합니다.

nameserver는 조회에 사용할 상류 서버 목록이며, 단순히 주 서버와 보조 서버의 엄격한 순서라고 볼 수는 없습니다. 동시 조회, 캐시, 서버 선택 방식은 커널마다 다를 수 있습니다. 서버를 여러 개 등록했더라도 실패 원인이 반드시 첫 번째 서버에 있는 것은 아닙니다. 테스트할 때는 변수를 줄이세요. 현재 네트워크에서 접근 가능한 서버 하나로 기본 기능을 확인한 다음 암호화된 DNS나 도메인별 분기 설정을 추가하세요.

Fake IP와 실제 주소

Fake IP 모드에서는 먼저 애플리케이션에 매핑된 주소를 반환하고, 커널이 주소와 도메인의 대응 관계를 보관했다가 연결이 들어오면 도메인 기준으로 처리합니다. 도메인 정보를 유지하는 데 유리하지만 DNS 조회와 연결이 같은 트래픽 가로채기 경로를 따라야 합니다. 애플리케이션이 매핑 주소를 받은 뒤 커널을 거치지 않고 직접 연결하면 접속에 실패할 수 있습니다. 클라이언트를 종료한 뒤에도 이전 캐시가 남아 일시적으로 접속이 안 될 수도 있습니다.

fake-ip-filter는 일부 도메인에 매핑 주소 대신 실제 주소를 반환하도록 합니다. 로컬 네트워크 검색, 일부 기기 서비스 또는 실제 주소가 필요한 프로그램에는 예외가 필요할 수 있지만, 목록이 길수록 좋은 것은 아닙니다. 자주 쓰는 도메인을 모두 제외하면 예상한 조회 경로가 달라집니다. 재현된 문제에 필요한 최소한의 예외만 추가하고, 변경 후에는 해당 애플리케이션의 캐시를 지운 다음 결과를 확인하세요.

Redir Host는 일반적으로 실제 주소를 반환하며 매핑 주소를 사용할 수 없는 일부 환경에 적합합니다. 그렇다고 모든 애플리케이션의 호환성 문제가 해결되는 것은 아닙니다. 도메인 정보를 온전히 유지할 수 있는지, 시스템에서 먼저 조회하는지, 대상 주소가 바뀌는지에 따라 규칙 동작도 달라집니다. 모드를 선택할 때는 두 방식의 속도를 일렬로 비교하기보다 현재 애플리케이션과 트래픽 가로채기 방식에 맞춰 테스트하세요.

Mihomo의 도메인별 DNS 조회 정책

# Mihomo 부분 예제: 기존 dns 객체에 추가하고 두 번째 dns 객체를 만들지 마세요
dns:
  nameserver-policy:
    "+.example.com":
      - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

nameserver-policy는 지정한 도메인의 조회에 사용할 DNS 서버를 설정합니다. 이 예제는 필드 계층을 보여 주기 위한 것으로, 문서용 예약 도메인을 특별 처리해야 한다는 뜻은 아닙니다. Mihomo의 proxy-server-nameserver는 프록시 서버 도메인을 조회할 때 사용합니다. 두 필드의 대상은 서로 다릅니다. 웹사이트 도메인과 노드 서버 도메인은 둘 다 도메인이라고 해서 같은 조회 단계로 처리되는 것은 아닙니다.

노드 서버를 도메인으로 지정하면 연결을 시작할 때부터 DNS 조회가 필요할 수 있습니다. 노드 도메인을 조회하는 데 해당 노드가 먼저 필요하다면 시작 과정에서 의존성 순환이 생깁니다. 문제를 조사할 때는 웹사이트 조회를 프록시로 보낼지 논의하기 전에, 노드 서버 도메인이 독립적으로 사용 가능한 경로를 통해 조회되는지 확인하세요. 암호화 DNS 서버를 도메인으로 지정한 경우에도 초기 조회와 연결 경로를 확인해야 합니다. 주소 하나만 바꾸면 순환이 해결된다고 가정하지 마세요.

DNS 누출 테스트는 특정 테스트 조건에서 관찰한 조회 출구를 보여 줄 뿐, 모든 트래픽에 적용되는 단일한 결론은 아닙니다. 브라우저의 보안 DNS, 애플리케이션 자체 DoH, 시스템 캐시, 로컬 네트워크 DNS가 예상한 경로를 우회할 수 있습니다. 검증할 때는 브라우저 설정, 커널 DNS 로그, TUN 가로채기 상태를 각각 확인하세요. 웹페이지에서 한 번 테스트하는 것으로 실제 조회 경로를 확인했다고 볼 수는 없습니다.

04 프록시 노드 필드와 프로토콜 범위

proxies 목록에는 실제 프록시 출구의 연결 정보가 저장됩니다. 각 항목에는 프로토콜, 서버 주소, 포트가 필요하며 인증 필드는 프로토콜에 따라 달라집니다. 클라이언트에 표시되는 노드 이름은 로컬 식별자일 뿐 인증 정보를 대신하지 않습니다. 기억하기 쉬운 이름으로 바꿔도 서버 위치는 달라지지 않으며, 서버에서 지원하지 않는 프로토콜 기능이 추가되지도 않습니다.

먼저 주소를 확인한 다음 인증 정보를 확인하세요

# 예제용 노드이며 예약 도메인과 가짜 비밀번호로는 실제 연결할 수 없습니다
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

server에는 호스트 이름이나 IP 주소를 입력하세요. 프로토콜 접두사와 경로, 쿼리 매개변수가 포함된 전체 웹 주소를 넣으면 안 됩니다. port는 서버에서 수신하는 포트로, 로컬의 mixed-port와 같은 값일 필요가 없습니다. 서비스 제공자가 안내한 값을 사용하세요. 웹에서 흔히 쓰는 포트라고 해서 모든 노드의 포트를 같은 값으로 바꾸면 안 됩니다.

Shadowsocks의 cipher와 password는 서버 설정과 일치해야 합니다. 암호화 방식은 임의로 선택할 수 있는 성능 옵션이 아닙니다. 이름을 잘못 입력하거나 커널에서 지원하지 않으면 연결에 실패합니다. 프로토콜 버전에 따라 키 형식도 달라질 수 있으므로 프로토콜 이름만 바꾸고 나머지 필드를 그대로 두면 안 됩니다. 구독에 정상 작동하는 노드가 있다면 원래 매개변수를 유지하고, 이해하지 못하는 필드를 추측으로 삭제하지 마세요.

TLS, SNI 및 인증서 검증

TLS 노드에는 일반적으로 서버 이름, 인증서, 전송 계층 매개변수도 설정해야 합니다. SNI는 TLS 핸드셰이크에서 서버 이름을 전달하는 기능이며, 직접 연결할 때 입력하는 IP와 다를 수 있습니다. 서버에 실제로 배포된 설정을 기준으로 하세요. 인증서 오류가 비밀번호 오류를 뜻하는 것은 아닙니다. 시스템 시간 차이, 이름 불일치, 중간 네트워크 간섭 때문일 수도 있습니다. 로그에 표시된 오류 유형을 먼저 확인하고 해당 필드를 점검하세요.

skip-cert-verify: false는 인증서 검증을 유지한다는 뜻입니다. 핸드셰이크가 실패한다고 검증을 끄는 것을 일반적인 해결책으로 삼지 마세요. 서버 이름이나 인증서 설정의 문제를 가릴 수 있습니다. 먼저 시스템 시간을 맞춘 다음 SNI와 서비스 제공자의 안내를 확인하세요. 구독의 노드 다수에서 갑자기 인증서 오류가 발생한다면 잘못된 파일을 불러왔는지, 인증이 필요한 네트워크를 거치는지도 확인해야 합니다.

VMess, VLESS, Trojan, Shadowsocks 등은 인증 필드가 서로 다릅니다. 사용자 식별자가 필요한 프로토콜도 있고, 비밀번호가 필요한 프로토콜도 있으며, 전송 방식이나 보안 매개변수까지 요구하는 경우도 있습니다. 이 페이지에서는 모든 필드를 섞은 만능 노드 설정을 제공하지 않습니다. 불필요한 필드가 무시되면 문제가 해결된 것처럼 오해할 수 있습니다. 프로토콜에 맞는 완전한 노드 정의를 사용하세요.

전송 기능은 양쪽 모두 지원해야 합니다

udp: true는 해당 노드에서 UDP를 허용하려는 설정일 뿐입니다. 실제 전송 가능 여부는 프로토콜, 서버, 네트워크, 진입점의 트래픽 가로채기 방식에 달려 있습니다. 일반적인 시스템 프록시의 HTTP 진입점은 모든 애플리케이션의 UDP를 자동으로 가로채지 않습니다. 게임이나 음성 앱이 작동하지 않는다면 YAML에서 이 값을 반복해서 바꾸기보다 먼저 트래픽이 커널에 들어오는지 확인한 뒤 노드의 UDP 지원 여부를 점검하세요.

WebSocket, gRPC 또는 다른 전송 계층을 사용할 때는 경로, 호스트 헤더, 서비스 이름이 서버 설정과 일치해야 합니다. 웹페이지가 열린다고 프록시 서비스의 핸드셰이크 매개변수까지 올바른 것은 아닙니다. 서버 포트에 TCP 연결이 된다고 프로토콜 인증에 성공한 것도 아닙니다. 로그의 연결 시간 초과, 인증 실패, 핸드셰이크 중단은 각각 다른 단계를 가리킵니다. 매개변수를 모두 바꾸기보다 단계별로 확인하면 원인을 찾기 쉽습니다.

새 프로토콜이나 확장 필드는 현재 커널에서 지원해야 합니다. 구형 Clash for Windows 커널은 Mihomo 설정을 몇 줄 추가한다고 기능이 생기지 않습니다. 이전하기 전에 Clash Plus, Clash Verge Rev, FlClash 등 클라이언트별 실제 지원 범위를 비교해 보세요. 자세한 내용은 클라이언트 비교에서 확인할 수 있습니다. UI에서 파일을 가져올 수 있어도 실행 커널이 모든 노드 형식을 받아들인다는 보장은 없습니다.

노드 이름은 중복되지 않도록 하세요. 이름이 같은 노드가 둘이면 참조 결과가 모호해질 수 있고 구독 갱신으로 이름이나 순서가 바뀔 수도 있습니다. 직접 관리할 때는 용도를 알아볼 수 있는 이름을 사용하고, 비밀번호와 전체 구독 주소, 개인 계정 정보는 넣지 마세요. 문제를 공유하기 전에 인증 값과 비공개 서버 정보를 삭제하세요. 필드 구조와 오류 메시지만 남겨도 형식 문제인지 프로토콜 지원 범위 문제인지 판단하는 데 충분한 경우가 많습니다.

05 프록시 그룹 선택과 상태 확인

프록시 그룹은 규칙과 노드 사이에 있습니다. 규칙은 변경되지 않는 그룹 이름으로 연결을 전달하고, 그룹은 사용할 출구를 선택합니다. 덕분에 노드를 바꿔도 모든 규칙을 다시 작성할 필요가 없습니다. 이 간접 참조를 이해한 뒤 그룹을 설계하세요. 하나는 수동 선택용, 하나는 자동 검사용으로 두고 특정 업무에는 별도 그룹을 만들 수 있습니다. 모든 웹사이트마다 같은 구성원을 복제한 그룹을 만들 필요는 없습니다.

수동 선택과 자동 선택을 구분하세요

# 앞 장에서 정의한 예제 노드 두 개를 사용합니다
proxy-groups:
  - name: "프록시 선택"
    type: select
    proxies:
      - "자동 선택"
      - "예제 SS"
      - "예제 Trojan"
      - DIRECT

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

select는 수동 선택 그룹으로, 보통 클라이언트 UI에서 구성원을 직접 바꿀 수 있습니다. 구성원에는 노드뿐 아니라 다른 프록시 그룹이나 DIRECT 같은 기본 출구도 포함할 수 있습니다. 위 예제에서는 자동 그룹을 선택 가능한 구성원으로 추가했으므로 평소에는 자동 검사 결과를 사용하고 필요할 때 특정 노드로 고정할 수 있습니다. 이름은 예시이므로 변경할 때 규칙의 참조도 함께 수정하세요.

url-test는 테스트 요청으로 후보 출구를 비교합니다. interval은 검사 간격으로 보통 초 단위를 사용하며, tolerance는 작은 차이로 인해 자주 전환되는 것을 줄이는 값입니다. 의미와 단위는 사용 중인 커널의 문서를 확인하세요. 일반적인 구현에서 위 예제의 허용 오차는 밀리초 단위입니다. UI가 계속 새로 고쳐지게 하려고 검사 간격을 지나치게 짧게 설정하지 마세요. 상태 확인도 연결과 트래픽을 발생시킵니다.

검사 성공이 실제 서비스 사용을 보장하지는 않습니다

테스트 주소에서 성공 응답을 받았다면 해당 출구를 통해 그 주소에 보낸 요청이 그 시점에 완료되었다는 뜻입니다. 동영상, 다운로드, 게임, 업무 시스템도 똑같이 작동한다는 뜻은 아닙니다. 지연 시간에는 연결 수립과 핸드셰이크, 응답 시간이 반영될 수 있지만 지속적인 대역폭을 직접 나타내지는 않습니다. 테스트에서 빠른 노드라도 혼잡, 패킷 손실, 대상 사이트의 제한으로 실제 서비스에서는 성능이 좋지 않을 수 있습니다.

따라서 안정적이고 예상한 응답을 정확히 반환하는 주소를 테스트 대상으로 선택한 뒤 실제 용도에 맞춰 검증하세요. 모든 노드의 검사에 동시에 실패한다면 서버가 전부 고장 났다고 단정하기 전에 테스트 대상에 접근할 수 있는지, DNS 조회에 문제가 없는지 확인하세요. 측정값과 실제 체감의 차이는 노드 지연 시간 측정 원리를 참고하세요.

장애 전환과 부하 분산

fallback은 보통 후보 순서에 따라 사용 가능한 출구를 선택하므로 주 회선과 예비 회선을 구성할 때 적합합니다. 지연 시간이 가장 낮은 출구를 자동 선택하는 또 다른 이름이 아닙니다. load-balance는 구현에서 지원하는 정책에 따라 연결을 분산하며, 여러 노드의 대역폭을 합쳐 하나의 연결 속도를 높이지는 않습니다. 로그인 세션이나 출구 주소에 민감한 사이트에서는 분산 방식이 세션 안정성에 영향을 주는지도 확인하세요.

프록시 그룹은 참조 방향이 명확하게 유지되도록 중첩해야 합니다. “업무” 그룹이 “프록시 선택”을 참조하고, “프록시 선택”이 실제 노드를 참조하도록 구성할 수 있습니다. 두 그룹이 서로를 참조해 순환이 생기게 해서는 안 됩니다. 그룹을 찾을 수 없거나 순환 의존성 오류가 나면 규칙에서 노드까지 이어지는 단방향 경로를 그려 간접 참조를 하나씩 펼쳐 보세요. 그룹이 많을수록 점검이 복잡해지므로 처음에는 용도가 분명한 소수의 그룹만 구성하는 것이 좋습니다.

자동 검사 그룹에 DIRECT를 포함할지는 용도에 따라 결정하세요. 직접 연결도 테스트에 성공해 선택될 수 있지만, 이 경우 프록시 출구를 거치지 않습니다. 특정 그룹의 목적이 반드시 프록시를 사용하는 것이라면 직접 연결의 검사 수치가 낮다는 이유만으로 후보에 넣지 마세요. 검사 간격을 미세 조정하는 것보다 후보 범위를 어떻게 정하느냐가 최종 동작에 더 큰 영향을 줍니다.

클라이언트는 프록시 그룹의 선택 결과를 기억할 수 있으므로 다시 로드해도 목록의 첫 번째 항목으로 돌아간다는 보장은 없습니다. 규칙은 올바르게 적용되는데 예상과 다른 출구를 사용한다면 그룹에서 실제로 선택된 항목을 펼쳐 확인하고, 중첩 구조를 따라 최종 노드까지 점검하세요. 가장 바깥 그룹의 이름만으로는 현재 연결 경로를 알 수 없습니다. 구독을 바꾼 뒤 같은 이름의 그룹 선택이 복원되는지도 클라이언트의 저장 설정에 따라 확인해야 합니다.

프로바이더로 노드를 가져오는 경우 프록시 그룹에서 use를 사용해 노드 집합을 참조할 수도 있습니다. 자세한 구조는 7장에서 다룹니다. 이때 노드 상태 검사와 그룹 내부 검사가 동시에 실행될 수 있으므로 같은 검사를 지나치게 자주 반복하지 마세요. 그룹 구조를 변경한 뒤에는 설정을 로드할 수 있는지 확인하고 UI에서 한 번 직접 전환한 다음 새 연결의 실제 출구를 점검해 참조 대상이 예상과 일치하는지 확인하세요.

06 규칙 문법과 일치 순서

규칙 모드에서는 일반적으로 위에서 아래로 규칙을 확인하고, 연결이 일치하는 규칙을 만나면 지정된 프록시 정책으로 전달합니다. 구체적인 예외를 앞에, 범위가 넓은 규칙을 뒤에 두고 마지막에 기본 규칙을 배치하세요. 규칙 목록은 가장 구체적인 항목을 자동으로 찾아 주는 라우팅 테이블이 아닙니다. 앞쪽의 넓은 규칙이 먼저 일치하면 뒤쪽의 세부 규칙은 해당 연결을 처리할 기회를 얻지 못할 수 있습니다.

명확한 예외를 먼저 쓰고 기본 규칙은 마지막에 두세요

# 기존 "프록시 선택" 프록시 그룹을 참조합니다
rules:
  - DOMAIN,portal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,프록시 선택
  - DOMAIN-KEYWORD,example,프록시 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,프록시 선택

DOMAIN은 지정한 도메인과 정확히 일치하는지 확인하고, DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 일치합니다. DOMAIN-KEYWORD는 도메인에 키워드가 포함되어 있는지 확인합니다. 키워드 규칙은 예상보다 범위가 넓어 이름만 비슷하고 용도가 전혀 다른 서비스까지 함께 일치시킬 수 있습니다. 대상 도메인을 알고 있다면 몇 줄을 줄이기 위해 설명 가능성을 포기하기보다 정확 일치나 접미사 규칙을 우선 사용하세요.

예제에서는 포털 도메인의 직접 연결 예외를 도메인 접미사 규칙보다 앞에 두었습니다. 따라서 포털에 접속하면 프록시 선택 규칙에 걸리지 않습니다. 두 규칙의 순서를 바꾸면 접미사 규칙이 먼저 요청을 처리해 예외가 적용되지 않습니다. 규칙을 작성했는데 효과가 없다면 목록 아래에 같은 규칙을 계속 추가하기보다 위쪽에 먼저 일치하는 규칙이 있는지 확인하세요.

도메인 규칙과 IP 주소 규칙

IP-CIDR은 대상 주소가 지정한 네트워크 범위에 포함되는지 확인합니다. 끝에 붙는 no-resolve는 이 주소 규칙을 적용하기 위해 도메인을 IP로 먼저 조회하지 말라는 뜻입니다. 연결에 대상 주소가 이미 있다면 주소 일치는 여전히 가능할 수 있습니다. 모든 DNS를 끄는 스위치도 아니고 도메인 규칙을 비활성화하지도 않습니다. 로컬 네트워크 주소에 예외를 설정할 때 불필요한 조회를 줄이기 위해 자주 사용합니다.

GEOIP는 주소 데이터베이스를 기준으로 대상 IP의 지역을 판별합니다. 도메인 등록 국가, 웹페이지 언어, 서비스 회사의 소재지를 기준으로 하는 것은 아닙니다. 여러 지역의 CDN을 사용하는 사이트는 같은 도메인이라도 서로 다른 지역의 IP를 반환할 수 있습니다. 특정 업무에 명확한 경로가 필요하다면 지리 정보 데이터베이스가 서비스 분류를 항상 대신해 줄 것이라고 기대하기보다 도메인 규칙을 사용하세요.

MATCH는 최종 기본 규칙이므로 보통 목록의 마지막에 둬야 합니다. 앞선 규칙에 걸리지 않은 연결에도 출구를 지정할 수 있습니다. 중간에 기본 규칙을 두면 뒤에 있는 규칙은 일반적으로 적용되지 않습니다. 기본 출구로 프록시와 직접 연결 중 무엇을 선택할지는 사용 목적에 따라 다릅니다. 예제에서는 “프록시 선택”을 사용하지만 모든 네트워크 환경에 같은 기본값이 적합하다는 뜻은 아닙니다.

새 연결에서 규칙 적용 여부를 확인하세요

규칙을 변경해도 이미 연결된 장시간 연결은 기존 출구를 계속 사용할 수 있고, 웹페이지가 연결이나 리소스 캐시를 재사용할 수도 있습니다. 검증할 때 새 요청을 보내고, 필요하다면 기존 연결을 닫은 뒤 Connections나 로그에서 적용된 규칙과 프록시 그룹, 최종 출구를 확인하세요. 페이지를 한 번 새로 고친 뒤 느낌만으로 규칙이 작동하지 않는다고 판단하지 마세요. 그룹 이름만 보지 말고 그룹에서 현재 선택된 노드도 확인하세요.

프로세스 규칙은 운영체제와 커널이 프로세스를 식별할 수 있어야 적용됩니다. Windows에서는 권한, 트래픽 가로채기 방식, 애플리케이션 구조의 영향을 받을 수 있습니다. 브라우저 하위 프로세스나 시스템 서비스 때문에 표시되는 이름이 예상과 다를 수도 있습니다. 사용하기 전에 연결 기록에서 실제 프로세스 정보를 확인한 뒤 현재 커널이 지원하는 문법으로 작성하세요. 여러 운영체제에서 공유하는 설정은 로컬 경로를 고정하기보다 도메인 규칙을 사용하는 편이 관리하기 쉽습니다.

규칙이 많아지면 먼저 업무별로 정리한 뒤 외부 규칙 집합으로 관리할지 검토하세요. 로컬 네트워크 예외, 특정 서비스 예외, 일반 분류, 최종 기본 규칙의 범위를 각각 명확하게 유지해야 합니다. 완전해 보이게 하려고 출처를 알 수 없는 규칙을 여러 개 이어 붙이지 마세요. 목록이 길어진다고 더 정확하게 적용되는 것은 아니며, 충돌과 중복 때문에 연결을 설명하기 어려워질 수 있습니다.

특정 애플리케이션에서만 규칙이 작동하지 않는다면 트래픽 진입점도 확인해야 합니다. 연결이 커널에 들어오지 않으면 규칙이 아무리 정확해도 처리에 참여할 수 없습니다. 애플리케이션이 도메인을 먼저 주소로 변환하면 도메인 일치 기능에 영향을 줄 수도 있습니다. 모호한 규칙을 더 추가하기보다 진입점, 조회, 일치, 출구를 각각 나눠 확인하면 원인을 더 빨리 찾을 수 있습니다.

07 구독 노드와 외부 규칙 집합

프로바이더를 사용하면 자주 바뀌는 내용을 기본 설정에서 분리할 수 있습니다. 노드 프로바이더는 노드 집합을, 규칙 프로바이더는 일치 조건 집합을 관리하며 기본 설정에는 참조와 정책 관계만 남깁니다. 노드를 갱신할 때 로컬 업무 그룹을 다시 작성할 필요가 없고, 규칙을 갱신할 때 전체 설정을 다시 다운로드하지 않아도 됩니다. 대신 다운로드, 파싱, 캐시, 참조 단계에 의존성이 추가되므로 기본 설정이 로드되었다는 이유만으로 모든 내용이 사용 가능하다고 판단해서는 안 됩니다.

전체 구독과 노드 프로바이더는 서로 다릅니다

# 로컬 노드 프로바이더 예제이며 먼저 해당 파일을 만들어야 합니다
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "구독 선택"
    type: select
    use:
      - local-nodes

위 예제에서는 개인 구독 주소가 문서에 노출되지 않도록 로컬 파일을 사용합니다. 해당 파일은 현재 커널에서 읽을 수 있어야 하며 노드 프로바이더에 필요한 데이터 구조를 포함해야 합니다. 상대 경로는 보통 설정을 불러온 디렉터리나 작업 디렉터리를 기준으로 하지만, 클라이언트가 자체 작업 디렉터리를 지정할 수도 있습니다. 로그와 파일 관리 화면에서 실제 위치를 확인하세요. 기본 설정 파일이 디스크에 있는 위치만 보고 추측하면 안 됩니다.

# providers/local-nodes.yaml의 내용 예제
proxies:
  - name: "로컬 예제 SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

전체 구독에는 포트, DNS, 프록시 그룹, 규칙이 들어 있을 수 있지만 노드 프로바이더에는 보통 노드 집합만 필요합니다. 아무 구독 링크나 proxy-providers에 그대로 넣으면 커널이 알아서 처리한다고 가정하지 마세요. 서비스에서 제공하는 형식과 현재 커널의 지원 여부를 먼저 확인한 뒤 전체 설정으로 가져올지 노드 집합으로 참조할지 결정하세요. 형식이 맞지 않으면 기본 설정에서 오류가 나지 않고 프로바이더가 비어 있는 것으로 나타날 수도 있습니다.

규칙 프로바이더는 규칙 유형별로 구성하세요

# Mihomo 로컬 규칙 프로바이더 예제
rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,구독 선택

# rules/local-direct.yaml의 내용 예제
payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

이 규칙 파일은 payload 아래에 규칙 항목을 넣으며, 실제 출구는 기본 설정의 RULE-SET에서 지정합니다. 일반 rules 목록을 그대로 넣거나 각 항목에 프록시 그룹을 반복해서 추가하지 마세요. 규칙 집합은 무엇과 일치하는지 정의하고 기본 설정은 그 규칙을 출구에 연결합니다. 역할을 이렇게 분리하면 같은 규칙을 여러 환경에서 재사용하기 쉽습니다.

behavior는 규칙 데이터의 형식과 일치해야 합니다. 도메인 집합, 주소 집합, 클래식 규칙 항목은 서로 다른 형식입니다. 클래식 규칙을 도메인 목록으로 처리하면 파싱 오류가 나거나 전혀 다른 결과로 일치할 수 있습니다. Mihomo는 다른 규칙 형식도 지원하지만 구형 커널에서는 지원하지 않을 수 있습니다. 설정을 공유할 때는 자신의 클라이언트에서 한 번 작동하는지만 확인하지 말고 대상 커널이 모두 받아들이는 형식을 선택하세요.

갱신 실패는 네 단계로 나눠 확인하세요

원격 프로바이더를 사용하려면 접근 가능한 다운로드 주소와 갱신 간격, 캐시 경로가 필요합니다. 첫째 네트워크 요청이 성공했는지, 둘째 응답이 예상한 YAML이나 규칙 데이터인지, 셋째 커널이 파싱할 수 있는지, 넷째 프록시 그룹이나 규칙에서 실제로 참조하는지 확인하세요. 웹페이지가 로그인 화면이나 구독 한도 안내, 오류 메시지를 반환했다면 HTTP 응답이 있더라도 사용할 수 있는 설정을 받은 것은 아닙니다.

갱신 간격은 보통 초 단위로 설정하며 자주 새로고침한다고 문제가 해결되지는 않습니다. 서버에서 요청 횟수를 제한할 수 있고 여러 클라이언트가 동시에 갱신하면 제한에 걸릴 수도 있습니다. 사용할 수 있는 캐시는 유지한 채 한 번 수동 갱신해 오류를 확인하세요. 실패 원인을 모르는 상태에서 모든 캐시를 지우면 일시적인 다운로드 문제로 인해 사용 가능한 노드까지 모두 사라질 수 있습니다.

구독 주소에는 개인 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 스크린샷과 로그, 내보낸 실행 설정에도 전체 주소가 노출될 수 있습니다. 도움을 요청할 때는 주소를 예약 도메인으로 바꾸고 응답 상태와 파싱 오류, 관련 필드 구조만 남기세요. 출처가 불분명한 온라인 변환 도구에 개인 구독을 제공하지 말고 다른 사람의 구독 주소도 공개 설정 예제에 넣지 마세요.

노드 집합을 갱신하면 이름이 바뀌어 수동 선택 결과나 필터 조건에 영향을 줄 수 있습니다. 프로바이더의 항목 수가 예상과 일치하는지, 프록시 그룹에 후보가 남아 있는지 확인한 다음 새 연결의 출구를 점검하세요. “다운로드는 성공했지만 그룹에 노드가 없는” 경우에는 참조 이름과 형식, 필터 조건을 중점적으로 살펴보세요. 오류 메시지별 대응 방법은 구독 갱신 관련 FAQ에서 확인할 수 있습니다.

08 오버라이드, 병합 및 실행 검증

구독은 원격 콘텐츠를 갱신하고 로컬 오버라이드는 개인 설정을 유지합니다. 두 영역을 명확히 나누지 않으면 구독을 갱신할 때 규칙이 사라지거나, 원본 파일을 수정해도 UI 설정이 다시 덮어쓸 수 있습니다. 먼저 클라이언트의 설정 관리 메뉴에서 현재 파일이 구독 원본인지, 오버라이드 조각인지, 최종 실행 파일인지 확인한 뒤 수정할 위치를 결정하세요. Clash for Windows의 Mixin과 다른 클라이언트의 병합 또는 스크립트 기능은 이름이 비슷하더라도 서로 바꿔 쓸 수 없습니다.

병합 규칙은 구현 방식에 따라 달라집니다

YAML은 데이터를 표현할 뿐 여러 파일을 어떻게 병합할지는 정하지 않습니다. 클라이언트에 따라 매핑을 재귀적으로 병합하거나 목록을 통째로 교체할 수 있으며, 규칙을 앞이나 뒤에 삽입하는 전용 기능을 제공하기도 합니다. 여러 도구에 있는 비슷한 이름의 “병합” 버튼이 같은 방식으로 동작한다는 보장은 없습니다. 짧은 rules 목록을 적용하기 전에 원래 규칙에 추가되는지 전체 규칙을 대체하는지 확인하세요. 그렇지 않으면 직접 작성한 두 규칙만 남을 수 있습니다.

# 오버라이드 예제이며 클라이언트가 해당 병합 방식을 지원할 때만 사용하세요
mixed-port: 7890
allow-lan: false
log-level: info

dns:
  ipv6: false

위 예제는 로컬 진입점과 일부 DNS 옵션을 고정하는 설정이지 완전한 실행 설정이 아닙니다. 별도 파일로 불러오면 나머지 네트워크 구성이 없고, 얕은 병합으로 DNS 객체 전체를 덮어쓰면 기존 상류 서버가 제거될 수 있습니다. 먼저 복사본에 적용한 다음 생성 결과를 확인해 기존 nameserver, 노드, 프록시 그룹, 규칙 등이 사라지지 않았는지 점검하세요.

개인 규칙을 추가할 때는 클라이언트가 명시적으로 제공하는 규칙 삽입 위치를 우선 사용하세요. 업무별 예외는 앞쪽에, 최종 기본 규칙은 마지막에 두어야 합니다. 기존 MATCH 뒤에 규칙을 추가하면 예상대로 적용되지 않습니다. 클라이언트에 안정적인 목록 병합 기능이 없다면 구독에서 생성된 규칙 목록 전체를 계속 수정하기보다 로컬 기본 설정에서 노드 프로바이더를 참조하는 방법을 고려하세요.

파일, UI, 실행 상태를 구분하세요

설정은 구독 다운로드, 로컬 조각 적용, 스크립트 실행, 실행 파일 기록, 커널 재로드 알림 등 여러 단계를 거칠 수 있습니다. 구체적인 순서는 클라이언트마다 다르므로 UI 설정이 항상 마지막에 적용된다고 가정하면 안 됩니다. “저장했는데 바뀌지 않았다면” 최종 실행 설정을 확인하고, 다시 불러오기에 성공했는지 점검한 뒤 기존 연결이 이전 상태를 계속 사용하는지 살펴보세요.

Mihomo 명령줄 프로그램을 사용한다면 아래 테스트 명령으로 설정을 검사할 수 있습니다. 명령의 파일 이름은 실제 파일로 바꾸고 작업 디렉터리에 관련 프로바이더 파일도 있어야 합니다. 테스트 통과는 해당 커널이 설정을 받아들일 수 있다는 뜻이지 노드 인증, 원격 다운로드, 실제 서비스 접속까지 성공한다는 보장은 아닙니다. 구형 환경에서는 해당 커널의 도움말에서 매개변수를 확인하고 프로그램 이름을 그대로 가져다 쓰지 마세요.

mihomo -t -f config.yaml

검증은 단계별로 진행하세요. 먼저 문법과 참조를 확인하고, 다음으로 진입점 수신 여부, DNS와 프로바이더를 점검한 뒤 실제 연결을 확인합니다. 오류에 줄 번호가 표시되더라도 해당 줄 위쪽의 들여쓰기와 따옴표, 목록 경계도 함께 살펴보세요. 파서가 오류를 발견한 위치가 처음 잘못 작성한 위치와 다를 수 있습니다. 한 곳을 수정할 때마다 다시 테스트하고, 사용 중인 설정에 추측에 따른 변경을 여러 개 한꺼번에 적용하지 마세요.

복구 지점을 저장한 뒤 실제 요청을 확인하세요

정식으로 수정하기 전에 현재 사용할 수 있는 설정을 내보내고 활성화된 오버라이드 항목과 프록시 그룹 선택을 기록하세요. 계속 바뀔 수 있는 구독 주소에만 의존하지 말고 복구 가능한 로컬 사본을 보관해야 합니다. 변경 후 네트워크가 끊기면 마지막으로 작동한 상태를 먼저 복원하세요. 연결이 끊긴 채 새 필드를 계속 추가할 필요는 없습니다. 백업에도 개인 인증 정보가 포함될 수 있으므로 안전한 위치에 보관하고 공개 공간에 업로드하지 마세요.

프록시 매개변수를 지원하는 도구로 요청을 보내 포트를 확인할 수 있지만, 진입점에 연결된 것과 대상에 접속한 것은 구분해야 합니다. Windows에서 아래 예제를 실행할 때는 curl.exe를 명시해 일부 터미널의 같은 이름 별칭이 개입하지 않도록 하세요. 대상은 문서용 예약 사이트입니다. 현재 네트워크에서 접속할 수 없다면 반환된 오류를 바탕으로 어느 단계에서 실패했는지 판단해야 하며 명령의 종료 결과만으로 모든 노드를 평가해서는 안 됩니다.

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

그다음 연결 기록에서 대상과 적용된 규칙, 최종 출구를 확인하고 직접 연결이 필요한 서비스와 프록시가 필요한 서비스를 각각 테스트하세요. TUN을 검증할 때는 시스템 프록시를 자체적으로 읽지 않는 애플리케이션도 사용해 트래픽 가로채기 범위가 예상과 맞는지 확인해야 합니다. 여러 클라이언트를 동시에 실행해 시스템 프록시, 가상 네트워크 어댑터, 수신 포트를 서로 차지하게 하지 마세요. 불안정하다면 먼저 네트워크를 가로채는 경로 하나만 명확하게 활성화하세요.

관리하기 쉬운 설정이라면 네 가지 질문에 답할 수 있어야 합니다. 트래픽은 어디로 들어오는지, 도메인은 어디에서 조회되는지, 어떤 규칙이 경로를 선택하는지, 최종 출구는 무엇인지입니다. 변경할 때는 이 가운데 한 계층에 집중하고 용도를 설명하는 주석을 남기며 더 이상 필요 없는 임시 예외를 삭제하세요. 그러면 구독 갱신이나 시스템 전환, 클라이언트 변경 후에도 설정을 더 길게 쌓는 대신 같은 경로를 따라 문제를 찾을 수 있습니다.