MIHOMO / CONFIGURATION REFERENCE

Clash YAML 설정 파일 가이드

구조 개요 · 필드 설명 · 참조 관계 · 적용 상태 확인

이 페이지는 설정을 편집하거나 규칙을 관리하고 필드 충돌을 해결하려는 사용자를 위한 안내서입니다. 먼저 어떤 클라이언트가 설정을 생성하는지 확인한 다음, 커널이 최종적으로 읽는 내용을 살펴보세요. 처음 설치하거나 구독을 가져오고 연결을 확인하려면 먼저 사용 가이드를 읽어보세요. 이 가이드는 필드 간 의존 관계를 기준으로 구성되어 있어 설정을 변경할 때 필요한 장을 찾아볼 수 있습니다.

예제는 mihomo 설정 기준이며 모든 Clash 파생 버전이 같은 필드를 지원한다는 뜻은 아닙니다. GUI 클라이언트가 포트, DNS, TUN 또는 제어 인터페이스를 관리할 수도 있습니다. 아직 클라이언트를 선택하지 않았다면 다운로드 페이지에서 우선 추천하는 Clash Plus와 플랫폼별 다른 선택지를 확인한 뒤, 해당 클라이언트의 실제 설정 경로에 맞춰 진행하세요.

1. YAML 구조와 설정 로딩 범위

설정 파일은 유형과 계층이 있는 데이터이지, 줄마다 실행되는 명령어 모음이 아닙니다. 최상위의 mixed-port는 수신 포트를 나타내고, dns는 맵이며, proxies, proxy-groups, rules는 보통 목록입니다. 커널은 먼저 데이터를 파싱한 뒤 리스너를 만들고 프록시와 그룹을 해석한 다음 연결을 받습니다. 따라서 파일에 적힌 순서가 시작 단계의 순서를 뜻하지는 않지만, 규칙 목록 안의 순서는 매칭 결과에 영향을 줍니다.

들여쓰기, 값 유형, 이름 참조

들여쓰기는 공백 두 칸으로 통일하고 탭은 사용하지 마세요. 같은 상위 항목에 속한 필드는 같은 위치에 맞춰야 합니다. 목록 항목 앞의 하이픈은 새 요소를 뜻합니다. enable을 dns와 같은 수준에 두면 필드의 소속이 달라지고, rules를 프록시 그룹 안쪽으로 들여쓰면 예상한 최상위 규칙이 되지 않습니다. 글자 모양만 보는 것보다 편집기의 들여쓰기 가이드를 확인하는 편이 정확합니다.

불리언은 true 또는 false로, 포트와 시간 간격은 보통 정수로 작성합니다. 노드 이름과 비밀번호, 특수 문자가 포함된 값은 따옴표로 감싸는 것이 좋습니다. 특히 콜론 뒤에 공백이 있거나, 샵 기호 또는 앞자리 0이 포함된 문자열은 주의하세요. 따옴표로 잘못된 들여쓰기를 고칠 수는 없고 목록이 맵으로 바뀌지도 않습니다. 오류가 나면 먼저 구조를 확인한 뒤 값의 유형을 점검하세요.

프록시와 프록시 그룹은 이름으로 서로를 참조합니다. 이름에 들어간 공백, 대소문자, 한글 문장부호도 실제 값의 일부입니다. "수동 선택"과 "수동 선택"은 서로 다른 이름입니다. 규칙을 추가하기 전에 대상 이름이 존재하는지 확인하고, 노드를 삭제하기 전에는 어떤 그룹이 해당 노드를 참조하는지 검색하세요. 이름이 중복되면 화면 표시와 실제 파싱 결과를 구분하기 어려우므로 정리해야 합니다.

실행 가능한 기본 설정 만들기

아래 설정은 로컬 혼합 프록시 포트만 만들고 모든 요청을 직접 연결합니다. 파일 경로와 포트 리스닝, 규칙 파싱을 확인할 때 사용할 수 있지만 원격 프록시 기능은 제공하지 않습니다. 테스트할 때는 브라우저가 로컬 혼합 포트를 사용하도록 설정하거나 클라이언트의 시스템 프록시를 잠시 켜세요. ‘커널이 시작됨’을 ‘원격 노드에 연결됨’으로 착각하지 마세요.

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

proxies: []

proxy-groups:
  - name: "수동 선택"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,수동 선택

검증이 끝난 기본 설정을 보관한 뒤 실제 노드와 자동 테스트 그룹, DNS를 하나씩 추가하세요. 변경 유형을 하나씩 적용할 때마다 설정을 다시 불러오고 로그를 확인하면 문제 범위를 최근 변경 사항으로 좁힐 수 있습니다. 설정 전체를 한 번에 바꾸면 문법, 네트워크, 참조 관계, 클라이언트 오버라이드 문제가 동시에 생겨 원인 파악이 어려워집니다.

YAML 맵에서 같은 키를 중복 정의하지 마세요. 파일 앞부분과 뒷부분에 dns가 각각 있어도 두 영역이 자동으로 합쳐지는 것은 아닙니다. 파서에 따라 중복 키를 거부하거나 뒤에 나온 값만 남길 수 있습니다. 이런 동작에 의존하면 같은 파일도 클라이언트마다 다르게 처리될 수 있습니다. 병합이 필요하다면 생성 단계에서 최상위 필드가 하나만 남도록 하세요.

원본 파일과 실행 파일 구분하기

구독에서 내려받은 원본, 사용자가 편집한 설정, 클라이언트가 생성한 실행 설정은 서로 다른 파일일 수 있습니다. 클라이언트는 시작 전에 관리 인터페이스를 추가하거나 포트를 바꾸기도 하므로 실행 디렉터리의 파일을 직접 편집하면 다음 업데이트 때 덮어써질 수 있습니다. 클라이언트에서 제공하는 로컬 설정, 확장 설정 또는 오버라이드 기능을 우선 사용하고 적용 범위를 확인하세요.

설정 오류에 표시된 줄 번호는 커널이 실제로 읽은 파일의 위치이며 구독 원문과 다를 수 있습니다. 참조 누락이나 필드 불일치가 발생하면 클라이언트에서 현재 활성화된 설정 이름과 실행 설정 내용을 먼저 확인하세요. 문제 해결 자료를 공유하기 전에는 구독 주소, 노드 비밀번호, 제어 인터페이스 키를 제거하세요. 재현에 필요한 구조만 남기고 실행 파일 전체를 공개하지 마세요.

2. 공통 필드, 수신 포트, 실행 모드

공통 필드는 트래픽이 커널에 들어오는 경로와 커널의 처리 방식을 정합니다. 원격 노드를 만들거나 모든 앱의 네트워크 설정을 자동으로 바꾸지는 않습니다. 문제를 진단할 때는 ‘커널이 수신 중인지’, ‘시스템 프록시가 설정됐는지’, ‘앱이 시스템 프록시를 사용하는지’를 구분하세요. 클라이언트 화면의 스위치와 YAML 필드가 연동될 수는 있지만 같은 계층의 설정은 아닙니다.

포트와 수신 범위 선택

필드	주요 용도	사용 시 유의점
`port`	HTTP 프록시 수신 포트	HTTP 프록시를 지원하는 앱에서 사용
`socks-port`	SOCKS 프록시 수신 포트	앱에서 해당 프록시 프로토콜을 선택해야 함
`mixed-port`	HTTP와 SOCKS 요청을 같은 포트에서 수신	데스크톱 클라이언트의 통합 진입점으로 자주 사용
`allow-lan`	LAN 기기의 접속 허용 여부	바인딩 주소와 방화벽도 함께 확인해야 함
`bind-address`	수신할 로컬 주소 범위	라우터의 포트 포워딩은 설정하지 않음

혼합 포트는 여러 앱이 하나의 진입점을 공유할 때 편리하고, 개별 포트는 HTTP와 SOCKS의 접속 방식을 구분하기 쉽습니다. 별도 요구가 없다면 모든 진입점을 켤 필요는 없습니다. 같은 주소의 포트 하나를 여러 리스너가 동시에 사용할 수는 없습니다. 포트 충돌은 다른 프록시 프로그램이나 이전 커널 프로세스, 종료되지 않은 클라이언트 백그라운드 서비스 때문에 발생할 수도 있으므로 현재 설정만 의심하지 마세요.

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

로컬에서만 사용할 때는 루프백 주소에 바인딩하는 것이 좋습니다. 휴대전화나 다른 PC가 이 기기를 통해 연결해야 한다면 LAN 수신을 설정하고 네트워크 범위에 맞춰 방화벽과 접근 인증도 구성하세요. allow-lan만 true로 바꿔서는 다른 기기가 연결된다고 보장할 수 없습니다. 방화벽만 열어도 루프백 주소에 바인딩된 서비스가 외부 요청을 받지는 않습니다.

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

mode: rule은 rules를 위에서 아래로 확인해 트래픽을 분기하며, 일상적인 사용에 적합합니다. global은 전역 프록시 그룹을 사용해 아웃바운드를 선택하고 일반 규칙 목록으로 대상을 결정하지 않습니다. direct는 직접 연결 모드입니다. 화면에서 모드를 바꿔도 원본 파일의 mode 값이 함께 바뀌지 않을 수 있습니다. 클라이언트가 제어 인터페이스로 실행 상태를 변경할 수도 있으므로 현재 화면과 연결 기록을 기준으로 판단하세요.

전역 모드로 바꿔도 커널을 거치지 않는 트래픽은 해결되지 않습니다. 앱이 시스템 프록시를 우회해 규칙 모드에서 연결 기록이 없다면 전역 모드로 바꿔도 대개 기록이 나타나지 않습니다. 먼저 앱 자체의 프록시 설정을 확인하고, 필요한 경우에만 TUN을 사용하세요. 반대로 연결이 이미 커널에 들어왔지만 직접 연결 규칙에 매칭됐다면 모드와 규칙 순서를 살펴봐야 합니다.

log-level은 로그 상세 수준을 조절하며 트래픽 분기에는 영향을 주지 않습니다. 평소에는 info를 사용하고 까다로운 문제를 재현할 때만 일시적으로 debug로 바꾸세요. 확인이 끝나면 원래대로 돌리세요. 상세 로그에는 도메인, 대상 주소, 접속 시간이 포함될 수 있으므로 저장하거나 공유할 때 범위를 제한해야 합니다. 타임아웃 로그 한 줄만 보고 모든 트래픽이 실패했다고 판단하지 말고, 노드 핸드셰이크인지 DNS인지 상태 점검인지 확인하세요.

제어 인터페이스와 저장 상태

external-controller는 제어 인터페이스이며 브라우저에 입력하는 프록시 포트가 아닙니다. 연결 정보를 읽거나 프록시 그룹을 전환하고 실행 설정을 갱신할 때 사용합니다. 앱의 프록시 주소에 제어 인터페이스를 입력하면 프로토콜이 맞지 않습니다. 커널을 직접 실행할 때 필요에 따라 활성화할 수 있지만, GUI 클라이언트는 보통 관련 매개변수를 자체적으로 생성하고 관리하므로 오버라이드로 같은 주소를 다시 지정하지 않는 것이 좋습니다.

제어 인터페이스를 활성화해야 한다면 루프백 주소에 바인딩하고 별도의 키를 설정하세요. 공용 네트워크에 그대로 노출해서는 안 됩니다. 예시 키는 구조 설명용이며 실제 사용 시 직접 생성해야 합니다. 클라이언트에 접근 자격 증명 관리 기능이 있다면 해당 기능을 사용하고, 예시 값을 공개 설정 저장소에 계속 보관하지 마세요.

external-controller: "127.0.0.1:9090"
secret: "replace-with-a-local-random-secret"

profile:
  store-selected: true
  store-fake-ip: true

store-selected는 프록시 그룹 선택을 저장하고 store-fake-ip는 fake-ip 매핑 상태를 저장합니다. 저장 기능이 설정 자체를 대신하지는 않습니다. 프록시 그룹 이름을 바꾸면 이전 이름으로 저장한 선택이 적용되지 않을 수 있습니다. 모드, 포트, 저장 옵션을 바꾼 뒤에는 진입 경로와 라우팅, 재시작 동작을 각각 확인하세요. 화면의 스위치 위치만으로 모든 설정이 적용됐다고 판단하지 마세요.

3. 프록시 노드 필드와 노드 제공자

프록시 노드는 특정 원격 연결을 정의하고 프록시 그룹은 그중 하나를 선택합니다. 노드 이름은 참조용 표시일 뿐이며 실제 연결 여부는 프로토콜, 서버, 포트, 인증 정보에 달려 있습니다. 이름을 바꿔도 노드 위치나 네트워크 지연은 달라지지 않습니다. 서비스 제공자가 다른 노드의 이름이 같다면 한 설정에 넣기 전에 이름을 바꿔 프록시 그룹 참조가 모호해지지 않도록 하세요.

프로토콜별 필수 필드 설정

proxies의 각 항목은 하나의 프록시 객체이며, 현재 프로토콜이 인식할 유형과 연결 매개변수가 필요합니다. 다른 프로토콜의 필드를 그대로 복사하지 마세요. Shadowsocks의 암호화 방식, Trojan의 비밀번호, 다른 프로토콜의 사용자 식별자는 서로 다른 역할을 합니다. 설정 파싱에 성공했다는 것은 형식이 맞다는 뜻일 뿐, 원격 서버가 해당 정보를 받아들인다는 뜻은 아닙니다.

proxies:
  - name: "예시 SS"
    type: ss
    server: "proxy.example.com"
    port: 8388
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

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

server는 실제 연결할 서버 주소이고 port는 원격 서비스 포트입니다. 로컬 혼합 포트를 입력하면 안 됩니다. 서버가 도메인 이름이면 노드 연결 전에 도메인 해석이 필요합니다. 따라서 DNS 설정이 모든 프록시에 영향을 줄 수 있습니다. 서버 주소를 IP로 바꾸더라도 프로토콜에 TLS가 필요하다면 서버가 요구하는 올바른 도메인 매개변수를 유지해야 합니다. 주소와 신원 확인을 혼동하지 마세요.

udp: true는 노드 설정에서 해당 UDP 전달 기능을 허용한다는 뜻이지, 전체 연결 경로에서 모든 UDP 앱을 지원한다는 뜻은 아닙니다. 프로토콜 구현, 서버 설정, 네트워크 제한, 앱의 연결 방식도 확인해야 합니다. 브라우저는 정상인데 음성 통신이 실패한다면 실제 전송 유형부터 확인하세요. 웹페이지 로딩 속도만으로 UDP 사용 가능 여부를 판단할 수 없습니다.

TLS 인증과 전송 매개변수

TLS 연결에서 서버 주소와 sni는 서로 다른 역할을 할 수 있습니다. 서버 주소는 접속 대상을 정하고, SNI는 핸드셰이크에서 대상 이름을 알립니다. 인증서를 검증하려면 이름과 유효 기간, 신뢰 체인이 모두 올바라야 합니다. 인증서 오류가 나면 기기 시간과 노드 도메인, 서버 인증서, 네트워크 리디렉션 여부를 먼저 확인하세요. 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.

skip-cert-verify: false는 정상적인 인증서 검증을 유지합니다. true로 설정하면 연결의 신뢰 경계가 달라질 뿐 서버에 연결할 수 없는 문제나 비밀번호 오류, 프로토콜 불일치가 해결되지는 않습니다. 서비스가 WebSocket이나 gRPC 등의 전송 방식을 사용한다면 서버와 동일한 경로, 호스트 이름 또는 서비스 이름도 설정해야 합니다. 서버 주소와 포트만으로는 이러한 값을 알 수 없습니다.

노드 필드 지원 범위는 커널 기능에 따라 달라집니다. 원본 Clash와 각 파생 버전, mihomo는 프로토콜과 확장 필드를 완전히 동일하게 지원하지 않습니다. 가져오기 중 지원하지 않는 프록시 유형이 표시되면 들여쓰기를 반복해서 수정하기보다 클라이언트가 실제로 사용하는 커널을 확인하세요. 커널과 UI의 역할은 Clash, mihomo와 클라이언트 관계도를 참고하세요.

proxy-providers로 외부 노드 관리하기

노드 제공자는 외부 노드 목록을 별도 리소스로 불러오므로 계속 갱신되는 노드 집합을 프록시 그룹에서 참조할 때 유용합니다. 모든 구독 형식을 가져오는 범용 도구는 아닙니다. 원격 콘텐츠는 커널이 지원하는 노드 제공자 형식이어야 하며, 흔히 proxies:를 루트로 사용합니다. 클라이언트에서 가져올 수 있는 전체 구독 파일이라도 제공자 주소로 바로 사용할 수 있는 것은 아닙니다.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://config.example.com/proxies.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.example.com/"
      interval: 600

proxy-groups:
  - name: "구독 선택"
    type: select
    use:
      - remote-nodes
    proxies:
      - DIRECT

여기서 interval은 리소스 업데이트 주기를 초 단위로 지정합니다. 상태 점검의 같은 이름 필드는 검사 주기를 뜻하므로 서로 다른 설정입니다. path는 로컬 캐시 경로입니다. 직접 실행할 때는 작업 디렉터리와 쓰기 권한을 확인하고 제공자마다 캐시 경로를 따로 사용하세요. 원격 업데이트가 실패하면 최초 로드라 캐시가 없는 경우와 기존 캐시를 계속 사용할 수 있는 경우도 구분해야 합니다.

제공자 주소에는 보통 접근 자격 증명이 포함되므로 스크린샷이나 공개 저장소에 올리지 마세요. 문제를 확인할 때는 도메인만 남기고 경로의 민감한 부분을 지운 뒤 업데이트 로그와 응답 형식, 노드 수 변화를 확인할 수 있습니다. 노드는 갱신됐는데 프록시 그룹에 새 이름이 보이지 않는다면 그룹의 use, 필터 조건, 현재 활성화된 설정을 확인하세요. 업데이트 버튼만 반복해서 누르지 마세요.

4. 프록시 그룹 유형, 테스트, 선택 상태

프록시 그룹은 규칙과 노드 사이의 안정적인 연결점입니다. 각 규칙이 ‘업무용 출구’를 계속 가리키게 하고 그룹 안의 노드만 필요에 따라 바꾸면 규칙마다 노드 이름을 고정하는 것보다 관리하기 쉽습니다. 프록시 그룹 자체가 원격 서비스를 제공하는 것은 아닙니다. 최종적으로 실제 노드나 다른 그룹, 내장 아웃바운드를 선택해야 합니다. 그룹 이름은 용도를, 노드 이름은 연결 대상을 나타내도록 구분하면 연결 기록을 읽기 쉽습니다.

수동 선택과 자동 테스트

select는 사용자가 직접 선택하는 방식으로, 업무나 네트워크, 지역에 따라 노드를 고를 때 적합합니다. 그룹 순서는 목록 표시에 영향을 주지만 선택 저장 기능을 켜면 시작 시 첫 번째 항목으로 돌아가지 않을 수 있습니다. url-test는 지정한 테스트 주소의 결과에 따라 후보를 선택하므로 비슷한 노드 사이에서 자동으로 조정할 때 유용합니다. 자동 선택 결과는 테스트 대상에 따라 달라지며 모든 웹사이트에서 같은 성능을 보장하지는 않습니다.

proxy-groups:
  - name: "업무용 출구"
    type: select
    proxies:
      - "자동 선택"
      - "예시 SS"
      - DIRECT

  - name: "자동 선택"
    type: url-test
    proxies:
      - "예시 SS"
      - "예시 Trojan"
    url: "https://www.example.com/"
    interval: 300
    tolerance: 80
    lazy: true

이 설정은 앞 장에 나온 같은 이름의 노드에 의존하므로 따로 복사하면 참조를 찾을 수 없습니다. interval은 테스트 간격이고 tolerance는 전환 허용 오차입니다. 두 값은 단위를 바꿔 사용할 수 없습니다. 적절한 허용 오차를 설정하면 결과가 조금씩 흔들릴 때 잦은 전환을 줄일 수 있지만 세션 연속성을 보장하거나 실패한 노드의 전송을 복구하지는 않습니다. 노드 수와 네트워크 안정성, 테스트 비용을 고려해 값을 조정하세요.

lazy: true를 설정하면 그룹을 실제로 사용하지 않을 때 불필요한 검사를 줄일 수 있습니다. 따라서 시작 직후 테스트 결과가 모두 표시되지 않아도 이상이 아닐 수 있습니다. 수동으로 검사를 실행해도 실패한다면 테스트 주소에 연결할 수 있는지, 인증서가 정상인지, 노드가 요청을 처리할 수 있는지 확인하세요. 테스트 트래픽도 노드를 통과하므로 간격을 너무 짧게 설정하면 기기와 네트워크, 서버에 부담을 줄 수 있습니다.

장애 조치와 부하 분산

fallback의 핵심은 우선순위입니다. 일반적으로 후보 순서대로 사용할 수 있는 항목을 선택하므로 기본 출구와 예비 출구를 둘 때 적합합니다. 테스트 지연이 낮은 노드를 찾는 url-test와는 다릅니다. 첫 번째 노드를 계속 사용할 수 있다면 뒤쪽 노드는 업무 트래픽을 거의 받지 않을 수 있습니다. 이는 우선순위 방식의 정상적인 동작이며 노드가 그룹에 잘못 추가됐다는 뜻은 아닙니다.

load-balance는 여러 후보에 연결을 분산하는 기능이지, 한 번의 다운로드에 여러 노드의 대역폭을 합치는 기능이 아닙니다. 분산 방식에 따라 같은 대상에 연결할 때 출구가 달라질 수 있습니다. 로그인 지역을 고정하거나 서버 세션을 유지해야 하는 업무라면 출구 변경의 영향을 먼저 살펴보세요. 그룹에 노드가 많다는 이유만으로 수동 선택보다 부하 분산이 낫다고 단정하지 마세요.

기존 연결은 프록시 그룹을 바꿔도 새 노드로 자동 이동하지 않는 경우가 많습니다. 브라우저의 지속 연결이나 스트리밍 세션, 백그라운드 통신은 기존 출구를 계속 사용할 수 있고 새 연결부터 변경된 선택이 반영됩니다. 그룹 전환을 확인하려면 해당 연결을 닫거나 요청을 다시 시작할 수 있지만, 진행 중인 작업이 중단될 수 있습니다. 기존 연결이 바뀌지 않았다는 이유로 설정이 적용되지 않았다고 판단하는 것은 흔한 오류입니다.

제공자 참조, 필터, 순환 참조

그룹의 proxies는 목록에 명시된 이름을 참조하고 use는 노드 제공자를 참조합니다. 필요에 따라 두 방식을 함께 사용하면 직접 연결 옵션이나 고정 노드를 유지하면서 동적으로 갱신되는 노드도 불러올 수 있습니다. 후보 이름은 보통 filter 등의 필드로 필터링합니다. 정규식은 따옴표로 감싸고 필터 적용 후 예상한 후보가 하나 이상 남는지 확인하세요.

proxy-groups:
  - name: "원격 출구"
    type: select
    use:
      - remote-nodes
    filter: "(?i)office|backup"
    proxies:
      - DIRECT

제공자에서 노드 이름이 바뀌면 필터 결과도 달라질 수 있습니다. 노드 목록이 갑자기 줄었다면 네트워크보다 먼저 업데이트된 원래 이름과 정규식을 확인하세요. 이름 문제를 숨기려고 모든 노드가 포함되도록 필터를 넓히지 마세요. 해당 업무에 맞지 않는 출구가 그룹에 들어갈 수 있습니다. 복잡한 필터를 수정하기 전에는 필터 없는 간단한 설정으로 제공자가 정상 로드되는지 확인하세요.

프록시 그룹은 다른 그룹을 참조할 수 있지만 서로를 계속 참조하는 순환 구조는 만들 수 없습니다. 예를 들어 A가 B를 참조하고 B가 다시 A를 참조하면 안 됩니다. 계층은 명확한 종착점이 있어야 하며 실제 노드나 내장 아웃바운드로 이어져야 합니다. 자동 그룹을 다시 자동 그룹 안에 중첩하면 동작을 파악하기 어려워집니다. 연결이 실패하면 가장 바깥쪽 그룹 이름만 보지 말고 각 단계의 선택을 확인하세요. 테스트 지연과 실제 사용 경험의 차이는 Clash 지연 테스트 원리에서 자세히 알아볼 수 있습니다.

5. 규칙 문법, 매칭 순서, 규칙 제공자

규칙 모드는 위에서 아래로 확인하며 처음 일치하는 규칙이 연결의 아웃바운드를 결정합니다. 같은 연결의 대상을 선택할 때 뒤에 있는 규칙은 보통 더 이상 확인하지 않습니다. 따라서 규칙이 있는지보다 어디에 있는지가 중요합니다. 구체적인 예외를 앞에 두고 범위가 넓은 규칙은 뒤에 배치한 다음, 마지막에 MATCH로 기본 처리를 지정하면 연결 기록의 판단 과정을 이해하기 쉽습니다.

도메인 규칙과 IP 규칙

DOMAIN은 도메인 전체 이름에, DOMAIN-SUFFIX는 지정 도메인과 하위 도메인에, DOMAIN-KEYWORD는 키워드가 포함된 이름에 매칭됩니다. 키워드 규칙은 범위가 넓어 관계없는 도메인까지 같은 정책에 포함될 수 있습니다. 서비스별로 트래픽을 나눌 때는 명확한 도메인이나 접미사를 우선 사용하세요. 도메인 규칙은 호스트 이름에 적용되며 전체 URL을 대상으로 하지 않습니다. 프로토콜, 경로, 쿼리 매개변수를 넣을 수 없습니다.

rules:
  - DOMAIN,api.example.com,업무용 출구
  - DOMAIN-SUFFIX,example.net,업무용 출구
  - 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,업무용 출구

IP 규칙은 대상 주소 범위를 처리하므로 도메인 규칙과 적용 대상이 다릅니다. no-resolve는 해당 IP 규칙이 도메인 요청을 판단하려고 별도로 DNS 조회를 시작하지 않게 합니다. 요청에 대상 IP가 이미 있으면 여전히 규칙에 매칭될 수 있습니다. 규칙 전체를 건너뛰거나 모든 DNS 요청을 끄는 설정은 아닙니다. 앱이 도메인과 IP 중 무엇을 커널에 전달하는지 함께 살펴보세요.

한 서비스는 로그인, API, 정적 리소스, 업데이트에 서로 다른 도메인을 사용할 수 있습니다. 홈페이지 도메인만 분기하면 페이지는 열리지만 로그인이 실패할 수 있습니다. 연결 기록을 보고 실제로 필요한 도메인을 추가하세요. 곧바로 광범위한 키워드 규칙이나 전역 모드로 바꾸지 마세요. 도메인을 알고 있는데 IP만 표시된다면 앱이 직접 DNS를 조회하는지, DNS 요청이 커널을 거치는지 확인해야 합니다.

규칙 대상과 데이터 의존성

규칙의 마지막 대상은 기존 프록시나 프록시 그룹, 또는 DIRECT, REJECT 같은 내장 아웃바운드가 될 수 있습니다. 존재하지 않는 그룹 이름을 지정하면 로드 오류가 발생하거나 설정을 사용할 수 없게 됩니다. 대부분의 업무 규칙은 용도가 안정적인 프록시 그룹을 가리키도록 하세요. 노드 이름을 바꿀 때 규칙을 하나씩 수정하지 않아도 됩니다. 차단 규칙은 가능한 한 정확하게 작성해야 합니다. 인증이나 인증서 관련 요청을 잘못 차단하면 원인을 바로 알아차리기 어려운 문제가 연쇄적으로 생길 수 있습니다.

GEOIP 등의 규칙은 해당 지리 데이터에 의존하며 규칙 제공자는 외부 리소스에 의존합니다. 설정 문법이 올바르더라도 데이터 파일이 없거나 다운로드에 실패하거나 캐시 경로에 쓸 수 없으면 초기화가 완료되지 않을 수 있습니다. 로그를 확인할 때 ‘규칙 문자열이 잘못됨’과 ‘규칙에 필요한 리소스를 사용할 수 없음’을 구분하세요. 두 문제는 해결 방법이 다릅니다.

프로세스 기반 규칙은 운영체제와 권한, 트래픽 유입 방식의 제약을 받습니다. 데스크톱에서 사용할 수 있는 프로세스 규칙이 라우터 포워딩 환경에서도 원래 앱을 식별한다고 가정하면 안 됩니다. 특히 LAN의 다른 기기에서 온 트래픽은 커널이 포워딩된 연결만 볼 뿐 원격 기기의 프로세스 이름을 자동으로 알 수 없습니다. 이런 환경에서는 도메인, 대상 주소, 식별 가능한 출발지 조건을 기준으로 정책을 구성하세요.

긴 규칙 목록은 rule-providers로 관리하기

규칙 제공자를 사용하면 긴 규칙 목록을 기본 설정에서 분리하고 기본 설정에는 우선순위와 출구 결정만 남길 수 있습니다. behavior는 규칙 의미를, format은 파일 형식을 지정하며 둘 다 원격 콘텐츠와 일치해야 합니다. 아래 예제는 YAML 형식의 classical 집합을 사용합니다. 집합 안에는 규칙 조건만 작성하고 각 조건 뒤에 프록시 그룹을 붙이지 않습니다. 대상은 기본 설정의 RULE-SET에서 지정합니다.

rule-providers:
  work-domains:
    type: http
    behavior: classical
    format: yaml
    url: "https://config.example.com/work-rules.yaml"
    path: ./rules/work-rules.yaml
    interval: 86400

rules:
  - RULE-SET,work-domains,업무용 출구
  - MATCH,DIRECT

해당 원격 파일은 다음과 같은 구조를 사용할 수 있습니다. 제공자가 도메인 목록으로 선언됐다면 전체 클래식 규칙 문자열을 일반 도메인처럼 넣으면 안 됩니다. 형식을 섞으면 파싱에 실패하거나 규칙이 예상대로 매칭되지 않을 수 있습니다. 업데이트 간격을 무작정 늘리기보다 콘텐츠 형식부터 확인하세요.

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,example.net

규칙 집합에도 신뢰와 관리 범위가 있습니다. 업데이트로 매칭 범위가 넓어지거나 좁아지면 같은 업무의 출구가 달라질 수 있으므로 용도가 분명하고 내용을 확인할 수 있는 집합을 선택하세요. 변경 전에는 캐시와 정상 동작이 확인된 설정을 보관하세요. 검증할 때는 매칭되어야 하는 대상과 매칭되면 안 되는 대상을 하나씩 골라 실제 규칙과 최종 아웃바운드를 확인해야 합니다. 성공 사례 하나만으로 모든 분기 설정이 올바르다고 판단하지 마세요.

6. DNS 해석, fake-ip, 부트스트랩 경로

DNS는 대상 도메인 해석과 노드 서버 주소 해석, 일부 규칙 판단에 모두 관여합니다. 웹페이지에 접속할 수 없다면 앱이 DNS 결과를 얻지 못했거나 커널이 노드 도메인을 해석하지 못했거나 DNS 경로와 연결 출구가 맞지 않는 등 여러 지점에서 문제가 생겼을 수 있습니다. 어떤 도메인을 어느 구성 요소가 어떤 경로로 해석하는지 먼저 확인한 뒤 필드를 바꾸세요. 모든 리졸버를 한꺼번에 바꾸면 기존 문제를 재현하기 어려워집니다.

DNS 수신 경로와 주소 처리 모드

dns.enable은 커널 DNS 기능을 켜고 listen은 DNS 요청을 받을 주소를 지정합니다. 그렇다고 운영체제 DNS 설정까지 자동으로 바뀌는 것은 아닙니다. 시스템 프록시를 명시적으로 사용하는 경우와 앱 내장 암호화 DNS, TUN을 통한 연결은 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:
    - 1.1.1.1
  nameserver:
    - "https://cloudflare-dns.com/dns-query"

fake-ip는 가상 주소를 사용해 도메인과 후속 연결을 연결하고, 커널은 해당 도메인과 규칙을 바탕으로 요청을 처리합니다. 이 주소는 웹사이트의 실제 서버 주소가 아니므로 테스트용 주소 대역이 보인다고 DNS 변조로 단정할 수 없습니다. LAN 검색이나 특정 검증을 위해 실제 주소가 필요한 앱은 필터 범위에 추가해야 할 수 있지만, 호환성 문제를 피하려고 모든 도메인을 필터에서 제외하지는 마세요.

redir-host는 일반적으로 실제 해석 주소를 반환하며 다른 호환성 요구에 적합할 수 있습니다. fake-ip와의 차이는 주로 주소를 연결하는 방식에 있으며 단순히 ‘빠르다’ 또는 ‘느리다’의 차이가 아닙니다. 트래픽 진입 경로와 앱 동작, 규칙 요구를 고려해 선택하세요. 모드를 바꾼 뒤에는 시스템 DNS 캐시와 앱 캐시, 기존 연결도 고려해야 합니다. 스위치를 바꾼 뒤 처음 보낸 요청만 확인해서는 안 됩니다.

부트스트랩 DNS와 노드 도메인 해석

default-nameserver는 DNS 서버 자체의 도메인을 해석하는 등 부트스트랩에 사용됩니다. 모든 업무에 같은 우선순위의 일반 리졸버를 하나 더 추가하는 설정은 아닙니다. 도메인 형식의 암호화 DNS 주소를 사용하면 클라이언트가 먼저 DNS 서비스 주소를 알아야 합니다. 부트스트랩 조회가 아직 준비되지 않은 프록시에 의존하고, 프록시 노드도 같은 DNS 서비스에 의존한다면 시작 과정에서 순환 대기가 생길 수 있습니다.

proxy-server-nameserver를 사용하면 노드 서버 도메인을 해석하는 경로를 따로 지정해 일반 트래픽의 DNS 설정과 섞일 때 생기는 의존성을 줄일 수 있습니다. 현재 네트워크에서 실제로 조회 가능한 DNS 서비스를 지정해야 합니다. 다른 네트워크에서 사용할 수 있다는 이유만으로 현재 네트워크에서도 연결된다고 가정하지 마세요. 방화벽과 통신사 네트워크, 기기의 DNS 정책이 결과에 영향을 줍니다.

respect-rules를 켜면 DNS 연결의 경로를 정할 때 분기 규칙을 고려합니다. 출구 정책을 통일해야 하는 환경에 적합하지만 규칙과 노드 DNS에 대한 의존성도 늘어납니다. 활성화하기 전에 노드 도메인을 별도로 해석할 방법을 마련하세요. DNS 요청이 프록시를 기다리고 프록시가 다시 DNS를 기다리는 상황을 피해야 합니다. 처음 문제를 진단할 때는 단순한 해석 경로로 기본 연결을 확인한 다음 분기 정책을 추가하세요.

도메인별 리졸버 선택과 캐시 확인

nameserver-policy를 사용하면 특정 도메인에 리졸버를 지정할 수 있습니다. 예를 들어 내부 도메인은 사내 DNS에 조회하도록 설정할 수 있습니다. 내부 DNS 주소는 네트워크 환경에 따라 달라지므로 해당 도메인 정책도 환경에 맞춰 조정해야 합니다. 내부 이름을 공용 리졸버에 보내면 원하는 주소를 얻지 못할 뿐 아니라 불필요한 내부 이름 조회가 외부에 노출될 수 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1
  nameserver:
    - "https://cloudflare-dns.com/dns-query"
  nameserver-policy:
    "+.corp.example.com":
      - 192.168.1.53

이 설정 조각은 실제 DNS 설정에 병합해야 하며 같은 파일에 두 번째 dns 항목을 추가하면 안 됩니다. 사내 DNS 예시 주소는 현재 환경에서 사용하는 실제 리졸버로 바꾸세요. fallback과 필터 조건을 함께 사용한다면 기본 조회 결과와 대체 결과의 선택 방식도 각각 확인해야 합니다. 대체 리졸버를 추가한다고 도메인별 분기가 자동으로 이뤄지거나 매번 같은 DNS가 사용되는 것은 아닙니다.

수정한 뒤에는 같은 도메인과 앱, 접속 방식으로 다시 테스트하세요. 터미널 조회 도구는 브라우저의 암호화 DNS 경로와 달리 시스템 리졸버를 직접 사용할 수 있습니다. 결과가 다르다고 해서 항상 커널 문제인 것은 아닙니다. DNS 경로를 확인한 뒤 관련 캐시를 지우고 연결을 다시 만드세요. fake-ip 매핑을 사용한다면 저장 상태도 확인해 이전 주소와 새 설정이 섞여 간헐적인 오류가 발생하지 않도록 하세요.

7. TUN 연결, 시스템 라우팅, 플랫폼별 차이

TUN은 운영체제에 가상 네트워크 인터페이스를 만들어 명시적 프록시를 사용하지 않는 일부 트래픽을 커널로 보냅니다. 트래픽을 받아들이는 기능이지 프록시 그룹이나 노드, 규칙을 대신하지는 않습니다. TUN을 켜도 커널은 각 연결을 직접 연결할지, 차단할지, 프록시를 사용할지 결정해야 합니다. 노드 자체가 작동하지 않는다면 TUN은 더 많은 앱을 같은 문제에 노출할 뿐 원격 연결을 복구하지 않습니다.

최소 설정과 권한 조건

데스크톱 클라이언트는 보통 인터페이스를 만들고 라우팅을 수정하기 위해 서비스를 설치하거나 필요한 권한을 받아야 합니다. 커널을 직접 실행할 때는 시스템 권한을 직접 처리해야 합니다. 설정에 enable: true가 있는데 로그에 인터페이스 생성 실패가 표시되면 규칙을 더 수정하기 전에 권한과 드라이버, 서비스 상태부터 해결하세요. GUI에서 스위치가 켜져 있어도 실제 인터페이스와 라우팅을 확인해야 합니다.

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

auto-route는 연결에 필요한 라우팅을 커널이 설정하도록 요청하고 auto-detect-interface는 아웃바운드 인터페이스 선택을 돕습니다. 유선과 무선, 가상 머신, 다른 터널 인터페이스가 함께 있는 기기에서는 기본 경로가 바뀌면서 자동 선택 결과가 달라질 수 있습니다. 네트워크를 전환한 뒤에만 문제가 생긴다면 구독 내용보다 현재 기본 경로와 실제 아웃바운드 인터페이스를 확인하세요.

stack은 가상 인터페이스의 트래픽을 처리할 네트워크 스택을 지정합니다. 사용할 수 있는 옵션과 동작은 현재 커널을 기준으로 확인하세요. 흔히 말하는 ‘범용 최적 조합’을 그대로 적용하지 마세요. 같은 앱도 UDP, LAN 접속, 대용량 전송에서 다르게 동작할 수 있습니다. 네트워크 스택을 바꿀 때는 다른 설정을 그대로 두고 같은 업무를 재검증해야 해당 필드가 실제 변화를 일으켰는지 알 수 있습니다.

DNS 하이재킹과 연결 범위

dns-hijack은 조건에 맞는 일반 DNS 트래픽을 커널 DNS로 전달합니다. 앱 자체의 HTTPS DNS를 자동으로 복호화하거나 TUN 라우팅 범위 밖의 모든 요청을 가로채지는 못합니다. 앱이 자체 DNS 경로를 계속 사용하면 규칙이 예상과 다른 대상 정보를 볼 수 있습니다. 앱의 DNS 설정과 실제 연결 경로를 먼저 확인한 뒤 조정 여부를 판단하세요.

라우팅을 가로챌 때는 LAN 프린터와 네트워크 저장 장치, 개발 환경, 가상 머신 네트워크도 고려해야 합니다. 규칙의 직접 연결은 트래픽이 커널에 들어온 뒤 어느 출구를 사용할지 결정하고, 시스템 라우팅 제외는 트래픽이 커널에 들어올지 결정합니다. 두 설정은 서로 다른 제어 방식입니다. 로컬 서비스에 연결되지 않는다면 요청이 커널에 들어왔는지 먼저 확인한 다음 대상 주소 규칙을 살펴보세요. 잘못된 계층에 예외를 계속 추가하지 마세요.

strict-route 같은 설정은 우회 경로를 제한하는 데 도움이 될 수 있지만 시스템 구성 요소와 다른 터널, LAN 통신에 영향을 줄 수 있습니다. 플랫폼에서 어떻게 동작하는지 이해한 뒤 사용하세요. 원격으로 관리하는 기기나 서버에서는 라우팅 변경으로 현재 관리 연결이 끊길 수 있습니다. 현장 접근이나 복구 방법을 확보한 뒤 설정하고, 복구 경로 없이 데스크톱 설정을 그대로 적용하지 마세요.

플랫폼별 실제 적용 상태 확인

플랫폼	우선 확인할 항목	주요 제약
Windows	서비스 권한, 가상 인터페이스, 방화벽	시스템 프록시와 UWP 앱의 연결 경로가 다를 수 있음
macOS	시스템 권한, 라우팅, 클라이언트 구현	네트워크 확장 기능이나 다른 터널이 연결에 영향을 줄 수 있음
Linux	TUN 장치, 권한, 정책 라우팅, 방화벽	데스크톱과 서버 환경을 각각 확인해야 함
Android / iOS	클라이언트 VPN 권한과 시스템 상태	데스크톱 TUN 필드를 모든 플랫폼의 공통 설정 경로로 볼 수 없음

Windows에서는 먼저 명시적 프록시가 정상인지 확인한 뒤 시스템 프록시를 끄고 TUN만 단독으로 테스트하면 두 연결 경로를 구분하기 쉽습니다. 명시적 프록시 환경의 UWP 앱 루프백 제한은 TUN 가로채기와 별개의 문제이므로, 네트워크에 연결되지 않는 모든 현상을 방화벽 탓으로 돌려서는 안 됩니다. 설치 및 서비스 문제 해결은 Clash Verge Rev Windows 설치 및 TUN 문제 해결을 참고하세요.

Linux에서는 다른 서비스가 포워딩과 방화벽, 정책 라우팅을 관리하는지 확인하세요. 네트워크 관리자가 다시 로드되면 기존 설정이 바뀔 수 있습니다. macOS와 모바일 플랫폼에서는 현재 클라이언트가 제공하는 권한 부여 경로를 사용하고 데스크톱 설정 파일을 그대로 덮어쓰지 마세요. Clash Plus, Clash Verge Rev, FlClash는 화면 구성이 서로 다르므로 현재 플랫폼의 클라이언트에서 실제 설정 위치를 확인해야 합니다.

인터넷 연결이 완전히 끊기면 먼저 TUN을 끄고 시스템 네트워크가 복구되는지 확인한 다음 커널 시작 로그와 DNS, 노드를 점검하세요. TUN을 꺼도 문제가 계속되면 노드를 계속 바꾸지 말고 남아 있는 시스템 프록시와 라우팅을 확인하세요. 테스트가 끝나면 필요한 연결 방식만 남겨야 합니다. 문제를 찾는 동안 여러 프록시나 터널을 동시에 실행하면 트래픽 경로를 파악하기 어려워집니다.

8. 클라이언트 오버라이드, 설정 병합, 검증 절차

최종 적용 설정은 구독 원문과 로컬 확장, 클라이언트 설정, 실행 상태가 함께 결정하는 경우가 많습니다. 구독 업데이트는 원본 내용을 새로 가져오고 오버라이드는 로컬 변경 사항을 유지하며 제어 인터페이스는 현재 선택을 바꿀 수 있습니다. 세 요소가 함께 작동한다면 편집기에서 파일 하나만 봐서는 전체 동작을 설명할 수 없습니다. 문제 해결의 목표는 ‘커널이 실제로 어떤 설정을 읽었고 연결이 실제로 어디로 갔는가’를 확인하는 것이지, 특정 필드가 저장됐는지 확인하는 데 그치지 않습니다.

병합 방식과 저장 위치 확인

맵과 목록, 단일 값은 병합될 때 서로 다른 방식으로 처리될 수 있습니다. 맵은 재귀적으로 덮어쓰고 목록은 전체 교체하거나 클라이언트가 뒤에 추가할 수 있습니다. 이는 클라이언트의 확장 방식에 따라 달라지며 YAML에 공통으로 정의된 규칙이 아닙니다. 특히 rules는 항목이 모두 유지되더라도 추가 위치가 달라지면 우선순위가 바뀝니다. 반드시 병합된 결과의 순서를 확인하세요.

예를 들어 구독 설정의 마지막에 MATCH가 있는데 클라이언트가 사용자 지정 도메인 규칙을 그 뒤에 추가하면 해당 규칙은 매칭될 기회가 없습니다. 클라이언트에서 제공하는 규칙 앞쪽 추가 기능을 사용하거나 생성 단계에서 사용자 지정 예외를 기본 처리보다 앞에 넣으세요. 화면에 ‘추가 완료’라고 표시됐다고 검증을 끝내지 말고 해당 요청을 보내 실제로 어떤 규칙이 매칭되는지 확인해야 합니다.

# 병합 후 기대되는 규칙 순서
rules:
  - DOMAIN,api.example.com,업무용 출구
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,업무용 출구

포트와 제어 인터페이스, TUN은 클라이언트가 관리하는 경우가 많아 같은 이름의 필드를 오버라이드해도 다시 덮어쓸 수 있습니다. 먼저 각 필드를 어느 계층에서 관리할지 정하고 한 곳에서 수정해 화면 설정과 파일 오버라이드가 서로 덮어쓰지 않도록 하세요. 클라이언트를 고를 때 Clash Plus를 출발점으로 삼을 수 있습니다. 다른 클라이언트를 사용하더라도 해당 클라이언트의 로컬 확장 기능에 변경 사항을 저장하세요. 특정 클라이언트의 스크립트 문법을 커널 공통 필드로 간주하면 안 됩니다.

구독 업데이트 후 변경 사항이 사라진다면 대개 잘못된 위치를 편집했거나 오버라이드가 현재 설정에 연결되지 않은 것입니다. 먼저 업데이트 전후의 원문을 확인한 다음 확장이 활성화됐는지와 적용 범위를 살펴보세요. 확장 기능에 따라 특정 설정 하나에만 적용되거나 모든 설정에 적용될 수 있습니다. 범위를 잘못 선택하면 테스트 설정이 일상 설정에 영향을 줍니다. 장기간 관리할 때는 로컬 변경 사항과 각각의 목적, 제거 조건을 기록해 두세요.

정적 검증 후 실행 검증

mihomo를 직접 실행한다면 적용할 설정 파일을 먼저 검사할 수 있습니다. 아래 명령은 지정한 파일을 현재 커널이 받아들일 수 있는지 확인할 뿐 원격 노드와 외부 규칙 리소스, 모든 업무의 종단 간 동작을 검증하지는 않습니다. GUI 클라이언트는 자체 커널과 별도의 작업 디렉터리를 사용할 수 있습니다. 터미널에서 다른 mihomo로 테스트에 성공해도 클라이언트가 같은 파일을 사용한다는 보장은 없습니다.

mihomo -t -f ./config.yaml

정적 검증에서는 네 가지 오류를 순서대로 확인하세요. 들여쓰기 또는 값 유형 오류, 존재하지 않는 이름 참조, 현재 커널에서 지원하지 않는 필드, 외부 리소스 로드 문제입니다. 오류가 발생하면 실제 의미가 있는 첫 번째 메시지를 기록하세요. 뒤에 나오는 오류는 앞선 문제의 연쇄 결과일 수 있습니다. 한 번에 하나씩 수정하고 다시 테스트하세요. 의미를 모른 채 여러 필드를 동시에 삭제하면 실행은 되더라도 기존 정책이 사라질 수 있습니다.

실행 단계에서는 먼저 리스너가 정상적으로 시작됐는지 확인하고, 테스트 요청이 커널에 들어왔는지 살펴본 다음 모드와 규칙, 프록시 그룹, 최종 노드를 점검하세요. 출구 IP와 실제 업무 결과는 마지막에 확인합니다. 직접 연결되어야 하는 요청 하나와 프록시를 사용해야 하는 요청 하나를 골라 각각 테스트하고, 필요하면 연결을 다시 만드세요. 첫 연결을 확인하는 전체 절차는 노드 선택, 지연 시간 테스트, 프록시 적용 확인을 참고하세요.

증상에 맞는 계층부터 다시 확인

설정 테스트는 통과했는데 앱에서 인터넷에 연결되지 않는 이유는 무엇인가요?

연결 기록에 요청이 표시되는지 먼저 확인하세요. 기록이 없다면 시스템 프록시와 앱 프록시, TUN 연결을 점검하세요. 기록은 있지만 요청이 실패한다면 DNS와 노드 핸드셰이크, 규칙 대상 등을 확인해야 합니다. DNS 조회 성공과 설정 테스트 통과는 중간 단계일 뿐 실제 연결 검증을 대신하지 않습니다.

프록시 그룹을 바꿨는데 출구가 바로 바뀌지 않는 이유는 무엇인가요?

현재 규칙 모드인지 전역 모드인지 확인하고 해당 요청이 실제로 어떤 그룹을 가리키는지 살펴보세요. 기존 장기 연결은 이전 출구를 계속 사용할 수 있으므로 새 연결을 만들어야 합니다. 새 요청도 바뀌지 않는다면 프록시 그룹 저장 상태와 중첩 그룹 선택, 클라이언트에서 예상한 설정을 불러왔는지 확인하세요.

구독을 업데이트한 뒤 로컬 규칙이 적용되지 않는 이유는 무엇인가요?

오버라이드가 현재 설정에 계속 연결되어 있는지, 목록이 교체·앞쪽 추가·뒤쪽 추가 중 어떤 방식으로 병합되는지 확인하세요. 최종 파일에 같은 이름의 최상위 키가 여러 개 있는지, 규칙이 MATCH 뒤에 놓였는지, 구독 업데이트로 대상 프록시 그룹 이름이 바뀌었는지 특히 살펴봐야 합니다. 실행 캐시를 계속 수동 편집하지 말고 생성 방식을 수정하세요.

복구 절차도 변경 절차만큼 명확해야 합니다. 먼저 정상 동작이 확인된 설정으로 되돌리고 최근에 추가한 오버라이드나 TUN 설정을 끈 다음 시스템 프록시와 DNS 상태를 확인하세요. 필드 하나를 해결하려고 클라이언트 디렉터리 전체를 삭제하지 마세요. 노드 선택과 캐시, 로컬 확장이 함께 들어 있을 수 있습니다. 다시 설치해야 한다면 플랫폼별 다운로드 페이지에서 해당 설치 파일을 선택하고 필요한 로컬 설정을 백업하세요.