Clash 프록시 그룹·DNS
·TUN 고급 설정

프록시 그룹 종류와 활용

먼저 노드, 프록시 그룹, 규칙의 역할을 구분하세요. 노드는 실제 프록시 연결 방식을 나타내고, 프록시 그룹은 사용할 출구를 선택하며, 규칙은 연결을 특정 그룹으로 보냅니다. 규칙에 노드를 직접 많이 지정하면 처음에는 이해하기 쉬워도 관리가 어려워집니다. 노드 이름이 바뀔 때마다 규칙을 하나씩 수정해야 하기 때문입니다. 규칙은 용도가 안정적인 그룹을 가리키게 하고, 노드는 그룹 안에서 교체하는 편이 낫습니다. 설정의 이름 참조는 문자 하나까지 정확히 일치해야 합니다. 공백, 대소문자, 문장부호가 달라져도 참조가 끊길 수 있습니다.

수동 선택·속도 테스트·장애 조치 그룹

select는 수동 선택 그룹으로, 기본 출구나 서비스별 출구에 적합합니다. 그룹 안에는 노드뿐 아니라 다른 프록시 그룹도 넣을 수 있습니다. url-test는 지정한 주소를 주기적으로 테스트해 연결 가능 여부와 응답 시간을 확인하고, 결과에 따라 출구를 선택합니다. 조건이 비슷한 노드에 적합합니다. fallback은 후보 순서를 우선합니다. 앞쪽 출구가 사용 가능하면 이를 쓰고, 장애가 발생한 뒤에야 다음 출구로 넘어갑니다. 지연 시간에 따라 노드를 재정렬하지 않으므로 속도 테스트 그룹 대신이 아니라 명확한 주·예비 회선에 적합합니다.

load-balance는 설정한 분배 방식에 따라 서로 다른 연결을 여러 출구로 나눕니다. 하나의 다운로드 연결에 여러 회선의 속도를 합산하지는 않습니다. 로그인 상태나 고정 출구, 일관된 지역이 중요한 서비스에서는 출구가 자주 바뀌면 추가 인증이 발생할 수 있습니다. 먼저 수동 그룹으로 서비스 동작을 확인한 뒤 부하 분산 도입을 검토하세요. 노드 속도 테스트 결과는 테스트 주소에 대한 결과일 뿐이므로 동영상, 코드 저장소, 게임 연결도 반드시 빨라진다고 볼 수 없습니다. 실제 서비스 접속으로 한 번 더 확인하세요.

관찰하기 쉬운 2단 구조 만들기

아래 구성은 수동 선택과 자동 테스트를 분리합니다. ‘구독 노드’는 기존 proxy-providers에 이미 정의된 프로바이더여야 하며, 사용 가능한 노드가 하나 이상 포함되어야 합니다. 먼저 ‘수동 선택’을 자동 그룹에 연결하고, 접속 문제가 생기면 패널에서 구체적인 출구로 전환하세요. 같은 예제를 파일 끝에 반복해서 붙이지 마세요. 이미 proxy-groups가 있다면 같은 최상위 키를 유지하고 해당 목록에 항목을 추가해야 합니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - 구독 노드
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 수동 선택
    type: select
    proxies:
      - 자동 선택
      - DIRECT
    use:
      - 구독 노드

interval의 단위는 초이며 테스트 간격을 뜻합니다. tolerance의 단위는 밀리초이며 작은 변동으로 인한 전환을 줄입니다. lazy를 사용하면 그룹을 사용하지 않을 때 불필요한 테스트를 줄일 수 있지만, 실제 테스트는 프로바이더 상태 확인 설정의 영향도 받습니다. 그룹 테스트와 구독 상태 확인을 모두 지나치게 짧은 간격으로 설정하지 마세요. 특히 모바일 네트워크에서는 지속적인 테스트가 기기 깨우기와 데이터 사용량을 늘립니다. 먼저 실제로 더 짧은 간격이 필요한 장애인지 살펴보세요.

참조, 순환 구조, 연결 안정성 확인

프록시 그룹은 한 방향으로 중첩해야 합니다. 예를 들어 서비스 그룹이 기본 출구를 가리키고, 기본 출구가 자동 그룹을 가리키며, 자동 그룹이 노드를 가리키도록 구성합니다. 두 그룹이 서로를 참조하거나 여러 단계를 거쳐 자기 자신으로 돌아오게 해서는 안 됩니다. 오류가 난 그룹에서 참조를 따라가며 이름이 존재하는지, 프로바이더가 로드됐는지, 필터 조건이 모든 노드를 제외하지 않았는지 확인하세요. 빈 그룹은 상위 단계에서 노드가 필터링된 경우가 많습니다. 규칙 자체가 잘못된 것이 아니라면 규칙을 반복해서 수정해도 해결되지 않습니다.

정책을 전환해도 기존 연결은 즉시 이동하지 않을 수 있으며, 주로 이후에 만들어지는 연결에 영향을 줍니다. 확인할 때는 테스트 앱의 기존 연결을 끊고 요청을 다시 보내세요. 필요한 경우 해당 연결만 정리하면 되며 기기 전체를 재시작할 필요는 없습니다. 로그인 서비스는 속도 테스트 결과에 따라 출구가 계속 바뀌지 않도록 업무용 그룹에 고정하는 편이 좋습니다. 규칙 모드와 전역 전환의 차이는 세 가지 프록시 모드 설명을 함께 참고하세요. 전역 모드 전환만으로 프록시 그룹 설정이 올바르다고 판단할 수는 없습니다.

규칙 세트 구독 관리

규칙 세트는 자주 갱신되는 도메인이나 IP 대역 목록을 기본 설정에서 분리합니다. 기본 설정에는 판단 순서와 출구 이름을 두고, 규칙 파일에서 매칭 대상을 관리합니다. 업무 도메인이 바뀌어도 전체 프록시 그룹을 반복해서 수정할 필요가 없고, 업데이트에 따른 차이도 추적하기 쉽습니다. 규칙 프로바이더와 노드 프로바이더는 서로 다른 객체입니다. 전자는 매칭 조건을 제공할 뿐 연결 가능한 프록시 노드를 만들지 않습니다. 다운로드에 성공해도 기본 규칙 목록에서 해당 규칙을 참조하고 있다는 뜻은 아닙니다.

behavior와 파일 형식 선택

behavior: domain은 도메인 목록에 적합하며, 같은 종류의 사이트를 모아 관리할 수 있습니다. ipcidr은 IP 대역을 대상으로 하고, classical은 도메인 접미사, 키워드, IP 대역 등 기존 방식의 규칙 조건을 포함할 수 있습니다. 파일 확장자가 아니라 실제 내용에 맞춰 선택하세요. 파일의 항목 구조와 프로바이더의 format, behavior가 서로 맞아야 합니다. 규칙 유형 접두사가 붙은 내용을 일반 도메인 목록으로 읽으면 파싱 오류가 나거나 예상과 다른 항목이 매칭될 수 있습니다.

먼저 로컬 규칙 파일로 구조를 확인한 다음 원격 업데이트를 연결하면 문제를 더 쉽게 추적할 수 있습니다. 아래 ./rules/work.yaml은 커널 작업 디렉터리 기준 경로이며, 그래픽 클라이언트 설치 디렉터리와 같다고 보장할 수 없습니다. 클라이언트가 샌드박스 또는 서비스 모드로 실행된다면 클라이언트의 설정 디렉터리 진입점을 통해 경로를 확인하고 커널의 파일 읽기 권한도 점검하세요. 기본 규칙의 ‘수동 선택’은 앞 장의 그룹 이름을 사용합니다. 실제 설정에서 다른 이름을 쓴다면 여기서도 맞춰 바꿔야 합니다.

# 기본 설정에 추가할 부분
rule-providers:
  업무 사이트:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work.yaml

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - RULE-SET,업무 사이트,수동 선택
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,수동 선택

# rules/work.yaml 파일 내용
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,gitlab.com

규칙 순서를 먼저 정한 뒤 업데이트 설정하기

규칙은 일반적으로 위에서 아래로 평가되며, 조건에 맞으면 해당 연결의 선택이 끝납니다. 구체적인 예외 규칙을 포괄적인 규칙보다 앞에 두고, 기본 처리용 MATCH는 맨 마지막에 배치하세요. 그렇지 않으면 뒤에 있는 업무 규칙은 실행되지 않습니다. 같은 도메인이 두 규칙 세트에 모두 있어도 더 구체적인 규칙이 자동 선택되지는 않으며, 참조 순서에 따라 결정됩니다. 규칙을 조정하기 전에 연결 상세 정보에서 현재 매칭된 규칙, 그룹, 출구를 기록하세요. 한 번에 규칙 하나만 이동해 비교하고, 목록 전체를 바꾼 뒤 웹페이지가 열리는지만 확인하지 마세요.

원격 프로바이더로 전환할 때는 유형을 http로 지정하고 소스 url, 로컬 캐시 path, 업데이트 간격 interval을 설정합니다. 소스는 내용과 관리 방식을 확인한 규칙 주소여야 합니다. 이 페이지에서는 임의의 온라인 목록을 신뢰할 수 있는 규칙으로 간주하지 않습니다. 프로바이더마다 캐시 경로를 다르게 지정하세요. 같은 경로를 공유하면 업데이트 결과가 서로 덮어쓸 수 있습니다. 소스 파일의 변경 빈도에 맞춰 간격을 정하세요. 보통 시간이나 일 단위가 반복 다운로드보다 적절하며, 문제를 점검할 때 직접 업데이트하면 됩니다.

원격 다운로드에는 시작 단계의 의존성 문제도 있습니다. 규칙 파일을 받으려면 프록시가 필요한데 프록시 선택이 해당 규칙 세트에 의존하면, 최초 시작 시 순환이 생길 수 있습니다. 다운로드에 사용할 수 있는 출구를 명시하거나 규칙 캐시를 미리 저장한 뒤, 캐시가 없는 상태에서도 시작이 완료되는지 확인하세요. ‘설정이 로드됨’을 프로바이더 상태 확인으로 대신하지 마세요. 기본 설정 로드가 성공해도 원격 규칙 요청이 진행 중이거나 이전 캐시를 계속 사용할 수 있으므로 프로바이더 업데이트 시각과 오류 메시지도 확인해야 합니다.

IP 규칙과 규칙 대체 처리

no-resolve는 IP 조건을 매칭하기 위해 도메인 조회를 새로 시작하지 않으려는 경우에 사용합니다. 모든 트래픽이 DNS를 건너뛰게 하는 옵션은 아닙니다. 연결에 대상 IP가 이미 있으면 IP 규칙이 매칭될 수 있지만, 도메인만 알고 IP가 없다면 이 옵션이 붙은 규칙을 건너뛸 수 있습니다. 넓은 범위의 규칙에 추가하기 전에 이후에 어떤 규칙이 연결을 처리할지 확인하세요. 사내망, 사설 IP, 자체 호스팅 서비스에는 명확한 직접 연결 규칙을 마련해야 합니다. 마지막 프록시 기본 규칙에만 의존하지 마세요.

규칙 업데이트 후 일부 연결에 문제가 생기면 먼저 업데이트를 중지하고 이전 규칙 파일로 복원한 뒤 구체적인 추가·삭제 항목을 비교하세요. 도메인이 더 앞선 규칙에 추가됐는지, IP 대역이 확대됐는지, 기본 출구가 바뀌었는지 확인합니다. 파일을 불러올 수 있지만 규칙이 매칭되지 않는다면 연결에 도메인 정보가 남아 있는지, 스니핑이 작동하는지, 앱이 커널 경로를 우회하는지 확인하세요. 규칙 모드에서 흔히 겪는 문제는 자주 묻는 질문을 참고하세요. 전체 설정을 다시 쓰기보다 문제를 재현할 수 있는 최소 규칙을 보존하는 것이 좋습니다.

DNS 설정 최적화

DNS 문제를 해결하려면 먼저 조회 경로를 그려 보세요. 앱이 누구에게 쿼리를 보내는지, 쿼리가 커널에 들어오는지, 커널이 어떤 상위 DNS 서버에 요청하는지, 그 요청이 어떤 출구를 거치는지 확인합니다. 브라우저에서 웹페이지가 열린다고 해서 시스템 DNS, 앱의 암호화 DNS, 커널 DNS가 모두 같은 경로를 쓴다는 뜻은 아닙니다. 특히 TUN을 사용하면 이전에 공유기가 처리하던 조회를 클라이언트가 맡을 수 있습니다. 강제 DNS 도구를 여러 개 함께 사용하면 관찰한 결과를 해석하기 더 어려워집니다.

수신 주소, 상위 DNS, 부트스트랩 조회 구분하기

listen은 커널이 DNS 쿼리를 받는 주소이며 상위 DNS 서버 주소가 아닙니다. 루프백 주소에 바인딩하면 로컬 기기에서 사용할 수 있고, LAN 주소에 바인딩하면 방화벽과 접근 범위를 추가로 고려해야 합니다. nameserver는 일반 조회에 사용할 상위 DNS를 지정합니다. default-nameserver는 상위 DNS 서버의 도메인을 조회할 때 사용합니다. DNS 서버에 요청하려면 먼저 그 서버의 주소를 알아야 하는 문제를 해결합니다. 부트스트랩에 숫자 IP 주소를 사용하면 이 순환을 줄일 수 있지만 현재 네트워크에서 해당 서버에 접속할 수 있는지 확인해야 합니다.

아래는 점검을 시작하기 위한 예제입니다. 권한이 필요 없는 로컬 포트에서 수신하고 암호화된 상위 DNS를 사용하며, 명확한 도메인 접미사 하나에 별도 해석기를 지정합니다. 이 설정만으로 시스템 DNS가 자동 변경되거나 모든 앱의 쿼리가 처리되는 것은 아닙니다. 설정을 병합한 뒤 클라이언트의 DNS 처리 옵션이나 다음 장의 TUN 설정을 통해 쿼리를 전달해야 합니다. 클라이언트가 이미 수신 포트를 관리한다면 같은 포트를 무작정 지정하지 마세요. 주소 충돌이 나거나 서로 충돌하는 설정이 두 벌 생성될 수 있습니다.

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
  nameserver-policy:
    "+.example.org":
      - 223.5.5.5

상위 DNS를 늘어놓기보다 도메인별 해석기 지정하기

nameserver-policy는 기업 내부망, 자체 도메인, 특정 DNS 경로가 필요한 서비스에 적합합니다. 기업 도메인은 내부 레코드에 응답할 수 있는 DNS 서버를 지정해야 합니다. 내부 조회를 공용 DNS로 보내면 보통 도메인을 찾지 못하거나 잘못된 주소를 받습니다. 예제의 example.org는 접미사 매칭 문법을 보여 주기 위한 것으로, 특별 분기가 필요한 실제 서비스 도메인이 아닙니다. 실제 적용 전 대상 도메인과 DNS 서버의 관계를 확인한 뒤 소유하거나 사용 권한이 있는 도메인으로 바꾸세요.

상위 DNS를 많이 추가한다고 조회가 더 안정적인 것은 아닙니다. 상위 DNS마다 지역별 콘텐츠 전송 주소를 다르게 반환하거나 캐시 정책이 다를 수 있어 여러 결과를 섞으면 접속 상태가 달라질 수 있습니다. fallback을 사용할 경우 필터 조건과 대체가 시작되는 방식을 함께 이해해야 합니다. 주 DNS가 시간 초과될 때 쓰는 단순한 예비 목록으로 보면 안 됩니다. 관찰하기 쉬운 경로 하나부터 시작해 조회 시간, 반환 주소, 서비스 접속 결과를 기록하고 문제가 DNS 계층에 있음을 확인한 뒤 정책을 추가하세요.

DNS 요청이 라우팅 규칙을 따르도록 설정할 때는 respect-rules로 경로를 제어할 수 있습니다. 다만 프록시 서버 도메인의 조회 경로도 proxy-server-nameserver 등을 사용해 명확히 정해야 합니다. 그렇지 않으면 프록시 주소를 조회하려면 프록시에 먼저 연결해야 하고, 프록시에 연결하려면 주소부터 조회해야 하는 순환이 발생할 수 있습니다. 기능 지원 범위는 커널 문서와 실행 로그를 기준으로 확인하세요. 그래픽 클라이언트의 DNS 설정이 추가 설정을 생성할 수 있으므로 편집기에 표시된 일부 내용만 보지 마세요.

캐시, IPv6, 앱 내장 DNS 확인

테스트는 세 단계로 진행하세요. 먼저 커널의 수신 포트에 직접 쿼리하고, 다음으로 시스템 기본 DNS를 테스트한 뒤, 마지막으로 실제 앱에서 접속합니다. 서버와 포트를 지정할 수 있는 도구를 사용해 dig @127.0.0.1 -p 1053 example.org를 실행할 수 있습니다. 첫 단계는 정상인데 두 번째 단계에서 문제가 생기면 시스템 설정과 쿼리 전달 경로를 확인하세요. 앞의 두 단계가 정상인데 브라우저만 다르면 브라우저의 보안 DNS, 앱 내 프록시, 기존 캐시를 확인합니다. 설정을 바꾼 뒤에는 기존 연결이 변화를 가리지 않도록 새 연결을 만들어 테스트하는 것이 좋습니다.

커널 DNS의 IPv6 응답을 끄더라도 운영체제의 IPv6 통신까지 완전히 중단되는 것은 아닙니다. 앱이 캐시, 다른 DNS, 직접 연결을 통해 IPv6 주소를 사용할 수 있습니다. 반대로 IPv6를 켠다면 AAAA 레코드 반환 여부만 확인하지 말고 로컬 라우팅, 프록시 출구, 대상 서비스가 모두 해당 경로를 지원하는지 확인하세요. 일부 네트워크에서만 문제가 생긴다면 전체 DNS 설정을 반복해서 전환하기보다 주소 계열별로 테스트하는 편이 효과적입니다. 시스템 네트워크 값을 바꾸기 전에 원래 값을 기록해 복원할 수 있게 하세요.

DNS 설정을 바꾼 뒤 간헐적인 문제가 생기면 캐시를 지우기 전에 상위 DNS에 도달할 수 있는지, 수신 포트가 충돌하는지, 쿼리가 실제로 커널에 들어오는지 확인하세요. 캐시는 정상적인 기능입니다. 자주 비우면 반복 요청이 늘고 시작 단계의 의존성 문제를 가릴 수 있습니다. 공용 네트워크, 기업 네트워크, 가정용 공유기는 DNS 프로토콜을 서로 다르게 제한할 수 있으므로 각 네트워크에서 따로 검증해야 합니다. 한 번 조회에 성공했다고 모든 환경에서 해결됐다고 단정하거나 특정 상위 DNS 주소를 영구적인 정답으로 취급하지 마세요.

TUN과 Fake-IP

TUN은 가상 네트워크 인터페이스로 라우팅 조건에 맞는 트래픽을 받아 시스템 프록시를 따르지 않는 일부 앱을 처리합니다. Fake-IP는 도메인을 가상 IP에 매핑해 이후 연결에서 커널이 도메인 정보를 복원할 수 있게 합니다. 두 기능은 함께 쓰이는 경우가 많지만 같은 기능은 아닙니다. 시스템 프록시가 작동한다고 TUN 권한과 라우팅도 올바르다는 뜻은 아니며, 가상 IP가 보인다고 연결이 원격 프록시로 전송됐다는 뜻도 아닙니다. 트래픽 유입, 도메인 매핑, 규칙 매칭, 최종 출구를 각각 확인하세요.

유입, 라우팅, DNS 순서로 활성화하기

먼저 현재 시스템 프록시 모드에서 구독과 노드가 정상 작동하는지 확인하세요. 라우팅을 변경하는 다른 도구를 끈 뒤 마지막으로 TUN을 활성화합니다. 데스크톱 클라이언트는 서비스 설치, 관리자 권한, 시스템 네트워크 확장이 필요할 수 있고, 모바일은 보통 시스템 VPN 인터페이스로 트래픽을 처리합니다. 플랫폼마다 작동 방식이 다르므로 데스크톱 권한 설정을 그대로 따라 하지 마세요. 처음 설정할 때는 다운로드 페이지에서 우선 추천하는 Clash Plus를 선택하고 시스템 안내에 따라 권한을 허용한 뒤, 클라이언트가 해당 필드를 지원하는 커널을 실제로 사용 중인지 확인하세요.

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는 외부 인터페이스를 식별해 프록시 자체 연결이 다시 TUN으로 들어가는 것을 방지하는 데 도움을 줍니다. stack은 네트워크 스택 구현을 정합니다. 사용할 수 있는 값과 적합한 환경은 시스템 지원 여부에 따라 달라지므로 특정 값이 모든 기기에 최선이라고 볼 수 없습니다. 예제에서는 점검 시작점으로 mixed를 사용합니다. 시작 로그에 미지원 오류가 나오면 DNS와 규칙을 동시에 바꾸지 말고 클라이언트 문서에 따라 선택하세요.

가상 IP와 DNS 하이재킹 범위 이해하기

Fake-IP가 반환하는 주소는 로컬 매핑에 사용하는 가상 IP이지 대상 웹사이트의 실제 공인 IP가 아닙니다. 따라서 ‘조회 결과가 이상해 보인다’는 이유만으로 설정 실패라고 판단할 수 없습니다. 접속이 완료되는지, 연결 상세 정보에서 도메인을 복원할 수 있는지 확인하세요. 실제 IP가 필요한 LAN 검색, 일부 네트워크 기기, 특수 앱의 도메인은 fake-ip-filter에 추가해 실제 주소로 조회할 수 있습니다. 필터는 조회 결과의 형태만 바꾸며 자동으로 직접 연결되게 하지는 않습니다. 직접 연결이 필요하면 해당 라우팅 규칙도 설정해야 합니다.

dns-hijack의 any:53은 TUN으로 들어오고 조건에 맞는 기존 DNS 요청을 대상으로 합니다. 모든 DNS가 가로채진다고 볼 수는 없습니다. 앱 내 HTTPS 암호화 DNS는 보통 다른 포트를 사용하므로 이 설정만으로 감지할 수 없습니다. 앱이 커널을 거치지 않고 DNS를 조회하면 커널에는 대상 IP만 보일 수 있으며, 이때 도메인 규칙 매칭 여부는 스니핑 같은 조건에 달려 있습니다. 설정을 바꾸기 전에 조회 프로토콜과 실제 유입 경로를 확인해 앱 설정을 조정하세요. 넓은 라우팅 규칙으로 DNS 경로 차이를 덮지 마세요.

내부망 접속과 남은 라우트 점검

활성화한 뒤 공용 인터넷에 먼저 접속하고, 공유기 관리 페이지, 프린터, 회사 내부망도 테스트하세요. 내부망에서만 문제가 생기면 노드를 바로 바꾸지 말고 직접 연결 규칙과 라우트 제외 범위를 확인합니다. 기업 VPN은 전용 IP 대역과 DNS를 전달할 수 있으므로 TUN 자동 라우팅과 함께 실행할 때 각 주소를 어느 쪽이 처리할지 명확히 해야 합니다. 제외 대역은 필요한 범위만 정확히 지정하세요. 주소 대역을 지나치게 크게 제외하면 프록시가 필요한 연결까지 커널을 우회해 일부 서비스는 복구되더라도 새로운 분기 오류가 생깁니다.

모든 연결이 실패하면 먼저 TUN을 끄고 시스템 프록시로 테스트를 복원하세요. 시스템 프록시에서는 정상이라면 노드에 문제가 없을 수 있습니다. TUN 초기화 로그, 기본 출구 인식, 라우트 설치를 중점적으로 확인하세요. 클라이언트를 정상 종료하면 보통 클라이언트가 만든 상태를 정리합니다. 비정상 종료 후에도 네트워크가 복구되지 않으면 클라이언트의 복구 메뉴에서 서비스와 라우트를 확인한 다음 필요한 경우 네트워크를 재시작하세요. 시스템 라우팅 테이블을 이해하지 못한 상태에서 항목을 일괄 삭제하지 마세요. 특히 기업 네트워크가 전달한 라우트는 삭제하면 안 됩니다.

Fake-IP 매핑과 앱 DNS 캐시에는 유효 기간이 있습니다. 커널을 재시작한 뒤 앱이 이전 가상 IP를 계속 사용하면 일시적인 연결 실패가 생길 수 있습니다. 먼저 앱이 DNS를 다시 조회하게 한 뒤 관련 캐시를 지울지 판단하세요. 상시 실행 여부와 모바일 백그라운드 정책도 영향을 줍니다. 자세한 내용은 모바일 백그라운드 배터리 사용량과 연결 유지를 참고하세요. 검증이 끝나면 정상 상태의 인터페이스, 라우트, DNS 설정을 기록해 두세요. 다음 네트워크 전환 때 처음부터 추측하지 않고 차이를 비교할 수 있습니다.

도메인 스니핑

도메인 규칙을 적용하려면 커널이 연결과 도메인의 관계를 알아야 합니다. 일반 프록시 입구에서 시작한 요청에는 도메인 정보가 포함된 경우가 많지만, TUN으로 들어온 연결에는 대상 IP만 있을 수 있습니다. 앱 자체 DNS, 캐시, IP 직접 연결을 사용할 때 특히 그렇습니다. 도메인 스니핑은 HTTP 호스트 필드나 TLS 핸드셰이크의 서버 이름처럼 연결 초기에 보이는 프로토콜 정보에서 도메인을 보완하려고 시도합니다. DNS를 대체하거나 모든 앱 콘텐츠를 복호화하는 기능은 아닙니다.

도메인 정보가 없을 때만 스니핑 활성화

문제를 점검할 때 연결 상세 정보를 먼저 확인하세요. 대상 항목에 도메인이 표시되고 규칙도 매칭된다면 ‘설정을 완전하게 만들기’ 위해 강제 옵션을 더 켤 필요는 없습니다. IP만 표시되면 DNS가 커널로 들어오는지, Fake-IP 매핑이 남아 있는지 확인한 뒤 스니핑을 검토하세요. 스니핑을 켜면 규칙 매칭 기준이 달라질 수 있으며, 이전에는 IP로 분기되던 연결에 도메인 조건이 추가됩니다. 적용 전에 명확한 서비스 몇 개를 골라 비교하고, 활성화 전후의 규칙과 출구 변화를 기록하세요.

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

sniff는 인식할 프로토콜과 포트를 지정하며 방화벽 포트를 여는 설정이 아닙니다. 실제로 필요한 범위만 지정하면 어떤 연결이 처리되는지 이해하기 쉽습니다. force-dns-mapping은 특정 DNS 매핑 상황에서 스니핑 기회를 넓히지만 모든 DNS 요청을 커널로 보내지는 않습니다. parse-pure-ip는 대상이 IP 주소인 트래픽과 관련됩니다. 예제에서는 후자를 끈 상태로 두어 명확한 주소 연결까지 넓은 도메인 추정 대상에 포함되지 않도록 합니다.

도메인 매칭과 대상 주소 변경 구분하기

override-destination은 스니핑으로 얻은 도메인을 연결 대상으로 바꿀지 여부와 관련됩니다. 비활성 상태로 두면 대상 연결 방식을 바꾸지 않고도 스니핑이 라우팅 판단 정보를 보완하는지 확인할 수 있습니다. 일부 서비스는 핸드셰이크의 이름을 실제 대상으로 바꿔 쓰기에 적합하지 않습니다. 자체 호스팅 입구, 공유 IP, 특수 포워딩 환경에서 특히 주의해야 합니다. 활성화 후 인증서 오류, 연결 재설정, 특정 앱 실패가 발생하면 대상 변경을 별도 변수로 점검하세요. 노드를 사용할 수 없다고 바로 결론 내리지 마세요.

스니핑에 적합하지 않은 도메인은 skip-domain에 명확한 예외로 추가할 수 있습니다. 다만 온라인에서 복사한 긴 일반 목록을 넣기보다 실제 장애 증거에 따라 예외를 정하세요. 예외를 추가하기 전에 여러 번 재현해 연결에 표시된 도메인, 실제 IP, 매칭 규칙을 기록하세요. 스니핑을 꺼야 문제가 해결된다면 프로토콜 인식, 대상 변경, 규칙 순서 중 무엇이 원인인지 더 확인해야 합니다. 이 관계를 파악해야 나중에 예외 범위를 계속 넓히지 않고도 안정적으로 관리할 수 있습니다.

암호화 프로토콜의 한계 이해하기

TLS 스니핑은 핸드셰이크에서 보이는 정보에 의존하므로 암호화된 클라이언트 인사말 같은 기능을 사용하면 실제 서비스 도메인을 알아내지 못할 수 있습니다. QUIC 인식도 프로토콜, 구현, 패킷 가시성에 따라 달라집니다. 프로토콜 이름을 설정했다고 모든 연결을 식별할 수 있는 것은 아닙니다. 도메인을 복원할 수 없는 트래픽에는 적절한 IP 규칙이나 기본 처리 정책을 마련하세요. 포트 범위를 끝없이 넓히지 마세요. 서비스 자체에서 앱 프록시 설정을 제공한다면 도메인을 포함하는 프록시 입구로 연결하는 편이 스니핑을 더 추가하는 것보다 명확할 수 있습니다.

스니핑 결과를 앱 사용자 인증으로 간주해서는 안 됩니다. 연결에 포함된 호스트 정보는 현재 프로토콜 맥락에서 얻은 단서일 뿐, 요청한 사용자를 증명하지 않으며 여러 테넌트 간 보안 경계 역할도 할 수 없습니다. 공유 출구, 내부망 권한, 접근 제어에는 별도의 네트워크 및 인증 체계를 사용해야 합니다. 목적지 주소를 엄격히 제한해야 하는 업무 환경에서는 관리자가 검증 가능한 규칙을 정해야 합니다. 도메인 스니핑만으로 연결 허용 여부를 판단하거나 관찰된 도메인을 접근 권한으로 간주해서는 안 됩니다.

검증할 때는 세 종류의 사례를 함께 유지하는 것이 좋습니다. 커널 DNS를 정상적으로 거치는 웹페이지, 별도 DNS를 사용하는 앱, IP 주소로 직접 연결하는 서비스입니다. 각 사례에서 접속 가능 여부뿐 아니라 대상 정보, 매칭 규칙, 최종 출구를 확인하세요. 스니핑을 켠 뒤에만 지연이 발생하면 프로토콜 범위를 하나만 남겨 테스트한 뒤 항목별로 다시 추가합니다. 문제를 찾는 데 필요한 수준까지만 로그를 자세히 설정하고, 점검 후에는 평소 수준으로 되돌리세요. 연결 정보가 포함된 로그를 계속 기록하거나 공개 공유하지 마세요.

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

원격 구독은 주기적으로 갱신되므로 다운로드한 설정을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 로컬 오버라이드는 포트, DNS, 규칙, 정책 설정을 별도 계층에서 관리해 상위 구독이 노드를 계속 업데이트할 수 있게 합니다. 클라이언트마다 오버라이드, 병합, 확장 설정, 스크립트 처리 등으로 부르지만 내부 동작은 같지 않습니다. 시작하기 전에 어느 계층을 변경하는지 확인하세요. 원본 구독, 클라이언트에 저장된 설정, 커널에 전달되는 최종 실행 설정은 서로 다를 수 있습니다.

병합 순서와 목록 처리 방식부터 기록하기

예를 들어 마지막에 기록한 mode가 이전 값을 덮어쓰는 것처럼 스칼라 필드는 이해하기 쉽습니다. 하지만 목록 필드는 뒤에 추가되거나 앞에 삽입되거나 전체가 교체될 수 있고, 객체 필드도 얕은 병합이나 재귀 병합 방식이 다를 수 있습니다. 두 클라이언트가 모두 ‘병합’이라고 부른다고 결과도 같다고 가정하지 마세요. 로컬 복사본에서 연결에 영향을 주지 않는 필드 하나만 변경하고 최종 설정을 미리 확인한 뒤 DNS나 규칙을 추가하세요. 미리보기 기능이 없다면 실행 설정 내보내기나 시작 로그를 확인하되 공유 전에 구독 주소와 노드 인증 정보를 삭제해야 합니다.

특히 rules 처리 방식을 확인하세요. 오버라이드가 사용자 지정 규칙을 기존 MATCH 뒤에 추가하면 해당 규칙은 실행되지 않을 수 있습니다. 목록 전체를 교체하면 기존 내부망 및 업무 예외가 사라질 수 있습니다. 프록시 그룹 목록도 마찬가지입니다. 그룹을 전부 덮어쓰면 상위 규칙에서 참조하는 이름이 유효하지 않게 됩니다. 관리할 때 유지해야 할 그룹 이름을 정리하고 사용자 지정 규칙을 삽입할 위치를 명확히 하세요. YAML 최상위 키를 중복해 병합을 흉내 내지 마세요. 파서마다 중복 키 처리 방식이 달라 신뢰하기 어렵습니다.

프로바이더로 다중 구독 분리 관리

여러 구독을 완성된 설정 파일째로 이어 붙일 필요는 없습니다. 각 소스를 독립 노드 프로바이더로 두고, 전체 설정에서 프록시 그룹, 규칙, DNS를 한곳에 정의하면 관리하기 쉽습니다. 아래 예제는 로컬 노드 파일 두 개로 구조를 보여 줍니다. 각 파일에는 유효한 proxies 목록이 있어야 하며 임의의 완성된 클라이언트 설정을 넣는 것이 아닙니다. 파일 경로는 작업 디렉터리 기준입니다. 프로바이더 상태 확인을 이미 사용 중이라면 필요에 따라 설정을 조정해 그룹 테스트와 너무 잦은 요청이 겹치지 않게 하세요.

proxy-providers:
  회선 A:
    type: file
    path: ./providers/a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900
  회선 B:
    type: file
    path: ./providers/b.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

proxy-groups:
  - name: 다중 구독 출구
    type: select
    use:
      - 회선 A
      - 회선 B

원격 프로바이더로 전환하려면 유효하며 사용 권한이 있는 구독 소스를 사용하고, 캐시 경로와 업데이트 간격을 각각 지정하세요. 구독 주소에는 접속 인증 정보가 들어 있는 경우가 많으므로 공개 저장소, 스크린샷, 문의 게시물에 올리지 마세요. 상위 소스에서 받은 내용의 형식도 확인해야 합니다. 완성된 설정을 가져오는 주소가 프로바이더 파일로 바로 읽힐 수 있는 것은 아닙니다. 노드 목록이 없다는 오류가 나면 각 노드의 프로토콜 필드를 급히 바꾸기보다 응답 내용과 유형부터 확인하세요. 오류는 최상위 데이터 구조에서 발생했을 수 있습니다.

서로 다른 소스에 같은 노드 이름이 있으면 패널에서 선택하거나 로그를 추적하기 어려워지고 이름 충돌이 날 수도 있습니다. 클라이언트나 커널에서 지원하는 접두사·접미사 기능을 사용해 소스마다 안정적인 식별자를 부여하세요. 변환 스크립트를 쓴다면 복사본에서 먼저 실행하고 결과를 확인합니다. 필터 조건에도 소스 구분을 반영해야 합니다. 지역 키워드에만 의존하면 상위 소스에서 이름을 바꾼 뒤 그룹이 갑자기 비게 될 수 있습니다. 병합한 뒤 소스 하나씩 비활성화해 나머지 소스만으로 필요한 대체 경로가 작동하는지 확인하세요.

편집기 화면이 아니라 실행 설정으로 검증하기

설정을 바꿀 때마다 유효성을 검사하고 다시 불러온 뒤 로그를 확인하세요. 기기에서 Mihomo 실행 파일을 직접 사용할 수 있다면 올바른 작업 디렉터리에서 아래 명령을 실행할 수 있습니다. 이 명령은 파일 구조와 참조 등을 확인할 뿐, 원격 노드나 규칙 소스에 반드시 접속할 수 있다는 뜻은 아닙니다. 그래픽 클라이언트 사용자는 내장 검사 기능을 이용하면 되며 커널 프로세스를 하나 더 실행할 필요가 없습니다. 프로세스 두 개가 동시에 실행되면 포트와 라우트를 놓고 경쟁해 원래 없던 문제가 생길 수 있습니다.

mihomo -t -f ./config.yaml

복구 기록에는 원본 설정, 로컬 오버라이드, 민감 정보를 제거한 변경 내역을 최소한 보관하세요. 노드 인증 정보는 접근이 통제된 위치에만 저장하고 문제 해결 자료와 함께 공유하지 마세요. 구독을 새로 고친 뒤에는 최종 규칙 순서, 프로바이더 상태, 그룹 내 노드 수를 다시 확인해야 합니다. 특히 상위 소스가 그룹 이름이나 기본 모드를 바꾼 경우 주의하세요. 최초 설치 설정 순서는 초기 설정 체크리스트를 참고하세요. 설정이 안정되면 자동 변경 계층을 가능한 한 줄이고, 한 가지 요구 사항은 한 계층에서만 관리해야 문제를 쉽게 추적할 수 있습니다.

외부 컨트롤 패널

외부 컨트롤 패널은 커널 제어 인터페이스를 통해 상태를 읽고, 정책을 전환하고, 연결을 확인하며, 프로바이더를 관리합니다. 프록시 입구가 아니므로 패널 연결에 성공했다고 앱이 자동으로 프록시를 사용하는 것은 아닙니다. 앱이 사용하는 프록시 포트, DNS 수신 포트, 패널이 연결하는 제어 주소를 구분하세요. 패널은 열리는데 연결 목록이 보이지 않는다면 트래픽을 처리하는 커널에 연결되어 있는지 확인하세요. 남아 있는 서비스, 다른 설정, 같은 기기에서 실행 중인 두 번째 인스턴스에 연결했을 수도 있습니다.

기본값은 로컬에서만 수신

external-controller는 제어 인터페이스의 수신 주소를 지정합니다. 개인용 데스크톱에서는 루프백 주소에 바인딩해 제어 인터페이스가 로컬에서만 접근되도록 하는 것이 좋습니다. external-ui는 로컬 패널 정적 파일 디렉터리를 가리키며 해당 디렉터리가 실제로 존재하고 커널 작업 디렉터리와의 관계가 명확해야 합니다. 아래 설정은 로컬 수신과 정적 디렉터리만 보여 주며 접근 인증 정보는 포함하지 않습니다. 클라이언트가 제어 주소와 암호를 자동으로 생성한다면 클라이언트의 관리 방식을 그대로 사용하세요. 오버라이드에서 기존 인증 설정을 함부로 지우지 마세요.

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

패널 인증에는 secret 등 관련 설정이 사용됩니다. 실제 배포에서는 직접 생성해 안전하게 보관하는 강력한 비밀번호를 사용하세요. 공유 가능한 패널 링크, 스크린샷, 공개 설정 파일에 비밀번호를 넣지 마세요. 로컬에만 바인딩해도 인증을 생략할 수 있는 것은 아닙니다. 로컬의 다른 프로그램과 브라우저를 통한 네트워크 접근도 고려해야 합니다. 웹페이지 기반 패널은 브라우저의 교차 출처 요청, 혼합 콘텐츠, 로컬 네트워크 접근 제한에도 영향을 받습니다. 페이지가 열려도 제어 인터페이스에 연결할 수 있다는 뜻은 아닙니다.

네트워크·인증·인스턴스 순서로 문제 해결

연결에 실패하면 먼저 커널이 실행 중인지, 수신 포트가 충돌하지 않는지 확인한 다음 패널에 입력한 프로토콜, 주소, 포트를 확인하세요. 연결 거부는 주로 수신 설정이나 방화벽 문제를 나타냅니다. 인증되지 않음 응답이 오면 인증 설정을 확인하세요. 상태는 읽을 수 있지만 프록시 그룹이 다르다면 다른 인스턴스에 연결됐을 가능성이 큽니다. 빨리 연결하려고 주소를 모든 인터페이스로 바꾸거나 인증을 끈 채 계속 사용하지 마세요. 로컬에서 최소한의 연결 경로를 만든 뒤 접근 범위를 단계적으로 넓히세요.

다른 기기에서 관리해야 한다면 수신 설정을 바꾸기 전에 접근이 통제된 터널이나 기존 관리 네트워크를 우선 사용하세요. 0.0.0.0에 직접 바인딩하면 여러 네트워크에서 인터페이스에 접근할 수 있으며 실제 노출 범위는 방화벽, 라우팅, 포트 포워딩에 따라 달라집니다. 제어 인터페이스는 출구 전환과 연결 확인 같은 관리 기능을 제공하므로 공용 인터넷에 직접 노출하지 마세요. 리버스 프록시가 꼭 필요하다면 전송 암호화, 접근 제어, 인증을 함께 설정하고 브라우저의 교차 출처 제한도 이해해야 합니다. 포워딩 규칙 하나만 추가해서 끝내면 안 됩니다.

연결 상세 정보부터 확인한 뒤 조치하기

연결 상세 정보는 유입 경로, 대상, 매칭 규칙, 정책 체인, 실제 노드 순서로 읽으세요. 유입 경로로 시스템 프록시와 TUN 중 어디서 트래픽이 들어왔는지 판단하고, 대상 정보로 도메인이 유지됐는지 확인합니다. 규칙은 어떤 그룹이 선택된 이유를 알려 주며 정책 체인은 그룹이 어떤 노드를 선택했는지 보여 줍니다. ‘수동 선택’이 표시돼도 최종 출구를 확인한 것은 아닙니다. 체인을 따라가며 확인하세요. 웹페이지 하나가 여러 연결을 만들 수 있으므로 대상 도메인별로 주요 요청과 리소스 요청을 구분해야 합니다. 연결 하나만 보고 페이지 전체의 경로를 판단하지 마세요.

패널의 전환과 다시 불러오기 작업도 영향이 다릅니다. 정책 전환은 주로 이후의 선택을 바꾸고, 설정을 다시 불러오면 규칙과 그룹 구조가 업데이트될 수 있으며, 연결을 닫으면 기존 세션이 끊깁니다. 문제를 해결할 때 먼저 현재 상태를 기록하고 대상 연결만 처리하세요. 파일 전송, 원격 터미널, 업무 회의까지 함께 끊지 않도록 주의합니다. 규칙 프로바이더 업데이트 실패는 다운로드 및 파싱 로그를 확인하고, 노드를 사용할 수 없으면 출구를 점검하세요. 로컬 앱이 연결 목록에 나타나지 않는다면 패널에서 속도 테스트를 반복하지 말고 트래픽 유입 계층을 확인하세요.

일상적인 관리는 짧은 절차로 반복할 수 있습니다. 현재 설정을 저장하고 한 가지 주제만 수정한 뒤 문법을 확인하고, 다시 불러온 다음 로그를 살펴보고, 지정한 앱에서 재접속해 검증하세요. 다른 네트워크에서 테스트할 때는 DNS와 기본 인터페이스도 확인하고, 다중 구독을 업데이트한 뒤에는 참조와 캐시를 점검합니다. LAN 프록시 공유와 제어 인터페이스 공개는 별개의 기능입니다. 다른 기기에서 프록시를 사용하려면 mixed-port와 allow-lan 설정 안내를 참고하고 제어 포트를 휴대폰 프록시 설정에 입력하지 마세요. 문제를 계속 찾기 어렵다면 민감 정보를 제거한 최소 설정과 재현 절차를 준비해 문제 해결 FAQ를 참고하세요.