Clash 고급 설정 가이드

프록시 그룹 유형과 활용

프록시 그룹은 규칙에 일치한 트래픽을 어떤 출구로 보낼지 정하며, 트래픽이 어느 사이트에 속하는지 판단하지는 않습니다. 설정에서 proxies는 실제 노드를 정의하고, proxy-groups는 노드나 다른 프록시 그룹을 묶어 선택 가능한 출구를 만듭니다. rules는 이 출구 이름을 참조합니다. 세 단계의 이름은 정확히 일치해야 합니다. 노드 이름을 비슷한 이름으로 바꿔도 기존 규칙이 새 항목을 자동으로 찾지는 않습니다.

변경하기 전에 설정 페이지에서 현재 활성화된 구독을 확인하고, 프록시 페이지에서 기존 프록시 그룹을 살펴보세요. 제공업체가 자동 선택, 지역별 분류, 앱별 라우팅을 위해 여러 단계의 그룹을 이미 구성했을 수 있습니다. 같은 이름의 그룹을 추가하면 충돌할 수 있고, 목록 전체를 덮어쓰면 기존 규칙이 대상을 잃을 수 있습니다. 전체 설정을 복사하기보다 이름과 참조 관계부터 기록하면 문제를 더 쉽게 찾을 수 있습니다.

수동 선택·속도 측정 선택·자동 전환

select는 출구를 직접 선택할 때 사용하며, 지역이나 로그인 환경을 고정해야 하는 앱에 적합합니다. 클라이언트의 선택값은 저장 설정의 영향을 받을 수 있으므로 YAML 목록의 첫 번째 항목만 보고 판단하지 마세요. 문제를 해결할 때는 프록시 페이지에서 그룹을 펼쳐 실제 선택 항목을 확인하세요. 그룹이 다른 그룹을 참조하면 실제 노드가 나올 때까지 계속 펼쳐야 합니다.

url-test는 연결 테스트 결과에 따라 출구를 선택하므로 용도가 비슷한 노드가 여러 개 있을 때 적합합니다. 테스트 주소의 안정성, 노드에서 해당 주소에 접속할 수 있는지, 테스트 간격이 지나치게 짧은지에 따라 결과가 달라집니다. 한 번 빠르게 측정됐다고 모든 사이트에서 더 빠른 것은 아닙니다. 다운로드, 동영상, 업무 서비스는 경로가 다를 수 있으므로 테스트 결과를 전송 속도 순위로 간주하지 마세요.

fallback은 목록 순서에 따라 사용 가능한 항목을 우선 사용하므로 주·보조 출구를 명확히 지정할 때 적합합니다. load-balance는 선택한 정책에 따라 연결을 분배하는 기능이며, 하나의 다운로드 연결을 여러 노드로 나눠 대역폭을 합산하지는 않습니다. 계정 지역, 결제 인증, IP 제한이 있는 서비스에서는 출구를 자주 바꾸면 추가 인증이 필요할 수 있습니다. 보통은 수동 선택 그룹이나 주·보조 그룹으로 동작을 먼저 확인하는 편이 좋습니다.

동작을 설명하기 쉬운 출구 구조부터 만들기

아래 예시는 규칙에서 프록시 그룹을 참조하는 방법만 보여 주며 프록시 서버 정보는 포함하지 않습니다. 내장 출구 두 개는 바로 사용할 수 있으므로 임의의 노드 정보를 만들 필요가 없습니다. 기존 설정에 합칠 때는 같은 최상위 항목을 다시 작성하지 말고 목록에 병합하세요. 예시는 기본적으로 직접 연결합니다. 프록시를 사용하려면 가져온 구독의 실제 노드나 기존 프록시 그룹을 구성원으로 추가한 뒤 클라이언트에서 선택하세요.

proxy-groups:
  - name: 수동 출구
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.org,수동 출구
  - MATCH,DIRECT

자동 그룹을 실제로 사용할 때는 url, interval, tolerance를 설정할 수 있습니다. 간격은 초 단위이며, 허용 오차는 미세한 차이로 선택이 반복해서 바뀌는 것을 줄여 줍니다. 간격을 짧게 설정한다고 항상 좋은 것은 아닙니다. 특히 모바일 네트워크나 데이터 요금이 부과되는 환경에서는 여러 그룹이 동시에 테스트할 때 추가 요청이 발생합니다. 먼저 적당한 테스트 간격을 사용하고, 로그를 확인해 조정이 필요한지 판단하세요.

그룹끼리 참조할 수 있지만 순환 참조는 피해야 합니다. 예를 들어 ‘업무 출구’가 ‘자동 출구’를 참조하는 것은 명확한 단방향 구조입니다. 반대로 ‘자동 출구’가 다시 ‘업무 출구’를 구성원으로 포함하면 코어가 유효한 의존 관계를 만들 수 없습니다. 구독을 여러 개 병합하면 서로 다른 구독에서 같은 그룹 이름을 사용하는 경우가 많아 이런 문제가 더 쉽게 생깁니다. 로컬 그룹 이름에는 용도를 나타내는 일정한 접두어를 붙여 구독 업데이트에 따라 바뀔 수 있는 표시 이름에 의존하지 않도록 하세요.

프록시 그룹을 확인할 때는 먼저 규칙 모드를 유지한 상태에서 확실히 일치하는 도메인에 접속하고, 연결 페이지에서 일치 규칙, 프록시 체인, 실제 출구를 확인하세요. 연결 기록이 없다면 트래픽이 코어에 들어왔는지부터 점검하고, 기록은 있지만 잘못된 그룹을 사용한다면 규칙 순서를 확인하세요. 모드, 노드, DNS를 한 번에 바꾸면 성공이나 실패의 원인을 찾기 어렵습니다.

규칙 세트 구독 관리

규칙 세트는 자주 바뀌는 조건을 기본 설정에서 분리해, 기본 설정에는 참조와 순서만 남겨 둡니다. 사이트 도메인 목록이 업데이트되어도 프록시 그룹이나 포트 설정을 반복해서 수정할 필요가 없습니다. 규칙 세트는 노드 구독과 다른 항목입니다. 노드 구독은 출구를 제공하고 규칙 세트는 매칭 조건을 제공합니다. 최종 출구는 RULE-SET 규칙에 지정된 정책으로 결정됩니다.

규칙 세트를 관리하기 전에 기존 규칙을 용도별로 정리하세요. 기기와 LAN 예외는 보통 우선순위를 높게 두고, 명확한 사이트별 라우팅은 그다음에 처리하며, 지역 범위 규칙과 기본 규칙은 뒤쪽에 둡니다. Mihomo는 대개 위에서 아래로 규칙을 확인해 처음 일치하는 규칙에서 멈춥니다. 아래에 더 구체적인 규칙이 있어도 위의 포괄적인 규칙을 자동으로 덮어쓰지 않습니다. 규칙 순서는 도메인 목록만큼 중요합니다.

동작 유형을 먼저 선택한 다음 파일 형식을 지정하세요

behavior는 규칙 내용의 의미를 나타냅니다. domain은 도메인 목록을 처리하고, ipcidr은 IP 주소 대역을 처리하며, classical은 유형 접두어가 붙은 규칙 조건을 포함할 수 있습니다. format은 YAML, 일반 텍스트, 지원되는 바이너리 규칙 형식 등 파일의 인코딩 형식을 나타냅니다. 형식이 올바르다고 동작 유형까지 맞는 것은 아니므로 둘 다 원본 내용과 일치해야 합니다.

아래 예시는 원격 주소 없이 로컬 파일을 사용합니다. 먼저 클라이언트가 접근할 수 있는 설정 디렉터리에 해당 파일을 만든 다음, 제공자 정의와 규칙 참조를 기본 설정에 병합하세요. 상대 경로는 브라우저 다운로드 폴더가 아니라 클라이언트가 코어에 전달하는 실제 작업 디렉터리를 기준으로 합니다. 로그에 파일을 찾을 수 없다고 나오면 도메인 내용을 반복해서 바꾸지 말고 설정 디렉터리와 실행 환경을 확인하세요.

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,수동 출구

해당하는 local-direct.yaml의 내용은 다음과 같습니다. 규칙 조건만 두고 각 행에 출구 정책을 적지 않았습니다. 출구는 기본 설정에서 참조해 한곳에서 지정하기 때문입니다. 마지막의 no-resolve는 이 주소 규칙이 도메인 조회를 직접 시작하지 않도록 하는 옵션이지, 클라이언트의 DNS 전체를 끄는 설정은 아닙니다. 위 예시의 ‘수동 출구’는 앞 장에서 만든 프록시 그룹을 사용하거나 기존 그룹 이름으로 바꾸세요.

payload:
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve
  - IP-CIDR,10.0.0.0/8,no-resolve

원격 관리로 전환하려면 제공자 유형을 type: http로 바꾸고 실제로 접속 가능한 url, 로컬 캐시 path, 초 단위 interval을 지정하세요. 파일 확장자만 보고 내용을 추측하지 마세요. 서버가 로그인 페이지, 접근 제한 안내 또는 일반 웹페이지를 반환하면 주소가 YAML로 끝나더라도 규칙 세트로 파싱할 수 없습니다. 먼저 응답 본문을 확인한 다음 설정 항목을 점검하세요.

업데이트 실패와 규칙 미일치를 따로 확인하세요

업데이트에 실패하면 먼저 다운로드 경로가 유효한지 확인하세요. 규칙 세트를 업데이트하려면 네트워크 연결이 필요합니다. 다운로드되지 않은 리소스에만 의존해 유일한 출구를 구성하면 안 됩니다. 캐시가 있으면 클라이언트가 이전 내용을 계속 사용할 수 있으므로 네트워크에 접속된다는 사실만으로 새 규칙이 로드됐다고 볼 수 없습니다. 제공자 상태와 로그에서 업데이트 완료 여부를 확인한 뒤 캐시 내용이 예상과 일치하는지 살펴보세요.

업데이트는 성공했지만 규칙이 일치하지 않는다면 앞에 더 넓은 범위의 규칙이 있는지 확인하세요. 같은 접미사에 대한 직접 연결 규칙이 있거나 앞선 주소 규칙이 먼저 일치할 수 있습니다. 연결 대상이 도메인인지 IP인지도 확인하세요. 도메인 매핑이 없는 상태에서 IP로 연결하면 도메인 규칙과 일치하지 않을 수 있습니다. 마지막으로 새 연결로 테스트했는지 확인하세요. 브라우저 연결 풀에 남은 기존 연결이 계속 사용될 수 있습니다.

규칙 세트가 커지면 모든 출처를 한꺼번에 추가하지 않는 편이 좋습니다. 여러 출처가 서로 덮어쓰거나 업데이트 주기가 다를 수 있고, 같은 사이트를 서로 다르게 분류할 수도 있습니다. 기본 분류 체계 하나를 정하고 필요한 로컬 예외만 추가하면 관리하기 쉽습니다. 각 제공자의 용도, 출처, 동작 유형, 참조 위치를 기록하세요. 삭제할 때는 먼저 참조를 제거한 다음 제공자 정의를 지우세요.

로컬 예외는 가능한 한 적용 범위를 명확하게 지정하세요. 도메인 하나의 출구를 바꾸려는 경우 최상위 도메인 전체나 넓은 주소 대역을 같은 정책에 포함하지 마세요. 주소 규칙은 조회를 유발하는지 특히 주의해야 합니다. 넓은 주소 대역 하나를 일치시키기 위해 불필요한 DNS 조회가 발생하지 않도록 하세요. 규칙이 일치하는 이유를 구체적으로 설정할수록 잘못된 라우팅을 추적할 범위가 좁아집니다.

원격 규칙은 설정 공급망의 일부이므로 용도가 명확하고 내용을 검토할 수 있는 출처를 선택하세요. 업데이트 전에는 이전에 사용하던 파일을 보관하고, 업데이트 후 대표 도메인 몇 개로 프록시 체인을 확인하세요. 최상위 항목과 들여쓰기 구조를 더 자세히 알아보려면 Clash 설정 파일 YAML 항목별 분석을 참고하세요. 병합 문제를 해결하려고 같은 항목을 중복 추가하지 마세요.

DNS 설정 최적화

DNS 설정의 목적은 서버 수를 단순히 늘리는 것이 아니라 도메인 조회와 연결 출구가 일관되도록 하는 것입니다. 요청에는 앱 자체 조회, 시스템 DNS, 코어 DNS, 프록시 서버 도메인 조회가 관여할 수 있습니다. 조회가 어느 계층에서 이루어지는지 먼저 알아야 브라우저는 정상인데 명령줄은 실패하거나, 출구를 바꿔도 이전 주소로 연결되는 이유를 설명할 수 있습니다.

클라이언트에서 dns.enable을 켜면 코어의 DNS 기능이 활성화되지만 모든 앱이 반드시 이를 사용한다는 뜻은 아닙니다. 시스템 프록시는 프록시 설정을 지원하는 앱의 연결을 처리할 뿐, 시스템 DNS까지 가로채지는 않을 수 있습니다. TUN의 DNS 리디렉션은 별도의 경로입니다. 앱 자체의 암호화 DNS도 일반적인 53번 포트 조회를 우회할 수 있으므로 스위치 상태만 보고 모든 조회가 통합됐다고 판단하지 마세요.

부트스트랩·일반·정책 DNS를 구분하세요

default-nameserver는 DNS 상위 서버의 도메인을 조회할 때 사용하며, 보통 직접 접속할 수 있는 IP 주소를 지정해야 합니다. nameserver는 일반 상위 서버 목록입니다. nameserver-policy를 사용하면 특정 도메인 범위에 상위 서버를 지정할 수 있습니다. 이는 DNS 조회 경로를 제어하며, 서비스 연결 경로를 제어하는 rules와는 다릅니다. 각각 따로 확인하세요.

아래 예시는 일반 조회 모드와 일부 도메인에 적용하는 DNS 정책을 보여 줍니다. 수신 주소를 루프백 인터페이스로 제한하고, 시스템 서비스와의 충돌을 피하기 쉬운 높은 포트 번호를 사용합니다. 이 설정은 운영체제의 DNS 설정을 자동으로 바꾸지 않으며 TUN도 포함하지 않습니다. 먼저 조회 명령으로 수신 포트에 직접 요청해 코어가 응답하는지 확인한 뒤 앱에 연결하세요. 병합할 때는 기존 DNS 객체를 교체하거나 통합해야 하며 파일 끝에 두 번째 객체를 추가하면 안 됩니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.org":
      - 223.5.5.5

예시의 도메인 정책은 매칭 문법을 설명하기 위한 것으로, 해당 도메인이 지정된 상위 서버를 반드시 사용해야 한다는 뜻은 아닙니다. 기업 내부 도메인은 공용 서버를 그대로 쓰지 말고 실제로 조회 가능한 내부 DNS를 지정하세요. 내부 서버를 사용할 때는 요청이 통과하는 네트워크 인터페이스와 라우팅도 확인해야 합니다. 회사 네트워크 밖에서는 내부 DNS에 접속할 수 없을 수 있으므로 주소를 고정하면 간헐적인 오류가 발생할 수 있습니다.

규칙 기반 DNS 출구 제어를 활성화할 때는 respect-rules와 proxy-server-nameserver의 조합도 확인하세요. 프록시 서버 주소가 도메인이라면 코어는 프록시에 연결하기 전에 먼저 주소를 조회해야 합니다. 이 조회를 아직 연결되지 않은 프록시를 통해서만 수행하도록 설정하면 안 됩니다. 프록시 서버 도메인에 별도의 접근 가능한 조회 경로를 두면 이런 시작 단계의 의존성 순환을 피할 수 있습니다.

대체 DNS는 서버를 두 배로 늘리는 보험이 아닙니다

fallback과 fallback-filter는 함께 이해해야 합니다. 후자는 어떤 조회 결과에 대체 서버를 사용할지 결정하며, 주 서버가 시간 초과되면 모든 보조 주소를 차례로 시도하는 단순한 기능이 아닙니다. 필터 조건을 확인하지 않은 채 대체 서버만 추가하면 같은 도메인에 대해 예상과 다른 주소가 선택될 수 있습니다. 먼저 간단한 설정으로 기본 조회를 확인하고, 구체적인 오염이나 지역 문제에 따라 분기 조건을 추가하세요.

암호화 DNS를 켜면 상위 서버까지 조회 내용이 전송되는 경로를 보호할 수 있지만, 현재 출구에 적합한 조회 결과를 보장하지는 않습니다. 원격 상위 서버가 다른 지역의 CDN 주소를 반환해 접속 경로가 우회될 수 있습니다. 특정 사이트가 느려지면 조회 결과, 실제 연결 주소, 출구 경로를 비교하세요. 모든 성능 문제를 노드 탓으로 돌리거나 도메인마다 별도 정책을 만들 필요는 없습니다.

IPv6는 전체 경로를 확인해야 합니다. 시스템에서 IPv6 주소를 받았더라도 프록시 노드, TUN 라우팅, 대상 사이트의 IPv6 경로가 모두 정상이라는 뜻은 아닙니다. DNS의 IPv6 응답을 끄면 문제 범위를 좁힐 수 있지만 시스템 라우팅 확인을 대신하지는 않습니다. 앱이 자체 캐시 주소를 사용하면 설정을 바꾼 뒤에도 계속 연결할 수 있습니다. 먼저 관련 앱의 연결을 종료한 다음 다시 조회하고 테스트해야 결과를 비교할 수 있습니다.

dig를 사용할 수 있는 시스템에서는 다음 명령으로 예시 수신 포트를 확인할 수 있습니다. 응답 여부, 비정상적인 지연, 주소 유형이 현재 모드와 일치하는지 살펴보세요. 조회에 성공해도 코어 DNS에 직접 접속한 이번 요청이 성공했다는 뜻일 뿐입니다. 실제 앱에서도 연결을 시작해 다른 DNS를 사용하지 않는지 확인하세요. 조회 도구가 설치되어 있지 않다면 테스트를 위해 시스템 DNS 전체를 바꿀 필요는 없습니다.

dig @127.0.0.1 -p 1053 example.org A
dig @127.0.0.1 -p 1053 example.org AAAA

캐시는 브라우저, 운영체제, 코어에 각각 남을 수 있으므로 계층별로 확인하세요. 정책을 바꾼 뒤에는 새 연결을 만들고, 필요한 경우 해당 계층의 캐시만 지우세요. 매번 컴퓨터를 재시작할 필요는 없습니다. 로그에서 조회 실패가 반복된다면 실패한 도메인과 사용된 상위 서버를 기록하세요. 사이트 하나만 문제라면 도메인 정책과 앱 자체 설정부터 확인하세요. 오류 로그를 읽는 방법은 로그 메시지와 문제 추적 방법을 참고하세요.

TUN과 Fake-IP

TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 읽지 않는 앱에 적합합니다. Fake-IP는 DNS 동작 방식 중 하나입니다. 코어가 내부 매핑용 주소를 반환하고, 이후 연결에서 도메인 정보를 복원합니다. 두 기능은 함께 쓰이는 경우가 많지만 서로 다른 기능이며 모든 환경에서 동시에 켤 필요는 없습니다. 먼저 필요한 것이 트래픽 처리인지 도메인 연계인지 확인한 다음 해당 계층을 조정하세요.

시스템 프록시만으로 충분하다면 TUN은 꺼 둬도 됩니다. 명령줄 도구, 게임 또는 직접 연결하는 앱의 트래픽까지 처리해야 할 때 TUN을 켜고 시스템 권한을 확인하세요. Clash Verge Rev의 서비스 모드, 운영체제 권한, 다른 네트워크 소프트웨어가 가상 인터페이스 생성에 영향을 줄 수 있습니다. UI에서 스위치가 켜져 있어도 인터페이스, 라우팅, 연결 기록을 확인해야 합니다.

먼저 트래픽 처리 경로를 만든 다음 DNS 모드를 조정하세요

아래 예시는 TUN 자동 라우팅과 Fake-IP를 함께 쓰는 일반적인 구성을 보여 줍니다. 가상 인터페이스를 만들고 경로를 설정할 권한이 필요하므로 클라이언트의 설정 화면에서 권한 상태를 확인하세요. 플랫폼마다 프로토콜 스택과 인터페이스 지원이 다릅니다. 다른 플랫폼의 특정 값을 성능 최적값으로 그대로 간주하지 말고, 호환 문제가 생기면 기존 프로토콜 스택으로 되돌리세요.

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"
  nameserver:
    - https://dns.alidns.com/dns-query

auto-route는 관련 경로를 추가하고 auto-detect-interface는 출구 인터페이스를 식별합니다. 다중 네트워크 어댑터, 가상 머신 브리지, 기업 VPN이 함께 있는 환경에서는 올바른 경로가 자동으로 선택된다고 보장할 수 없습니다. Wi-Fi를 바꾸거나 유선 네트워크에 연결하거나 다른 터널을 시작한 뒤 트래픽이 끊기면 출구 인터페이스와 라우팅 변경부터 확인하세요. 구독을 바로 다시 만들 필요는 없습니다.

dns-hijack의 일반 DNS 리디렉션은 모든 종류의 도메인 조회를 가로채는 기능이 아닙니다. 앱 자체의 HTTPS DNS 요청은 암호화된 서비스 트래픽이므로 일반 DNS 패킷처럼 처리할 수 없는 경우가 많습니다. 일부 시스템의 로컬 DNS 서비스도 별도 전달 경로를 사용합니다. 검증할 때는 조회 결과와 연결 페이지의 도메인을 함께 확인하세요. 53번 포트 규칙을 작성했다는 이유만으로 모든 앱의 DNS가 제어된다고 판단하지 마세요.

Fake-IP 주소는 매핑용 주소이지 원격 서버 주소가 아닙니다

Fake-IP 모드에서 예약된 주소 범위의 IP가 보이는 것은 정상일 수 있습니다. 해당 주소를 대상 사이트의 장애로 바로 판단하지 마세요. 실제 연결 시에는 이 매핑을 관리하는 코어를 거쳐야 합니다. 앱이 매핑 주소를 받은 뒤 코어를 우회해 직접 연결하면 대개 실패합니다. 따라서 DNS 처리와 트래픽 라우팅을 함께 구성해야 하며, 시스템 DNS만 코어를 가리키게 하는 것으로 충분하지 않을 수 있습니다.

fake-ip-filter는 특정 도메인에 실제 조회 결과를 반환하도록 설정합니다. LAN 기기 이름이나 호환성 문제가 확인된 앱 도메인이 대표적인 대상입니다. 목록이 길수록 안정적인 것은 아닙니다. 제외 도메인이 많으면 사용할 수 있는 도메인 매핑 정보가 줄고 이후 규칙 매칭 경로도 달라질 수 있습니다. 먼저 문제가 확인된 대상을 찾고 최소 범위만 예외로 추가하세요. 처음부터 공용 도메인 공간 전체를 제외하지 마세요.

로컬 도메인 접미사를 예외로 설정해도 기기 검색 프로토콜 지원까지 해결되는 것은 아닙니다. 프린터, 화면 공유, 파일 공유는 멀티캐스트, 브로드캐스트 또는 운영체제 서비스에 의존할 수 있으므로 도메인 조회가 성공해도 기기를 검색하지 못할 수 있습니다. 문제를 해결할 때는 기기 IP 접근, 이름 조회, 서비스 포트 개방을 각각 확인한 뒤 라우팅 예외가 필요한지 판단하세요. 기기 하나를 고치려고 모든 사설망 트래픽을 강제로 프록시 처리하지 마세요.

기업 VPN과 함께 사용할 때는 기업 네트워크에 필요한 경로를 먼저 유지하세요. 두 소프트웨어가 모두 기본 경로를 제어하려 하면 트래픽이 터널 사이를 반복해서 이동하거나 내부 서비스에 접근하지 못할 수 있습니다. 활성화 전후의 라우팅 테이블을 기록하고 공용 인터넷, 내부 주소, 프록시 서버 주소를 각각 테스트한 다음 인터페이스 제외나 대역 예외를 설정할지 결정하세요. 구체적인 항목은 현재 코어 기능과 시스템 라우팅 구조에 맞춰 선택해야 합니다.

Fake-IP를 끄거나 설정을 바꾸면 앱에 이전 매핑 주소가 남아 있지만 새 코어에는 해당 기록이 없을 수 있습니다. 이때는 앱 연결을 종료하고 다시 조회하세요. 필요하면 캐시를 정리하되 모든 오류를 노드 연결 끊김으로 단정하지 마세요. 매핑 지속성을 켜면 일부 재시작 상황에서 일관성을 유지하는 데 도움이 되지만, 다른 DNS 서비스가 요청을 가로채거나 트래픽이 코어를 우회하는 문제까지 해결하지는 않습니다.

검증 순서는 고정하는 것이 좋습니다. 먼저 일반 프록시 연결을 확인하고, 다음으로 TUN을 켜 프록시를 사용하지 않던 앱을 테스트한 뒤, 마지막으로 Fake-IP를 전환해 도메인 매칭을 확인하세요. 각 단계에서 작동하는 설정을 보관하세요. TUN을 켜자마자 전체 네트워크가 끊기면 먼저 기능을 끄고 네트워크를 복구한 뒤 권한과 라우팅을 살펴보세요. 노드를 반복해서 바꾸는 것으로 가상 인터페이스 미생성 문제를 해결할 수는 없습니다.

도메인 스니핑

도메인 스니핑은 HTTP 요청의 Host나 TLS 핸드셰이크의 서버 이름처럼 연결 초기 단계에서 확인할 수 있는 프로토콜 정보로 도메인을 보완합니다. 대상 IP만 있을 때 도메인 규칙 매칭을 개선할 수 있지만 모든 연결의 도메인을 복원하거나 HTTPS 내용을 복호화하지는 않습니다. 앱의 프로토콜, 핸드셰이크 이름 숨김 여부, 트래픽이 코어에 들어왔는지에 따라 결과가 달라집니다.

활성화하기 전에 실제로 도메인 정보가 누락됐는지 확인하세요. Fake-IP 매핑에서 올바른 도메인 정보를 이미 제공한다면 스니핑으로 얻는 이점이 거의 없을 수 있습니다. 연결이 코어에 들어오지 않는다면 스니핑을 켜도 해결되지 않습니다. 연결 페이지에서 대상 IP와 포트는 보이지만 도메인이 비어 있어 사이트 접미사 규칙이 일치하지 않는 경우가 대표적인 점검 대상입니다.

필요한 프로토콜과 포트부터 제한적으로 설정

아래 설정은 일반적인 웹 포트에서 HTTP, TLS, QUIC 스니핑을 시도하며 기존 도메인 정보가 없는 연결도 처리하도록 합니다. TUN을 시작하거나 DNS 설정을 대체하지 않으며 모든 앱의 프록시 동작을 자동으로 바꾸지도 않습니다. 병합한 뒤에는 새 연결을 만들어야 합니다. 이미 핸드셰이크가 끝난 장시간 연결은 스니핑을 켜도 초기 프로토콜 정보를 다시 제공하지 않는 경우가 많습니다.

sniffer:
  enable: true
  parse-pure-ip: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ip는 원래 IP 정보만 있는 연결을 처리하도록 시도하는 설정이지 모든 바이너리 프로토콜을 식별한다는 뜻은 아닙니다. 포트 범위 역시 해당 포트에서 관련 프로토콜이 실행된다는 보장은 없이 식별을 시도할 대상을 정합니다. 모든 포트와 프로토콜을 추가해도 처리 범위만 넓어질 뿐, 핸드셰이크에 읽을 수 있는 도메인 정보가 없는 문제는 해결되지 않습니다.

override-destination은 스니핑으로 얻은 대상 정보로 기존 연결 대상을 덮어쓸지 결정합니다. 도메인을 알아낼 수 있는지와는 별개의 설정입니다. 실제 연결 주소가 중요한 앱에서는 대상을 덮어쓰면 서비스 선택이 달라지거나 앱 캐시와 일치하지 않을 수 있습니다. 예시에서 HTTP의 덮어쓰기를 명시적으로 끈 것은 먼저 도메인 식별 여부를 확인한 뒤 호환성에 따라 조정하기 위해서입니다.

식별된 정보와 원래 대상을 대조하세요

CDN, 여러 도메인이 공유하는 주소, 앱에 내장된 주소 목록 때문에 IP와 도메인이 일대일로 대응하지 않을 수 있습니다. 하나의 IP에서 여러 사이트를 서비스할 수 있으므로 역방향 조회나 주소 소유자만으로 현재 요청의 도메인을 단정하지 마세요. 스니핑으로 얻은 프로토콜 이름은 주소만 보고 추측하는 것보다 구체적이지만, 리디렉션이나 여러 백엔드 요청이 있는 경우에는 앱의 실제 동작도 함께 확인해야 합니다.

테스트할 때는 안정적으로 재현되는 요청 하나를 선택하고 관련 연결을 종료한 뒤 다시 접속해 연결 페이지에서 대상 도메인, 일치 규칙, 출구 체인을 확인하세요. 도메인은 표시되지만 규칙이 일치하지 않으면 규칙 순서와 매칭 유형을 확인하세요. 규칙은 올바른데 서비스가 실패한다면 출구, DNS 주소, 대상 덮어쓰기 동작을 추가로 점검하세요. 스니핑이 성공했다고 연결 전체가 정상인 것은 아닙니다.

연결 과정을 확인할 수 있을 정도로 로그 수준을 잠시 높이고 한 번 재현한 뒤 평소 수준으로 되돌리세요. 상세 로그에는 접속 도메인과 연결 정보가 포함될 수 있으므로 장기간 보관하거나 그대로 공개하지 않는 편이 좋습니다. 다른 사람에게 문제 해결 자료를 전달할 때는 구독 주소, 계정 정보, 컨트롤 인터페이스 인증 정보를 제거하고 관련 로그 몇 줄과 필요한 설정 구조만 남기세요.

QUIC은 UDP를 사용하므로 HTTP/3가 정상 작동하는지는 프록시 노드와 네트워크 경로의 UDP 지원 여부에도 달려 있습니다. 연결이 실패하면 프로토콜 전송 문제인지 도메인 식별 문제인지 먼저 구분하세요. QUIC 스니핑을 꺼도 앱이 TCP로 강제 전환되지는 않습니다. 앱 자체 구현에 따라 대체 연결 여부가 달라지므로 이 설정을 범용 프로토콜 변환 기능으로 간주하지 마세요.

일부 TLS 연결은 암호화된 핸드셰이크 이름 방식을 사용하거나 다른 터널을 통해 전송될 수 있습니다. 이 경우 관찰 가능한 정보가 줄어들어 스니핑으로 원래 도메인을 복원할 수 없습니다. 앱이 제어 가능한 DNS 경로를 사용하게 하거나 Fake-IP 매핑을 유지하는 편이 낫습니다. 범위를 충분히 이해한 경우 주소·프로세스 조건으로 규칙을 보완할 수도 있지만 스니핑 포트 목록을 무한정 늘리지는 마세요.

특정 앱의 호환성 문제에는 현재 코어가 지원하는 항목을 사용해 skip-domain 같은 예외를 설정할 수 있습니다. 먼저 해당 도메인을 제외하고 테스트하세요. 예외 조건은 실제로 식별된 대상과 일치해야 합니다. 로그에 IP만 표시되는데 한 번도 나타나지 않은 도메인을 지정하면 효과가 없을 수 있습니다. 스니핑을 끈 뒤 문제가 해결되면 규칙 전체를 삭제하지 말고 프로토콜 범위와 대상 덮어쓰기를 하나씩 비교하세요.

기업 내부 앱, 고정 IP 서비스, 기기 관리 페이지는 특히 주의해야 합니다. 실제 주소의 용도와 다른 호스트 이름을 보내거나 게이트웨이의 특정 매핑에 의존할 수 있습니다. LAN 직접 연결 규칙을 유지해 스니핑 결과가 내부 요청을 공용 인터넷 출구로 보내지 않도록 하세요. 연결, 규칙, 로그 화면의 역할은 클라이언트 UI 기능 살펴보기를 참고해 각각 확인할 수 있습니다.

로컬 오버라이드와 다중 구독 병합

구독 내용은 보통 원격에서 관리되지만 로컬 설정은 업데이트 후에도 유지되어야 합니다. 원격 구독에서 내려받은 YAML을 직접 수정하면 당장은 적용되더라도 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 로컬 오버라이드는 개인 설정과 주기적으로 업데이트되는 원격 내용을 분리하는 기능입니다. 편집 메뉴의 이름보다 어느 단계에서 실행되는지, 어떤 항목에 적용되는지, 최종 결과가 무엇인지 확인하는 것이 중요합니다.

Clash Verge Rev에서는 설정 페이지의 확장, 병합 또는 스크립트 기능을 통해 로컬 변경 사항을 관리하세요. 구체적인 메뉴 이름은 실제 UI를 기준으로 확인해야 합니다. 일부 설정은 클라이언트 전역 설정을 통해 실행 중인 코어 설정에 기록되므로 구독 파일의 값이 최종값이 아닐 수 있습니다. 원본 파일에 같은 항목을 반복해서 추가하기보다 먼저 클라이언트 설정을 확인하고 실행 설정과 로그를 살펴보세요.

객체 병합과 목록 대체를 따로 검증하세요

병합 방식에 따라 객체와 배열을 처리하는 방법이 다를 수 있습니다. 객체는 키 단위로 병합되지만 rules, proxy-groups 같은 목록은 전체가 대체되거나 앞 또는 뒤에 추가될 수 있습니다. DNS 항목 하나가 유지됐다고 해서 규칙 목록도 같은 방식으로 유지된다고 볼 수 없습니다. 식별하기 쉬운 로컬 규칙 하나로 실제 동작을 테스트한 다음 수정 범위를 넓히세요.

아래 예시는 ‘프록시 그룹 선택 저장’이라는 설정 의도를 나타내며 범용 병합 지시문은 아닙니다. 클라이언트가 인식하는 병합 기능에 넣은 뒤 실행 설정에 기존 구독의 필수 항목이 유지됐는지 확인하세요. 스크립트가 전체 profile 객체를 다시 만들면 나중에 실행된 결과가 앞선 설정을 덮어쓸 수 있습니다. 편집기에서 저장됐는지만 보지 말고 최종 출력을 확인하세요.

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

로컬 규칙을 추가할 때는 삽입 위치를 특히 주의해야 합니다. 특정 사이트를 위한 규칙은 앞쪽에 배치하세요. 이미 있는 MATCH 뒤에 추가하면 보통 실행되지 않습니다. 명확한 기본 규칙 하나면 충분하며 구독마다 하나씩 더 추가할 필요는 없습니다. 병합된 목록의 각 행은 용도를 설명할 수 있어야 합니다. 중복 규칙이 지나치게 많으면 문제 해결이 어려워집니다.

구독 두 개를 완전한 설정 두 개처럼 그대로 이어 붙이면 안 됩니다

완전한 설정에는 포트, DNS, 프록시 그룹, 규칙이 함께 들어 있는 경우가 많으므로 두 파일을 단순히 이어 붙일 수 없습니다. YAML 최상위 키가 중복되면 파서가 거부하거나 뒤쪽 값이 앞쪽 값을 덮어쓸 수 있으며, 결과는 도구마다 다릅니다. 노드만 결합하려면 구독을 프록시 제공자로 사용하는 편이 좋습니다. 프록시 그룹과 규칙은 로컬에서 통합 관리해 여러 원격 출처가 기본 설정을 놓고 충돌하지 않도록 하세요.

아래 예시는 구조를 먼저 확인할 수 있도록 로컬 프록시 제공자 두 개를 사용합니다. 두 파일은 사용자가 직접 준비해야 하며 각각 올바른 proxies 목록을 포함해야 합니다. 임의의 Base64 노드 문자열이 아닙니다. 이 예시에는 가상의 서버가 없으며 제공자 참조와 기본 직접 연결 구성원만 있습니다. 처음 테스트할 때는 각 파일이 개별적으로 작동하는지 확인한 뒤 통합 선택 그룹을 활성화하세요.

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 구독 모음
    type: select
    use:
      - source-a
      - source-b
    proxies:
      - DIRECT

프록시 제공자 파일에는 실제로 사용할 수 있는 노드 정의를 유지할 수 있지만, 제공자 형식과 무관한 전체 규칙이나 전역 설정은 제거해야 합니다. 원격 제공자로 전환한 뒤에는 실제 구독 주소, 캐시 경로, 업데이트 간격을 지정하세요. 형식이 호환되지 않으면 신뢰할 수 있는 로컬 처리 방법이나 서비스 제공업체의 호환 기능을 사용하세요. 차이점은 구독 가져오기 방법과 형식 안내를 참고하세요.

여러 출처를 사용할 때는 노드 이름 중복도 문제가 됩니다. 제공자 이름이 달라도 같은 프록시 그룹에 표시된 노드를 구분하기 어려울 수 있고, 이름으로 필터링하는 스크립트가 잘못된 항목을 선택할 수도 있습니다. 출처 접두어를 사용하거나 현재 코어가 지원하는 이름 처리 기능을 활용해 이름을 안정적으로 유지하세요. 지역 깃발, 임시 이벤트 이름, 트래픽 표시는 장기 참조의 유일한 기준으로 삼지 마세요.

필터 표현식에는 대체 경로도 마련해야 합니다. 지역 키워드로 필터링할 때 서비스 제공업체가 이름을 바꾸면 그룹이 갑자기 비어 있을 수 있습니다. 빈 그룹이 클라이언트에 명확히 표시되는지 확인하고 직접 선택할 수 있는 경로를 남겨 두세요. 정규식을 사용하기 전에 적은 수의 노드에서 매칭 결과를 확인하세요. 검증되지 않은 복잡한 표현식을 모든 프록시 그룹에 한꺼번에 적용한 뒤 빠진 구성원을 추측으로 찾지 마세요.

스크립트는 이름 통일이나 소량의 규칙 삽입처럼 명확하고 반복 가능한 변환에 적합하지만, 기록 없이 많은 설정을 바꾸는 용도로는 적합하지 않습니다. 실행 전에 입력을 보관하고 실행 후 출력을 확인하세요. 오류가 발생하면 원래 구독으로 확실히 되돌릴 수 있어야 합니다. 다른 사람이 만든 스크립트라면 외부 주소에 접속하는지, 로컬 정보를 읽는지, 제어 인터페이스를 변경하는지 검토하세요. 인터넷에 연결된다는 이유만으로 장기간 사용하기에 적절한 것은 아닙니다.

외부 컨트롤러

외부 제어 API는 코어 상태 조회, 연결 확인, 프록시 그룹 선택 변경에 사용하며, 컨트롤 패널은 이 API를 호출하는 프런트엔드입니다. 브라우저에서 사용하는 HTTP 프록시 포트와는 다른 접속 경로입니다. 혼합 포트는 프록시 트래픽을 처리하고 제어 포트는 관리 요청을 처리합니다. 패널에 혼합 포트 주소를 입력하면 대개 연결 오류가 발생할 뿐 클라이언트 프록시 화면이 열리지는 않습니다.

Clash Verge Rev에는 일반적인 프록시, 연결, 로그 화면이 있어 로컬에서 사용할 때는 보통 클라이언트만으로 충분합니다. 별도 패널, 원격 기기 관리, 자동화된 조회가 필요할 때 외부 제어를 설정하세요. 제어 기능은 현재 연결과 출구 선택에 영향을 줄 수 있으므로 포트를 LAN에 개방하기 전에 수신 범위와 접근 가능한 기기부터 고려해야 합니다.

로컬 사용은 루프백 수신부터 시작하세요

아래 예시는 루프백 주소에서만 수신하고 로컬에 둔 패널 정적 파일 디렉터리를 참조합니다. 디렉터리는 사용자가 준비해야 하며 경로는 실제 코어 작업 디렉터리를 기준으로 합니다. 예시의 비밀번호는 교육용 가짜 값입니다. 실제로 사용할 때는 직접 생성한 긴 임의 값으로 바꾸세요. 실제 비밀번호를 공개 설정 파일, 스크린샷, 공유 링크, 버전 관리 저장소에 기록하지 마세요.

external-controller: 127.0.0.1:9090
secret: "example-only-change-before-use"
external-ui: ./ui

제어 포트와 혼합 포트는 각각 점유 상태를 확인해야 합니다. 설정을 저장한 뒤 로그에 수신 실패가 표시되면 다른 클라이언트나 코어 프로세스가 해당 포트를 사용 중인지 확인하세요. 포트 충돌을 피하려고 수신 범위를 모든 인터페이스로 바로 바꾸지 마세요. 포트를 변경한 뒤에는 패널의 접속 설정도 함께 수정해야 합니다. 문제 해결 방법은 혼합 포트 점유 문제 해결을 참고하되 확인할 포트는 현재 제어 포트로 바꾸세요.

패널은 API 주소와 인증 정보가 필요하지만 코어와 같은 기기에서 실행될 필요는 없습니다. 패널 페이지의 127.0.0.1은 브라우저가 실행되는 기기를 가리킵니다. 휴대폰 브라우저에서 패널을 열면 데스크톱 컴퓨터의 루프백 주소가 아닙니다. 원격 접속 실패의 흔한 원인이므로 데스크톱 설정에서 ‘LAN 연결 허용’을 켜는 것만으로 해결되지는 않습니다.

기기 간 연결은 주소만 바꾸지 말고 경계와 접근 권한을 확인하세요

기기 간 관리가 꼭 필요하다면 신뢰할 수 있는 네트워크, 명확한 방화벽 규칙, 인증된 접근 경로를 사용하세요. 수신 주소를 0.0.0.0으로 바꾸면 여러 인터페이스에서 연결을 받는다는 뜻일 뿐, 자동으로 보안 경계가 만들어지는 것은 아닙니다. 기기가 공용 네트워크, 가상 네트워크, 게스트 Wi-Fi에 동시에 연결되어 있다면 예상보다 넓은 범위에 노출될 수 있으므로 설정 전에 각각 확인하세요.

브라우저로 API에 접속할 때는 동일 출처 정책, CORS 설정, 혼합 콘텐츠 제한이 영향을 줄 수 있습니다. HTTPS 패널에서 일반 HTTP API를 요청하면 브라우저가 차단할 수 있지만, 이것이 코어가 실행되지 않는다는 뜻은 아닙니다. 먼저 로컬에서 API 응답 여부를 확인하고 개발자 도구에서 구체적인 오류를 살펴보세요. 주소나 프로토콜 설정 문제를 숨기려고 모든 출처를 허용하는 광범위한 CORS 설정을 사용하지 마세요.

로컬 패널 리소스는 검토할 수 있고 API와 호환되는 프로젝트에서 가져와 해당 프로젝트의 안내에 따라 배포하세요. 디렉터리가 있다는 사실만으로 리소스가 완전한 것은 아니며, 페이지가 열린다고 API 인증까지 성공한 것도 아닙니다. 문제를 해결할 때는 ‘정적 페이지 로드’, ‘API 연결’, ‘인증 성공’, ‘작업 성공’을 네 단계로 나눠 각각 결과를 확인하세요. 빈 화면 문제와 인증 실패를 혼동하지 마세요.

자동화된 조회도 최소 노출 원칙을 따라야 합니다. 스크립트가 로컬에서만 작동하면 편의를 위해 제어 API를 인터넷에 공개할 필요가 없습니다. 인증 정보는 실행 환경에서 안전하게 제공하고 웹페이지 스크립트에 하드코딩하지 마세요. 브라우저에서 내려받을 수 있는 JavaScript는 방문자가 모두 읽을 수 있으므로 코드 난독화나 파일명 변경으로 비밀번호를 숨길 수 없습니다. 문제 해결 자료에서는 요청 헤더와 연결 설정도 정리하세요.

변경 후에는 정해진 순서로 확인하세요

첫째, 실행 설정에 예상한 수신 주소가 포함되어 있는지 확인하고 로그에서 포트 점유나 설정 파싱 오류가 보고되는지 살펴보세요. 둘째, 같은 기기에서 API 접속과 인증 결과를 확인하세요. 셋째, 패널을 불러와 현재 사용 중인 코어에 연결되는지, 백그라운드에 남은 다른 프로세스에 연결되는지 확인하세요. 마지막으로 쉽게 되돌릴 수 있는 프록시 그룹 선택을 하나 바꾸고 클라이언트 UI에 반영되는지 살펴보세요.

API에 접속되지만 패널의 프록시 그룹이 비어 있다면 현재 설정에서 프록시 그룹이 실제로 로드됐는지 먼저 확인한 뒤 패널과 API의 호환성을 살펴보세요. 상태는 확인할 수 있지만 선택을 바꿀 수 없다면 해당 그룹이 수동 선택을 지원하는지, 인증과 요청에 오류가 있는지 확인하세요. 이런 단계별 점검을 클라이언트 재설치로 대신하지 마세요. 재설치해도 잘못된 대상 주소나 중복된 백그라운드 프로세스는 자동으로 해결되지 않습니다.

마무리할 때는 평소 로그 수준으로 되돌리고 임시로 열어 둔 수신을 닫으세요. 더 이상 필요하지 않은 로컬 패널 디렉터리나 자동화 작업을 삭제하고 사용할 수 있는 설정 백업을 보관하세요. 백업에는 공개해도 되는 설정 구조와 개인 구독 정보를 구분해 두고 공유할 때는 필요한 부분만 제공하세요. 이후 클라이언트나 코어를 업데이트하면 같은 순서로 주요 기능을 다시 확인해야 문제가 설정, 패널, 실행 환경 중 어디에서 비롯됐는지 판단할 수 있습니다.