Clash 고급 설정 가이드

프록시 그룹 유형과 연결 경로 구성

프록시 그룹은 규칙과 노드 사이에서 동작합니다. 규칙은 연결이 어떤 트래픽에 해당하는지 판단하고, 프록시 그룹은 해당 트래픽에 사용할 최종 출구를 정합니다. 여러 규칙에 노드 이름을 직접 넣으면 노드 이름 변경이나 구독 업데이트가 전체 설정에 영향을 줍니다. 먼저 안정적인 용도의 그룹 이름을 정한 뒤 그룹 안에서 노드를 조정하면, 일상적인 노드 변경과 규칙 관리를 분리할 수 있습니다. 연결 기록에서 선택 과정을 추적하기도 쉬워집니다.

수동 선택과 자동 선택의 역할

select는 업무 서비스, 특정 지역 콘텐츠, 임시 문제 해결처럼 출구를 직접 확인하고 선택해야 하는 경우에 적합합니다. 그룹에는 노드뿐 아니라 다른 프록시 그룹도 포함할 수 있습니다. 바깥쪽에는 수동 선택 그룹을 두고 안쪽에 자동 속도 테스트 그룹을 배치하면 구성을 이해하기 쉽습니다. 매번 도메인 규칙마다 노드를 지정하지 않고 자동 선택과 직접 연결 중 하나만 고르면 됩니다.

url-test는 지정한 테스트 주소로 그룹 구성원의 연결 상태를 확인해 용도가 비슷한 노드 중 하나를 자동 선택합니다. 테스트 결과는 해당 노드와 테스트 대상 간의 연결 상태만 보여 주며, 모든 서비스의 사용 경험을 보장하지는 않습니다. 테스트 주소는 안정적으로 접속할 수 있고 탐지를 허용하며 실제 사용 환경과 가까운 곳을 선택하세요. 간헐적으로 실패하는 주소 하나만 기준으로 삼으면 불필요한 노드 전환이 발생할 수 있습니다.

fallback은 후보 순서에 따라 사용할 수 있는 출구를 찾는 방식으로, 주 회선을 우선 사용하고 문제가 생기면 예비 회선으로 전환할 때 적합합니다. load-balance는 정책에 따라 연결을 분산하며, 하나의 연결을 여러 회선으로 합치는 기능은 아닙니다. 로그인 상태, 접속 IP, 지역 일관성이 중요한 서비스는 먼저 고정 출구를 사용하세요. 출구 변경이 허용되는 서비스인지 확인한 후 연결 분산을 고려하는 편이 안전합니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,DIRECT

위 예제는 그룹 이름과 규칙 참조 관계를 확인하기 위한 것입니다. 현재 PROXY 그룹에는 DIRECT만 있으므로 실제 연결은 직접 연결됩니다. 사용하려면 클라이언트에서 기존 노드나 다른 프록시 그룹을 추가하세요. 이름은 현재 설정과 정확히 일치해야 합니다. 그룹 이름에 ‘프록시’가 들어간다고 해서 원격 출구를 거친다고 단정하지 말고, 구성원을 확인해 최종 선택을 확인하세요.

자동 속도 테스트 설정과 노드 제공자

노드 제공자를 사용할 때 프록시 그룹의 use에는 파일 이름이 아니라 proxy-providers의 키 이름을 지정합니다. 제공자의 상태 검사와 그룹의 자동 선택은 목적이 다릅니다. 전자는 노드의 사용 가능 상태를 관리하고, 후자는 그룹 내 선택에 관여합니다. 두 곳에서 모두 자주 탐지하면 요청이 중복될 수 있으므로, 일반적으로 탐지 간격을 넉넉하게 설정한 뒤 실제 장애 복구 요구에 맞춰 조정하세요.

interval은 초 단위의 탐지 간격이며, tolerance는 작은 차이로 인해 노드가 자주 바뀌는 것을 줄이는 데 사용합니다. 최소 속도를 보장하거나 연결 시간 제한을 설정하는 값은 아닙니다. 자동 선택은 주로 새로 만드는 연결에 영향을 줍니다. 이미 시작된 다운로드나 통화, 장시간 연결은 선택 상태가 바뀌어도 즉시 다른 노드로 이동하지 않을 수 있습니다. 변경 사항을 확인하려면 테스트 연결을 종료하고 요청을 새로 시작하세요.

참조 확인과 전환 검증

그룹을 중첩할 수 있지만 순환 참조가 생겨서는 안 됩니다. 예를 들어 업무 그룹이 자동 그룹을 참조하고, 자동 그룹이 다시 업무 그룹을 참조하면 출구 경로를 확정할 수 없습니다. 수정할 때는 먼저 그룹 이름을 정리한 뒤 각 그룹의 구성원을 차례로 확인하세요. 하나의 노드를 여러 그룹에서 사용하는 것은 문제가 아닙니다. 중복된 그룹 이름, 존재하지 않는 이름 참조, 여러 단계의 중첩을 거쳐 자기 자신으로 돌아오는 구조를 방지해야 합니다.

검증할 때 연결 기록에서 일치한 규칙, 프록시 그룹 경로, 최종 노드를 함께 확인하세요. 규칙은 맞지만 출구가 다르다면 먼저 바깥쪽 그룹에 저장된 선택을 확인하고, 다음으로 안쪽 자동 그룹의 상태를 살펴보세요. 그룹이 비어 있다면 제공자가 정상적으로 로드되었는지, 필터 표현식이 모든 노드를 제외하지 않았는지 확인하세요. 처음부터 DNS를 수정하면 출구 문제와 이름 확인 문제가 뒤섞일 수 있습니다.

구독 업데이트로 노드가 삭제되더라도 안정적으로 유지해야 하는 업무 그룹 이름은 보존하세요. 중요한 서비스는 별도의 프록시 그룹으로 만들어 일반 그룹의 자동 변경에 영향을 받지 않도록 할 수 있습니다. 중첩을 계속 늘리기보다는 검증된 구성을 기록해 두는 편이 관리하기 쉽습니다. 여러 구독의 노드를 연결하는 방법은 로컬 오버라이드와 여러 구독 병합을 참고하세요.

규칙 제공자 관리와 규칙 매칭 순서

규칙 제공자를 사용하면 자주 업데이트되는 도메인이나 IP 대역을 기본 설정에서 분리할 수 있습니다. rule-providers가 규칙을 불러오고, RULE-SET을 사용해 규칙 체인에 연결합니다. 따라서 기본 설정에는 분류와 출구 관계만 남길 수 있습니다. 규칙 제공자는 노드 구독이 아니며 프록시 그룹을 자동으로 만들지 않습니다. 파일이 정상적으로 로드되어도 이를 참조하는 규칙이 없으면 연결 판단에 사용되지 않습니다.

동작 유형과 파일 형식 확인

behavior는 규칙 내용의 의미를 지정합니다. domain에는 도메인 목록, ipcidr에는 IP 대역, classical에는 유형이 지정된 규칙 항목을 넣습니다. format은 파일의 인코딩 형식을 지정하며, 두 설정은 서로 대체할 수 없습니다. 텍스트 파일을 내려받았다고 해서 특정 동작 유형을 선택할 수 있는 것은 아닙니다. 파일을 열어 실제 항목을 확인하세요.

원격 업데이트 없이 구조를 검증할 수 있도록 아래에서는 로컬 클래식 규칙 제공자를 사용합니다. 두 번째 설정을 기본 설정 디렉터리의 rules/work.yaml에 저장하고, 먼저 해당 디렉터리를 읽을 수 있는지 확인한 뒤 첫 번째 설정을 불러오세요. PROXY는 프록시 그룹에 미리 정의해야 합니다. 규칙 제공자에는 매칭 조건만 저장하고 각 항목 뒤에 출구를 반복해서 지정하지 않습니다.

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

rules:
  - RULE-SET,work,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

클래식 규칙 제공자는 DOMAIN-SUFFIX 같은 유형 접두사를 유지합니다. 도메인 목록은 항목 자체의 의미가 다르므로 위 파일의 behavior만 바꿔 그대로 사용할 수 없습니다. 바이너리 규칙 형식을 사용한다면 현재 코어가 해당 형식을 지원하는지도 확인하세요. 오류가 발생하면 캐시 경로를 계속 바꾸기보다 파일 내용과 설정에 선언한 유형이 일치하는지 먼저 점검하세요.

원격 업데이트와 캐시의 역할

원격 규칙 제공자로 바꾸려면 type: http를 사용하고 실제 규칙 주소, 업데이트 간격, 별도의 캐시 경로를 지정해야 합니다. 업데이트 간격의 단위도 초입니다. 원격 주소에서는 선언한 형식에 맞는 규칙 파일을 제공해야 합니다. 웹 페이지나 로그인 페이지, 오류 메시지가 반환되면 업데이트가 성공한 것이 아닙니다. 연결에 성공했다고 해서 내용까지 정상적으로 파싱된 것은 아닙니다.

캐시가 있으면 원격 파일을 일시적으로 가져올 수 없는 동안 기존 규칙을 계속 사용할 수 있지만, 실행 가능 여부는 캐시의 존재와 코어의 로드 결과에 따라 달라집니다. 처음 사용할 때는 로그에서 다운로드와 파싱이 모두 완료되었는지 확인하세요. 여러 제공자에 같은 캐시 파일을 지정하지 마세요. 업데이트 중 한 규칙이 다른 규칙을 덮어쓰면 분류 이름은 맞지만 내용이 잘못되는 문제를 알아차리기 어렵습니다.

원격 규칙의 출처도 설정의 신뢰 범위에 포함됩니다. 규칙 관리자는 도메인 분류를 변경해 연결 출구에 영향을 줄 수 있습니다. 적용하기 전에 규칙의 용도, 업데이트 방식, 적용 범위를 확인하고 로컬에서 테스트한 뒤 기본 설정에 연결하세요. 안정성이 중요한 일부 서비스는 기본 설정에 정확한 규칙을 추가해 동작을 고정할 수 있습니다. 광범위한 원격 목록에 전적으로 의존할 필요는 없습니다.

우선순위에 따라 규칙 체인 정렬

일반 규칙은 위에서부터 순서대로 검사하며, 먼저 일치한 규칙이 출구를 결정합니다. 따라서 로컬 예외는 일반 규칙 제공자보다 앞에 두고, 범위가 넓은 IP 대역 규칙은 뒤쪽에 배치하며, MATCH는 마지막 기본 규칙으로 둡니다. 기본 규칙을 앞에 두면 뒤의 규칙은 적용될 기회를 잃습니다. 광범위한 차단 규칙을 서비스 예외보다 앞에 두어도 예외가 가려집니다. 이런 순서 오류는 프록시 그룹을 바꿔도 해결되지 않습니다.

IP 관련 규칙을 적용하려면 도메인 확인이 필요할 수 있습니다. 일부 IP 규칙에서 지원하는 no-resolve는 해당 규칙을 위해 추가로 도메인을 확인하지 않도록 하는 옵션이며, 연결에서 DNS를 완전히 건너뛰게 하는 설정은 아닙니다. 알려진 대상 주소에만 의존하려면 사용할 수 있지만, 도메인을 확인한 뒤 특정 IP 대역에 속하는지 판단하려는 경우에는 주의하세요. 예상한 매칭 범위가 달라질 수 있습니다.

잘못된 경로로 연결되는 문제를 조사할 때는 대상 도메인과 실제로 일치한 규칙부터 기록한 뒤 해당 규칙 제공자를 확인하세요. 가장 앞에 정확한 도메인 규칙을 임시로 추가하면 문제의 원인이 규칙 순서인지 출구인지 파악하는 데 도움이 됩니다. 테스트가 끝나면 임시 규칙을 삭제하고 용도가 명확한 예외만 남기세요. 서로를 가리는 규칙이 설정에 쌓이지 않도록 관리해야 합니다.

규칙이 많다면 출처별로 무작정 쌓기보다 업무 서비스, 미디어 서비스, 로컬 네트워크처럼 용도에 따라 나눠 구성하세요. 한 번에 한 종류만 업데이트하고 연결 기록을 살펴보면 변경 원인을 파악하기 쉽습니다. 필드 간 참조 구조는 config.yaml 최상위 필드 살펴보기에서 확인할 수 있습니다. 연결 실패의 일반적인 점검 방법은 FAQ를 참고하세요.

DNS 설정과 이름 확인 경로

DNS는 주소를 찾는 데서 끝나지 않습니다. 도메인과 주소, 이후의 출구가 서로 맞아야 합니다. 같은 도메인도 DNS 서버에 따라 다른 결과를 반환할 수 있고, 프록시 출구의 네트워크에 따라 대상에 연결할 수 있는지도 달라질 수 있습니다. 설정을 최적화하기 전에 앱의 요청이 클라이언트 DNS로 들어오는지 확인하고, DNS 요청이 어떤 출구를 통해 전달되는지 파악한 다음, DNS 서버를 비교하세요. 서버 목록만 바꾸는 방식으로는 충분하지 않습니다.

수신 주소, 상위 DNS, 초기 확인 구분

listen은 클라이언트 DNS 서비스가 요청을 받는 위치를 지정하고, nameserver는 일반 도메인 조회에 사용할 상위 DNS를 지정합니다. 서로 다른 계층의 설정입니다. 루프백 주소에서 수신하도록 설정하면 이 컴퓨터에서만 접근할 수 있습니다. 설정 파일에 주소를 적었다고 운영체제가 자동으로 그 주소를 사용하지는 않습니다. 운영체제 DNS 설정, TUN의 DNS 가로채기 또는 클라이언트 기능을 통해 요청을 해당 수신 포트로 보내야 합니다.

default-nameserver는 주로 DNS 상위 서버의 도메인을 확인할 때 사용하므로 직접 연결할 수 있는 명확한 주소를 지정해야 합니다. 암호화된 상위 DNS를 도메인 이름으로 지정했다면 먼저 해당 도메인을 확인할 방법이 있어야 합니다. 초기 DNS 확인이 아직 연결되지 않은 프록시에 의존하면 시작 단계에서 순환 참조가 발생할 수 있습니다. 이 경우 노드 도메인과 DNS 서버 도메인을 모두 확인하지 못할 수 있습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"

이 예제는 설정 필드의 위치를 보여 줍니다. 표시된 공용 DNS 주소는 현재 네트워크에서 접속할 수 있는지 확인한 뒤 선택해야 합니다. 시스템 포트의 요청을 1053으로 자동 전달하지 않으며, 모든 앱이 이 DNS 서비스를 사용한다고 보장하지도 않습니다. 적용한 뒤에는 먼저 해당 포트로 직접 조회해 수신이 정상인지 확인하고, 이어서 운영체제와 앱의 DNS 경로를 점검하세요. 시스템이 연결되지 않은 문제를 상위 DNS 장애로 오인하지 않도록 주의해야 합니다.

노드 도메인과 서비스 도메인 분리

서비스 도메인은 최종적으로 프록시를 통해 접속할 수 있지만, 프록시 노드 도메인은 보통 프록시가 작동하기 전에 확인해야 합니다. 해당 필드를 지원하는 코어에서는 proxy-server-nameserver로 노드 도메인을 조회할 DNS 서버를 별도로 지정할 수 있습니다. 변경하기 전에 상위 DNS에 직접 접속할 수 있는지 확인하세요. 노드 주소의 도메인을 확인할 수 없다면 프록시 그룹의 탐지 실패만으로 원격 서비스가 중단되었다고 판단할 수 없습니다.

nameserver-policy를 사용하면 특정 도메인에 사용할 DNS 서버를 지정할 수 있습니다. 내부 도메인, 분할 DNS 또는 명확한 지역별 요구가 있는 서비스에 적합합니다. 기업 내부 도메인은 내부 영역에 접근할 수 있는 DNS 서버로 보내야 합니다. 공용 DNS 서버에는 일반적으로 해당 레코드가 없습니다. 먼저 하나의 도메인 접미사에 적용해 검증한 뒤 범위를 넓히세요. 일반 도메인이 내부에서만 접근할 수 있는 서버로 잘못 전달되지 않도록 주의해야 합니다.

respect-rules를 사용하면 DNS 상위 서버로 향하는 연결도 규칙에 따라 출구를 선택합니다. 노드 도메인 확인 경로도 함께 살펴 DNS가 프록시에 의존하고 프록시는 다시 같은 DNS 경로에 의존하는 상황을 피해야 합니다. 이 설정은 누구에게나 적용할 수 있는 속도 향상 옵션이 아닙니다. DNS 요청의 출구를 지정해야 할 이유가 없다면 기본 설정을 단순하게 유지하고 기본 연결이 안정된 뒤에 정책을 추가하는 편이 문제를 찾기 쉽습니다.

계층별로 확인하고 웹페이지 동작으로 DNS 조회를 판단하지 않기

앱은 자체 DNS 캐시를 보유하거나 암호화 DNS를 사용할 수 있습니다. 브라우저에 내장된 DNS 확인 기능은 운영체제 설정을 우회할 수 있으며 이미 연결된 세션은 DNS를 다시 조회하지 않을 수도 있습니다. 설정을 바꾼 뒤에는 클라이언트 조회, 운영체제 조회, 앱의 새 연결을 각각 확인하고 필요하면 해당 캐시를 비우세요. 기존 연결을 종료하지 않고 페이지를 새로 고치는 것만으로는 새 설정의 적용 여부를 확인하기 어렵습니다.

dig를 사용할 수 있는 시스템에서는 다음 명령으로 예제 수신 포트에 직접 질의할 수 있습니다. Fake-IP 주소가 반환되면 해당 매핑 기능을 거쳐 조회된 것이며, 대상 서버가 실제로 그 주소를 사용한다는 뜻은 아닙니다. 명령이 시간 초과되면 먼저 수신 주소와 포트 사용 여부를 확인하세요. 응답은 오지만 앱이 계속 실패한다면 운영체제 연결, 라우팅, 규칙 매칭을 점검하세요. 모든 상위 DNS 서버를 바로 바꿀 필요는 없습니다.

dig @127.0.0.1 -p 1053 example.com A

일반 도메인은 정상인데 내부 도메인만 실패한다면 검색 도메인, 내부 DNS 서버, VPN 경로를 확인하세요. 모든 도메인이 실패하지만 IP 주소로는 연결된다면 DNS 가로채기와 상위 DNS 경로를 중점적으로 점검해야 합니다. 도메인 확인은 되지만 연결 시간이 초과된다면 프록시 경로와 대상 서버 접속 가능성을 다시 살펴보세요. DNS 조회 성공만으로 예상한 출구를 통해 연결된다고 보장할 수는 없습니다.

상위 DNS 서버 수를 늘리는 것을 일반적인 최적화 방법으로 보지 마세요. 서버가 많아지면 개인정보와 장애 범위가 커지고, 서버별로 다른 응답을 반환해 문제 해결이 더 어려워질 수 있습니다. 신뢰할 수 있는 서버를 소수만 선택하고 특수 도메인 정책과 선택 이유를 기록하세요. DNS 설정과 Fake-IP의 관계는 다음 장에서 주소 매핑, 캐시 만료, 앱이 저장한 주소를 함께 살펴보세요.

TUN과 Fake-IP의 네트워크 처리 범위

TUN은 시스템 라우팅을 통해 들어오는 IP 패킷을 받는 가상 네트워크 인터페이스입니다. Fake-IP는 DNS 계층의 주소 매핑 기능입니다. 두 기능은 함께 사용하는 경우가 많지만 같은 기능은 아닙니다. 시스템 프록시는 프록시 설정을 따르는 앱을 대상으로 하고, TUN은 더 많은 네트워크 요청을 처리할 수 있습니다. 모든 연결 문제의 기본 해결책으로 취급하지 말고, 앱의 네트워크 요청을 어디까지 처리해야 하는지에 따라 사용 여부를 결정하세요.

복구 가능한 네트워크 연결 설정 순서

사용하기 전에 일반 프록시로 노드, 구독, 프록시 그룹이 정상적으로 작동하는지 확인한 다음 클라이언트에 서비스 설치나 관리자 권한이 필요한지 살펴보세요. 데스크톱 운영체제에서는 가상 인터페이스와 라우팅 권한이 필요할 수 있고, 모바일에서는 시스템 VPN 권한을 부여해야 하는 경우가 많습니다. 앱에서 스위치를 켰다고 네트워크 처리가 완료된 것은 아닙니다. 로그에서 인터페이스 생성, 라우트 설정, DNS 가로채기에 오류가 없는지 확인하세요.

아래는 자주 사용하는 기본 필드입니다. auto-route는 라우트를 자동으로 설정하고, auto-detect-interface는 출구 인터페이스를 식별하며, dns-hijack는 DNS 가로채기 대상을 지정합니다. 지원 여부와 동작은 운영체제와 코어에 따라 다릅니다. 먼저 클라이언트의 기본 TUN 설정을 사용한 뒤 최종 설정을 확인하세요. 앱 설정과 오버라이드에서 서로 반대되는 값을 동시에 지정하지 않도록 주의해야 합니다.

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

stack은 네트워크 스택 구현을 선택하는 필드이며, 이름만 보고 성능을 판단할 수 없습니다. 운영체제마다 구현 지원, 프로토콜 처리, 리소스 사용량이 다릅니다. 특정 앱에서 문제가 생기면 다른 설정은 그대로 두고 클라이언트가 실제로 지원하는 네트워크 스택만 바꿔 비교하세요. 운영체제 환경도 기록하고 라우트, DNS, MTU를 동시에 조정하지 마세요.

Fake-IP 도메인 매핑 이해하기

Fake-IP 모드에서는 앱에 매핑 주소를 반환하고, 이후 연결에서 클라이언트가 해당 주소를 도메인으로 복원해 트래픽을 분류합니다. 예제에 표시된 주소 대역은 이 기능에 사용하는 것이며 대상 웹사이트의 실제 주소가 아닙니다. 대상 IP만으로 도메인을 판별하기 어려운 문제를 줄일 수 있지만, DNS 조회와 이후 연결이 같은 매핑 환경으로 들어와야 합니다. 매핑 경로가 끊기면 연결에 실패할 수 있습니다.

앱이 주소를 오래 캐시하거나 절전 모드에서 연결을 복구하는 경우, 또는 클라이언트 인스턴스를 전환하면 기존 매핑이 유효하지 않을 수 있습니다. 이때는 먼저 도메인을 다시 조회하고 새 연결을 만드세요. 필요하다면 앱과 시스템의 캐시를 비웁니다. 이전 Fake-IP 주소를 hosts 파일이나 서비스 설정에 넣거나 다른 기기에 서버 주소로 공유하지 마세요. 해당 주소는 매핑 테이블을 벗어나면 예상한 도메인 의미를 갖지 않습니다.

fake-ip-filter는 지정한 도메인에 Fake-IP 대신 실제 주소를 반환하도록 합니다. 실제 주소 의미가 필요한 일부 LAN 검색, 내부 서비스, 호환성 문제에 사용할 수 있습니다. 필터링한다고 직접 연결되는 것은 아닙니다. 실제 주소를 받은 뒤에도 연결 출구는 규칙에 따라 결정됩니다. 확인된 문제가 있는 도메인만 하나씩 추가하고, 너무 넓은 범위를 지정해 Fake-IP 기능 전체가 무력화되지 않도록 주의하세요.

라우트 충돌과 LAN 접근

회사 VPN, 컨테이너 네트워크, 가상 머신, 다른 프록시 도구가 라우트를 변경할 수 있습니다. TUN을 시작한 뒤 내부 리소스만 접속할 수 없다면 관련 네트워크 대역의 라우트가 어디로 향하는지 비교하고 기존 경로를 유지하거나 제외해야 하는지 확인하세요. 인터넷 연결을 복구하려고 모든 라우트를 삭제하지 마세요. 특히 원격으로 기기를 관리하는 경우 관리 연결이 끊길 수 있으므로 다른 복구 방법을 미리 준비해야 합니다.

‘LAN 연결 허용’을 켜는 것과 TUN을 활성화하는 것은 별개의 설정입니다. 전자는 일반적으로 프록시 수신 포트에 다른 기기가 접근할 수 있는지에 영향을 주고, 후자는 이 기기의 라우팅을 처리합니다. 다른 기기에 프록시를 제공하려면 수신 주소, 방화벽, 인증 설정도 확인해야 합니다. 이 기기에서 TUN을 켜도 LAN 전체의 트래픽이 자동으로 클라이언트를 통과하지는 않습니다.

네트워크 처리를 시작한 뒤 인터넷이 전혀 되지 않으면 TUN, 시스템 DNS, 시스템 프록시 순서로 상태를 확인하고 클라이언트를 종료할 때 인터페이스와 라우트가 정리되는지도 살펴보세요. 먼저 기본 네트워크를 복구한 다음 한 가지 네트워크 처리 방식만 다시 테스트합니다. 설치 파일과 플랫폼 선택은 다운로드 페이지를 참고하고 Clash Plus를 우선 선택하세요. 기능 지원 여부는 사용 중인 클라이언트의 실제 설정을 기준으로 확인해야 합니다.

도메인 스니핑과 규칙 보완

도메인 스니핑은 연결 초기에 오가는 프로토콜 데이터에서 호스트 이름을 찾아 대상 IP만으로는 알 수 없는 정보를 보완합니다. DNS가 제공하는 도메인 매핑을 보완하지만, 완전한 이름 확인과 라우팅 설계를 대신하지는 않습니다. 사용하기 전에 실제로 도메인 정보가 누락된 문제인지 확인하세요. 연결 기록에 이미 올바른 도메인과 매칭 규칙이 표시된다면 스니핑을 추가해도 출구 문제는 해결되지 않을 가능성이 큽니다.

식별 가능한 정보와 한계

HTTP 요청에는 호스트 헤더가 포함될 수 있고, TLS 핸드셰이크에서는 서버 이름을 확인할 수 있습니다. 일부 QUIC 핸드셰이크에서도 단서를 얻을 수 있습니다. 정보가 노출되는지는 프로토콜과 핸드셰이크 방식, 코어의 지원 여부에 따라 달라집니다. 스니핑은 HTTPS 내용을 복호화하지 않으므로 암호화된 요청 전체를 읽을 수 없습니다. 이름 정보가 보호되거나 프로토콜이 지원되지 않으면 클라이언트가 도메인을 알아낼 방법은 없습니다.

일부 앱은 고정 IP에 직접 연결하거나 자체 이름 확인 절차를 사용해 클라이언트 DNS를 거치지 않습니다. 이런 경우 스니핑을 통해 도메인 규칙이 다시 적용될 수 있습니다. 하지만 하나의 IP에서 여러 서비스가 제공될 수 있고 앱 핸드셰이크의 이름이 사용자가 입력한 주소와 다를 수도 있습니다. 실제 연결 기록에서 결과를 확인하고 웹사이트가 열리는지만으로 판단하지 마세요.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
      override-destination: false
  skip-domain:
    - "*.lan"
    - "*.local"

예제는 HTTP와 TLS의 일반적인 포트만 대상으로 제한하고 대상 오버라이드를 끄므로 식별 결과를 살펴보는 데 적합합니다. 모든 사용자 지정 포트가 자동으로 포함되는 것은 아니며 QUIC 식별도 활성화되어 있지 않습니다. 서비스가 다른 포트를 사용한다면 프로토콜을 확인한 뒤 범위를 넓히세요. 포트는 필터 조건일 뿐 프로토콜을 증명하지 않습니다. 임의의 포트에서 모든 프로토콜을 탐지하면 불필요한 간섭이 발생할 수 있습니다.

도메인 식별과 대상 오버라이드를 따로 확인

override-destination은 식별한 도메인을 기준으로 연결 대상을 바꿀지 설정합니다. 끄면 먼저 도메인 식별과 규칙 변경 여부를 관찰할 수 있습니다. 켜면 이후 이름 확인과 연결 방식이 달라질 수 있습니다. 두 동작은 나눠서 테스트하세요. 먼저 식별 결과를 신뢰할 수 있는지 확인하고, 대상 변경이 필요한지 검토해야 어느 단계에서 문제가 생겼는지 구분하기 쉽습니다.

고정 IP 접속, 내부 리버스 프록시, 특정 대상 주소가 필요한 앱은 대상 오버라이드와 호환되지 않을 수 있습니다. 특정 서버에 연결하도록 지정했더라도 핸드셰이크 도메인을 기준으로 다시 조회하면 다른 서버로 연결될 수 있습니다. 로그인 문제가 생기거나 서비스 응답이 달라졌다면 원하는 그룹의 규칙이 일치하는지만 보지 말고 원래 주소, 식별한 도메인, 최종 연결 대상을 비교하세요.

skip-domain으로 스니핑에서 제외할 도메인을 지정할 수 있습니다. 용도가 불분명한 긴 제외 목록을 복사하지 말고 명확한 내부 서비스와 호환성 예외부터 추가하세요. 범위를 너무 넓히면 해결하려던 도메인 누락이 계속될 수 있습니다. 너무 좁게 설정하면 간섭이 필요 없는 내부 연결에 변화가 생길 수 있습니다. 항목마다 결과를 확인하는 것이 중요합니다.

DNS 및 앱의 암호화된 이름 확인과 함께 문제 해결

브라우저의 암호화 DNS를 사용하면 클라이언트가 일반 DNS 요청을 확인하지 못할 수 있지만, 스니핑으로 도메인을 복원할 수 있다는 뜻은 아닙니다. 핸드셰이크의 이름까지 숨겨지면 클라이언트가 알 수 있는 정보는 IP와 일부 제한된 데이터뿐입니다. 앱이 클라이언트에서 처리할 수 있는 이름 확인 경로를 사용하도록 하거나 IP 기반 규칙의 한계를 받아들여야 합니다. 효과가 없는 스니핑 포트 설정을 반복해서 추가하지 마세요.

문제 해결에는 도메인이 고정되어 있고 연결을 쉽게 다시 만들 수 있는 서비스를 하나 선택하세요. 먼저 스니핑을 끄고 규칙 매칭을 기록한 다음, 대상 오버라이드 없이 도메인 식별을 켜고 필요할 때만 오버라이드를 테스트합니다. 매번 기존 연결을 종료하고 프록시 그룹 선택은 그대로 유지하면서 도메인과 최종 출구를 확인하세요. 이렇게 하면 이름 식별, 규칙 매칭, 연결 대상 변경을 분리해 원인을 파악할 수 있습니다.

UDP 서비스만 비정상이라면 노드가 필요한 전송 방식을 지원하는지, TUN이 해당 트래픽을 처리하는지, 프로토콜이 스니핑 대상에 포함되는지를 따로 확인하세요. 브라우저는 QUIC 연결에 실패한 뒤 TCP로 전환할 수 있으므로 웹페이지가 열렸다고 두 경로가 모두 정상인 것은 아닙니다. 규칙이 올바른지 확인한다는 이유로 UDP 전체를 차단하지 마세요. 앱 동작을 바꾸고 원래 문제를 가릴 수 있습니다.

스니핑 설정은 범위를 좁게 유지하고 목적을 분명히 하세요. DNS 매핑이 안정된 것을 확인한 뒤 실제로 필요한 프로토콜에만 활성화하고 설정 기록에 용도를 남기면 됩니다. 반복해서 확인할 수 있는 개선이 없다면 더 단순한 설정으로 되돌리는 편이 관리하기 쉽습니다. 규칙 모드, 연결 로그, 일반적인 오류는 FAQ와 함께 확인하세요. 스니핑에 모든 트래픽 분류를 맡길 필요는 없습니다.

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

구독은 원격에서 제공하는 내용을 관리하고, 로컬 오버라이드는 기기와 개인의 요구를 반영합니다. 두 설정은 별도로 저장해야 합니다. 내려받은 구독 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 모든 설정을 구독에 맡기면 포트, DNS, 네트워크 처리 방식이 원격 설정에 따라 바뀔 수 있습니다. 어떤 필드는 원격에서 관리하고 어떤 필드는 로컬에서 유지할지 명확히 정하세요.

클라이언트의 병합 방식부터 확인

클라이언트에 따라 설정 병합, 오버라이드 파일, 규칙 패치, 스크립트 처리 기능을 제공할 수 있습니다. 이름이 비슷해도 실제 동작은 다릅니다. 특히 배열 필드는 구현에 따라 전체 교체되거나 항목이 추가 또는 앞에 삽입될 수 있습니다. 실행 순서와 적용 범위를 확인한 뒤 사용하세요. 특정 클라이언트의 패치 문법을 모든 mihomo YAML에 적용할 수 있는 일반 문법으로 간주하지 마세요. 순서를 모르는 오버라이드 방식을 동시에 사용하지 않는 것도 중요합니다.

먼저 로그 수준 변경처럼 위험이 낮은 필드로 테스트할 수 있습니다. 설정을 불러온 뒤 최종 설정에서 값이 바뀌었는지 확인하고, 다음으로 규칙 앞에 삽입하거나 목록을 교체하는 방식을 테스트하세요. 화면에서 저장되었다는 것은 입력이 접수되었다는 뜻일 뿐, 최종 설정에 의도한 대로 병합되었다는 의미는 아닙니다. 코어에 전달된 최종 유효 설정과 코어의 로드 결과를 확인해야 합니다.

로컬에서 관리할 내용은 기기 설정과 서비스 설정으로 나누는 것을 권장합니다. 기기 설정에는 수신 포트, DNS, TUN, 컨트롤 인터페이스를 두고 서비스 설정에는 안정적인 그룹 이름, 규칙 순서, 로컬 예외를 둡니다. 이렇게 하면 기기를 옮길 때 네트워크 설정만 조정하고 서비스 규칙 전체를 다시 작성할 필요가 없습니다. 스크립트를 사용하는 오버라이드는 설정 전체를 새로 만들 수도 있으므로 먼저 스크립트 동작을 살펴보세요.

여러 구독은 노드 제공자로 분리

전체 구독 두 개를 병합할 때의 문제는 보통 노드 자체보다 중복된 프록시 그룹 이름, 반복되는 규칙, 호환되지 않는 DNS 설정에서 발생합니다. 노드 두 그룹을 함께 사용하려는 목적이라면 각 출처에서 별도의 노드 파일을 제공하도록 하고 로컬 설정에서 프록시 그룹을 통합 관리하는 편이 명확합니다. 아래는 로컬 파일을 사용한 구조 예제입니다. 파일에는 노드 제공자가 읽을 수 있는 proxies 목록이 있어야 합니다.

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

proxy-groups:
  - name: PROXY
    type: select
    use:
      - access-a
      - access-b
    proxies:
      - DIRECT

전체 구독에는 보통 프록시 그룹과 규칙도 들어 있으므로 파일 이름만 바꿨다고 올바른 노드 제공자가 되는 것은 아닙니다. 파일 구조가 로드 방식과 호환되는지, 또는 클라이언트가 지원하는 변환 기능을 사용할 수 있는지 확인하세요. 원격 제공자를 사용한다면 실제 구독 주소와 개별 캐시 경로를 지정해야 합니다. 구독 주소에 접근 자격 정보가 포함될 수 있으므로 공개 문서나 문제 해결용 스크린샷에 노출하지 마세요.

이름 충돌과 규칙 순서 유지

두 출처에서 같은 노드 이름을 사용하면 선택 항목을 구분하기 어렵거나 참조 대상이 명확하지 않을 수 있습니다. 가져오기 또는 사전 처리 단계에서 안정적인 출처 접두사를 추가하는 방법을 우선 고려하세요. 적용하기 전에 클라이언트에서 지원하는 이름 변경 방식을 확인해야 합니다. 표시 이름만 보고 지역이나 용도를 추측하지 마세요. 출처 표시는 관리 범위를 구분하기 위한 것이며 실제 연결 가능 여부는 연결 테스트로 확인해야 합니다.

규칙을 병합할 때는 순서에 따른 동작을 유지해야 합니다. 사용자 지정 예외는 일반적으로 앞에 두고, 구독의 일반 분류는 중간에 배치하며, 기본 규칙은 하나만 남겨 마지막에 둡니다. 두 규칙 배열을 그대로 이어 붙이면 첫 번째 배열의 MATCH가 두 번째 배열의 모든 규칙을 가릴 수 있습니다. 클라이언트가 규칙을 기본적으로 뒤에 추가한다면 앞에 삽입하는 기능이 있는지 확인하세요. 규칙 항목이 존재한다는 것만으로 적용되었다고 판단하면 안 됩니다.

프록시 그룹의 참조가 순환하지 않는지도 확인하세요. 병합 후 같은 이름의 업무 그룹 두 개를 남기거나 그룹 이름을 바꾼 뒤 규칙의 출구를 수정하지 않으면 로드 오류나 예상하지 못한 선택이 발생할 수 있습니다. 제공자를 먼저 불러온 다음 통합 프록시 그룹을 만들고 마지막으로 규칙을 추가하는 순서로 최소 검증을 진행하세요. 각 단계에서 로그를 확인해 노드 로드 문제와 규칙 참조 문제를 한꺼번에 최종 설정에 반영하지 않도록 합니다.

백업, 업데이트, 롤백

백업에는 로컬 오버라이드, 기본 설정, 규칙 파일, 제공자 구성 설명을 포함해야 합니다. 민감한 구독 주소는 별도로 보관하세요. 클라이언트 화면을 캡처한 것만으로는 참조 관계를 복구할 수 없습니다. 업데이트된 최종 설정만 백업하면 기존 오버라이드 방식이 사라질 수 있습니다. 큰 변경을 하기 전에 연결이 되는 상태와 관련 설명을 함께 보관해 문제가 생겼을 때 어느 계층을 복원해야 할지 파악할 수 있도록 하세요.

구독 업데이트를 테스트할 때 로컬 예외가 유지되는지, 규칙 순서가 바뀌었는지, 현재 선택이 삭제된 노드를 가리키는지 확인하세요. 문제가 생기면 최신 패치를 먼저 비활성화하고 백업을 불러오세요. 실패한 설정에 연달아 수정을 추가하지 마세요. 프로필 전환과 구독 업데이트의 차이는 여러 설정 관리 노트를 참고하세요. 기본 가져오기 절차는 사용 가이드를 확인하면 됩니다.

외부 컨트롤러와 설정 검증 절차

외부 컨트롤 인터페이스를 사용하면 실행 상태를 조회하고 프록시 그룹을 전환하거나 일부 관리 작업을 수행할 수 있습니다. 컨트롤 패널은 이 인터페이스에 시각적 환경을 제공합니다. 패널 자체가 프록시 출구를 제공하거나 코어를 대체하지는 않습니다. 패널 연결 실패와 프록시 연결 실패는 서로 다른 문제입니다. 트래픽은 정상적으로 전달되더라도 관리 인터페이스가 수신 대기하지 않거나 인증 정보가 일치하지 않거나 브라우저 보안 정책에 의해 접근이 차단될 수 있습니다.

로컬 수신 설정과 로컬 패널 파일

이 기기에서만 관리한다면 external-controller를 루프백 주소에 바인딩하세요. external-ui는 로컬 패널 리소스 디렉터리를 지정하며 해당 디렉터리에 실제 정적 파일이 있어야 합니다. 디렉터리 이름을 입력한다고 패널이 자동으로 만들어지는 것은 아닙니다. 아래 예제는 수신 주소와 리소스 경로를 보여 줍니다. 사용하기 전에 로컬에서 컨트롤 인터페이스 인증 키를 별도로 설정하고 공개 예제의 값을 장기 자격 증명으로 복사하지 마세요.

external-controller: 127.0.0.1:9090
external-ui: ./ui

인증 필드는 최상위 secret이며, 별도로 생성한 긴 임의 문자열을 사용하고 패널 연결 설정에도 같은 값을 입력해야 합니다. 이 키는 컨트롤 인터페이스 인증에 사용되며 노드 비밀번호나 구독 주소와는 다릅니다. 같은 값을 여러 용도로 사용하지 마세요. 스크린샷, 공유 링크, 공개 설정 파일에 키가 노출되면 관리 권한이 위험해질 수 있으므로 문제 해결을 위해 공유하기 전에 민감한 정보를 제거하세요.

수신 주소를 모든 인터페이스로 변경하면 다른 네트워크 기기가 관리 인터페이스에 접근할 수 있습니다. 편의를 위해 무작정 개방해서는 안 됩니다. 원격 관리가 꼭 필요하다면 접근이 통제된 네트워크와 적절한 암호화 연결을 사용하고 시스템 방화벽을 확인하세요. 인증이 설정되어 있다고 네트워크 분리를 무시해도 되는 것은 아닙니다. 관리 인터페이스는 실행 동작을 변경할 수 있으므로 관리자 권한에 준해 보호해야 합니다.

네트워크, 인증, 브라우저 제한을 각각 확인

패널이 연결되지 않으면 먼저 현재 코어 프로세스가 컨트롤 인터페이스 설정을 실제로 불러왔는지 확인한 다음 주소와 포트를 점검하세요. 브라우저에 표시되는 로컬 주소는 브라우저가 실행 중인 기기를 기준으로 합니다. 다른 기기에서 패널을 열면 루프백 주소는 코어가 실행 중인 호스트를 가리키지 않습니다. 이 문제를 해결한다며 수신 범위를 바로 넓히지 말고, 기기 간 관리가 정말 필요한지 먼저 판단하세요.

이 기기에서 인증을 설정하지 않은 상태라면 다음 명령으로 인터페이스 응답을 확인할 수 있습니다. 이미 키를 설정했다면 해당 인증을 포함한 요청을 보내야 하며, 이 확인을 위해 인증을 삭제할 필요는 없습니다. 연결 거부는 일반적으로 수신 대기 중인 서비스가 없거나 주소가 잘못된 경우입니다. 인증 오류는 인터페이스에 접근할 수 있지만 자격 증명이 일치하지 않는다는 뜻인 경우가 많습니다. 두 문제를 따로 해결하세요. 프록시 노드를 계속 바꿔도 결과는 달라지지 않습니다.

curl --fail --silent --show-error http://127.0.0.1:9090/version

원격 HTTPS 페이지에서 로컬 HTTP 인터페이스를 요청하면 혼합 콘텐츠, 교차 출처 또는 로컬 네트워크 접근 제한에 걸릴 수 있습니다. 패널 화면이 비어 있다면 정적 파일 경로가 잘못되었을 수도 있습니다. 클라이언트 내장 패널이나 신뢰할 수 있는 로컬 패널을 우선 사용하고 브라우저 개발자 도구의 콘솔 메시지를 하나씩 확인하세요. 모든 출처를 허용하는 설정을 일반적인 해결책으로 사용하지 말고 패널 연결을 위해 브라우저 보안을 전부 끄지 마세요.

설정 로드 전후로 두 차례 검증

첫 번째 검증은 설정을 불러오기 전에 합니다. YAML 들여쓰기, 필드 유형, 참조 이름, 파일 경로를 확인하세요. mihomo 명령을 사용할 수 있는 환경에서는 테스트를 실행할 수 있습니다. 로컬 제공자가 포함된 설정이라면 관련 파일도 준비되어 있어야 합니다. 테스트를 통해 문법과 일부 참조 문제를 발견할 수 있지만 원격 노드 연결, 시스템 권한, 모든 서비스 규칙의 적합성까지 보장하지는 않습니다.

mihomo -t -f ./config.yaml

두 번째 검증은 설정을 불러온 다음 진행합니다. 먼저 시작 로그에서 인터페이스, 제공자, 규칙 제공자가 모두 정상적으로 로드되었는지 확인하세요. 그런 다음 반복해서 재현할 수 있는 테스트 연결을 만들고 도메인, 일치한 규칙, 프록시 그룹 경로, 최종 출구를 확인합니다. 이후 직접 연결이 필요한 서비스와 프록시가 필요한 서비스를 각각 테스트하세요. 패널에 실행 중이라고 표시되는 것만으로 설정부터 실제 연결까지 모두 정상이라고 볼 수는 없습니다.

패널에서 임시로 변경한 선택이 구독이나 로컬 오버라이드에 저장되지 않을 수 있습니다. 선택을 장기간 유지하려면 클라이언트의 저장 방식이 적용되는지 확인하세요. 규칙을 장기간 유지하려면 관리 가능한 설정 계층에 추가해야 합니다. 실행 중 변경을 유일한 백업으로 취급하지 마세요. 재시작, 업데이트, 프로필 전환 후 패널에서 조정한 상태가 사라지면 설정이 저절로 바뀐 것처럼 보일 수 있습니다.

문제 원인은 한 번에 하나씩 변경

설정 파싱, 파일 로드, DNS, 출구, 규칙, 시스템 네트워크 처리 순서로 문제를 확인하는 것이 좋습니다. 한 번에 한 계층만 수정하고 결과를 기록한 다음 다음 단계로 넘어가세요. 업데이트 직후 문제가 발생했다면 스니핑을 켜고 네트워크 스택을 바꾸고 DNS를 다시 설정하기보다 최근에 정상 작동한 설정을 먼저 복원해 관련성을 확인하세요. 변수는 적을수록 원인을 찾기 쉽습니다.

시작 직후 앱이 비정상 종료되면 오류 기록을 보관하고 자동 재시작을 반복하지 마세요. 로그 확인과 설정 롤백 절차를 참고해 조치하세요. 실행은 되지만 특정 기능만 비정상이라면 이 가이드의 관련 장을 확인하면 됩니다. 조정을 마친 뒤 최종 설정과 각 항목의 용도를 저장해 두면 다음 구독 업데이트나 기기 이전에서도 같은 검증 절차를 따를 수 있습니다.