Clash 고급 설정 가이드

프록시 그룹 유형과 선택 방식

프록시 그룹은 규칙에 일치한 연결을 최종적으로 어느 노드나 출구로 보낼지 결정합니다. 트래픽 분기를 점검할 때는 규칙이 지정한 그룹 이름을 먼저 확인하고, 해당 그룹에서 현재 어떤 구성원이 선택되어 있는지 살펴보세요. 프록시 목록에서 사용 가능으로 표시된 노드만 보고 연결에 실제로 사용될 노드를 판단할 수는 없습니다. 일반적으로 노드를 ‘수동 선택’ 그룹에 넣고, ‘자동 선택’이나 ‘장애 조치’ 등의 그룹에서 같은 노드를 참조한 뒤, 서비스 규칙이 상위 그룹을 가리키도록 구성합니다. 그룹 이름은 대소문자와 공백까지 포함해 규칙 끝에 지정한 대상과 정확히 일치해야 합니다. 구독 업데이트로 새 노드가 추가되면 노드 필터가 예상한 이름을 계속 포함하는지도 확인하세요.

네 가지 선택 방식

select는 사용자가 지정한 구성원을 유지하므로 고정 출구가 필요한 로그인이나 원격 접속에 적합합니다. 테스트 결과가 바뀌어도 노드를 자동으로 변경하지 않습니다. url-test는 테스트 URL의 응답 시간을 기준으로 구성원을 선택하므로 출구가 바뀌어도 괜찮은 일반적인 웹 탐색에 알맞습니다. fallback은 구성원 순서대로 사용 가능한 첫 번째 항목을 선택합니다. 주 회선을 우선 사용하고 연결이 끊긴 경우에만 전환하려는 상황에 적합합니다. load-balance는 서로 다른 연결을 여러 구성원에 분산합니다. 같은 웹사이트에서 출구 IP를 유지해야 한다면 로그인 트래픽을 부하 분산 그룹에 맡기지 않는 편이 좋습니다. 테스트 성공은 테스트 주소에 연결할 수 있다는 뜻일 뿐, 모든 대상 사이트에 접속할 수 있다는 의미는 아닙니다. 특정 사이트에서 실패하면 실제 연결 기록도 확인하세요.

확인하기 쉬운 그룹에 노드 배치하기

아래 예시에서는 설정에 ‘노드 A’와 ‘노드 B’라는 프록시가 이미 있다고 가정합니다. 실제로는 구독에 표시된 노드 이름으로 두 구성원을 바꾸고, 이름이 같은 프록시 그룹을 중복으로 만들지 마세요. interval의 단위는 초입니다. tolerance는 자동 선택 시 현재 구성원을 유지할 수 있는 지연 시간 차이로, 결과가 비슷할 때 잦은 전환을 줄여 줍니다. 테스트 URL은 현재 네트워크에서 안정적으로 접속할 수 있고 짧은 응답을 반환하는 주소를 사용하세요. 로그인이 필요한 사이트를 테스트 대상으로 삼는 것은 적절하지 않습니다.

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - 노드 A
      - 노드 B
      - DIRECT
  - name: 자동 선택
    type: url-test
    proxies:
      - 노드 A
      - 노드 B
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 장애 조치
    type: fallback
    proxies:
      - 노드 A
      - 노드 B
    url: http://www.gstatic.com/generate_204
    interval: 300
rules:
  - DOMAIN-SUFFIX,example.org,수동 선택
  - MATCH,자동 선택

놓치기 쉬운 차이가 하나 더 있습니다. 노드 테스트는 그룹 구성원을 대상으로 하지만 실제 요청은 먼저 규칙과 일치해야 합니다. 예시의 도메인 규칙보다 앞에 직접 연결 규칙이 있으면 해당 요청은 ‘수동 선택’ 그룹에 들어가지 않습니다. 진단할 때는 클라이언트의 ‘연결’ 화면에서 대상 도메인과 일치한 규칙을 찾아 어느 그룹을 가리키는지 확인한 다음, ‘프록시’ 화면에서 해당 그룹의 구성원과 선택 상태를 확인하세요. 변경 후에도 기존 연결에 예전 출구가 표시된다면 연결을 끊고 새 요청을 보내세요. 이미 연결된 트래픽은 보통 중간에 경로가 바뀌지 않습니다.

마지막으로 기본 규칙을 확인하세요. MATCH는 일반적으로 규칙 목록 맨 끝에 둡니다. 앞선 규칙에 하나도 일치하지 않을 때 사용할 출구를 결정하기 때문입니다. 앞쪽에 배치하면 뒤에 있는 세부 규칙이 적용되지 않습니다. 규칙이 작동하는지 임시로 확인하려면 특정 도메인 하나를 수동 그룹으로 보내 새 연결을 만든 뒤 기록을 살펴보세요. 모든 트래픽을 전역 모드로 전환할 필요는 없습니다. 테스트가 끝나면 진단 규칙을 삭제하고 기존 순서와 선택 항목을 복구해 변경 범위를 추적할 수 있게 하세요.

룰셋 구독 관리

룰셋을 사용하면 자주 바뀌는 도메인이나 IP 항목을 기본 설정에서 분리할 수 있습니다. rule-providers에서 출처와 형식, 로컬 캐시 경로를 지정하고 rules에서 RULE-SET으로 참조합니다. 룰셋 내용을 업데이트할 때 기본 설정을 항목별로 다시 작성할 필요가 없지만, 룰셋 다운로드와 파싱, 캐시, 참조라는 처리 과정이 추가됩니다. 어느 단계에서든 실패하면 의도한 트래픽 분기가 적용되지 않을 수 있습니다. 먼저 원격 룰셋이 필요한지, 오랫동안 바뀌지 않을 로컬 규칙 몇 개면 충분한지 판단하세요. 직접 추가할 도메인이 몇 개뿐이라면 rules에 바로 적는 편이 관리하기 쉽습니다.

룰셋 콘텐츠 형식 구분하기

behavior: domain은 도메인 항목, behavior: ipcidr은 네트워크 대역, behavior: classical은 완전한 클래식 규칙 표현식을 담을 때 사용합니다. format: yaml과 format: text는 다운로드한 콘텐츠 형식과 일치해야 하며, 파일 확장자만 보고 판단하면 안 됩니다. YAML 룰셋은 일반적으로 payload 아래에 항목을 나열하고, 클래식 룰셋에는 DOMAIN-SUFFIX 같은 유형 접두사가 들어갈 수 있습니다. 클래식 규칙 텍스트를 도메인 룰셋으로 불러오거나 웹페이지의 오류 안내를 규칙 파일로 캐시하면 파싱에 실패합니다. 원격 주소를 처음 참조하기 전에 브라우저에서 로그인 페이지나 리디렉션된 안내 페이지가 아닌 실제 규칙 콘텐츠가 반환되는지 확인하세요.

예시에서는 필드 간 관계를 보여 주기 위해 문서 도메인을 사용했으며, 이 주소는 구독 가능한 룰셋 출처가 아닙니다. 실제 환경에 적용할 때는 신뢰하는 룰셋 주소로 바꾸고 해당 파일에 맞게 behavior와 format을 설정하세요. 캐시 path는 설정 디렉터리를 기준으로 한 상대 경로를 사용하고, 여러 provider가 같은 파일을 가리키지 않도록 하세요. interval은 업데이트 확인 주기이며 요청할 때마다 다시 다운로드하는 설정이 아닙니다.

rule-providers:
  work-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/work-domains.yaml
    path: ./rules/work-domains.yaml
    interval: 86400
rules:
  - RULE-SET,work-domains,수동 선택
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,자동 선택

앞의 예시에 해당하는 work-domains.yaml은 다음과 같이 작성할 수 있습니다. 도메인 룰셋에는 도메인 항목만 적고, 기본 설정의 rules 목록에서 사용하는 프록시 그룹 이름을 각 줄에 반복해서 넣지 마세요. 출구는 해당 룰셋을 참조하는 RULE-SET 행에서 지정합니다. 하나의 룰셋을 여러 규칙 행에서 참조할 수도 있지만, 앞선 규칙이 먼저 일치하면 뒤의 규칙은 선택 대상이 되지 않으므로 순서를 확인해야 합니다.

payload:
  - example.net
  - '+.example.org'

로드 과정에 따라 문제 해결하기

업데이트 후에는 먼저 클라이언트에서 룰셋 다운로드나 파싱 오류가 보고됐는지 확인하고, 캐시 파일이 있는지와 콘텐츠 형식이 여전히 예상대로인지 살펴보세요. 다운로드에는 성공했지만 규칙이 적용되지 않는다면 RULE-SET에 적힌 provider 이름, 해당 프록시 그룹 이름, rules 내 위치를 확인하세요. 도메인 규칙이 일치하려면 비교할 도메인 정보가 필요합니다. 대상 IP만 확인되는 연결은 도메인 규칙과 예상대로 일치하지 않을 수 있습니다. IP 규칙에서는 DNS 해석과 no-resolve 같은 옵션이 일치 경로에 미치는 영향도 확인하세요. 특정 규칙 하나를 적용하려고 모든 DNS 설정을 한꺼번에 바꾸면 안 됩니다.

구독 자체에 규칙과 룰셋이 포함되어 있을 수도 있습니다. 클라이언트가 구독을 업데이트할 때마다 기본 설정을 덮어쓴다면, 다운로드한 설정 파일을 직접 수정하는 것은 일시적인 변경에 불과합니다. 클라이언트의 오버라이드 기능을 사용하거나 직접 관리하는 설정에서 규칙 출처를 고정하세요. 규칙을 옮길 때는 검증할 수 있는 도메인 하나를 먼저 남겨 두고, 설정을 다시 불러온 뒤 ‘연결’ 화면에서 새 RULE-SET에 일치하는지 확인한 다음 나머지 항목을 옮기세요. 서로 겹치고 우선순위가 불분명한 원격 규칙을 두 세트 동시에 활성화하지 마세요. 어떤 규칙이 앞서는지, 기본 출구는 무엇인지 먼저 확인해야 합니다.

DNS 설정과 해석 경로

DNS 설정은 대상 도메인을 어떻게 해석할지와 프록시 서버 자체의 도메인을 어떻게 해석할지, 서로 다른 두 가지에 영향을 줍니다. 먼저 브라우저에서 보낸 DNS 요청이 클라이언트로 들어오는지 확인한 다음 DNS 서버 목록을 살펴보세요. 시스템 프록시는 일반적으로 앱의 HTTP 또는 SOCKS 트래픽을 처리하지만, 시스템의 모든 DNS 조회까지 처리한다는 뜻은 아닙니다. TUN 모드와 DNS 하이재킹 설정은 별도의 경로입니다. 도메인은 해석되지만 연결할 수 없다면 DNS 오류라고 단정하지 말고 규칙 일치 여부, 노드 연결 가능 여부와 대상 연결 로그도 함께 확인하세요.

주요 DNS 서버 필드 이해하기

default-nameserver는 주로 DNS 서버 자체의 도메인을 해석하는 등 초기 조회에 사용되므로 직접 접속할 수 있는 IP 주소를 지정하는 것이 좋습니다. nameserver는 일반 조회에 사용하는 서버 목록입니다. proxy-server-nameserver에는 프록시 노드 도메인을 해석할 서버를 별도로 지정할 수 있어, 노드 해석이 서비스 도메인의 분기 설정에 영향을 받지 않도록 합니다. nameserver-policy는 도메인별로 해석기를 지정합니다. 서버 URL, 일반 IP, 포트가 포함된 주소 표기를 혼동하지 마세요. 지정한 프로토콜 형식이 현재 커널의 DNS 업스트림 지원 범위에 맞아야 하며, 관련 네트워크에서 업스트림에 접속할 수 있어야 합니다.

아래 예시는 각 항목의 기본적인 역할 분담을 보여 주며, 현재 사용하는 해석기를 모두 예시 주소로 바꿀 필요는 없습니다. 활성화하기 전에 현재 네트워크에서 해당 주소에 접속할 수 있는지 확인하세요. 네트워크 제한이 있거나 사내 도메인을 내부 DNS로 조회해야 하는 환경에서는 특히 주의해야 합니다. respect-rules처럼 DNS 아웃바운드 경로에 영향을 주는 옵션은 기본 DNS 해석이 정상인지 확인한 뒤 검토하세요. 그래야 해석기와 프록시 노드의 도메인 조회가 서로 의존하는 상황을 피할 수 있습니다.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  proxy-server-nameserver:
    - 1.1.1.1
  fake-ip-filter:
    - '*.lan'
    - localhost.ptlogin2.qq.com

ipv6: false는 예시에서 선택한 값일 뿐, 모든 네트워크에서 IPv6를 꺼야 한다는 뜻은 아닙니다. 기기와 업스트림 해석기, 프록시 경로에서 IPv6를 정상적으로 사용할 수 있다면 실제 접속 요구에 따라 결정하세요. fake-ip-filter는 일부 도메인에 실제 해석 결과를 반환하도록 지정합니다. 로컬 네트워크 검색에 의존하거나 Fake-IP를 사용할 수 없는 앱에 적합합니다. 항목을 추가할수록 의도한 일치 경로를 우회하지 않는지 확인해야 합니다. 내부 도메인은 공용 DNS가 사설 네트워크 주소를 반환하길 기대하지 말고, 해당 도메인을 해석할 수 있는 내부 DNS를 사용하세요.

요청 하나로 문제 위치 찾기

먼저 클라이언트의 DNS 기능이 활성화되어 있는지 확인하고 설정을 다시 불러온 뒤 로그에 업스트림 연결 불가 메시지가 있는지 살펴보세요. 그런 다음 대상 도메인으로 새 연결을 만들어 실제 주소나 Fake-IP를 받았는지, 응답을 받지 못했는지 기록합니다. 클라이언트 로그에 해당 조회가 없다면 앱이 자체 보안 DNS를 사용하는지, 시스템이 다른 해석기를 계속 가리키는지, 현재 프록시 모드가 해당 요청을 처리하는지 확인하세요. 로그에 조회 기록은 있지만 결과가 예상과 다르다면 nameserver-policy의 일치 항목, Fake-IP 필터, 로컬 캐시를 점검하세요. 설정을 바꾼 뒤에는 클라이언트가 제공하는 캐시 삭제 방법으로 다시 테스트해 이전 응답을 새 설정의 결과로 오인하지 않도록 하세요.

DNS 서버가 정상적으로 응답해도 이후 연결까지 정상이라는 뜻은 아닙니다. 테스트할 때는 도메인과 출구 정책을 확인할 수 있는 요청을 선택하고, ‘연결’ 화면에서 최종 규칙도 살펴보세요. DIRECT에 일치하면 직접 연결 경로를 점검하고, 프록시 그룹에 일치하면 해당 그룹의 노드를 확인하세요. 사내 네트워크에서는 내부 도메인의 해석 경로를 유지하는 것이 특히 중요합니다. 기존 DNS 설정을 기록한 뒤 하나씩 조정하고, 문제를 찾는 동안 DNS와 규칙, TUN을 동시에 변경하지 마세요. 그래야 어느 변경부터 문제가 생겼는지 알 수 있습니다.

TUN 모드와 Fake-IP 함께 사용하기

시스템 프록시와 TUN은 트래픽을 처리하는 범위가 다릅니다. 시스템 프록시는 앱이 운영체제의 프록시 설정을 따라야 작동합니다. TUN은 가상 네트워크 인터페이스를 만들어 프록시 설정을 직접 참조하지 않는 앱의 트래픽도 클라이언트로 전달합니다. TUN을 켠다고 모든 문제가 저절로 해결되는 것은 아닙니다. 라우트 설정, DNS 하이재킹, 다른 VPN, 로컬 네트워크 접속과 시스템 권한이 결과에 영향을 줍니다. 처음 활성화하기 전에 일반 시스템 프록시로 연결이 정상적으로 되는지 확인하고 현재 DNS와 라우팅 상태를 기록하세요. 그러면 TUN을 켠 뒤 문제가 생겼을 때 기존 설정 문제인지 새로 추가된 처리 경로 문제인지 구분할 수 있습니다.

최소 설정부터 시작하기

auto-route는 커널이 라우트를 설정하도록 하고, auto-detect-interface는 실제 아웃바운드 인터페이스를 식별합니다. 네트워크 인터페이스가 자주 바뀌는 기기라면 식별 결과를 특히 주의 깊게 확인하세요. dns-hijack의 any:53은 조건에 맞는 일반 DNS 조회를 가로챈다는 뜻이지만, 앱이 직접 만드는 암호화 DNS 연결까지 처리한다고 보장하지는 않습니다. 클라이언트에 따라 화면의 스위치가 해당 필드를 설정하기도 하고, 네트워크 확장 프로그램이나 가상 인터페이스 권한이 필요하기도 합니다. 스위치 표시만 보지 말고 클라이언트에서 실제 적용된 설정을 확인하세요.

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

stack: mixed는 테스트에 사용할 수 있는 네트워크 스택 설정입니다. 특정 앱의 핸드셰이크나 로컬 네트워크 접속에 문제가 생기면 증상을 기록한 뒤 클라이언트가 지원하는 다른 스택과 비교하세요. 모든 라우팅 매개변수를 한꺼번에 바꾸지는 마세요. 기기에 회사 VPN이나 다른 투명 프록시, 가상 머신 브리지가 이미 있다면 라우팅 우선순위와 인터페이스 충돌을 확인해야 합니다. 두 프로그램이 모두 기본 라우트를 가로채려 하면 연결이 반복해서 끊기거나, 내부망으로 가야 할 주소가 잘못된 출구로 전달될 수 있습니다. 먼저 다른 트래픽 처리 도구를 잠시 중지해 비교한 다음 라우트를 제외하거나 인터페이스를 조정할지 결정하세요.

Fake-IP의 매핑 방식 이해하기

Fake-IP는 대상 도메인을 곧바로 실제 주소로 해석하는 대신 앱에 가상 주소를 전달하고, 커널에 도메인과 해당 주소의 매핑을 저장합니다. 이후 연결이 들어오면 커널이 이를 바탕으로 도메인을 복원해 도메인 규칙을 적용할 수 있습니다. 이 방식은 DNS 조회와 그 뒤의 연결이 서로 연결 가능한 경로를 통해 클라이언트에 들어와야 작동합니다. 앱이 다른 DNS 경로를 사용하거나 이전 주소를 캐시했다면 도메인과 연결이 일치하지 않을 수 있습니다. 앱에 IP만 표시되고 도메인 규칙이 적용되지 않는다면 먼저 해당 앱의 DNS 조회와 연결이 모두 로그에 나타나는지 비교하세요.

로컬 네트워크 기기 검색이나 프린터, 화면 전송, 실제 주소만 사용하는 일부 앱에는 Fake-IP가 적합하지 않을 수 있습니다. 문제가 분명한 도메인만 필터에 추가한 뒤 기기 검색과 연결을 테스트하세요. 도메인 접미사 목록 전체를 광범위하게 제외하지 않는 것이 좋습니다. 로컬 네트워크 IP에 계속 접속할 수 없다면 사설 주소를 프록시 그룹으로 보내는 규칙이 있는지, 운영체제 방화벽과 로컬 네트워크 권한이 어떻게 설정되어 있는지 확인하세요. Fake-IP 필터는 해석 결과만 처리할 뿐 라우팅 규칙을 대신하지 않습니다. 진단이 끝나면 브라우저, 시스템 프록시를 따르지 않는 앱 하나, 로컬 네트워크 서비스 하나를 각각 테스트해 TUN이 필요한 트래픽을 제대로 처리하면서 로컬 접속도 유지하는지 확인하세요.

도메인 스니핑과 규칙 일치

클라이언트에 대상 IP만 표시되지만 도메인 규칙으로 출구를 결정해야 할 때, 도메인 스니핑으로 연결의 프로토콜 핸드셰이크에서 도메인을 확인할 수 있습니다. 주로 HTTP 요청이나 TLS·QUIC 핸드셰이크에서 확인 가능한 정보를 살펴보는 기능입니다. 웹페이지 내용을 읽거나 모든 암호화 연결의 원래 도메인을 알아내는 기능은 아닙니다. 스니핑한 도메인이 연결 대상을 대체하는지, 라우팅에 반영되는지는 관련 옵션에 따라 달라집니다. 활성화하기 전에 ‘연결’ 화면을 먼저 확인하세요. 대상 도메인이 이미 온전히 표시되고 규칙도 정상적으로 적용된다면, 도메인을 더 많이 표시하려고 스니핑 범위를 넓힐 필요는 없습니다.

프로토콜과 포트 범위 지정하기

아래 예시는 일반적인 HTTP, TLS, QUIC 포트만 다룹니다. ports는 검사 범위를 제한하고 override-destination은 스니핑 결과로 대상을 덮어쓸지 결정합니다. 현재 사용하는 앱에 맞는 포트만 남기고 문제가 있는 연결을 대상으로 테스트하세요. QUIC은 UDP 기반이므로 네트워크나 클라이언트에서 해당 UDP 트래픽을 처리하지 않는다면 QUIC 스니핑 항목만 추가해도 연결이 커널로 들어오지 않습니다. 비표준 포트를 사용하는 HTTP도 마찬가지로 실제 서비스 포트를 하나씩 확인해야 합니다.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
    QUIC:
      ports:
        - 443
  skip-domain:
    - '+.lan'

예시에서 로컬 네트워크 도메인을 제외한 것은 로컬 네트워크로 보내야 할 대상에 불필요한 판단을 적용하지 않기 위해서입니다. 실제 설정은 사용하는 앱에 맞춰 조정해야 합니다. 일부 프로그램은 IP로 서버에 연결하면서 TLS 핸드셰이크에는 접속 목적과 다른 도메인을 포함할 수 있습니다. 스니핑 결과로 대상을 강제로 덮어쓰면 기존 라우팅 동작이 달라질 수 있습니다. 특정 서비스가 스니핑을 활성화한 뒤에만 실패한다면 활성화 전후의 대상 주소와 일치 규칙, 오류 로그를 비교한 다음 해당 대상에 제외 조건을 설정하세요. 모든 규칙 기반 분기를 바로 끄지는 마세요.

전체 점검 과정에 스니핑 포함하기

연결에 도메인 규칙을 적용할 수 있는지 확인하려면 최소 세 가지를 점검해야 합니다. DNS에서 연결과 연계할 수 있는 도메인을 제공하는지, 스니핑이 도메인을 확인해 적용했는지, 규칙 목록에서 기본 규칙보다 앞서 해당 도메인 항목이 일치하는지 확인하세요. ‘연결’ 화면에 IP만 표시되면 앱이 원래 고정 IP를 사용한 것인지 먼저 살펴보세요. 도메인이 표시되지만 출구가 잘못됐다면 스니핑 프로토콜을 추가하기보다 규칙 순서와 프록시 그룹을 우선 확인하세요. Fake-IP가 활성화된 트래픽은 앱의 DNS 조회와 연결이 같은 처리 경로를 거치지 않았는지도 확인해야 합니다.

스니핑은 ‘모든 IP를 도메인으로 바꾸는’ 범용 스위치가 아닙니다. 모든 프로토콜에서 호스트 이름을 식별할 수 있는 것은 아니며, 프로토콜이 업데이트되면 핸드셰이크에서 확인 가능한 필드가 달라질 수 있습니다. 로그에 스니핑 결과가 없더라도 클라이언트가 해당 연결을 처리하지 않았다고 단정할 수는 없습니다. 확인 가능한 연결 대상과 규칙 일치 결과, 최종 출구를 기준으로 진단하세요. 앱별로 테스트하면서 한 번에 프로토콜 하나 또는 제외 항목 하나만 바꾸고, 기존 연결을 끊은 뒤 새 요청을 보내세요. 브라우저에서만 문제가 나타난다면 브라우저가 자체 DNS나 QUIC을 사용하는지, 다른 앱과 같은 경로로 트래픽을 전달하는지도 확인하세요.

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

구독 파일은 제공자가 업데이트하므로 다운로드한 파일을 직접 수정해도 다음 새로고침까지만 유지되는 경우가 많습니다. 로컬 오버라이드는 포트와 DNS, 규칙, 프록시 그룹처럼 직접 관리하는 설정을 업데이트되는 노드 정보와 분리하기 위한 기능입니다. 클라이언트마다 오버라이드 구현 방식은 다릅니다. 설정을 가져온 뒤 패치를 적용하거나, 필드별로 병합하거나, 스크립트로 최종 YAML을 생성하기도 합니다. 먼저 클라이언트에서 ‘오버라이드’, ‘설정 병합’ 또는 이와 비슷한 메뉴를 찾아 적용 순서를 확인한 다음 결과를 쉽게 살펴볼 수 있는 필드 하나로 시험하세요. 배열이 항상 추가된다고 가정하지 마세요. 규칙이나 프록시 그룹이 통째로 교체되면 기존 트래픽 분기가 사라질 수 있습니다.

최종 적용 파일부터 확인하기

확인해야 할 대상은 편집기 안의 설정 조각이 아니라 클라이언트가 불러온 최종 설정 전체입니다. mixed-port, mode, dns, proxy-groups, rules에 예상한 내용만 남아 있는지 확인하세요. 아래 예시는 직접 관리하는 설정에 넣을 수 있는 최상위 설정입니다. 클라이언트의 오버라이드 화면에서 특정 패치 형식만 지원한다면 해당 화면의 요구사항에 맞게 변환하세요. 이 예시가 모든 클라이언트에 통용되는 오버라이드 파일은 아닙니다. 포트가 충돌하면 먼저 어떤 프로세스가 해당 포트를 사용 중인지 확인한 다음 설정을 변경하고 그 포트를 사용하는 앱도 함께 업데이트하세요.

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

여러 구독을 병합할 때는 노드 이름도 확인해야 합니다. 두 구독에서 모두 ‘자동 선택’, ‘기본 노드’ 또는 같은 지역 이름을 제공할 수 있습니다. 병합 도구가 이름을 기준으로 덮어쓴다면 최종 설정에서 다른 구독의 구성원을 참조할 수 있습니다. 병합하기 전에 원본 구독을 보관하고 각각의 노드 이름과 업데이트 주기를 기록하세요. 병합 후에는 최종 proxies, proxy-providers, proxy-groups의 이름 참조를 확인하세요. 노드 목록은 재료일 뿐입니다. 누가 노드를 선택하는지, 규칙이 어느 그룹을 가리키는지, 구독 업데이트 후 새 노드가 그룹에 어떻게 추가되는지 명확히 정해야 합니다.

업데이트 후 검증 절차 고정하기

먼저 각 구독을 한 번씩 업데이트해 원본 설정이 정상적으로 파싱되는지 확인하세요. 그런 다음 로컬 오버라이드를 적용하고 최종 설정을 불러올 수 있는지 살펴봅니다. 이어서 직접 연결 규칙 하나와 프록시 규칙 하나, 마지막 MATCH를 확인하고 각각 새 연결을 만들어 일치 결과를 검증하세요. 마지막으로 구독을 새로고침한 뒤 다시 테스트합니다. 처음에는 성공했지만 업데이트 후 실패한다면 오버라이드가 다시 적용됐는지, 그룹 구성원 필터가 업데이트된 노드 이름과 일치하는지 집중적으로 살펴보세요. 다운로드와 병합, 파싱, 연결 중 어느 단계에서 실패했는지 기록하면 서로 다른 문제를 뒤섞지 않고 해결할 수 있습니다.

규칙 목록의 최종 순서는 한 곳에서 관리하는 것이 좋습니다. 구독 A의 MATCH가 구독 B의 세부 규칙보다 앞에 있으면 B의 규칙은 실행되지 않습니다. 병합 도구가 이름이 같은 그룹을 단순히 이어 붙이면 참조 대상이 불분명해질 수도 있습니다. 정상적으로 연결되는 원본 설정을 보관하고 큰 변경을 할 때마다 현재 작동하는 오버라이드 내용을 복사해 두세요. 구독 링크가 전체 YAML을 제공하는지 노드 목록만 제공하는지 알아보려면 구독 형식과 변환 안내를 참고하세요. 형식을 변환해도 기존 규칙과 프록시 그룹이 모두 유지된다는 보장은 없습니다.

외부 컨트롤러와 설정 점검

외부 컨트롤 인터페이스를 사용하면 호환되는 패널에서 연결과 규칙, 프록시 그룹 상태를 확인하고, 그룹을 전환하거나 설정을 다시 불러올 수도 있습니다. 혼합 프록시 포트와는 다른 서비스입니다. mixed-port는 앱 트래픽을 받고 external-controller는 관리 인터페이스를 제공합니다. 설정을 진단할 때 패널에서 현재 그룹 선택과 실제 연결, 적용 규칙을 확인할 수 있습니다. 다만 패널에 표시되는 결과의 기준은 현재 실행 중인 커널입니다. 클라이언트 내장 화면에서 이미 필요한 정보를 확인할 수 있다면 별도로 네트워크 관리 포트를 열지 말고 내장 화면을 사용하세요.

먼저 로컬 주소에만 바인딩하기

현재 컴퓨터에서만 패널에 접속한다면 컨트롤 인터페이스를 127.0.0.1에 바인딩하세요. 로컬 패널에 연결하려고 모든 네트워크 인터페이스에서 수신하도록 바꾸지 마세요. 예시의 빈 secret은 외부와 격리된 로컬 테스트에서만 사용할 수 있습니다. 로컬 네트워크 기기에서 접속해야 한다면 별도의 관리 키를 설정하고 접근 가능한 네트워크를 제한한 뒤 시스템 방화벽도 확인하세요. 구독 링크와 관리 키, 노드 인증 정보가 들어 있는 전체 설정을 출처가 불분명한 온라인 패널에 붙여 넣지 마세요.

external-controller: 127.0.0.1:9090
secret: ""
mixed-port: 7890
mode: rule

컨트롤 인터페이스 주소는 커널이 제공하지만 패널도 접속 주소를 알아야 합니다. 일부 클라이언트 내장 패널은 주소를 자동으로 가져오지만, 독립 실행형 패널은 직접 입력해야 할 수 있습니다. 연결되지 않으면 먼저 커널이 해당 설정을 실제로 불러왔는지, 해당 포트를 다른 프로세스가 사용 중이지 않은지, 패널이 같은 기기에 연결하는지 확인하세요. 브라우저나 시스템 프록시가 로컬 컨트롤 요청을 원격으로 보내고 있지 않은지도 살펴보세요. 포트를 바꿨다면 패널에 저장된 주소도 함께 바꿔야 합니다. 인증 오류가 발생하면 컨트롤 인터페이스의 키 설정을 확인하고 노드 구독 비밀번호를 패널 키로 잘못 입력하지 않았는지 확인하세요.

패널 결과를 설정 파일에서 다시 확인하기

패널에 그룹이 표시된다고 규칙이 해당 그룹을 참조한다는 뜻은 아닙니다. 그룹을 전환할 수 있어도 새 연결이 반드시 그 그룹을 사용한다는 보장은 없습니다. 하나씩 확인하려면 먼저 ‘설정’에서 현재 불러온 파일과 업데이트 상태를 확인한 뒤, ‘규칙’에서 대상 도메인에 적용되는 규칙을 살펴보고 마지막으로 ‘연결’에서 요청이 실제로 어떤 규칙과 일치했는지 확인하세요. 클라이언트에서 설정을 바꾼 뒤에도 패널에 이전 그룹이 표시되면 패널을 새로고침하고 컨트롤 인터페이스가 다른 커널 인스턴스에 연결된 것은 아닌지 확인하세요. 패널에 캐시된 표시만 보고 설정을 수정하지 마세요.

설정을 불러오지 못하면 로그에 표시된 필드와 줄 번호부터 확인하고 YAML 들여쓰기와 중복 최상위 키, 규칙이 가리키는 그룹 이름, provider의 로컬 경로를 점검하세요. YAML은 공백으로 계층을 표현하며 목록 항목의 하이픈은 예상한 계층에 있어야 합니다. 웹페이지에서 설정을 복사할 때 탭이나 전각 문장 부호가 섞여도 파싱에 실패할 수 있습니다. 저장해 둔 정상 설정으로 먼저 되돌린 뒤 이 페이지의 예시를 조금씩 추가하고 다시 불러오는 편이 이미 작동하지 않는 전체 파일에서 계속 추측하는 것보다 안전합니다. 처음 설치한 뒤 연결 방법을 모르겠다면 빠른 시작으로 돌아가세요. 그래픽 클라이언트를 바꾸려면 설치 파일 페이지에서 플랫폼을 선택하세요. Clash Plus를 가장 먼저 추천합니다.