Clash 설정 심화 가이드: 프록시 그룹, DNS, TUN

모드와 설정 기준선

고급 설정을 시작하기 전에 작동이 확인된 연결 경로가 필요합니다. 현재 접속 가능한 구독, 직접 선택한 노드 하나, 시스템 프록시 설정을 유지하고 클라이언트 이름, 코어 종류, 혼합 포트, 현재 Profile을 기록하세요. 구독 교체, TUN 활성화, DNS 변경을 한꺼번에 하지 마세요. 여러 항목을 동시에 바꾸면 웹페이지가 열리는지만으로는 어떤 계층에서 동작이 달라졌는지 파악할 수 없습니다.

설정 원본과 실행 결과 구분하기

클라이언트는 보통 구독 파일, 로컬 설정, 오버라이드를 조합해 코어에 전달합니다. 구독 편집기에 포트가 하나 적혀 있다고 해서 코어가 같은 포트에서 실제로 수신하는 것은 아닙니다. 클라이언트에서 제공하는 실행 설정, 코어 설정 미리보기 또는 시작 로그를 확인해 실제값을 파악하세요. 파일을 저장했는데 동작이 바뀌지 않았다면 같은 필드를 반복해서 추가하기보다 현재 활성화된 Profile을 편집했는지, 다시 불러와야 하는지 먼저 확인하세요.

설정에서 이름을 참조하는 부분도 실행 의존 관계에 포함됩니다. 규칙 끝에 지정한 정책 이름은 노드나 프록시 그룹에 있어야 하고, 프록시 그룹에서 참조하는 provider도 정의되어 있어야 합니다. YAML 구문 분석에 성공했다는 것은 문법이 유효하다는 뜻일 뿐, 참조 대상이 존재한다는 의미는 아닙니다. 공백으로 들여쓰고 탭은 피하세요. 이름에 쉼표, 콜론 또는 특수 문자가 있으면 따옴표로 감싸고, 이름을 바꾼 뒤에는 모든 참조 위치를 확인하세요.

규칙·전역·직접 연결 모드의 용도

mode: rule은 규칙 목록을 위에서부터 확인해 아웃바운드를 결정합니다. 전역 모드는 프록시 연결이 필요한 트래픽을 보통 전역 정책으로 보냅니다. 직접 연결 모드는 프록시를 거치지 않고 아웃바운드로 연결할 때 사용합니다. 모드를 바꿔도 노드, 이름 해석, 라우팅 문제가 저절로 해결되지는 않으며 모든 앱의 트래픽이 처리되는 것도 아닙니다. 시스템 프록시를 사용하지 않는 프로그램의 트래픽이 코어로 들어오는지는 앱 설정, TUN 또는 게이트웨이 포워딩에 따라 달라집니다.

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

이 기준 설정은 혼합 프록시 포트를 7890으로 지정하고 LAN 접근은 차단하며 정보 수준 로그를 유지합니다. 혼합 포트는 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있지만 앱에서 올바른 프록시 프로토콜을 사용해야 합니다. 포트가 이미 사용 중이면 다른 수신 프로세스를 중지하거나 클라이언트와 앱 설정을 함께 변경하세요. 앱의 숫자만 바꾸면 실제로 수신 대기 중인 곳이 없는 포트로 연결될 수 있습니다.

모드	확인하기 좋은 항목	이것만으로 판단할 수 없는 항목
규칙	도메인·주소 및 규칙 순서	모든 앱의 트래픽이 처리되는지
전역	현재 프록시 경로가 작동하는지	규칙 내용이 올바른지
직접 연결	로컬 네트워크 및 직접 접속 경로	DNS가 반드시 코어를 우회하는지

반복 가능한 검증 절차 만들기

매번 설정 하나만 바꾸고 같은 앱에서 새 연결을 요청하세요. 기존 장기 연결은 이전 정책을 계속 사용할 수 있으므로 해당 연결을 끊거나 테스트 앱을 다시 시작해야 합니다. 먼저 연결 패널에서 요청이 코어로 들어왔는지 확인한 다음 적용된 규칙과 실제 아웃바운드를 살펴보세요. 연결 기록이 없다면 트래픽 처리 계층을 확인하고, 기록은 있지만 정책이 잘못 선택됐다면 규칙과 프록시 그룹을 점검하세요.

전역 모드에서는 연결되지만 규칙 모드에서 실패한다면 두 모드가 서로 다른 아웃바운드를 선택했거나, 규칙 모드가 대상에 맞지 않는 직접 연결 경로를 사용했을 가능성이 큽니다. 실제 아웃바운드 이름을 비교한 뒤 판단하세요. 특정 사이트에 직접 연결할 수 있다고 해서 구독 전체에 문제가 없다는 뜻은 아닙니다. 대상 주소, DNS 응답, 서버 동작이 서로 다를 수 있습니다. 같은 대상을 비교한 결과를 남겨야 일부 사례를 전체 장애로 오해하지 않습니다.

클라이언트 인터페이스와 코어 동작을 구분하려면 용어 설명에서 설정 구조와 네트워크 트래픽 처리 개념을 먼저 살펴보세요. 클라이언트를 바꿀 때는 다운로드 센터에서 Clash Plus를 우선 확인하고, 플랫폼과 필요한 코어 기능에 따라 다른 클라이언트와 비교하세요. 인터페이스에 따라 스위치 위치는 달라질 수 있지만, 이 페이지의 검증 순서는 같습니다. 설정 로드, 요청 유입, 규칙 일치, 아웃바운드 연결 순으로 확인하세요.

프록시 그룹 유형과 활용

프록시 그룹을 사용하면 규칙과 개별 노드를 분리할 수 있습니다. 규칙은 ‘업무용 출구’ 같은 그룹을 계속 참조하고, 그룹 안의 노드는 구독 업데이트에 따라 교체할 수 있습니다. 설계 전에 원하는 선택 방식을 정하세요. 직접 선택할지, 특정 회선을 우선 사용할지, 응답이 빠른 후보를 자동으로 고를지, 개별 연결을 여러 출구로 분산할지 결정해야 합니다. 모든 그룹 유형을 한 설정에 쌓아 두지 마세요. 계층이 많아질수록 문제 해결 시 확인해야 할 참조 관계도 길어집니다.

수동 선택과 자동 선택

select는 아웃바운드를 직접 지정할 때 적합하며 선택 결과를 이해하기 쉽습니다. url-test는 탐지 결과를 바탕으로 후보를 자동 선택합니다. fallback은 목록 순서대로 사용 가능한 항목을 선택하므로 주 회선과 보조 회선 구성에 적합합니다. load-balance는 정책에 따라 연결을 분산하며 단일 다운로드 연결의 대역폭을 합산하지는 않습니다. 로그인, 결제, 세션 서비스처럼 출구가 안정적이어야 하는 경우에는 자동 전환을 자주 하지 않는 편이 좋습니다.

아래 예제는 현재 설정에 ‘회선 A’와 ‘회선 B’라는 노드가 이미 정의되어 있다고 가정합니다. 실제로 사용할 때는 구독에 표시된 정확한 이름으로 바꾸세요. 최상위 수동 그룹에서는 자동 그룹이나 노드를 직접 선택할 수 있습니다. 규칙이 최상위 그룹만 참조하게 하면 후보 목록을 바꿀 때 규칙을 하나씩 수정하지 않아도 됩니다.

proxy-groups:
  - name: 자동 출구
    type: url-test
    proxies:
      - 회선 A
      - 회선 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 업무용 출구
    type: select
    proxies:
      - 자동 출구
      - 회선 A
      - 회선 B

rules:
  - DOMAIN-SUFFIX,example.com,업무용 출구
  - MATCH,업무용 출구

탐지 매개변수 이해하기

interval은 초 단위 탐지 간격이고, tolerance는 전환 허용 오차로 후보 간 결과가 조금 달라질 때 잦은 전환을 막습니다. 탐지 URL은 후보 회선을 통해 안정적으로 접속할 수 있어야 합니다. 탐지값은 해당 회선에서 지정한 테스트 서비스로 요청을 보낸 결과를 나타낼 뿐, 모든 사이트의 속도나 동영상 전송량, 패킷 손실률, 특정 플랫폼의 이용 가능성을 보여주지는 않습니다.

여러 그룹이 같은 후보를 공유하면서 간격까지 짧으면 상태 확인 요청이 늘어납니다. 우선 적당한 간격으로 설정하고 회선 변화 빈도에 따라 조정하세요. 지연 탐지와 관련된 지연 실행 동작을 사용하면 사용되지 않는 그룹은 새 결과가 바로 나오지 않을 수 있습니다. 패널에 표시된 오래된 값은 마지막 탐지 시각과 함께 해석해야 하며, 계속 갱신되는 실시간 모니터링 값으로 보면 안 됩니다.

중첩 그룹·구독 참조·용도별 분리

노드를 proxy-providers에서 제공하는 경우 노드 이름을 모두 복사하는 대신 그룹의 use로 provider를 참조할 수 있습니다. 구독에 노드가 추가되거나 삭제되면 로드 결과에 따라 후보 목록도 바뀝니다. 이름 필터는 후보를 추리는 데 유용하지만, 지역 표시는 대개 제공자가 붙인 이름일 뿐 실제 출구 지역을 뜻하지는 않습니다. 필터 표현식이 잘못되면 그룹이 비어 있을 수 있으니 펼쳐진 후보 목록을 확인하세요.

안정적인 구성은 보통 수동 선택이 가능한 전체 출구 하나와 용도별 그룹 몇 개로 이뤄집니다. 업무 규칙은 용도별 그룹을 참조하고, 해당 그룹은 자동 그룹이나 고정 노드를 참조하도록 구성하세요. A 그룹이 B 그룹을 참조하고 B 그룹이 다시 A 그룹을 참조하는 순환 구조는 피해야 합니다. 설정 로드에 실패할 수 있습니다. 자동 그룹 안에 자기 자신으로 되돌아오는 선택 경로를 두지 마세요. 인터페이스에 이름이 표시되더라도 최종 아웃바운드를 확인하지 못할 수 있습니다.

자동 그룹이 자주 바뀐다면 후보의 안정성과 테스트 서비스의 제한 여부부터 확인한 다음 허용 오차를 늘리거나 주·보조 그룹으로 바꾸세요. 특정 서비스만 문제가 있다면 테스트 중 출구가 계속 바뀌지 않도록 같은 노드를 고정해 재검사하세요. 그룹 선택이 바뀌어도 기존 연결은 이전 아웃바운드를 계속 사용할 수 있습니다. 정책 그룹 버튼에 새 이름이 표시되는지만 보지 말고 새 연결을 확인하세요.

노드 품질은 트래픽 배율, 지역, 프로토콜에도 영향을 받으므로 탐지값 하나만으로 순위를 매기면 안 됩니다. 노드 선택과 지연 시간 판단 방법을 참고해 후보 목록을 구성하세요. 심화 설정의 목표는 모든 업무를 같은 자동 경로로 보내는 것이 아닙니다. 각 규칙의 선택 이유를 분명히 하고 장애가 발생하면 수동으로 바꿀 수 있는 출구를 마련하는 것입니다.

규칙 집합으로 규칙 관리하기

규칙 목록은 일치 순서를 결정하고, 규칙 집합은 일련의 조건을 관리합니다. 자주 바뀌는 도메인이나 주소를 rule-providers로 분리하면 기본 설정을 간결하게 유지할 수 있지만, 규칙 집합이 별도의 우선순위 체계를 만드는 것은 아닙니다. 코어는 계속 rules를 위에서 아래로 확인하며 처음 일치한 규칙이 아웃바운드를 결정합니다. 범위가 지나치게 넓은 집합을 앞에 두면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다.

먼저 규칙 유형을 정한 다음 파일 형식을 선택하세요

behavior: domain은 도메인 집합에, ipcidr은 주소 대역에, classical은 여러 종류의 완전한 규칙 조건에 사용합니다. 동작 유형과 파일 형식은 별개의 기준입니다. format은 파일 인코딩 방식을 나타내고, 동작 유형은 내용을 어떻게 해석할지 정합니다. 파일 확장자가 모두 YAML이라고 해서 DOMAIN-SUFFIX 전체 항목을 도메인만 받는 집합에 넣을 수 있는 것은 아닙니다.

아래는 구조를 먼저 확인하기 쉽도록 로컬 classical 규칙 집합을 사용합니다. 두 번째 블록을 코어 작업 디렉터리의 rules/work.yaml에 저장하고 첫 번째 블록은 현재 설정에 병합하세요. 예제는 ‘업무용 출구’ 프록시 그룹이 이미 있다고 가정합니다. 파일 기반 provider를 수정한 뒤에는 보통 다시 불러와야 합니다. 클라이언트가 파일을 다른 작업 디렉터리에 복사한다면 실제로 읽는 경로를 확인하세요.

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

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

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.org

예외·일반 규칙·최종 규칙 배치

다른 조건보다 먼저 적용해야 하는 예외를 소수만 앞에 둔 뒤 업무용 도메인 집합과 필요한 주소 규칙을 배치하고, 마지막에 MATCH를 두는 방법을 권장합니다. 여기서 GEOIP,CN,DIRECT는 흔히 볼 수 있는 구성의 예일 뿐, 모든 대상에 지역 기반 직접 연결이 적합하다는 뜻은 아닙니다. 주소 위치 데이터, 여러 지역에 걸친 서비스, 공유 인프라가 결과에 영향을 주므로 실제 업무에 맞게 조정하세요.

도메인 규칙은 일치를 위해 주소를 바로 조회할 필요가 없는 경우가 많지만, 주소 규칙은 DNS 조회를 유발할 수 있습니다. 이 매개변수를 지원하는 주소 규칙에 no-resolve를 추가하면 일치만을 위한 조회를 막을 수 있습니다. 다만 도메인만 있고 대상 주소가 없는 요청은 해당 규칙과 일치하지 않을 수도 있습니다. 보편적인 성능 옵션이 아니라 규칙 정확성과 DNS 동작 사이의 선택입니다.

동작 유형	주요 대상	주요 확인 사항
`domain`	도메인 및 도메인 일치 방식	도메인 집합 문법에 맞는지
`ipcidr`	IPv4·IPv6 네트워크 대역	마스크와 주소 계열이 올바른지
`classical`	완전한 규칙 조건	아웃바운드 정책 이름이 잘못 포함됐는지

원격 업데이트도 설정 의존 관계로 보기

HTTP 유형을 선택하면 실제로 접근할 수 있는 규칙 URL, 캐시 경로, 업데이트 간격을 지정해야 합니다. 업데이트 간격은 초 단위이므로 클라이언트 구독 화면의 분이나 시간 단위를 그대로 입력하면 안 됩니다. provider마다 고유한 캐시 경로를 지정해 파일을 공유하지 않도록 하세요. 첫 실행 때 캐시가 없으면 규칙을 다운로드하는 연결 경로가 먼저 작동해야 합니다. 그렇지 않으면 아직 설정되지 않은 의존 항목이 자기 자신을 기다리는 순환이 생길 수 있습니다.

원격 업데이트 실패와 규칙 일치 실패는 나눠서 점검하세요. 먼저 provider가 로드됐는지, 항목이 있는지 확인한 뒤 요청이 집합과 일치하는지 살펴보세요. 기존 캐시가 있으면 계속 실행될 수 있지만, 업데이트에 성공했다는 뜻은 아닙니다. 반대로 다운로드가 완료되어도 내용이 지정된 동작 유형에 맞는다는 보장은 없습니다. 로그의 파싱 오류, 빈 집합, 다운로드 오류는 각각 별도로 처리하고 모두 노드 문제로 돌리지 마세요.

규칙 집합을 관리할 때는 출처, 용도, 복구 파일을 기록하고 마지막으로 정상 로드된 내용을 보관하세요. 집합을 새로 추가한 뒤에는 포함되어야 할 도메인 하나와 포함되면 안 되는 도메인 하나로 양방향 테스트를 하고, 다른 업무에 영향이 있는지도 살펴보세요. 결과가 예상과 다르면 관련 규칙을 잠시 앞쪽으로 옮겨 우선순위 영향을 확인한 뒤, 원인을 파악하면 의도한 순서로 되돌리세요. 예외를 계속 덧붙이는 방식에 의존하지 마세요.

DNS 경로 최적화

DNS 설정에서는 먼저 요청 경로를 설계하고 그다음 서버를 선택해야 합니다. 앱이 어디에 질의하는지, 코어가 어디에 질의하는지, 코어가 프록시 서버의 도메인을 어떻게 조회하는지 구분하세요. 브라우저가 별도의 암호화 DNS를 사용하거나 운영체제가 이전 응답을 캐시할 수 있고, 라우터가 질의를 전달할 수도 있습니다. nameserver만 바꿔도 모든 앱의 요청이 코어를 거치거나 프록시 노드의 도메인이 같은 경로로 조회되는 것은 아닙니다.

초기 DNS 조회와 일반 DNS 조회 구분하기

default-nameserver는 주로 DNS 상위 서버의 도메인을 조회하기 위한 초기 서버입니다. 현재 네트워크에서 직접 접근할 수 있는 주소를 선택하세요. nameserver는 일반적인 서비스 조회를 처리하고 proxy-server-nameserver는 프록시 노드 도메인 조회에 사용됩니다. 이 용도를 섞으면 ‘프록시 주소를 조회하려면 먼저 프록시에 연결해야 하는’ 의존성 순환이 생겨 시작 후 오랫동안 아웃바운드를 설정하지 못할 수 있습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  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
  fake-ip-filter:
    - "*.lan"
    - "*.local"

이 예제는 현재 네트워크에서 나열된 DNS 서버에 접근할 수 있다고 가정합니다. 시스템 DNS를 자동으로 1053 포트로 변경하거나 TUN 가로채기를 활성화하지는 않습니다. 대부분의 시스템 DNS 설정에는 사용자 지정 포트를 입력할 수 없으므로 수신 상태와 트래픽 처리를 따로 확인해야 합니다. 포트를 지정할 수 있는 조회 도구로 코어를 테스트한 뒤 시스템 요청이 실제로 코어로 리디렉션되는지 확인하세요.

도메인별 DNS 상위 서버 선택

nameserver-policy를 사용하면 특정 도메인에 지정한 상위 서버를 사용할 수 있습니다. 내부 도메인, 전용 DNS 환경 또는 실제로 조회 결과가 달라야 하는 업무에 적합합니다. 이 설정은 DNS 리졸버를 선택할 뿐 최종 연결의 아웃바운드를 결정하지는 않습니다. ‘특정 도메인이 특정 DNS를 사용한다’는 것과 ‘특정 도메인이 반드시 프록시를 거친다’는 것은 다릅니다. 연결은 여전히 규칙 일치 과정을 거치며 DNS 요청 자체의 라우팅 설정도 영향을 줄 수 있습니다.

respect-rules로 DNS 요청이 규칙을 따르게 할 때는 프록시 서버 도메인의 조회와 초기 연결 경로를 특히 주의해서 확인하세요. DNS 요청도 규칙에 들어오면 잘못된 최종 정책 때문에 아직 연결되지 않은 프록시에 질의가 의존할 수 있습니다. 먼저 직접 처리할 수 있어야 하는 질의를 정한 뒤 정책을 추가하세요. 암호화 DNS 주소가 보인다는 사실만으로 전송 경로가 예상대로라고 단정할 수는 없습니다.

캐시·IPv6·결과 비교

DNS를 바꾼 뒤에는 앱, 운영체제, 코어의 캐시를 각각 고려해야 합니다. 웹페이지를 다시 여는 것만으로는 기존 연결을 재사용할 수 있으므로 새 DNS 조회의 근거가 되지 않습니다. 관련 연결을 닫고 필요한 계층의 캐시를 정리한 다음 조회와 연결 로그를 확인하세요. 처음부터 모든 상태를 지우지 말고 변경 전 결과를 남겨 응답 주소, 응답 유형, 실제 아웃바운드를 비교해야 문제가 어느 계층에서 발생했는지 파악할 수 있습니다.

최상위 ipv6와 DNS 설정 아래의 ipv6는 적용 범위가 다릅니다. 전자는 코어의 IPv6 사용과 관련되고 후자는 DNS 응답에 포함되는 IPv6 결과에 영향을 줍니다. 네트워크에 사용 가능한 IPv6 경로가 없는데 앱이 우선 사용할 IPv6 주소를 받으면 연결을 기다리다가 다른 주소로 전환될 수 있습니다. 반대로 IPv6를 무조건 끄는 것도 모든 네트워크에 적합한 해결책은 아니므로 기기의 라우팅과 서비스 요구사항을 먼저 확인하세요.

DNS 조회는 정상인데 연결에 실패한다고 DNS 서버를 계속 바꿔서는 안 됩니다. 선택한 아웃바운드로 대상 주소에 접속할 수 있는지, 규칙이 잘못 분류했는지, 인증서와 시스템 시간이 올바른지 확인하세요. DNS 조회는 실패했지만 노드에는 연결할 수 있다면 조회 경로와 상위 서버의 접근 가능성을 중점적으로 살펴보세요. ‘주소를 조회함’과 ‘앱 요청이 완료됨’을 별도 확인 항목으로 두면 DNS를 무작정 바꿔 보는 일을 줄일 수 있습니다.

TUN과 Fake-IP 함께 사용하기

TUN은 트래픽을 코어로 전달하는 방식이고 Fake-IP는 DNS에서 도메인 연결 정보를 유지하는 방식입니다. 함께 사용하는 경우가 많지만 같은 기능은 아닙니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅과 함께 패킷을 전달합니다. Fake-IP는 앱에 예약 주소를 반환한 뒤 코어가 해당 주소를 원래 도메인과 연결합니다. Fake-IP만 켜서는 앱 트래픽이 자동으로 처리되지 않고, TUN만 켜서도 코어가 각 연결의 도메인을 반드시 파악하는 것은 아닙니다.

최소 범위부터 트래픽 처리 시작하기

데스크톱 클라이언트에서 TUN을 활성화하려면 서비스 모드, 관리자 권한 또는 시스템 네트워크 확장 권한이 필요할 수 있으며 플랫폼마다 방식이 다릅니다. 기존 DNS와 규칙 설정은 유지한 상태에서 클라이언트가 인터페이스를 생성했는지 확인한 뒤 자동 라우팅을 켜세요. 다른 VPN, 가상 머신 네트워크, 보안 소프트웨어도 라우팅이나 필터를 설치할 수 있습니다. 동시에 사용할 때는 기본 경로가 어떻게 바뀌는지 기록해 설정 문법 문제와 충돌을 구분하세요.

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

이 예제는 일반 UDP와 TCP의 DNS 포트를 가로채며 모든 암호화 DNS를 투명하게 처리하지는 않습니다. 브라우저가 별도로 보내는 HTTPS DNS 요청은 일반 HTTPS 연결처럼 보이므로 포트 가로채기만으로 질의 내용을 복원할 수 없습니다. 먼저 테스트 앱이 시스템 DNS 경로를 사용하도록 하고 도메인이 올바르게 매핑되는지 확인한 다음 앱 자체의 암호화 DNS 설정을 유지할지 결정하세요.

네트워크 스택과 인터페이스 정책 선택

system, gvisor, mixed는 서로 다른 네트워크 스택 처리 방식을 나타내며 지원 여부는 플랫폼과 코어 빌드에 따라 달라집니다. 특정 스택이 항상 최선이라고 가정하지 마세요. 특정 프로토콜과 호환되지 않으면 다른 설정은 그대로 둔 채 하나씩 비교하고, 로그에 해당 옵션이 지원되지 않는다고 명확히 표시되는지 확인하세요. 설정을 저장할 수 있다고 해서 코어가 그 값을 실제로 사용한다는 뜻은 아닙니다.

출구 인터페이스 자동 감지는 단일 출구를 사용하는 일반적인 기기에 적합하지만, 여러 네트워크 어댑터, 핫스팟 공유, 컨테이너, 라우터 환경에서는 인터페이스와 라우팅을 명시적으로 설계해야 할 수 있습니다. 시스템 업데이트, 재연결, 장치 변경으로 인터페이스 이름이 달라질 수 있습니다. 트래픽이 가상 인터페이스로 계속 되돌아오거나 연결 수가 비정상적으로 늘고 전체 네트워크가 끊기면 대상 사이트를 계속 재시도하지 말고 먼저 TUN을 꺼 네트워크를 복구한 뒤 라우팅 루프를 확인하세요.

Fake-IP 매핑과 예외 관리

앱이 Fake-IP를 받은 뒤에는 연결이 같은 매핑을 저장한 코어를 다시 거쳐야 합니다. 기기 A가 DNS 응답을 반환하고 기기 B가 연결을 처리하면 B는 해당 예약 주소가 어느 도메인에 대응하는지 모를 수 있습니다. LAN에서 프록시를 공유할 때는 DNS 요청과 연결을 어느 장치가 처리하는지 명확히 하세요. Fake-IP 결과를 해당 프록시를 거치지 않는 기기나 다른 네트워크 경로에 그대로 노출해서는 안 됩니다.

fake-ip-filter는 지정한 도메인에 Fake-IP를 할당하지 않도록 합니다. 다만 필터링 후에도 실제 주소를 조회할 수 있는 상위 DNS 서버가 필요합니다. 실제 주소가 필요한 앱은 오류가 확인된 도메인부터 예외에 추가하고, 범위가 넓은 공용 접미사를 한꺼번에 제외하지 마세요. 필터 범위가 너무 넓으면 코어가 매핑으로 도메인을 파악할 기회가 줄고, 일부 판단이 주소 규칙이나 스니핑에 맡겨집니다.

앱에 오래된 Fake-IP가 캐시된 상태에서 코어를 다시 시작해 매핑이 사라지면 새 연결에서 도메인을 복원하지 못할 수 있습니다. 저장 동작을 이해한 뒤 profile.store-fake-ip를 사용해 매핑을 유지하고 클라이언트가 관련 데이터 디렉터리도 보존하는지 확인하세요. 문제를 해결할 때는 필터 목록을 무작정 늘리기보다 앱 캐시를 지우고 다시 조회하는 편이 효과적일 수 있습니다. 해당 코어를 사용하지 않는 네트워크로 전환한 뒤에는 이 예약 주소를 계속 사용하지 않도록 주의하세요.

검증에는 일반 웹페이지, 시스템 프록시를 따르지 않는 앱 하나, LAN 서비스 접속이 포함되어야 합니다. 각각 코어에 들어오는지, 도메인이 표시되는지, 예상한 규칙과 일치하는지 확인하세요. 시스템 프록시는 정상인데 TUN만 문제가 있다면 라우팅, 권한, DNS 가로채기, 네트워크 스택으로 범위를 좁히세요. 두 방식의 차이는 TUN 모드와 시스템 프록시의 작동 원리 비교에서 더 알아볼 수 있습니다. 트래픽 처리 범위를 넓히려고 모든 기능을 동시에 켤 필요는 없습니다.

도메인 스니핑과 적용 범위

연결에 대상 IP만 있고 신뢰할 수 있는 도메인 정보가 없으면 도메인 규칙이 예상대로 적용되지 않을 수 있습니다. 도메인 스니핑은 일부 프로토콜 핸드셰이크나 요청 정보에서 호스트명을 추출해 규칙 판단에 필요한 단서를 보완합니다. HTTPS 내용을 복호화하는 기능이 아니며 모든 연결을 식별하지도 못합니다. 먼저 DNS 트래픽 처리와 Fake-IP 매핑을 정상화한 다음 경계 사례에 스니핑을 적용하는 편이 전적으로 스니핑에 의존하는 것보다 관리하기 쉽습니다.

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

HTTP는 요청의 호스트 정보를 통해 도메인을 추출할 수 있고 TLS는 보이는 핸드셰이크 정보에서 서버 이름을 확인할 수 있는 경우가 많습니다. QUIC은 코어 지원 여부와 실제 트래픽에 따라 다릅니다. 앱이 사용자 지정 프로토콜을 쓰거나 IP에 직접 접속하고, 기존 연결을 재사용하거나 관련 핸드셰이크 정보를 숨기면 스니핑으로 도메인을 알아내지 못할 수 있습니다. 결과가 비어 있다고 코어가 작동하지 않는 것은 아닙니다. 먼저 해당 트래픽에 식별할 수 있는 정보가 있는지 확인하세요.

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

이 예제는 범위를 일반적인 서비스 포트로 제한하고 원래 대상 주소를 유지합니다. parse-pure-ip를 켜면 IP만 있는 연결도 식별을 시도하고, force-dns-mapping은 DNS 매핑 환경의 스니핑 동작과 관련됩니다. 이름이 비슷한 매개변수라도 정상적인 DNS 흐름을 대신하지는 않습니다. 코어가 필드를 지원하지 않는다고 표시하면 클라이언트 이름만 보지 말고 실제 코어를 확인하세요.

도메인 정보 보완과 연결 대상 변경 구분하기

override-destination은 스니핑 결과를 연결 대상에 반영할지 결정합니다. 일부 도메인 기반 재연결이 필요한 경우 대상 변경이 도움이 될 수 있지만, 앱이 선택한 주소를 무효화할 수도 있습니다. 전용 IP, 내부 서비스, CDN 라우팅, 인증서 바인딩에 의존하는 업무라면 우선 꺼 둔 채 도메인 보완과 규칙 결과만 확인하고 필요할 때 활성화하세요.

하나의 IP에서 여러 도메인을 제공할 수 있고 하나의 도메인이 여러 주소를 반환할 수도 있습니다. 스니핑한 도메인을 다시 조회하면 앱이 처음 사용한 주소와 다른 결과가 나올 수 있습니다. 따라서 ‘도메인을 정확히 식별함’과 ‘최종적으로 올바른 서비스에 연결됨’은 별도로 검증해야 합니다. 오버라이드를 켠 뒤 특정 앱만 실패한다면 오버라이드를 끄고 비교한 다음 해당 도메인에 스니핑 제외 정책을 설정하세요.

예외와 개인정보 보호 범위 관리

스니핑에 적합하지 않은 도메인은 코어가 지원하는 경우 skip-domain 등의 제외 설정에 추가할 수 있습니다. 호환성 문제가 확인된 경우에만 예외를 추가하고 이유를 기록하세요. 출처가 불분명한 대규모 제외 목록을 그대로 복사하는 것은 권장하지 않습니다. 제외 범위가 너무 넓으면 스니핑이 사실상 작동하지 않는데도 문제 해결 과정에서 기능이 계속 전부 적용된다고 오해하고 규칙에 보완 설정만 계속 추가할 수 있습니다.

스니핑은 암호화된 클라이언트 핸드셰이크 등의 보호를 우회하지 못하며 앱 로그를 대신할 수도 없습니다. 확인된 도메인은 연결 계층의 호스트명일 수 있어 사용자가 보고 있는 페이지 제목이나 전체 서비스와 일치하지 않을 수 있습니다. 특히 공유 인프라를 사용하는 서비스는 주의해야 합니다. 규칙은 안정적이고 검증 가능한 호스트명을 기준으로 설계하고, 한 번 확인한 도메인만으로 인프라 전체를 같은 아웃바운드에 넣지 마세요.

문제를 해결할 때는 대상 하나를 고정하고 기존 연결을 닫은 뒤 다시 요청하세요. 스니핑을 끈 상태와 켠 상태에서 대상 도메인, 규칙 이름, 아웃바운드를 비교합니다. 스니핑 전에 이미 명확한 주소 규칙과 일치했다면 규칙 순서와 코어 처리 방식도 확인하세요. 한 번의 테스트에서 포트 범위, 대상 오버라이드, 분기 규칙 집합을 동시에 바꾸면 어떤 설정이 차이를 만들었는지 알 수 없습니다.

로그에는 방문 도메인, 대상 주소, 앱 정보가 포함될 수 있습니다. 로그 수준을 일시적으로 높였다면 문제를 파악하는 데 필요한 시간만 기록하고 공유 전에 구독 주소, 인증 정보, 개인 접속 기록을 제거하세요. 문제가 해결되면 일반 로그 수준으로 되돌리고 유효한 최소 설정만 유지하세요. 스니핑은 설명 가능한 보조 기능으로 사용해야 합니다. DNS, 트래픽 처리, 규칙 참조의 구조적 문제를 가리는 데 사용해서는 안 됩니다.

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

구독을 업데이트하면 보통 원격 Profile 내용이 교체되므로 다운로드된 파일을 직접 수정하면 다음 업데이트에서 변경 사항이 사라질 수 있습니다. 로컬 오버라이드는 수신 포트, DNS 정책, 일부 업무 규칙, 컨트롤 인터페이스처럼 기기나 사용자가 장기간 유지할 설정을 보관합니다. 오버라이드, 병합, 확장, 스크립트 등 진입점 이름은 클라이언트마다 다르며 병합 방식도 같다고 볼 수 없습니다. 필드를 교체하는지, 객체를 깊이 병합하는지, 배열을 이어 붙이는지 먼저 확인하세요.

설정 소유권을 세 종류로 나누기

원격 구독은 노드와 관련 구조를, 로컬 기기 설정은 권한·수신·트래픽 처리 방식을, 사용자 정책은 업무별 분기와 장기 예외를 관리하도록 구분하세요. 같은 필드를 세 계층이 동시에 관리하지 않는 편이 좋습니다. 예를 들어 인터페이스에서 포트를 고정하고 오버라이드에서 다른 포트를 지정하며 구독에도 세 번째 값이 있으면 숨겨진 로드 순서에 따라 최종 결과가 달라집니다. 클라이언트를 바꿀 때도 쉽게 동작이 달라질 수 있습니다.

먼저 log-level처럼 결과를 확인하기 쉽고 영향이 적은 필드 하나로 병합 동작을 시험하세요. 설정을 불러온 뒤 최종 설정을 확인하고 규칙 배열이 어떻게 처리되는지도 테스트합니다. 새 규칙이 기존 rules 전체를 덮어쓴다면 해당 진입점은 예상한 추가 방식이 아닙니다. 모든 YAML 병합이 기존 배열을 보존한다고 가정하지 말고 클라이언트에서 제공하는 앞에 추가, 뒤에 추가 또는 규칙 편집 기능을 사용하세요.

# 병합 조각: 사용 전에 클라이언트의 객체 및 배열 처리 방식을 확인하세요
log-level: info

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

전체 파일을 이어 붙이지 말고 노드를 병합하기

두 개의 완전한 구독 파일에 모두 포트, DNS, 프록시 그룹, 최종 규칙이 들어 있을 수 있습니다. 텍스트를 그대로 이어 붙이면 중복 키가 생기거나 서로 덮어쓸 수 있습니다. 더 안정적인 방법은 기본 설정 하나에서 규칙과 그룹 구조를 관리하고 여러 proxy-providers로 노드를 제공하는 것입니다. 각 원본은 코어가 지원하는 노드 provider 형식이어야 합니다. 완전한 클라이언트 설정 파일은 파일 이름만 바꾼다고 노드 목록이 되지 않습니다.

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 노드 목록과 유효한 프로토콜 필드가 있어야 합니다. 이 예제는 참조 관계만 보여주며 노드 인증 정보를 제공하지 않습니다. 출처가 다른 노드의 이름이 겹치면 구분하기 어려우므로 알아보기 쉬운 이름을 유지하는 것이 좋습니다. 이름 변경이나 출처 접두어 추가가 필요하다면 클라이언트 또는 변환 과정에서 공식 지원하는지 확인하세요. 업데이트로 생성된 파일을 반복 적용할 수 없는 수작업 방식으로 바꾸지 마세요.

업데이트 간격·변환·실패 시 복구

클라이언트 Profile 업데이트 간격과 코어 provider 업데이트 간격은 서로 다른 작업이며 단위도 다를 수 있습니다. 전자는 기본 설정을 다시 가져오고 후자는 특정 노드나 규칙 원본을 갱신합니다. 각 작업을 누가 실행하는지, 캐시가 어디에 있는지, 업데이트 실패 후 이전 파일을 계속 사용하는지 기록하세요. 기기 절전, 모바일 네트워크 제한, 백그라운드 작업 정책 때문에 업데이트가 늦어질 수 있으므로 간격 숫자만으로 실제 실행 시각을 판단해서는 안 됩니다.

구독 주소에는 접근 인증 정보가 포함되는 경우가 많으므로 전체 링크를 공개 스크린샷, 로그, 예제 저장소에 올리지 마세요. 형식을 변환해야 한다면 원본 주소가 타사 서비스에 전달되는지 먼저 확인하세요. 신뢰할 수 있는 클라이언트 내장 기능이나 로컬 변환 방식을 우선 사용하고, 변환 후 노드 옵션이 빠지지 않았는지 점검하세요. 설정이 로드되는 것은 첫 단계일 뿐입니다. 프로토콜 필드가 단순화되면 실제 연결 동작이 달라질 수 있습니다.

병합을 한 번 적용할 때 사용할 수 있는 기본 설정, 새 오버라이드 조각, 복구 방법을 각각 준비하세요. 적용 후에는 노드 수가 예상과 맞는지, 프록시 그룹이 비어 있지 않은지, 규칙 참조가 존재하는지, DNS와 포트가 계획대로인지 확인합니다. 업데이트 후 문제가 생기면 클라이언트를 다시 설치해 단서를 잃기보다 새 오버라이드를 비활성화해 기준 설정으로 돌아가세요. 복구가 성공하면 조각별로 다시 활성화합니다.

Profile 전환과 병합을 지원하는 방식은 클라이언트마다 다릅니다. 설정 하나로 전환했다고 여러 구독의 노드를 동시에 사용하는 것은 아닙니다. 관리 방식을 먼저 확인하려면 Profile 구조와 여러 구독 관리를 읽어보세요. 장기간 관리할 때는 규칙의 목적과 출처 관계를 간단히 기록해 두는 편이 복잡하고 설명 없는 병합 스크립트에 의존하는 것보다 이전과 업데이트 후 검증이 쉽습니다.

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

외부 컨트롤 인터페이스는 코어 상태 조회, 정책 전환, 연결 확인, 일부 관리 작업 실행에 사용합니다. 앱이 인터넷에 연결할 때 쓰는 프록시 포트가 아닙니다. 흔히 컨트롤 포트로 9090을 사용하며 혼합 프록시 포트는 7890일 수 있습니다. 브라우저나 시스템 프록시를 컨트롤 포트로 설정해도 일반 프록시 서비스가 제공되지는 않습니다. 배포하기 전에 두 포트의 용도, 수신 주소, 접근 허용 기기를 각각 정리하세요.

우선 로컬에서만 수신하도록 설정하기

단일 기기에서 사용하는 클라이언트라면 보통 LAN에 컨트롤 인터페이스를 공개할 필요가 없습니다. 루프백 주소를 사용하면 접근 범위를 좁힐 수 있습니다. 클라이언트가 이미 컨트롤 인터페이스와 인증 값을 관리한다면 오버라이드에서 강제로 덮어쓰지 마세요. 내장 패널이 연결되지 않을 수 있습니다. 아래 인증 값은 필드 위치를 보여주기 위한 예시입니다. 실제 환경에서는 별도의 강력한 값을 생성해 안전하게 보관하세요.

external-controller: 127.0.0.1:9090
secret: "your-password"

컨트롤 인터페이스의 인증 기능만으로 네트워크 경계가 보호되는 것은 아닙니다. 원격 관리가 꼭 필요하다면 수신 주소를 변경하기 전에 신뢰할 수 있는 네트워크, 암호화된 전송, 방화벽 제한을 설계하세요. 편의를 위해 모든 주소에서 수신하도록 열거나 인터넷에 포트를 직접 연결하지 마세요. 이 인터페이스를 호출할 수 있는 사용자는 아웃바운드 정책을 바꾸거나 연결 정보를 읽을 수 있으므로 시스템 관리 인터페이스와 같은 수준으로 접근 권한을 관리해야 합니다.

API로 인터페이스 문제와 패널 문제 구분하기

먼저 코어가 실행 중인 기기에서 인터페이스를 확인하고 그다음 브라우저 패널을 점검하세요. 아래 명령의 인증 값은 앞부분의 예제 설정과 연결됩니다. 실제 환경에서는 함께 바꾸세요. 인증 실패, 연결 거부, 예상과 다른 응답은 각각 인증 설정, 수신 상태나 프로세스 상태, 포트 또는 서비스 선택 문제에 해당합니다. 모두 패널을 다시 다운로드한다고 해결되는 것은 아닙니다.

curl --fail --silent --show-error \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/version

curl --fail --silent --show-error \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/proxies

Windows PowerShell에서는 curl이 명령 별칭이나 버전에 따라 다르게 동작할 수 있습니다. curl.exe를 명시적으로 실행하고 사용 중인 터미널에 맞춰 줄바꿈 방식을 조정하세요. 인터페이스에서 데이터를 받을 수 있으면 패널에 입력한 주소, 프로토콜, 인증 값을 확인합니다. HTTPS로 열린 패널이 일반 HTTP 인터페이스에 연결할 때는 브라우저의 혼합 콘텐츠 정책에 막힐 수 있습니다.

정적 패널과 연결 기록의 범위

external-ui는 로컬 패널 정적 파일의 디렉터리를 지정하며 경로는 코어 작업 위치를 기준으로 해석됩니다. 정적 파일이 있다고 올바른 코어에 연결된 것은 아닙니다. 패널을 연 뒤 컨트롤 주소와 인증 상태를 확인하세요. 내장 패널은 보통 이 관계를 이미 처리하므로 일반 데스크톱 사용자는 클라이언트에서 제공하는 진입점을 우선 사용하고 출처가 불분명한 관리 페이지를 여러 개 관리하지 않는 편이 좋습니다.

패널의 연결 목록은 보통 현재 연결을 확인하는 용도이며 영구 감사 기록으로 볼 수 없습니다. 코어를 다시 시작하거나 연결을 닫고 설정을 전환하면 표시되는 정보가 달라질 수 있습니다. 문제 해결에 필요한 로그는 보관하되 연결 세부 정보를 장기간 공개하지 마세요. 문제를 공유할 때는 대상 유형, 적용 규칙, 오류 종류만 설명하면 됩니다. 구독 링크, 인증 값, 전체 접속 기록은 먼저 제거하세요.

업데이트 후 검증 목록 만들기

클라이언트를 업데이트하거나 구독을 교체하고 오버라이드를 조정할 때마다 같은 순서로 확인하세요. 코어가 시작됐는지 확인하고 실제 수신 포트를 살펴본 뒤 provider 로드, 규칙 일치, DNS와 TUN을 차례로 검증합니다. 마지막에 외부 패널을 확인하세요. 패널을 일시적으로 사용할 수 없어도 로그와 기본 연결을 통해 프록시 경로가 정상인지 판단할 수 있으므로 관리 화면 장애를 전체 네트워크 장애로 오해하지 않을 수 있습니다.

복구할 때는 마지막으로 편집한 파일 하나만 되돌리는 대신 직전의 검증된 설정 조합 전체를 복원하세요. 구독 캐시, 오버라이드, 정책 선택, 클라이언트 스위치가 함께 최종 동작을 결정합니다. 어떤 오버라이드를 끌지, 어느 Profile을 선택할지, TUN을 끌지, 캐시를 언제 지울지 복구 기록에 남기세요. 복구 후 새 연결을 요청해 이전 세션이 결과를 가리지 않는지 확인하세요.

이 페이지의 각 장은 따로 참고할 수 있지만 설정 순서는 의존 관계를 따라야 합니다. 먼저 연결 입구와 노드를 안정화한 다음 프록시 그룹과 규칙을 구성하고, 이어서 DNS, TUN, 스니핑을 조정한 뒤 마지막으로 원격 관리를 설정하세요. 기본 연결에 문제가 있다면 시스템 프록시 설정으로 돌아가 확인하세요. 클라이언트를 옮길 때는 다운로드 센터를 참고하세요. 설정 필드를 계속 늘리는 것보다 매번 관찰 가능한 결과와 실행 가능한 복구 절차를 남기는 편이 유지 관리에 도움이 됩니다.