Clash 고급 설정 가이드

프록시 그룹 유형과 트래픽 분기

규칙의 대상과 노드 선택 분리하기

프록시 그룹은 규칙과 실제 아웃바운드 사이를 이어주는 계층입니다. 규칙이 연결을 어느 그룹으로 보낼지 결정하면, 그룹은 사용할 아웃바운드를 선택합니다. 업무 규칙을 특정 노드 이름에 직접 연결하면 노드 이름 변경, 구독 교체, 서비스 제공자 변경이 모두 규칙에 영향을 줍니다. 안정적인 그룹 이름을 정해 두면 그룹 구성원만 관리하면 되므로 규칙은 같은 대상을 계속 참조할 수 있고 장기적인 유지 관리 부담도 줄어듭니다.

proxies는 실제 아웃바운드를 정의하고, proxy-groups는 선택하거나 자동으로 관리할 그룹을 정의하며, rules는 순서에 따라 이들을 참조합니다. 세 영역의 이름은 공백, 대소문자, 문장 부호까지 정확히 일치해야 합니다. 그룹이 다른 그룹을 참조할 수는 있지만 순환 참조는 허용되지 않습니다. 예를 들어 업무 그룹이 자동 그룹을 가리키고 자동 그룹이 다시 업무 그룹을 가리키면 유효한 선택 경로를 만들 수 없습니다.

선택 방식에 맞는 그룹 유형 고르기

select는 수동 선택용으로, 출구를 직접 지정해야 할 때 적합합니다. url-test는 연결 상태를 검사해 아웃바운드를 선택하므로 용도가 비슷한 회선 묶음에 적합합니다. fallback은 구성원 순서대로 사용 가능 여부를 확인해 앞쪽의 사용 가능한 출구를 우선합니다. load-balance는 정책에 따라 연결을 분배합니다. 여러 노드의 대역폭을 하나의 다운로드에 합치는 기능이 아니며, 동일한 계정의 모든 연결이 항상 같은 IP 주소를 사용한다고 보장하지도 않습니다.

업무 그룹과 자동 그룹을 두 단계로 구성하기

아래 예시는 코어에 내장된 직접 연결 아웃바운드를 사용합니다. 따라서 그룹 간 실제 참조 관계는 보여주지만 프록시 기능은 제공하지 않습니다. 실제로 사용할 때는 자동 그룹의 직접 연결 구성원을 현재 사용 중인 노드 이름으로 바꾸거나, 이미 정의된 프록시 제공자를 use로 참조하세요. 자동 선택이 업무에 맞지 않을 때 고정 출구로 빠르게 전환할 수 있도록 수동 선택 항목도 남겨 두세요.

proxy-groups:
  - name: 자동 출구
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 일상 사용
    type: select
    proxies:
      - 자동 출구
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,일상 사용
  - MATCH,일상 사용

interval의 단위는 초이며 검사 간격을 지정합니다. tolerance의 단위는 밀리초로, 작은 차이 때문에 선택이 자주 바뀌는 것을 줄여 줍니다. lazy는 그룹을 사용하지 않을 때의 검사 동작을 제어합니다. 검사 주소는 안정적으로 접속할 수 있어야 하며 회선의 실제 용도와도 되도록 맞아야 합니다. 가벼운 웹페이지 하나의 검사 결과만으로 대용량 전송, 동영상 재생, 특정 지역 서비스의 성능을 판단할 수는 없습니다.

로그인 상태를 유지해야 하는 서비스는 별도의 수동 그룹을 만들고 출구를 가능한 한 안정적으로 유지하는 편이 좋습니다. 쇼핑, 결제, 계정 관리 연결을 계속 바뀌는 출구 그룹에 넣으면 서비스에서 위험 신호로 판단할 수 있습니다. 출구를 바꿔야 한다면 관련 작업을 먼저 중지하고 대상 노드를 선택한 다음 연결을 새로 만드세요. 기존 연결은 그룹 선택을 바꿔도 자동으로 이동하지 않는 경우가 많습니다.

실제 규칙 매칭 결과에서 그룹 경로 역추적하기

문제를 확인할 때는 먼저 연결 상세 정보에서 규칙 대상을 확인하고, 프록시 그룹을 펼쳐 현재 선택된 항목을 확인한 뒤, 실제 노드까지 확인하세요. 화면에서 특정 노드를 선택한 상태라고 해서 대상 사이트가 반드시 해당 그룹을 거치는 것은 아닙니다. 규칙이 앞에서 직접 연결로 매칭됐거나 앱의 트래픽이 코어에 전달되지 않았을 수 있습니다. 회선을 비교하기 전에 경로부터 확인하면 규칙 문제를 노드 문제로 오해하는 일을 줄일 수 있습니다.

그룹이 비어 있다면 구성원 이름이 실제로 존재하는지, 프록시 제공자가 정상적으로 로드됐는지, 필터 표현식이 모든 노드를 제외하지는 않았는지 확인하세요. 참조 오류를 감추려고 전역 모드를 반복해서 바꾸지 마세요. 모드 설명은 아웃바운드 모드 가이드에서 확인할 수 있습니다. YAML 각 영역의 관계를 더 알아보려면 설정 파일 항목별 해설을 참고하세요.

규칙 집합을 구독으로 관리하기

규칙 순서를 정한 다음 출처별로 나누기

규칙은 위에서 아래로 확인하며, 일반적으로 처음 조건에 맞는 항목에서 아웃바운드 대상이 결정됩니다. 구체적인 도메인 규칙은 범위가 넓은 지역 규칙보다 앞에 두고, 최종 기본 규칙은 맨 뒤에 둡니다. 규칙을 외부 파일로 나누더라도 관리 방식만 달라질 뿐 순서에 따른 매칭 방식은 그대로입니다. 잘 관리된 규칙 집합도 잘못된 위치에 두면 실제로 매칭될 기회가 없을 수 있습니다.

rule-providers는 규칙 리소스를 선언하고, RULE-SET은 해당 리소스를 매칭 흐름에 연결합니다. 제공자 이름은 참조용 식별자일 뿐, 프록시를 사용할지 직접 연결할지를 자동으로 정하지 않습니다. 실제 정책 대상은 RULE-SET 뒤에 지정합니다. 같은 규칙 집합을 설정마다 다른 프록시 그룹에 연결할 수 있으므로 분류 데이터와 개인의 출구 선호를 각각 관리하기 편리합니다.

behavior와 format의 차이 이해하기

behavior는 규칙 내용을 어떻게 해석할지 지정합니다. domain은 도메인 목록, ipcidr은 IP 대역, classical은 DOMAIN-SUFFIX나 IP-CIDR 같은 전체 규칙 유형을 유지합니다. format은 파일의 인코딩 형식을 나타내며, YAML, 일반 텍스트, MRS 등이 쓰입니다. 파일 확장자는 이름을 붙이는 관례일 뿐이므로 실제 내용 형식을 확인하는 절차를 대신할 수 없습니다.

먼저 인라인 제공자를 사용해 전체 연결 구조를 살펴보겠습니다. 원격 다운로드가 필요하지 않아 이름, behavior 유형, 규칙 순서를 확인하는 데 적합합니다. classical 내용의 각 항목에는 정책 대상을 쓰지 않습니다. 이를 참조하는 RULE-SET에서 이미 대상이 지정되기 때문입니다. 항목에 정책 이름을 중복으로 넣으면 형식 호환성 문제가 생길 수 있습니다.

rule-providers:
  로컬 예외:
    type: inline
    behavior: classical
    payload:
      - DOMAIN-SUFFIX,example.com
      - IP-CIDR,192.168.50.0/24,no-resolve

rules:
  - RULE-SET,로컬 예외,DIRECT
  - MATCH,DIRECT

로컬 구조가 정상적으로 로드되는지 확인한 다음, 중앙에서 업데이트해야 하는 부분을 원격 제공자로 바꾸세요. 아래 주소는 형식 설명을 위한 예시이므로 실제 적용 전에 접근할 수 있고 내용 형식도 맞는 규칙 파일 주소로 바꿔야 합니다. 그대로 사용할 수 있는 규칙 서비스 주소가 아닙니다. 상대 경로 path는 코어의 작업 디렉터리를 기준으로 해석되며 클라이언트에서 보이는 구독 폴더와 다를 수 있습니다.

rule-providers:
  업무 도메인:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/business.yaml
    path: ./rules/business.yaml
    interval: 86400

rules:
  - RULE-SET,업무 도메인,DIRECT
  - MATCH,DIRECT

업데이트와 오프라인 복구 경로 설계

원격 업데이트는 첫 실행과 이후 새로 고침을 모두 고려해야 합니다. 로컬 캐시가 없는 첫 실행에서 리소스 주소에 아직 구성되지 않은 프록시 경로가 필요하면 시작 단계의 의존성 문제가 생길 수 있습니다. 현재 네트워크에서 접근할 수 있는 규칙 출처를 우선 선택하세요. 리소스를 내려받을 출구를 지정해야 한다면 현재 코어가 지원하는 제공자 필드를 확인하고, 해당 출구가 규칙 집합에 역으로 의존하지 않도록 하세요.

업데이트 간격을 지나치게 짧게 설정하지 마세요. 규칙 분류는 보통 초 단위로 바뀌는 데이터가 아니며, 자주 가져오면 네트워크 요청이 늘고 잘못된 업데이트도 더 빨리 퍼집니다. 복구할 수 있도록 이전 설정을 보관하고, 로그에서 제공자가 정상적으로 로드됐는지 확인하세요. 실패해도 캐시를 계속 사용할 수 있는지는 캐시 상태, 클라이언트 폴더, 실패 유형에 따라 달라지므로 영구적인 안전장치로 여겨서는 안 됩니다.

규칙 집합마다 경로를 따로 지정하고 여러 제공자가 같은 파일을 쓰지 않도록 하세요. PC를 바꾸거나 클라이언트를 재설치할 때 주 YAML만 백업하고 로컬 규칙 파일을 빠뜨리지 마세요. 모바일 앱의 샌드박스와 데스크톱 파일 경로는 서로 다르므로 절대 경로를 그대로 복사해도 이식되지 않는 경우가 많습니다. 장기적으로 관리할 설정에는 명확한 상대 경로를 사용하고, 어떤 파일을 클라이언트가 관리하는지 기록해 두세요.

잘못된 매칭과 DNS 부작용 다루기

사이트가 잘못 분기되면 실제로 매칭된 규칙 이름부터 확인한 다음, 분류 데이터 문제인지 순서 문제인지 판단하세요. 개인 예외는 보통 공용 규칙 집합보다 앞에 두고 필요한 도메인이나 대역만 적습니다. 도메인 하나를 수정하려고 큰 범주의 전체 트래픽을 직접 연결로 바꾸지 마세요. 같은 규칙 집합을 사용하는 다른 서비스까지 경로가 바뀔 수 있습니다.

no-resolve는 일부 주소 규칙이 매칭을 위해 추가 도메인 조회를 일으키지 않도록 하는 옵션이지, 모든 연결의 DNS를 끄는 기능은 아닙니다. 앱에서 대상 IP를 이미 제공했다면 주소 규칙은 정상적으로 확인할 수 있습니다. 도메인 규칙과 주소 규칙을 함께 쓸 때는 어느 단계에서 조회가 발생할 수 있는지 명확히 해야 규칙 때문에 생긴 조회를 DNS 중복 요청으로 오해하지 않습니다.

DNS 설정과 조회 경로 최적화

조회 흐름을 따라 DNS가 처리되는 위치 찾기

DNS를 최적화하려면 먼저 조회 흐름을 파악해야 합니다. 앱이 도메인을 어디에 전달하는지, 시스템이 이를 가로채는지, 코어가 조회를 받는지, 마지막으로 어떤 업스트림이 결과를 반환하는지 확인하세요. 주 YAML의 DNS 주소만 바꿔서는 브라우저, 시스템 서비스, 개별 앱의 조회가 모두 같은 경로를 따른다고 보장할 수 없습니다. 브라우저 자체의 암호화 DNS, 앱 내 조회, 캐시 때문에 테스트 결과가 예상과 다를 수 있습니다.

시스템 프록시는 주로 프록시 설정을 따르는 앱의 트래픽을 처리하며 시스템의 모든 DNS를 자동으로 처리하지는 않습니다. TUN을 사용하면 처리 범위를 넓힐 수 있지만 라우팅, DNS 가로채기 규칙, 앱 동작에 따라 결과가 달라집니다. 테스트할 때는 앱 하나를 정하고 필요한 캐시를 비운 뒤 코어 로그에 표시된 도메인 정보와 대조하세요. 업스트림, 향상 모드, 라우팅 설정을 동시에 바꾸면 어떤 변경이 효과를 냈는지 판단하기 어렵습니다.

부트스트랩 조회, 일반 조회, 노드 조회 구분하기

default-nameserver는 주로 DNS 업스트림 자체의 도메인을 처음 조회할 때 사용합니다. nameserver는 일반 DNS 조회에 사용할 업스트림 목록입니다. proxy-server-nameserver는 프록시 노드의 도메인을 조회하며, 노드 조회가 프록시에 의존하고 프록시 연결은 다시 노드 조회에 의존하는 순환을 막는 데 도움이 됩니다. 이 필드들은 단순한 주·보조 서버 관계가 아니므로, 이름만 보고 앞서 실패해야 다음으로 전환된다고 해석해서는 안 됩니다.

nameserver-policy는 지정한 도메인이 특정 업스트림을 사용하도록 설정합니다. 예를 들어 로컬 네트워크 서비스나 사내 도메인에 사용할 수 있습니다. 매칭 문법은 현재 코어 문서를 기준으로 확인하세요. 일반적인 하위 도메인에는 +.example.com 같은 형식을 사용할 수 있습니다. 내부 도메인은 이를 처리할 수 있는 내부 DNS로 보내야 합니다. 공용 DNS에 보낸 뒤 사설 서비스 주소가 돌아오기를 기대해서는 안 됩니다.

dns:
  enable: true
  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
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.example.com":
      - 192.168.50.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"

예시에 나온 사설망 DNS 주소는 실제 라우터나 조직에서 제공하는 조회 서버로 바꾸세요. 내부 도메인을 사용할 일이 없다면 연결할 수 없는 주소를 남겨 두지 말고 해당 정책을 삭제하세요. 암호화 DNS는 조회 전송 방식을 바꾸지만 조회가 자동으로 프록시를 통과하게 하지는 않습니다. 연결 출구는 코어의 DNS 옵션, 라우팅, 규칙을 함께 확인해야 합니다.

규칙 준수와 대체 조회 설정은 신중하게

respect-rules를 사용하면 DNS 업스트림 연결에 라우팅 규칙을 적용할 수 있지만 의존 관계도 늘어납니다. 활성화하기 전에 노드 도메인용으로 사용할 수 있는 전용 조회 경로를 마련하고, 조회 서버 연결이 아직 설정되지 않은 출구에 다시 의존하지 않는지 확인하세요. 네트워크가 안정적으로 작동한다면 필드 구성이 더 완벽해 보인다는 이유만으로 활성화할 필요는 없습니다.

fallback과 fallback-filter를 사용할 때는 코어가 어떤 결과를 허용 가능한 것으로 판단하는지 먼저 파악하세요. 대체 업스트림은 일반 업스트림이 시간 초과된 뒤에만 사용하는 예비 서버가 아닙니다. 필터 조건에 따라 어떤 결과가 반환될지도 달라질 수 있습니다. 실제 네트워크 환경을 모른 채 지역 조건과 IP 필터를 많이 복사해 넣으면 조회가 늘고 주소 선택도 일관되지 않을 수 있습니다.

IPv6는 DNS 응답, 시스템 라우팅, 노드 지원 여부, 대상 사이트 연결 상태를 함께 확인해야 합니다. dns.ipv6: false는 주로 코어의 DNS 응답에 영향을 줍니다. 시스템 전체에서 IPv6를 비활성화하는 설정도 아니며, 앱이 이미 캐시한 주소를 사용하지 못하게 막지도 않습니다. 일부 사이트에서만 연결이 지연되면 연결 상세 정보에서 접근할 수 없는 IPv6 경로를 먼저 시도했는지 확인하세요.

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

도메인이 전혀 조회되지 않으면 업스트림 주소에 연결할 수 있는지, 업스트림 자체의 도메인을 부트스트랩 조회할 수 있는지 먼저 확인하세요. 노드 연결만 실패한다면 노드 도메인 조회를 우선 점검합니다. 내부 서비스만 이상하다면 공용 업스트림으로 잘못 보내는지 확인하세요. 관련 없는 여러 사이트가 동시에 느리다면 시스템 기본 조회와 코어 조회를 비교해 문제가 실제로 DNS에서 비롯됐는지 판단하세요.

도메인 조회가 성공해도 대상 주소에 연결할 수 있다는 뜻은 아닙니다. 로그에서 주소를 가져왔는데 이후 연결이 시간 초과된다면 아웃바운드 규칙, 방화벽, 회선을 확인하세요. DNS 서버를 계속 바꾸는 것으로 해결하려 하지 마세요. 브라우저, 시스템, 코어의 캐시는 서로 독립적이므로 테스트 범위에 맞게 캐시를 지우고 기존 연결을 종료해야 합니다. 캐시 잔류와 전송 병목을 구분하는 방법은 느린 인터넷 속도 단계별 진단을 참고하세요.

TUN 가상 네트워크 인터페이스와 Fake-IP

트래픽 진입점과 DNS 향상 모드 구분하기

TUN은 시스템에 가상 네트워크 인터페이스를 만들고 라우팅 조건에 맞는 트래픽을 코어로 전달합니다. Fake-IP는 DNS 향상 모드입니다. 코어가 도메인에 가상 IP를 반환하고 매핑을 통해 도메인을 복원한 뒤 후속 처리를 진행합니다. 두 기능을 함께 사용하는 경우가 많지만 같은 설정은 아닙니다. TUN을 켜도 DNS가 반드시 처리되는 것은 아니며, Fake-IP를 켜도 모든 앱이 가상 인터페이스를 통과하는 것은 아닙니다.

시스템 프록시는 브라우저나 프록시 설정을 따르는 프로그램에 적합합니다. TUN은 시스템 프록시만으로 처리할 수 없는 트래픽까지 다뤄야 할 때 유용합니다. 전환 전에 기존 시스템 프록시 경로가 정상인지 확인하고 TUN만 따로 테스트하세요. 다른 VPN, 가상 네트워크 소프트웨어, 엔드포인트 보안 제품도 설치돼 있다면 기본 라우트와 인터페이스 우선순위를 확인하세요. 트래픽을 가로채는 도구 여러 개가 자동으로 조정될 것이라고 가정하면 안 됩니다.

최소한의 라우팅 설정부터 시작하기

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"

auto-route는 관련 라우트를 자동으로 설정하고, auto-detect-interface는 출구 인터페이스를 자동으로 찾습니다. stack은 트래픽 처리 스택을 정하는 옵션이지 성능 등급을 선택하는 옵션이 아닙니다. 시스템, 프로토콜, 앱마다 호환성이 다릅니다. 먼저 클라이언트에서 지원하는 기본값을 사용하고, 문제를 재현해 비교 결과를 기록한 뒤에만 다른 스택을 시험하세요.

dns-hijack에서 일반 포트를 가로채는 설정은 주로 일반 DNS 트래픽을 대상으로 합니다. 이 설정만으로 암호화 DNS까지 코어 조회로 변환된다고 볼 수는 없습니다. 실제 동작은 운영체제와 라우팅 방식에도 영향을 받습니다. 앱이 암호화 조회 서비스에 직접 연결하면 예상한 도메인 매핑을 우회할 수 있으므로 포트 규칙을 계속 추가하기보다 앱 자체의 DNS 설정을 확인하세요.

권한과 플랫폼 차이 다루기

데스크톱에서는 클라이언트가 제공하는 서비스 설치 및 권한 부여 절차를 통해 TUN을 활성화하는 것이 좋습니다. 데스크톱 세션 전체를 장기간 과도한 권한으로 실행하지 마세요. Android의 VPN 권한은 시스템이 관리하며, 일반적으로 동일한 VPN 채널을 사용하는 앱 두 개를 동시에 실행할 수 없습니다. iOS에서는 해당 플랫폼용 클라이언트 메뉴를 이용하세요. 데스크톱 TUN 필드가 모든 플랫폼에서 같은 방식으로 작동한다고 간주해서는 안 됩니다.

기업 네트워크에 연결된 장치는 내부 대역, 전용 DNS, 보안 소프트웨어와 관련해 추가 조건이 있을 수 있습니다. 먼저 조직에서 허용하는 접속 방식을 확인한 뒤 필요한 경로 제외를 설정하세요. 모든 사설 IP 대역을 제외하는 목록을 그대로 복사하지 마세요. 일부 업무 트래픽은 실제로 코어를 거쳐야 할 수 있습니다. 제외 범위는 실제 네트워크 대역과 일치시켜야 하며 원격 서비스가 로컬 네트워크 출구로 잘못 나가지 않도록 확인하세요.

Fake-IP 매핑과 호환성 예외 관리하기

Fake-IP가 반환하는 가상 주소는 노드 주소도 대상 서버의 실제 주소도 아닙니다. 앱이 해당 주소에 연결하면 코어는 매핑 정보를 바탕으로 도메인을 복원합니다. 설정을 바꾸거나 코어를 다시 시작한 뒤 시스템에는 이전 가상 주소가 남아 있고 코어의 매핑은 바뀌었다면 일시적인 연결 실패가 발생할 수 있습니다. 먼저 관련 캐시를 지우고 연결을 다시 만든 다음, 매핑을 영구 저장해야 하는지 검토하세요.

fake-ip-filter는 일치하는 도메인이 실제 주소를 조회하도록 합니다. 로컬 네트워크 검색이나 특정 앱이 실제 주소에 의존하는 경우에 적합합니다. 문제를 진단한다는 이유로 인터넷 전체를 대상으로 하는 광범위한 필터를 한꺼번에 추가하지 마세요. 도메인 매핑과 연동되는 Fake-IP의 장점을 잃을 수 있습니다. 필터를 추가한 뒤에도 실제 주소가 올바른지, 접근 규칙이 적절한지 확인해야 합니다. 필터가 서버 연결 문제를 해결해 주지는 않습니다.

트래픽이 TUN을 통해 처리되는지 확인하려면 연결 페이지에서 테스트 앱의 새 연결을 찾아 매칭된 규칙과 출구를 확인하세요. TUN 스위치가 켜져 있는지만 확인해서는 안 됩니다. TUN을 끈 뒤 네트워크가 복구됐는지와 시스템에 수동 프록시가 남지 않았는지도 확인하세요. 설치 및 권한 문제는 먼저 가이드를 참고하세요. 클라이언트를 바꿔야 한다면 다운로드 센터에서 플랫폼에 맞는 버전을 선택하고, 여러 프록시 진입점을 동시에 실행해 비교하지 마세요.

도메인 스니핑과 규칙 매칭

스니핑으로 확인할 수 있는 정보 파악하기

코어에 들어오는 연결에는 대상 IP만 있고 도메인 규칙에 필요한 정보가 없는 경우가 있습니다. 도메인 스니핑은 프로토콜 핸드셰이크나 요청 내용에서 호스트 이름을 추출합니다. 예를 들면 HTTP의 Host, TLS 핸드셰이크에 노출되는 서버 이름, 지원되는 QUIC 핸드셰이크 정보 등이 있습니다. 이는 라우팅에 필요한 단서를 보완하는 기능이지 암호화된 웹페이지 내용을 복호화하는 기능은 아니며, 모든 연결에서 도메인을 알아낼 수 있는 것도 아닙니다.

Fake-IP 매핑이 완전하다면 코어는 해당 도메인을 이미 알고 있으므로 스니핑 효과가 크지 않을 수 있습니다. 앱이 자체적으로 조회하거나 실제 IP를 직접 사용하거나 DNS 조회가 코어를 거치지 않는 경우에는 스니핑이 도메인 규칙 매칭을 개선할 수 있습니다. 정보가 어느 단계에서 누락되는지 확인한 뒤 활성화 여부를 결정하세요. 이미 안정적으로 작동하는 경로라면 설정을 완벽하게 보이게 하려고 불필요한 판단 과정을 추가할 필요가 없습니다.

프로토콜과 포트 범위 제한하기

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "+.example.com"

이 예시는 범위를 일반적인 웹 포트로 제한합니다. parse-pure-ip는 순수 IP 대상도 스니핑을 시도하도록 하고, force-dns-mapping은 일부 DNS 매핑 환경에서 스니핑 처리를 확대합니다. 어느 옵션도 앱이 보내지 않은 호스트 이름을 만들어 내지는 않습니다. 포트 범위가 넓을수록 확인할 트래픽이 많아지고 웹이 아닌 프로토콜을 후보로 잘못 판단할 가능성도 커집니다.

override-destination은 스니핑 결과를 단순히 매칭 정보로 보완할지, 연결 대상을 실제로 바꿀지 결정합니다. 대상을 바꾸면 새로 도메인을 조회해 앱이 처음 선택한 것과 다른 주소에 연결할 수 있습니다. 특정 진입점, IP 고정성, 로컬 네트워크 조회에 의존하는 서비스에서는 이 변화를 신중하게 검토해야 합니다. 처음 시험할 때는 이 옵션을 끄고 라우팅 정보만으로 충분한지 확인하세요.

호환성 문제에 정확한 예외 설정하기

skip-domain은 스니핑에 적합하지 않은 것으로 확인된 도메인을 건너뛰는 설정입니다. 예시의 접미사는 형식을 보여주기 위한 것이므로 실제 문제가 발생한 서비스로 바꾸세요. 예외를 추가하기 전에 스니핑을 끈 경우와 켠 경우의 연결 로그, 대상 주소, 규칙을 비교하세요. 반복해서 재현할 수 있는 차이에만 장기 예외를 적용하세요. 그렇지 않으면 일시적인 회선 문제를 불필요한 설정으로 굳힐 수 있습니다.

앱이 고정 IP를 사용하고 핸드셰이크에도 도메인이 포함되지 않는다면 도메인 규칙에 적용할 신뢰할 만한 근거가 없습니다. 이런 경우 명시적인 IP 규칙을 사용하거나 클라이언트와 플랫폼이 지원하는 범위에서 프로세스 규칙을 고려하세요. 특정 도메인 규칙을 매칭하려고 가짜 매핑을 만들지 마세요. 하나의 주소에서 여러 서비스가 제공될 수 있으며 역방향 조회로 얻은 이름이 앱이 실제로 접속하는 호스트 이름과 같다는 보장도 없습니다.

암호화된 ClientHello 같은 기술은 핸드셰이크에서 확인할 수 있는 정보를 줄일 수 있고, 비표준 프로토콜은 인식되지 않을 수 있습니다. QUIC을 제대로 분석할 수 있는지는 코어의 지원 여부와 실제 핸드셰이크 구조에 따라 달라집니다. 스니핑으로 도메인을 찾지 못했다고 반드시 설정 오류인 것은 아닙니다. 포트를 계속 늘리기보다 진입점과 DNS 흐름을 다시 살펴보고 앱의 조회를 코어가 처리하도록 해야 하는지 판단하세요.

같은 연결로 규칙 변경 확인하기

비교 테스트 전에 테스트 앱의 기존 연결을 종료하고 대상 페이지 하나만 여세요. 연결 상세 정보에서 원래 대상, 인식된 도메인, 매칭된 규칙, 최종 아웃바운드를 기록합니다. 그런 다음 스니핑 설정이나 매개변수 하나만 바꾸고 같은 과정을 반복하세요. 기존의 장시간 연결은 핸드셰이크를 다시 수행하지 않습니다. 페이지를 새로 고쳐도 기존 연결을 재사용할 수 있어 설정이 바뀌지 않은 것처럼 보일 수 있습니다.

도메인 스니핑과 규칙 우선순위는 서로 다른 문제입니다. 올바른 도메인을 인식했더라도 앞에서 먼저 매칭된 IP 규칙이나 프로세스 규칙이 이미 아웃바운드를 결정했을 수 있습니다. 예상과 다른 결과가 나오면 먼저 매칭된 규칙을 확인하고 순서를 조정하세요. 전역 모드에서 프록시 연결이 보인다고 해서 특정 도메인 규칙이 작동한다는 뜻은 아닙니다.

활성화한 뒤 일부 앱에서 첫 연결만 느려졌다면 스니핑 범위가 지나치게 넓은지, 대상 프로토콜을 지원하는지, 불필요한 대상 변경을 켜 두었는지 확인하세요. 곧바로 노드 품질 문제라고 단정하지 마세요. 프로토콜과 포트를 하나씩 좁혀 최소 재현 사례를 만든 다음 로그 페이지의 주요 오류를 참고해 핸드셰이크 실패, 조회 실패, 연결 시간 초과를 구분하세요.

로컬 오버라이드와 여러 구독 병합

구독 원본을 보존하고 최종 적용 설정 확인하기

구독은 외부에서 가져오는 입력이고, 클라이언트가 저장하는 Profile은 설정 컨테이너이며, 코어가 읽는 것은 최종 적용된 설정입니다. 이 세 가지가 항상 같은 것은 아닙니다. 클라이언트가 포트 설정, TUN 옵션, 로컬 오버라이드를 추가하거나 다시 불러오는 과정에서 파일을 새로 생성할 수 있습니다. 캐시된 구독 원본을 직접 수정해도 다음 업데이트 때 내용이 사라지기 쉬우므로 장기 설정 관리 방법으로 적합하지 않습니다.

먼저 설정 페이지에서 현재 어떤 Profile을 사용 중인지 확인한 다음, 클라이언트에서 오버라이드, 확장 설정, 설정 편집 기능을 제공하는지 살펴보세요. 클라이언트마다 메뉴 이름과 병합 방식이 다릅니다. FlClash에서는 현재 앱 화면과 실제 생성 결과를 기준으로 판단하세요. 해당 기능이 없다면 별도의 완전한 로컬 설정을 관리하고, 임의의 YAML 조각이 자동으로 병합된다고 가정하지 마세요.

로컬 오버라이드에는 개인 규칙, DNS 선호 설정, 컨트롤러 제한을 보관하고 구독 제공자는 노드 정보를 계속 관리하도록 구성할 수 있습니다. 역할을 나누면 회선 업데이트 때 개인 규칙을 다시 작성할 필요가 없고, 기기를 바꿀 때도 어떤 설정이 개인 환경에 속하는지 쉽게 확인할 수 있습니다. 기본 개념은 Profile 및 여러 설정 관리를 참고하고, 구독을 처음 가져올 때는 가이드 절차를 따르세요.

맵, 목록, 참조를 각각 처리하기

YAML 맵과 목록은 같은 방식으로 다룰 수 없습니다. 맵은 키별로 병합될 수도 있고 객체 전체가 교체될 수도 있습니다. 목록은 뒤에 추가되거나 앞에 삽입되거나 완전히 덮어써질 수 있으며, 구체적인 동작은 클라이언트의 오버라이드 방식에 따라 다릅니다. 특히 rules에서는 기존 MATCH 뒤에 규칙을 추가해도 대개 매칭되지 않습니다. 편집기에서 저장됐는지만 확인하지 말고 최종 규칙 순서를 반드시 확인하세요.

아래 코어 필드는 선택 상태와 매핑 상태를 유지하는 데 사용할 수 있지만, 클라이언트가 이를 관리하는지와 설정을 바꾼 뒤에도 유지되는지는 실제 동작을 확인해야 합니다. 여러 구독 내용을 병합하는 명령도 아니며 이름이 같은 노드 문제를 해결하지도 않습니다. 회사와 가정처럼 환경 차이가 큰 경우에는 조건을 계속 덧붙이는 것보다 Profile을 따로 유지하는 편이 관리하기 쉽습니다.

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

서로 다른 출처의 노드를 하나의 프록시 그룹에 넣으려면 proxy-providers를 사용할 수 있습니다. 단, 각 출처는 코어가 지원하는 프록시 제공자 형식의 내용을 제공해야 합니다. 전체 Clash 설정 파일, 일반 노드 링크 목록, 다른 구독 형식은 제공자 파일로 바로 사용할 수 있다고 보장되지 않습니다. 먼저 파일 구조를 확인하고 proxies를 중심으로 구성된 유효한 노드 목록인지 확인하세요.

프록시 제공자로 여러 출처 연결하기

proxy-providers:
  회선 A:
    type: http
    url: https://example.com/provider-a.yaml
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  회선 B:
    type: http
    url: https://example.com/provider-b.yaml
    path: ./providers/b.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 통합 선택
    type: select
    use:
      - 회선 A
      - 회선 B

rules:
  - MATCH,통합 선택

예시 주소는 실제 제공자 주소로 바꾸고 캐시 경로는 서로 다르게 지정하세요. 구독 인증 정보를 공개 스크린샷, 블로그, 공유 저장소에 올리지 마세요. 실제 설정 백업도 민감한 파일로 취급해야 합니다. 노드 비밀번호, 구독 링크, 컨트롤러 비밀번호가 함께 들어 있을 수 있습니다. 문제 해결 자료를 공유할 때는 구조만 남기고 실제 값은 반드시 삭제하거나 가리세요.

출처가 여러 개면 이름이 같은 노드가 생기기 쉽습니다. 노드 이름은 화면에 표시될 뿐 아니라 저장된 선택 상태와 규칙 참조에도 사용될 수 있어 이름이 중복되면 구분하기 어렵습니다. 현재 코어가 제공자 이름 변경을 지원한다면 문서에 따라 출처별 접두사를 지정하세요. 지원하지 않는다면 관리 가능한 데이터 처리 단계에서 이름을 바꾸거나 제공자를 분리해 사용하세요. YAML 전체에 단순 텍스트 바꾸기를 적용하면 규칙 대상과 그룹 이름까지 함께 손상될 수 있습니다.

되돌릴 수 있는 업데이트 절차 만들기

업데이트 전에 직전의 정상 설정과 로컬 오버라이드를 보관하세요. 업데이트한 뒤에는 제공자 로드, 그룹 구성원, 규칙 순서, DNS 설정을 차례로 확인합니다. 필요하면 해당 바이너리 디렉터리에서 mihomo -t -f ./config.yaml을 실행해 코어의 설정 검사 기능으로 구문을 확인하세요. 이 검사는 설정을 파싱할 수 있다는 뜻일 뿐, 노드에 연결할 수 있거나 규칙이 업무 요구에 맞는다는 뜻은 아닙니다.

설정을 다시 불러온 뒤 새 연결 하나를 만들어 아웃바운드가 예상과 같은지 확인한 다음 다른 앱 작업을 재개하세요. 실패하면 최근에 추가한 오버라이드부터 되돌리고 모든 Profile을 바로 삭제하지 마세요. 문제 기록에는 원래 설정, 변경한 부분, 최종 생성 결과, 오류 로그를 함께 남기세요. 구독을 반복해서 다시 가져오는 것보다 단계별로 되돌리는 편이 원인을 찾기 쉽고 이미 확인한 개인 설정도 보존할 수 있습니다.

외부 컨트롤 패널과 유지 관리 절차

프록시 진입점과 관리 인터페이스 구분하기

mixed-port 같은 프록시 포트는 앱 연결을 받는 데 사용하고, external-controller는 관리 인터페이스를 제공합니다. 컨트롤 패널은 관리 인터페이스를 통해 연결을 확인하고 프록시 그룹을 바꾸거나 실행 상태를 조정합니다. 컨트롤 패널 자체가 새로운 프록시 노드인 것은 아닙니다. 로컬 네트워크 연결을 허용하는 프록시 옵션을 열었다고 해서 관리 인터페이스까지 외부에 공개해야 하는 것은 아니며, 두 설정을 따로 검토해야 합니다.

데스크톱 클라이언트는 보통 내부 컨트롤 인터페이스를 통해 코어를 관리합니다. 수신 주소, 포트, 비밀번호를 직접 바꾸면 클라이언트 화면이 자체 코어에 연결하지 못할 수 있습니다. 먼저 클라이언트에서 해당 필드를 직접 설정할 수 있는지, 시작할 때 값을 다시 생성하는지 확인하세요. 화면에는 연결 끊김으로 표시되지만 실제 트래픽은 계속 작동한다면 프록시 코어가 멈췄다고 단정하지 말고 컨트롤 인터페이스부터 확인하세요.

기본적으로 로컬 호스트에만 바인딩하기

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui

여기 나온 비밀번호는 설명을 위한 예시입니다. 실제로 사용할 때는 별도의 강력한 비밀번호로 반드시 바꾸세요. external-ui는 준비된 컨트롤 패널 정적 파일 폴더를 가리키며, 경로를 입력한다고 페이지가 자동으로 생성되지는 않습니다. 상대 경로는 코어의 작업 디렉터리를 기준으로 해석됩니다. 클라이언트 샌드박스, 서비스를 실행하는 계정, 파일 권한에 따라 파일을 읽지 못할 수도 있습니다. 설정한 뒤에는 먼저 로컬 인터페이스에 연결할 수 있는지 확인하고 패널 파일을 점검하세요.

웹 패널이 필요하지 않다면 external-ui를 생략하고 클라이언트 자체의 관리 기능을 사용하면 됩니다. 패널이 필요하다면 현재 코어 인터페이스와 호환되는 정적 파일을 신뢰할 수 있는 경로로 준비하세요. 패널에서 일부 항목이 보이지 않는다는 이유로 수신 주소를 함부로 더 열지 마세요. 패널 호환성, 인터페이스 인증, 코어 응답 중 무엇이 원인인지 먼저 확인하세요.

브라우저 연결과 인증 확인하기

패널이 열린다는 것은 정적 페이지에 접근할 수 있다는 뜻일 뿐, 컨트롤 인터페이스에 정상적으로 연결됐다는 뜻은 아닙니다. API 주소, 비밀번호, 이벤트 연결을 각각 확인해야 합니다. 브라우저 콘솔에서 연결 거부가 표시되면 포트나 수신 설정을 확인하세요. 인증 실패는 비밀번호 문제일 수 있습니다. 다른 출처에서 페이지를 열었다면 교차 출처 정책의 영향을 받을 수도 있습니다. 오류 유형마다 수정할 위치가 다릅니다.

HTTPS 페이지에서 HTTP 컨트롤 인터페이스를 요청하면 실제 네트워크 연결이 가능하더라도 브라우저가 혼합 콘텐츠로 차단할 수 있습니다. 교차 출처 접근을 허용할 때도 모든 사이트에서 인증 정보를 사용할 수 있도록 열어 두지 마세요. 먼저 패널이 제공되는 출처를 확인하고 코어가 지원하는 최소 권한 설정을 사용하세요. 비밀번호를 공개 링크의 쿼리 매개변수에 넣으면 브라우저 기록, 스크린샷, 접속 로그에 남을 수 있습니다.

원격 관리는 제어된 로컬 포워딩이나 신뢰할 수 있는 네트워크를 통해 로컬 인터페이스에 접속하는 방법을 우선 사용하세요. LAN에서 수신해야 한다면 방화벽으로 접근 가능한 주소를 제한하고 네트워크 환경을 신뢰할 수 있는지 확인하세요. 컨트롤 포트를 인터넷에 직접 공개하지 마세요. 이 인터페이스는 정책을 바꾸거나 기존 연결에 영향을 줄 수 있어 단순히 상태만 보여주는 포트보다 권한 범위가 넓습니다.

읽기 전용 정보부터 확인하기

패널에 처음 연결하면 실행 모드, 프록시 그룹, 연결 기록부터 확인하고 전역 설정은 바로 바꾸지 마세요. 클라이언트 화면과 대조해 두 인터페이스가 같은 코어 인스턴스를 관리하는지 확인합니다. 독립 mihomo와 데스크톱 클라이언트를 동시에 실행하면 포트가 다른 인스턴스가 완전히 다른 설정을 사용할 수 있습니다. 패널에서 선택이 바뀌어도 실제 트래픽에 영향이 없다면 다른 인스턴스에 연결했을 가능성이 큽니다.

문제 해결 순서를 정해 두세요. 코어 실행 여부, 인터페이스 수신 상태, 인증, 패널에서 설정 읽기, 새 연결 확인 순으로 진행합니다. 각 단계에서는 현재 계층의 문제만 해결하세요. 업무 연결은 정상인데 패널이 비어 있으면 정적 파일과 브라우저를 확인하고, 패널은 정상이지만 업무 연결이 실패하면 프록시 진입점, 규칙, DNS, 노드를 점검하세요. 관리 화면의 상태를 실제 연결 테스트 대신 사용하면 안 됩니다.

장기 유지 관리 및 복구 점검 목록

큰 변경을 할 때마다 어떤 필드를 왜 수정했는지, 어떻게 검증했고 어떻게 되돌릴지 기록하세요. 기본 설정을 백업할 때는 로컬 규칙 폴더, 제공자 캐시 경로, 클라이언트가 관리하는 오버라이드 내용도 함께 기록합니다. 기기를 옮긴 뒤에는 최소한의 연결 경로부터 복구한 다음 TUN, DNS 정책, 컨트롤 패널을 하나씩 복원하세요. 이전 시스템의 경로와 권한 문제까지 그대로 옮기지 않도록 주의해야 합니다.

클라이언트와 코어가 항상 동시에 업데이트되는 것은 아닙니다. 알 수 없는 필드가 있거나 설정 검사에 실패하거나 패널 기능이 다르게 보인다면 현재 실제로 실행 중인 코어가 지원하는 기능을 확인하세요. 화면 모양만 보고 지원 여부를 추측하지 마세요. 클라이언트를 다시 선택하려면 다운로드 센터에서 플랫폼별 버전을 확인하세요. 처음부터 연결을 복구할 때는 구독 가져오기 및 연결 가이드로 돌아가 기본 절차를 먼저 완료한 다음 이 페이지의 고급 설정을 장별로 복원하세요.