Clash 설정 파일 완벽 가이드

01 / DOCUMENT SHAPE

YAML 구조 개요: 계층을 먼저 보고 필드를 수정하기

최상위 블록은 어떻게 함께 작동하는가

실행 가능한 Clash Meta 설정은 서로 무관한 필드의 모음이 아니라, 명확한 참조 방향을 가진 처리 흐름입니다. 공통 필드는 리스닝 포트, 실행 모드 및 LAN 접근 범위를 정하고, dns는 도메인 확인 방식을 결정합니다. proxies와 proxy-providers는 사용할 프록시를 제공하고, proxy-groups는 프록시와 다른 정책 그룹을 선택·속도 측정·장애 조치 관계로 구성합니다. rule-providers는 외부 규칙 모음을 제공하며, 마지막으로 rules가 작성 순서에 따라 연결을 특정 정책 그룹으로 전달합니다. 어느 한 단계의 이름이라도 일치하지 않으면 뒤의 구조가 문법상 올바르더라도 로딩 또는 실행 단계에서 작동하지 않을 수 있습니다.

YAML은 들여쓰기로 부모·자식 관계를 표현하며, 보통 공백 두 칸을 사용하고 탭은 섞지 않습니다. 콜론 뒤에는 공백이 필요하고, 목록 항목은 하이픈으로 시작하며 같은 수준의 필드는 동일한 들여쓰기를 유지해야 합니다. 문자열에 따옴표를 사용할지는 내용에 따라 결정합니다. 일반적인 영문 이름은 그대로 작성해도 되지만 콜론, 샵, 중괄호가 포함되거나 불리언으로 해석될 수 있는 내용은 따옴표를 쓰는 편이 안전합니다. 정책 그룹 이름에 공백이나 한글을 사용해도 되지만 모든 참조 위치에서 대소문자, 공백, 문장 부호까지 완전히 같아야 합니다.

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query

proxies:
  - name: "예시 노드"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "예시 노드"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,노드 선택
  - MATCH,DIRECT

매핑, 시퀀스, 스칼라의 차이

dns: 뒤에는 키·값 필드 묶음인 매핑이 오고, nameserver: 뒤에는 각 업스트림 서버가 목록 항목 하나를 차지하는 시퀀스가 옵니다. mode: rule의 rule은 스칼라입니다. 가장 흔한 구조 오류는 목록 항목에 속해야 할 필드를 최상위로 되돌리거나, 두 번째 노드의 필드를 첫 번째 노드 내부에 계속 들여쓰는 경우입니다. 복잡한 노드는 ‘하이픈 하나로 완전한 객체 하나를 시작’하는 형식이 좋습니다. 각 객체의 내부 필드를 세로로 맞추면 잘못된 계층을 쉽게 발견할 수 있습니다.

YAML 앵커와 별칭으로 일부 설정을 재사용할 수 있지만, 구독 변환기·클라이언트 오버라이드·일부 편집기는 고급 YAML 문법을 완전히 동일하게 처리하지 않습니다. 장기 유지보수가 목적이라면 명시적인 필드를 우선 사용하세요. 많은 노드가 실제로 같은 매개변수를 공유하고 로딩 체인이 앵커를 지원한다는 점을 확인한 경우에만 &name과 *name을 도입하는 것이 좋습니다. 설정 몇 줄을 반복하는 편이 숨겨진 상속 관계보다 문제를 해결하기 쉽습니다.

최소 설정과 전체 설정

최소 설정에는 리스닝 포트, 프록시 하나, 정책 그룹 하나와 마지막 규칙만 포함할 수 있지만, 실제 사용에서는 DNS, 구독 제공자, 규칙 모음, TUN 및 지속성 설정도 필요한 경우가 많습니다. 먼저 최소 골격이 정상적으로 로드되는지 확인한 뒤 블록을 하나씩 추가하세요. 복잡한 설정 전체를 한꺼번에 넣고 문제를 해결하려 하면 원인이 DNS인지, 노드 매개변수인지, 규칙 참조인지 판단하기 어렵습니다. 새 블록을 추가할 때는 ‘로드 성공, 연결 성공, 규칙 매칭 정상’의 세 단계를 각각 검증해 모든 이상을 설정 파일 자체의 문제로 단정하지 않도록 하세요.

설정 파일의 주석은 #으로 시작하며 필드 용도와 변경 이유를 기록하는 데 유용합니다. 다만 주석 설명에 의존하는 핵심 이름을 자주 바꾸지는 마세요. 구독 업데이트로 노드와 정책 그룹 영역이 다시 생성되면 로컬 주석도 덮어써질 수 있습니다. 장기적인 설명은 별도 문서에 보관하고, 설정 안에는 현장에서 문제를 해결하는 데 필요한 짧은 주석만 남기세요. 예를 들어 특정 직접 연결 규칙이 LAN 기기를 위한 것인지, 특정 DNS 업스트림이 프록시를 통해서만 접근 가능한지 등을 기록할 수 있습니다.

02 / GENERAL

공통 필드: 포트, 모드, 리스닝 및 실행 상태

포트 필드 선택 방법

port는 HTTP 프록시 포트를, socks-port는 SOCKS5 포트를 제공하며, mixed-port는 하나의 포트에서 HTTP와 SOCKS5 요청을 모두 받습니다. 데스크톱 클라이언트에서 다른 프로그램에 프록시 주소 하나만 노출하면 된다면 mixed-port가 가장 간단합니다. 특정 소프트웨어가 한 가지 프로토콜만 요구하거나 두 연결 유형을 따로 기록해야 한다면 포트를 분리할 수 있습니다. 포트 번호는 다른 프로세스가 사용하지 않으면 되며 특정한 관용 번호로 고정할 필요는 없습니다.

redir-port와 tproxy-port는 투명 프록시 진입점으로, 보통 Linux 방화벽 규칙과 함께 사용하며 시스템 프록시 포트와는 다릅니다. 이 두 필드만 작성한다고 트래픽을 자동으로 가로채지는 않습니다. 라우팅 테이블, 정책 라우팅 및 nftables 또는 iptables 규칙이 함께 필요합니다. 그래픽 클라이언트의 TUN 모드는 대개 클라이언트가 가상 네트워크 카드와 라우팅을 생성하므로, 라우터의 투명 프록시 규칙을 그대로 동시에 적용하면 이중 전달이나 루프가 발생할 수 있습니다.

mode는 규칙 처리 참여 여부를 결정합니다

mode: rule은 rules를 위에서 아래로 매칭하며 일상적인 트래픽 분할의 기본 모드입니다. global은 연결을 하나의 전역 정책으로 보내므로 특정 노드의 사용 가능 여부를 임시로 확인할 때 유용하지만 기존 규칙 로직을 우회합니다. direct는 대상에 직접 연결하여 장애가 프록시 체인 때문인지 판단할 때 적합합니다. ‘규칙이 매칭되지 않는’ 문제를 해결할 때는 먼저 현재 실행 모드가 여전히 rule인지 확인하세요. 그래픽 클라이언트의 모드 전환이 설정 파일의 초기값을 덮어쓸 수 있기 때문입니다.

log-level은 로그의 상세 수준을 제어합니다. 정상 실행에는 info를 사용하고, 규칙이나 연결 문제를 찾을 때만 일시적으로 debug로 높인 뒤 점검이 끝나면 되돌리세요. 로그가 계속 늘어나는 것을 막을 수 있습니다. 로그의 규칙 매칭, DNS 조회, 다이얼 실패 및 시간 초과 정보는 분리해서 봐야 합니다. 특정 정책 그룹이 선택되었다는 것은 트래픽 분할 결과가 정해졌다는 뜻일 뿐, 그룹 안의 최종 노드 연결 성공을 의미하지는 않습니다.

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: strict

LAN 접근 및 리스닝 범위

allow-lan은 다른 기기가 Clash의 리스닝 포트에 접근할 수 있는지 결정합니다. true로 설정한 뒤에도 운영체제 방화벽에서 해당 포트를 허용하고, Clash가 실행 중인 기기의 LAN 주소를 프록시 서버로 사용해야 합니다. bind-address는 리스닝 주소를 제한합니다. 로컬에서만 사용할 때는 루프백 범위를 유지하고, LAN 공유가 필요할 때만 리스닝 범위를 넓히세요. 공유 프록시를 공용 네트워크 인터페이스에 직접 노출해서는 안 되며, 특히 클라우드 서버나 공인 주소가 있는 네트워크 카드에서는 더욱 주의해야 합니다.

external-controller는 제어 인터페이스를 제공하며 그래픽 클라이언트와 웹 패널이 이를 통해 연결, 로그 및 정책 상태를 읽습니다. 제어 인터페이스와 프록시 포트의 용도는 다르므로 브라우저 프록시 주소로 사용하면 안 됩니다. 제어 인터페이스를 외부에서 접근할 수 있게 할 경우 인증 정보를 설정하고 방화벽에서 허용 출처를 제한하세요. 설정에 포함된 제어 인증 정보는 로컬 민감 정보이므로 공개 저장소나 공개 질문 게시판에 올리지 마세요.

ipv6은 코어가 IPv6 주소를 처리하고 반환할지에 영향을 주지만 단순한 네트워크 가속 스위치는 아닙니다. 업스트림 네트워크, 프록시 노드, 대상 사이트 중 어느 한 단계라도 IPv6 경로가 완전하지 않으면 일부 연결이 대기하다가 다른 경로로 전환될 수 있습니다. 사용 가능한 IPv6 네트워크가 없다면 비활성화하는 편이 동작을 일정하게 유지하기 쉽습니다. 완전한 듀얼 스택 환경일 때만 활성화하고 DNS 응답과 실제 연결 경로를 각각 확인하세요.

03 / DNS PIPELINE

DNS 설정: 확인 경로, Fake-IP 및 트래픽 분할 관계

DNS 블록이 해결하는 것은 단순한 주소 확인 하나가 아닙니다

Clash의 DNS 모듈은 도메인을 주소로 확인할 뿐 아니라 도메인 규칙, Fake-IP 매핑 및 정책별 업스트림 선택의 기반도 제공합니다. 내장 DNS를 끄면 앱이 시스템 확인 결과를 직접 사용하는 경우가 많아 코어가 대상 IP만 보게 되고, 도메인에 의존하는 규칙이 안정적으로 매칭되지 않을 수 있습니다. DNS를 활성화할 때는 가로챌 요청이 실제로 DNS 리스닝 주소로 들어오게 해야 합니다. 설정에 dns.enable: true만 작성하고 시스템이 계속 다른 서버로 조회를 보낸다면 완전한 확인 경로가 구성되지 않습니다.

listen은 DNS 서비스의 리스닝 위치와 포트를 지정합니다. 데스크톱 GUI의 TUN 구현은 보통 DNS 하이재킹을 자동으로 처리하지만, 라우터에서 직접 실행할 때는 LAN 클라이언트의 조회를 해당 리스닝 포트로 전달하거나 방화벽에서 리디렉션해야 합니다. 모든 인터페이스에서 리스닝한다면 방화벽 접근 범위도 함께 확인해 재귀 조회 서비스가 통제되지 않는 네트워크에 노출되지 않도록 하세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.local"

default-nameserver, nameserver 및 프록시 노드 도메인

nameserver는 기본 업스트림 확인 서버로, 일반 UDP 주소와 암호화 DNS 주소를 모두 입력할 수 있습니다. 암호화 DNS 자체가 도메인 이름이라면 코어가 먼저 해당 도메인의 주소를 알아야 하므로 default-nameserver가 초기 확인을 담당해야 합니다. 초기 확인 서버에는 직접 접근 가능한 IP 주소를 주로 사용해 ‘업스트림 도메인을 확인해야 업스트림에 접근할 수 있는데, 확인이 다시 해당 업스트림에 의존하는’ 순환을 피하세요.

proxy-server-nameserver는 프록시 서버 자체의 도메인을 확인하는 데 사용됩니다. 프록시 노드가 아직 연결되지 않은 상태에서는 노드 도메인을 먼저 확인해야 하므로, 현재 네트워크에서 직접 접근 가능하고 결과가 안정적인 업스트림을 우선 선택해야 합니다. 노드 도메인 확인을 해당 노드를 통해서만 접근할 수 있는 서버로 강제하면 시작 의존성 순환이 발생합니다. 노드가 모두 시간 초과되지만 IP 주소로 입력한 노드는 정상이라면 이 계층을 먼저 확인하세요.

respect-rules를 사용하면 DNS 조회도 규칙을 참고해 출구를 선택할 수 있어 확인 트래픽까지 분할해야 하는 설정에 적합합니다. 다만 초기 확인, 프록시 노드 확인, 기본 확인 사이에 서로 기다리는 구조가 생기지 않도록 해야 합니다. 설정이 복잡하다면 먼저 규칙 인식을 끄고 기본 확인을 검증한 다음 단계적으로 활성화하는 편이 모든 DNS 옵션을 한 번에 추가하는 것보다 안전합니다.

Fake-IP와 Redir-Host의 차이

fake-ip 모드는 예약 주소 풀에서 매핑 주소를 반환합니다. 앱이 해당 주소에 연결하면 코어가 매핑 테이블을 통해 원래 도메인을 복원하고 규칙을 적용합니다. 이 방식은 연결 단계에서 도메인 정보를 유지하고, 앱이 실제 주소를 먼저 받아 연결하면서 발생하는 트래픽 분할 오류도 줄여 줍니다. 주소 풀은 로컬 또는 통제된 네트워크 안에서 매핑용으로만 사용되며 대상 웹사이트의 실제 주소가 아닙니다. 예약된 대역이 반환된다고 해서 DNS 오류는 아닙니다.

redir-host는 실제 확인 주소를 반환하므로 실제 IP에 의존하는 LAN 서비스, 일부 게임 및 특수한 네트워크 검사와 호환성이 좋지만 도메인과 후속 연결을 연결하는 기능은 상대적으로 제한됩니다. 프린터 검색, LAN 호스트 이름, 기기 화면 전송 또는 특정 앱 로그인에 문제가 생기면 전체 강화 모드를 바꾸지 말고 해당 도메인을 먼저 fake-ip-filter에 추가해 보세요. 필터 목록은 가능한 한 정확하게 작성해야 합니다. 범위를 너무 넓히면 많은 도메인이 매핑을 우회해 도메인 규칙의 일관성이 떨어집니다. 매핑 과정과 필터 범위는 Fake-IP 모드 원리 자세히 보기에서 이어서 확인할 수 있습니다.

nameserver-policy를 이용한 선택적 DNS 확인

nameserver-policy를 사용하면 특정 도메인이 지정된 DNS 업스트림을 사용하도록 설정할 수 있습니다. 내부 도메인은 LAN DNS에, 특정 공용 도메인군은 다른 확인 서버에 맡기는 식입니다. 정책 키에는 도메인 규칙 모음이나 도메인 매칭 형식을 사용할 수 있고, 값에는 업스트림 하나 또는 여러 업스트림을 지정할 수 있습니다. 이 기능은 ‘특정 도메인을 어디에서 확인할지’를 정하는 것이며 ‘최종 연결이 어느 프록시를 통과할지’를 정하는 기능은 아닙니다. 연결 출구는 여전히 rules와 정책 그룹이 결정합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.corp.example":
      - 192.168.1.1
    "rule-set:private-domain":
      - 192.168.1.1

04 / PROXY OBJECTS

프록시 노드 필드: 연결 대상, 프로토콜 매개변수 및 제공자

노드 객체의 공통 골격

proxies는 노드 객체 목록입니다. 각 객체에는 최소한 이름, 유형, 서버 주소 및 포트가 필요하며 인증, 전송 및 암호화 필드는 프로토콜에 따라 달라집니다. name은 다른 블록에서 노드를 참조하는 고유 식별자이므로 중복해서는 안 됩니다. 이름이 같은 노드가 둘이면 UI 표시와 정책 참조를 구분하기 어려워집니다. server에는 IP 또는 도메인을 사용할 수 있지만 도메인을 입력할 때는 노드 연결 전에 DNS 블록이 해당 도메인을 확인할 수 있어야 합니다.

프로토콜 필드는 유형을 넘어 그대로 복사해서는 안 됩니다. 한 프로토콜에서 유효한 필드가 다른 노드 유형에서도 같은 효과를 내는 것은 아닙니다. 알 수 없는 필드는 무시될 수도 있고 설정 검사에 실패할 수도 있습니다. 구독을 정리할 때는 프로토콜에 필요한 매개변수만 남기고 변환 과정에서 남았지만 코어가 인식하지 못하는 장식용 필드는 삭제하세요. 노드 연결에 실패하면 먼저 유형, 서버, 포트, 인증 네 가지를 확인한 다음 TLS, 전송 계층 및 서버 이름을 점검하세요. 정책 그룹이나 규칙부터 수정해서는 안 됩니다.

proxies:
  - name: "업무용 SOCKS"
    type: socks5
    server: 192.168.1.10
    port: 1080
    username: "proxy-user"
    password: "your-password"
    udp: true

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

TLS와 서버 이름

TLS를 사용하는 프로토콜에는 일반적으로 tls, 서버 이름 및 인증서 검증 설정이 포함됩니다. 서버 이름은 핸드셰이크 단계에서 인증서와 가상 호스트를 선택하는 데 사용하며, 노드 연결 주소와 같을 수도 있고 서버에서 별도로 지정할 수도 있습니다. 연결 주소를 IP로 작성했는데 서버 인증서가 도메인으로 발급되었다면 서버 이름을 정확히 입력하는 것이 특히 중요합니다. 인증서 오류를 장기간 검증 비활성화로 가리지 말고 시스템 시간, 노드 정보, 서버 이름 및 중간 네트워크를 먼저 확인하세요. 프록시를 켠 뒤 브라우저에 인증서 경고가 표시되면 HTTPS 인증서 오류 단계별 문제 해결을 참고하세요.

WebSocket, gRPC 등의 전송 계층에는 경로, Host 또는 서비스 이름도 포함될 수 있습니다. 이 값은 서버 배포 방식에 따라 정해지므로 클라이언트가 추측해서 알아낼 수 없습니다. 경로의 슬래시, 대소문자 및 빈 문자 하나도 핸드셰이크에 영향을 줄 수 있으며, 구독 변환 시 중첩 필드를 잘못 펼치지 않도록 해야 합니다. TCP로 서버 포트까지 연결되지만 곧바로 종료되고 로그에 핸드셰이크 실패가 나타난다면 네트워크 도달성보다 TLS와 전송 계층 매개변수를 우선 점검하세요.

proxy-providers로 동적 노드 모음 관리

노드가 많거나 출처를 주기적으로 갱신해야 한다면 proxy-providers를 사용할 수 있습니다. 제공자는 파일 또는 원격 주소에서 노드를 읽고 상태 확인을 설정할 수 있습니다. 정책 그룹은 각 노드 이름을 proxies에 직접 입력하는 대신 use로 제공자 전체를 참조합니다. 이 구조는 구독 업데이트 후 새 노드가 정책 그룹에서 누락되는 문제를 줄이고, 서로 다른 출처를 별도 모음으로 관리하기도 쉽습니다.

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/primary.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxy-groups:
  - name: "자동 선택"
    type: url-test
    use:
      - primary
    url: https://www.gstatic.com/generate_204
    interval: 300

path는 제공자 콘텐츠의 로컬 캐시 위치이며, 실행 중인 사용자는 상위 디렉터리에 쓰기 권한이 있어야 합니다. 컨테이너와 시스템 서비스 환경에서는 상대 경로가 설정 파일이 아닌 프로세스의 작업 디렉터리를 기준으로 하므로 주의해야 합니다. 제공자 다운로드는 성공했지만 캐시 저장에 실패한다면 실제 작업 디렉터리와 마운트 경로를 확인하세요. 원격 주소의 접근 매개변수는 민감한 설정이므로 로그나 설정 일부를 공유하기 전에 삭제해야 합니다.

상태 확인은 테스트 주소에 해당 노드를 통해 요청을 완료할 수 있는지만 판단하며, 모든 대상에 접근할 수 있다는 뜻도 아니고 대역폭 측정과도 다릅니다. 테스트 주소는 안정적이고 응답 본문이 작으며 일상 트래픽의 프로토콜 요구와 비슷해야 합니다. 확인 간격이 너무 짧으면 연결을 계속 생성해 노드가 많을 때 리소스 사용량이 늘고, 너무 길면 장애 상태 반영이 늦어집니다. 노드 수와 전환 요구에 맞춰 균형을 잡으세요.

05 / POLICY LAYER

정책 그룹 필드: 선택, 속도 측정, 장애 조치 및 중첩

정책 그룹은 규칙과 노드 사이의 조정 계층입니다

규칙은 보통 특정 노드를 직접 가리키지 않고 정책 그룹을 가리킵니다. 따라서 노드가 바뀌어도 전체 규칙을 다시 작성할 필요 없이 그룹 구성원이나 현재 선택만 조정하면 됩니다. select 그룹은 사용자가 직접 구성원을 선택하고, url-test는 테스트 결과에 따라 자동 선택하며, fallback은 구성원 순서대로 사용 가능한 항목을 찾고, load-balance는 여러 사용 가능 구성원에 연결을 분배합니다. 유형마다 해결하는 문제가 다르므로 UI에 표시되는 지연 시간만으로 적합성을 판단해서는 안 됩니다.

proxies 목록에는 노드뿐 아니라 다른 정책 그룹과 DIRECT, REJECT 같은 내장 정책도 넣을 수 있습니다. 중첩을 사용하면 ‘서비스 분류’와 ‘노드 선택’을 분리할 수 있습니다. 예를 들어 스트리밍 규칙이 ‘미디어 서비스’를 가리키고, 미디어 서비스가 다시 ‘노드 선택’을 참조하게 구성할 수 있습니다. 그러나 중첩이 지나치게 깊으면 판단이 어려워지고 순환 참조가 발생할 수도 있습니다. 의존성 방향은 한쪽으로만 내려가야 하며 어떤 그룹도 자신을 직접 또는 간접적으로 포함해서는 안 됩니다.

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "자동 선택"
      - "장애 조치"
      - "예시 노드"
      - DIRECT

  - name: "자동 선택"
    type: url-test
    proxies:
      - "예시 노드"
      - "보조 노드"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: "장애 조치"
    type: fallback
    proxies:
      - "예시 노드"
      - "보조 노드"
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: "미디어 서비스"
    type: select
    proxies:
      - "노드 선택"
      - DIRECT

속도 측정 결과를 해석하는 방법

url-test는 클라이언트가 노드를 통해 지정된 테스트 주소에 접근을 완료하는 데 걸린 시간을 측정합니다. 여기에는 연결 설정과 요청 응답이 포함되며 모든 웹사이트에 적용되는 일반적인 지연 시간은 아닙니다. 테스트 주소가 속한 네트워크, 해당 주소까지의 노드 경로 및 로컬 DNS가 결과에 영향을 줍니다. 테스트 값이 낮은 노드가 실제 다운로드에서는 느릴 수 있는데, 이는 대역폭, 혼잡, 대상 사이트까지의 경로 또는 연결 재사용 차이 때문일 수 있으며 정책 그룹의 계산 오류는 아닙니다. 속도 문제는 노드·회선·로컬 설정의 세 계층으로 나누어 확인하세요.

tolerance는 결과가 비슷한 노드 사이에서 빈번한 전환을 막습니다. 새 결과가 현재 노드보다 조금 나을 뿐이라면 연결을 계속 유지하는 편이 반복 선택보다 안정적입니다. interval은 주기적인 확인을 제어하고, lazy는 비활성 정책의 테스트를 줄일 수 있습니다. 매개변수는 사용 방식에 맞춰 조정해야 합니다. 가끔 연결하는 데스크톱과 상시 실행되는 라우터의 리소스 예산은 다르고, 노드 수가 늘면 상태 확인 요청량도 함께 증가합니다.

fallback과 load-balance의 사용 범위

fallback은 순서와 사용 가능 여부를 중시합니다. 앞쪽 구성원이 사용 가능하면 계속 사용하므로 주 회선과 예비 회선이 명확한 구성에 적합합니다. 최저 지연 시간만을 목표로 하지 않으므로 예비 노드의 지연 시간이 더 낮아도 선택되지 않을 수 있습니다. load-balance는 여러 연결을 분배하기 위한 기능이며 하나의 다운로드 연결을 여러 노드로 나눈다는 뜻은 아닙니다. 단일 TCP 또는 UDP 세션은 소스 주소 변경으로 세션이 깨지지 않도록 보통 하나의 출구를 유지합니다.

로드 밸런싱에서는 동일한 대상에 고정된 출구가 필요한지도 고려해야 합니다. 로그인, 결제, CAPTCHA 또는 출처 주소에 민감한 서비스는 연속 요청이 서로 다른 노드로 나뉘면 재인증을 요구할 수 있습니다. 이때는 대상 매핑을 유지하는 정책을 사용하거나 관련 도메인을 고정 노드 그룹에 넣으세요. 일반 사용자라면 명확한 수동 선택 그룹과 자동 속도 측정 그룹 하나를 조합하는 편이 다층 로드 밸런싱보다 유지 관리하기 쉽습니다.

이름 설계가 장기 유지보수에 미치는 영향

정책 그룹 이름은 규칙의 마지막 항목과 클라이언트 UI에 모두 표시됩니다. ‘노드 선택’, ‘장애 조치’, ‘미디어 서비스’, ‘메신저’처럼 용도 중심으로 이름을 정하고, 노드 지역·프로토콜·서비스 용도를 하나의 긴 이름에 모두 넣지 않는 것이 좋습니다. 규칙 제공자와 정책 그룹은 일대다 또는 다대일로 연결할 수 있지만 이름은 안정적으로 유지해야 합니다. 이름을 자주 바꾸면 기존 오버라이드, 스크립트 및 로컬 규칙이 동시에 작동하지 않을 수 있습니다.

구독에서 제공하는 정책 그룹은 업데이트 때 다시 생성될 수 있습니다. 로컬에서 장기적으로 유지해야 하는 그룹은 클라이언트가 지원하는 오버라이드 계층에 두고 삽입 위치를 명확히 지정하세요. 규칙이 로컬 그룹을 가리키는데 오버라이드 실행 순서가 규칙 병합보다 늦으면 최종 설정에 정의되지 않은 참조가 잠시 생길 수 있습니다. 점검할 때는 특정 조각의 존재만 보지 말고 최종 파일에 정책 그룹이 정의되어 있으며 코어가 로드하는 동일한 설정 범위 안에 정의가 포함되는지 확인하세요.

06 / RULE ENGINE

규칙 문법: 위에서 아래로 매칭하며 첫 번째 매칭이 적용됩니다

규칙 순서가 실제 우선순위입니다

rules는 순서가 있는 목록입니다. 연결은 첫 항목부터 검사하며 첫 번째로 매칭된 규칙이 지정한 정책을 즉시 적용하고 이후 규칙은 처리하지 않습니다. 따라서 정확한 도메인과 별도 처리가 필요한 서비스는 앞에 두고, 넓은 도메인 접미사·IP 대역·지역 집합은 중간에 배치하며, MATCH는 마지막에 두어 나머지 연결을 처리합니다. 범위가 넓은 규칙을 앞에 배치하는 것은 ‘규칙을 작성했는데도 적용되지 않는’ 주요 원인 중 하나입니다.

규칙은 보통 유형, 매칭 값 및 정책 이름으로 구성하며 영문 쉼표로 구분합니다. 정책 이름은 정의된 정책 그룹, 노드 또는 내장 정책과 일치해야 합니다. 일부 규칙에는 추가 옵션을 넣을 수 있습니다. 예를 들어 IP 규칙의 no-resolve는 주소를 얻기 위한 추가 확인을 매칭 과정에서 수행하지 않도록 합니다. 규칙의 쉼표는 구조를 나누는 구분자이므로 특수한 내용을 YAML 따옴표로 감싸도 Clash의 규칙 해석 방식 자체가 바뀌지는 않습니다.

rules:
  - DOMAIN,api.example.com,노드 선택
  - DOMAIN-SUFFIX,example.com,노드 선택
  - DOMAIN-KEYWORD,example,노드 선택
  - PROCESS-NAME,example.exe,DIRECT
  - DST-PORT,22,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,노드 선택

도메인 규칙의 적용 범위

DOMAIN은 완전한 도메인 하나만 매칭하므로 단일 API나 호스트에 적합합니다. DOMAIN-SUFFIX는 해당 도메인과 하위 도메인을 매칭해 사이트 전체에 사용할 수 있습니다. DOMAIN-KEYWORD는 도메인에 지정 문자열이 포함되기만 해도 매칭될 수 있어 범위가 가장 넓고 오매칭도 쉽습니다. 접미사 규칙으로 해결할 수 있다면 몇 줄을 줄이려고 키워드 규칙을 사용하지 마세요. 키워드가 너무 짧으면 대상 서비스와 무관한 도메인까지 매칭될 수 있습니다.

도메인 매칭은 연결 단계에서 코어가 원래 호스트 이름을 알고 있어야 합니다. HTTP 또는 TLS 서버 이름, Fake-IP 매핑 및 스니핑이 도메인 정보를 제공할 수 있지만, 앱이 IP에 직접 연결하면 도메인 규칙은 당연히 매칭되지 않습니다. 이때는 같은 도메인을 여러 형식으로 반복 추가하기보다 앱 자체의 동작을 확인해야 합니다. 트래픽 스니핑을 활성화하면 일부 연결의 도메인 식별을 보완할 수 있지만 지원되는 프로토콜과 포트에 한계가 있으며 올바른 DNS 가로채기를 대신할 수는 없습니다.

IP, 포트 및 프로세스 규칙

IP-CIDR과 IP-CIDR6는 대상 주소 범위로 매칭하므로 LAN, 예약 주소 및 명확한 서비스 대역에 적합합니다. 공용 서비스의 주소는 바뀌거나 여러 서비스가 공유할 수 있어 공용 IP를 많이 수동 관리하는 것보다 도메인이나 규칙 모음이 안정적인 경우가 많습니다. GEOIP는 주소 데이터베이스에 따라 분류하며 결과는 로컬 데이터 파일에 좌우됩니다. 데이터가 오래되면 새로 할당된 주소가 예상과 다른 분류에 들어갈 수 있으므로 데이터베이스 업데이트도 규칙 유지보수의 일부입니다.

DST-PORT는 대상 포트로 매칭하며 같은 포트를 사용하는 서로 다른 웹사이트를 구분하지 못합니다. 현대 웹 트래픽은 443 포트를 많이 공유하므로 포트 전체를 하나의 정책으로 보내는 것은 범위가 지나치게 넓을 수 있습니다. 프로세스 규칙은 프로그램 이름이나 경로로 매칭할 수 있지만 지원 여부는 운영체제, 실행 권한 및 가로채기 방식에 따라 다릅니다. 게이트웨이 장비는 단말의 프로세스를 볼 수 없고 일부 샌드박스 앱도 완전한 프로세스 정보를 제공하지 않습니다. 여러 플랫폼에서 사용할 설정을 프로세스 규칙에 전적으로 의존해서는 안 됩니다.

rule-providers로 대규모 규칙 모음 분리

rule-providers는 규칙 내용을 로컬 파일 또는 원격 리소스에 두고, 기본 규칙 목록에서 RULE-SET으로 참조하게 합니다. 제공자에는 동작 유형, 형식, 캐시 경로 및 업데이트 주기를 선언해야 합니다. domain 유형은 도메인 모음에, ipcidr는 주소 대역에, classical은 여러 클래식 규칙에 사용할 수 있습니다. 동작 유형과 파일 내용이 일치해야 하며, 다운로드가 성공해도 예상대로 파싱되지 않을 수 있습니다.

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: "https://example.com/rules/private-domain.yaml"
    interval: 86400

  private-ip:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./rules/private-ip.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,노드 선택

규칙 제공자의 업데이트 실패가 코어를 즉시 중지시키는 것은 아닙니다. 기존 캐시가 계속 사용될 수 있기 때문입니다. 따라서 ‘설정 로드 성공’과 ‘규칙 업데이트 완료’는 별개의 상태입니다. 새 도메인이 매칭되지 않으면 제공자 상태, 캐시 파일 수정 시간, 다운로드 응답 내용 및 동작 유형을 확인하세요. 원격 리소스가 규칙 파일 대신 웹 오류 페이지를 반환하면 네트워크 요청은 성공으로 표시되어도 파싱 단계에서 실패할 수 있습니다.

마지막 정책은 설정의 기본 방향을 보여 줍니다. MATCH,노드 선택으로 끝내면 분류되지 않은 트래픽을 프록시 선택 그룹으로 보내고, MATCH,DIRECT로 끝내면 명시된 대상만 프록시를 사용합니다. 두 설계 모두 가능하며, 규칙 데이터베이스의 적용 범위가 사용자 기대와 일치하는지가 중요합니다. 마지막 정책을 바꾸면 매칭되지 않은 모든 연결에 영향을 주므로 특정 웹사이트를 임시로 고치는 스위치처럼 사용하지 말고 별도로 검증하세요.

07 / MERGE LAYERS

오버라이드 및 병합: 구독 업데이트 후 로컬 설정 유지

먼저 설정의 출처 계층을 파악하기

그래픽 클라이언트의 최종 설정은 보통 여러 출처로 구성됩니다. 원격 구독은 노드와 기본 정책을 제공하고, 로컬 오버라이드는 공통 필드를 수정하거나 규칙을 추가하며, 클라이언트 자체 설정은 시스템 프록시, TUN, 제어 포트 등의 실행 매개변수를 결정합니다. 화면의 ‘구독 내용’은 그중 한 계층에 불과한 경우가 많습니다. 특정 필드가 왜 바뀌었는지 판단하려면 병합 순서와 같은 이름의 필드가 충돌할 때 덮어쓰기, 추가 또는 깊은 병합 중 어떤 방식이 적용되는지 알아야 합니다.

클라이언트마다 오버라이드 명칭과 기능이 완전히 같지는 않습니다. YAML 조각, 스크립트 또는 전·후순위 규칙을 지원하는 방식이 각각 다릅니다. 클라이언트를 옮길 때 기존 오버라이드가 그대로 실행될 것이라고 가정해서는 안 됩니다. Clash Plus는 일반 사용자의 기본 그래픽 진입점으로 적합합니다. 다른 클라이언트가 필요하다면 다운로드 페이지에서 플랫폼별로 Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android, Surfboard 및 보관 클라이언트를 비교하세요.

매핑 덮어쓰기와 목록 추가는 같은 작업이 아닙니다

mode, log-level, dns.enable 같은 단일 값 필드는 오버라이드 시 새 값이 기존 값을 대체하는 경우가 많습니다. rules, proxies, proxy-groups 같은 목록을 단순히 덮어쓰면 구독의 기존 내용이 삭제되고, 단순히 추가하면 새 규칙이 MATCH 뒤에 놓여 영원히 매칭되지 않을 수 있습니다. 따라서 목록을 수정할 때는 위치를 명확히 해야 합니다. 사용자 정의의 정확한 규칙은 보통 넓은 범위의 규칙 앞에 넣고, 기본 규칙은 항상 마지막에 유지하세요.

매핑의 깊은 병합에도 한계가 있습니다. fake-ip-filter 항목 하나만 추가하려 했는데 병합기가 전체 dns 객체를 교체하면 기존 nameserver와 리스닝 필드가 사라집니다. 반대로 DNS를 완전히 교체하려 했는데 도구가 키별 병합을 수행하면 구독에 남아 있던 정책 필드가 계속 유지됩니다. 오버라이드를 사용하기 전에 클라이언트가 객체와 배열을 처리하는 방식을 확인하고, 오버라이드 조각의 문법만 보지 말고 최종 설정으로 결과를 검증하세요.

# 로컬 오버라이드 조각 예시
mode: rule
log-level: info

dns:
  enable: true
  fake-ip-filter:
    - "*.lan"
    - "+.local"

rules:
  - DOMAIN,internal.example,DIRECT
  - DOMAIN-SUFFIX,example.com,노드 선택

규칙 삽입 위치가 오버라이드 적용 여부를 결정합니다

구독 마지막에 이미 MATCH,노드 선택이 있다고 가정해 보겠습니다. 로컬 규칙을 목록 끝에 그대로 추가하면 절대 실행되지 않습니다. 올바른 방법은 기본 규칙 앞에 삽입하거나 오버라이드 도구의 ‘선행 규칙’ 기능을 사용하는 것입니다. 구독에 범위가 넓은 DOMAIN-SUFFIX, GEOIP 또는 규칙 모음이 포함되어 있다면 로컬의 정확한 예외 규칙도 이 넓은 규칙보다 앞에 둬야 합니다. 규칙에는 명시적인 우선순위 숫자가 없으며 위치가 곧 우선순위입니다.

정책 그룹을 오버라이드할 때는 구성원 참조도 처리해야 합니다. ‘개발 서비스’라는 그룹을 새로 만드는 것만으로는 충분하지 않습니다. 규칙이 해당 그룹을 가리켜야 하고, 그룹 내부에서 참조하는 ‘노드 선택’도 최종 설정에 존재해야 합니다. 구독 제공자가 정책 그룹 이름을 바꾸면 로컬 오버라이드가 정상적으로 병합되어도 로드 시 정의되지 않은 정책 오류가 발생할 수 있습니다. 구독의 사용자 정의 이름에 대한 의존성을 줄이거나, 구독 구조가 바뀔 때마다 최종 참조 그래프를 확인하는 편이 안전합니다.

스크립트 오버라이드는 조건부 수정에 적합하지만 복잡도를 제한해야 합니다

스크립트로 노드를 순회하거나 정책 그룹을 다시 만들고 이름에 따라 규칙을 삽입할 수 있어, 업데이트 때마다 달라지는 목록을 처리하는 데 유용합니다. 그러나 필드가 없거나 노드 이름에 특수 문자가 포함되거나 클라이언트 업그레이드로 입력 구조가 바뀌는 등 새로운 실패 지점도 생깁니다. 모든 구독이 같은 골격을 가진다고 가정하지 말고 객체 유형과 배열 존재 여부를 먼저 검사하세요. 오류가 발생하면 불완전한 결과를 반환하지 말고 원래 설정을 보존하면서 명확한 로그를 남겨야 합니다.

복잡한 스크립트는 일반 코드처럼 버전 관리하고 테스트해야 합니다. 수정할 때마다 한 가지 문제만 해결하고 입력 예시를 보존하며, 빈 노드 목록, 정책 그룹 누락, 동일한 규칙의 기존 존재 같은 경계 조건을 처리하세요. 포트 변경이나 규칙 두 개 추가 정도라면 YAML 오버라이드가 스크립트보다 투명한 경우가 많습니다. 선언형 조각으로 반복 작업을 표현하기 정말 어려울 때만 스크립트를 사용하세요.

코어 직접 실행 시의 병합 전략

mihomo를 직접 실행할 때는 배포 과정에서 템플릿이나 설정 생성 도구로 병합을 처리할 수 있지만, 생성 결과는 독립적으로 점검 가능한 YAML 한 개여야 합니다. 서비스를 시작하기 전에 임시 파일로 생성하고 검사가 끝난 뒤 정식 설정으로 원자적 교체를 수행하면 병합 중단으로 불완전한 파일이 남는 것을 막을 수 있습니다. 라우터와 보조 라우터 환경에서는 디렉터리 권한, 영구 저장 파티션 및 부팅 순서도 규칙 다운로드와 캐시 복구에 영향을 줍니다. 관련 구조는 라우터 및 보조 라우터 배포 개요를 참고하세요.

08 / VALIDATION

검사 및 문제 해결: 로드 실패부터 트래픽 분할 이상까지

먼저 정적 검사를 수행하고 실행 로그를 확인하세요

설정 문제는 계층별로 처리해야 합니다. 첫 번째 계층은 YAML 파싱 가능 여부로, 들여쓰기·콜론·목록·따옴표를 포함합니다. 두 번째는 Clash 설정 의미가 성립하는지 여부로, 노드 유형·필수 필드·정책 참조·규칙 형식을 확인합니다. 세 번째에 이르러서야 DNS 불통, 노드 핸드셰이크 실패, 시스템 프록시 미활성화 또는 투명 프록시 라우팅 누락 같은 실행 중 네트워크 문제를 다룹니다. 첫 번째 계층을 통과하지 못했다면 노드 지연 시간을 테스트하거나 방화벽을 수정할 필요가 없습니다.

코어를 직접 실행할 때는 설정 검사 매개변수로 지정한 디렉터리의 설정을 검증할 수 있습니다. 실제 명령의 실행 파일 경로와 설정 디렉터리는 배포 위치에 맞게 조정하세요. 그래픽 클라이언트에도 보통 설정 검사, 다시 로드 또는 로그 메뉴가 있습니다. UI에 ‘로드 실패’만 표시된다면 상세 로그를 열어 구체적인 필드를 확인하세요. 검사하기 전에 파일을 저장하고 편집기에 탭이나 보이지 않는 문자가 들어가지 않았는지 확인해야 합니다.

mihomo -t -d /path/to/config-directory
mihomo -d /path/to/config-directory

검사 명령이 통과했다는 것은 코어가 설정 구조를 받아들일 수 있다는 뜻일 뿐, 모든 원격 노드·DNS 업스트림·규칙 제공자에 접근할 수 있다는 의미는 아닙니다. 시작한 뒤에는 제공자 업데이트, DNS 요청, 연결 다이얼 및 규칙 매칭을 관찰해야 합니다. 로그 수준을 일시적으로 debug로 설정하면 더 많은 맥락을 얻을 수 있지만, 분석할 때는 하나의 명확한 요청에 집중해 수많은 백그라운드 연결 속에서 단서를 놓치지 않도록 하세요.

로드 실패의 흔한 원인 분기

오류가 특정 줄을 가리켜도 실제 원인은 바로 앞줄에 있을 수 있습니다. 예를 들어 따옴표를 닫지 않아 이후 내용이 잘못 파싱되거나 상위 들여쓰기가 이미 바뀐 경우입니다. 오류 줄부터 가장 가까운 최상위 필드까지 위로 올라가며 확인하세요. ‘정책을 찾을 수 없음’ 같은 오류가 나타나면 규칙 끝의 이름을 검색한 뒤 정책 그룹 정의도 검색해 공백과 기호까지 한 글자씩 비교하세요. 이름 중복이 발생하면 직접 작성한 노드뿐 아니라 제공자를 펼친 뒤 정적 노드와 이름이 겹치는지도 확인해야 합니다.

한 클라이언트에서는 작동하지만 다른 클라이언트로 옮긴 뒤 실패한다면 지원 필드, 코어 기능 또는 오버라이드 형식이 원인인 경우가 많습니다. 먼저 기본 노드 하나, 선택 그룹 하나, 규칙 두 개만 남긴 최소 설정을 내보내 대상 클라이언트가 로드할 수 있는지 확인한 뒤 블록을 하나씩 복원하세요. 무작정 필드를 계속 삭제하며 운에 맡기지 말고, 매번 한 블록만 바꾸면서 문법 검사·시작·실제 연결 중 어느 단계에서 변화가 생겼는지 기록해야 합니다.

연결은 성공하지만 페이지가 열리지 않음

노드 테스트는 성공했지만 웹페이지가 열리지 않는다면 DNS, 규칙 및 앱 트래픽 가로채기를 분리해 확인해야 합니다. 먼저 mixed-port를 명시한 명령으로 간단한 주소에 접근해 프록시 포트가 작동하는지 확인하세요. 다음으로 브라우저 또는 시스템 프록시가 같은 주소를 가리키는지 점검하고, 대상 도메인이 어떤 규칙과 매칭되었는지 관찰합니다. 로그에 해당 앱의 연결이 전혀 없다면 문제는 가로채기 계층에 있습니다. 연결은 있지만 규칙이 예상과 다르면 규칙 또는 도메인 인식 문제입니다. 정책은 올바르지만 다이얼에 실패한다면 노드와 전송 계층으로 돌아가세요.

일부 웹사이트는 정상인데 다른 사이트가 오래 기다린다면 IPv6, UDP, HTTP/3 및 MTU를 확인하세요. 앱이 IPv6 또는 QUIC를 먼저 시도한 뒤 실패해야 다른 경로로 전환할 수 있습니다. TUN 환경에서 MTU가 너무 크면 작은 요청은 정상이어도 큰 응답이 멈출 수 있습니다. 문제 해결 중에는 단일 기능을 임시로 끄고 비교할 수 있지만, 원인을 확인한 뒤에는 네트워크 조건과 프로토콜 지원을 기준으로 수정하고 서로 충돌하는 임시 스위치를 계속 쌓아 두지 마세요.

TUN 및 투명 프록시 추가 점검

TUN 가로채기는 가상 네트워크 카드, 라우팅 및 권한에 의존합니다. 데스크톱에서는 가상 카드를 만들기 위해 시스템 권한이 필요할 수 있고, Linux에서는 커널 기능, 포워딩 설정 및 정책 라우팅도 관련됩니다. TUN이 활성화된 것으로 표시되지만 앱 트래픽이 로그에 들어오지 않는다면 코어만 재시작하지 말고 기본 경로와 제외 대역을 확인하세요. LAN 대역, 가상 머신 네트워크, 컨테이너 네트워크 및 회사 내부망은 보통 명시적인 직접 연결이 필요합니다. 그렇지 않으면 로컬 서비스가 잘못 프록시로 전달될 수 있습니다.

게이트웨이 투명 프록시에서는 코어 자체의 트래픽이 다시 전달되지 않도록 해야 합니다. 노드 연결, DNS 업스트림 요청 및 규칙 다운로드가 동일한 투명 프록시 체인으로 다시 들어가면 루프가 발생합니다. 일반적인 해결 방법은 실행 사용자, 프로세스 마크 또는 라우팅 마크를 기준으로 제외하는 것이지만, 구체적인 방법은 nftables·iptables 및 시스템 라우팅 설계에 따라 달라집니다. 설정 파일은 리스닝 포트와 TUN 매개변수만 제공할 뿐 운영체제 계층의 완전한 루프 제외를 대신할 수 없습니다.

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

재현 가능한 문제 해결 기록 만들기

유용한 문제 해결 기록에는 최소한 현재 클라이언트 또는 코어 실행 방식, 설정 출처, 문제가 발생한 단계, 한 번의 요청에 해당하는 로그, 정상으로 확인된 단계 및 최근 변경 사항이 포함되어야 합니다. 설정 일부를 공유하기 전에는 구독 주소, 인증 정보, 제어 인증 정보 및 노드 비밀번호를 삭제하되 필드 구조, 정책 이름 및 규칙 순서는 남겨야 합니다. ‘작동하지 않는다’는 설명이나 관련 없는 전체 로그만으로는 오류 계층을 판단하기 어렵습니다.

수정이 끝나면 임시로 높인 로그 수준, 테스트 규칙 및 우회 설정을 정리한 뒤 다시 로드하고 재시험하세요. 장기간 실행하는 라우터나 서버라면 서비스를 재시작해 부팅 경로, 작업 디렉터리 및 캐시 권한을 확인해야 합니다. 현재 터미널 세션에서는 작동하지만 시스템 서비스에서는 실패하는 상황을 방지할 수 있습니다. LAN 공유 환경은 mixed-port 및 allow-lan 설정 가이드에서 리스닝 주소, 방화벽 및 기기 프록시 매개변수가 동일한 경로에 있는지 추가로 확인하세요.