Clash 고급 설정 가이드

설정 파일과 적용 순서

구독 파일, 생성된 설정, 실행 상태 구분하기

Clash 클라이언트는 보통 세 가지를 함께 관리합니다. 원격에서 내려받은 구독 파일, 클라이언트가 가공한 최종 설정, 그리고 커널에 로드된 실행 상태입니다. 구독 파일의 복사본을 수정해도 화면에 변화가 없다면 매개변수가 잘못된 것이 아니라 클라이언트가 다른 생성 파일을 사용 중일 수 있습니다. 변경하기 전에 현재 활성화된 설정 이름과 커널 유형, 최종 설정 미리보기 위치를 확인하고 기존 모드, 포트, 프록시 그룹 선택을 기록해 두세요.

구독에는 노드, 프록시 그룹, 규칙, DNS가 모두 들어 있을 수도 있고 노드 목록만 제공될 수도 있습니다. 클라이언트가 시스템 프록시, TUN, 오버라이드 설정에 따라 항목을 추가할 수도 있으므로 디스크의 원본 YAML이 최종 적용 결과와 같지는 않습니다. 원격 콘텐츠는 입력, 로컬 오버라이드는 변환 과정, 실행 설정은 점검 대상으로 보면 됩니다. 차이가 생기면 이 경로를 따라 각 단계를 비교하세요. 세 위치를 동시에 수정하면 다음 구독 업데이트 후 어느 단계에서 변경 사항이 유지됐는지 파악하기 어렵습니다.

최소 설정으로 기본 동작 확인하기

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

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,수동 선택

이 최소 예제는 설정 구조를 이해하기 위한 것입니다. 혼합 포트는 HTTP와 SOCKS 프록시 요청을 모두 받고, 규칙 모드는 규칙 목록에 따라 연결을 처리하며, 마지막 기본 규칙은 수동 선택 그룹으로 보냅니다. 프록시 노드를 추가하지 않았고 그룹에는 직접 연결만 있으므로 프록시 출구가 자동으로 생기지는 않습니다. 실제로 사용할 때는 유효한 노드나 프록시 목록을 유지하고 프록시 그룹에 연결하세요. 예제를 적용하려고 구독에 포함된 인증 필드, 전송 계층 설정, 서버 필수 매개변수를 삭제하지 마세요.

YAML은 탭이 아닌 공백으로 들여씁니다. 같은 단계의 목록 항목은 들여쓰기를 맞추고, 특수 문자가 들어간 이름과 비밀번호는 따옴표로 감싸는 것이 좋습니다. 최상위 dns, rules, proxy-groups를 한 문서에 중복 정의하면 안 됩니다. 중복 키는 파서가 거부하거나 뒤에 나온 값으로 덮어쓸 수 있습니다. 코드를 복사한 뒤 들여쓰기와 이름 참조를 확인하세요. YAML 파싱에 성공해도 프록시 그룹 참조와 규칙 의미가 올바르다는 보장은 없습니다.

문법을 확인한 뒤 통제된 방식으로 다시 불러오기

커널을 직접 사용하는 경우 mihomo -t -f config.yaml을 실행해 설정을 확인할 수 있습니다. 클라이언트가 커널을 명령 검색 경로에 등록하지 않았다면 실제 실행 파일 경로를 지정하세요. 규칙 세트 캐시 등 상대 경로는 작업 디렉터리에 따라 달라지므로 테스트에서도 실행 환경과 같은 작업 디렉터리를 사용해야 합니다. 문법 검사는 구조와 참조 오류를 찾는 데 도움이 되지만 실제 네트워크 연결을 대신하거나 원격 규칙 세트 다운로드 성공을 보장하지는 않습니다.

변경 전에 정상 작동이 확인된 전체 설정을 백업하고 클라이언트 오버라이드 설정도 기록하세요. 한 번에 한 항목만 변경하고 검사를 통과한 뒤 다시 불러오세요. 수신 주소, 가상 네트워크 카드, 라우팅에 관련된 항목은 클라이언트 안내에 따라 커널을 재시작해야 합니다. 설정을 다시 불러오는 데 성공했다고 기존 연결까지 모두 전환된 것은 아닙니다. 기존 출구를 계속 사용하는 연결이 있을 수 있으므로 대상 연결을 새로 만들고 로그의 설정 로드 결과를 확인하세요. 스위치 모양만 보고 판단하지 마세요.

커널이 시작되지 않으면 먼저 이전 설정을 복원한 다음 파싱 오류, 포트 점유, 권한 부족을 구분하세요. 포트 오류는 혼합 포트 점유 문제 해결을, 구조 문제는 YAML 설정 항목별 안내를 참고하세요. 기본 연결을 복구한 뒤 고급 설정을 이어 가는 편이 작동하지 않는 설정에 패치를 계속 덧붙이는 것보다 원인을 찾기 쉽습니다.

프록시 그룹 유형과 트래픽 분기 실전

규칙은 대상을 정하고 프록시 그룹은 출구를 정합니다

규칙 목록은 연결을 특정 정책으로 보내고, 프록시 그룹은 후보 중 실제 출구를 선택합니다. 후보에는 노드, 다른 프록시 그룹, 내장 항목인 DIRECT 또는 REJECT가 올 수 있습니다. 두 계층은 나눠 설계하세요. 먼저 수동 선택, 자동 선택, 업무용 서비스처럼 용도별 그룹을 만들고 규칙은 변경이 적은 그룹 이름을 참조하게 합니다. 노드 추가와 삭제는 하위 단계에서 처리하면 구독 업데이트 때마다 규칙 전체를 고칠 필요가 줄어듭니다.

select는 사용자가 화면에서 후보를 선택하는 방식으로, 전체 트래픽의 진입 그룹이나 출구를 고정해야 하는 서비스에 적합합니다. 현재 노드를 사용할 수 없다고 자동으로 다른 후보를 선택하지는 않습니다. 사용자가 선택한 항목 자체가 자동 그룹인 경우는 예외입니다. 로그인 위치나 장시간 세션을 유지해야 한다면 자주 전환하기보다 수동으로 출구를 고정하는 편이 이해하기 쉽습니다. 그룹 이름은 화면에 표시되는 라벨이자 규칙에서 참조하는 식별자입니다. 이름을 바꾸면 해당 그룹을 참조하는 규칙과 상위 그룹도 함께 수정해야 합니다.

자동 선택, 장애 전환, 부하 분산

url-test는 비슷한 노드 중 하나를 자동으로 선택할 때 적합합니다. 다만 측정 주소에 대한 연결 결과가 모든 웹사이트에서의 사용 경험을 뜻하지는 않습니다. fallback은 후보 순서가 중요합니다. 앞쪽 항목이 사용 가능한 상태라면 우선 선택하므로 주·대기 구성에 적합합니다. 두 방식 모두 연결 측정에 의존합니다. 측정 대상 사이트에 접속할 수 없거나 인증서 오류, 네트워크 제한이 있으면 실제로 사용 가능한 후보를 실패로 판단할 수 있으므로 문제 해결 시 측정 대상도 따로 확인하세요.

load-balance는 여러 연결을 분산하며, 하나의 연결을 여러 개로 나눠 대역폭을 합치지는 않습니다. 라운드 로빈 방식에서는 같은 서비스의 여러 연결이 서로 다른 출구를 사용할 수 있습니다. 일관성 해시를 사용해도 관련 도메인이 모두 같은 노드로 연결된다고 보장할 수는 없습니다. 결제, 로그인, 접속 IP에 민감한 서비스는 출구가 고정된 그룹에 따로 두는 것이 좋습니다. 연결 도중 정책을 바꿔도 이미 맺어진 전송 연결은 보통 이동하지 않으므로 새로 연결해야 변경된 선택을 확인할 수 있습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - 주요 노드
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 프록시 진입점
    type: select
    proxies:
      - 자동 선택
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,프록시 진입점
  - MATCH,프록시 진입점

이 예제에서는 '주요 노드'라는 프록시 그룹이 이미 있다고 가정합니다. use는 구독 링크가 아니라 그룹 이름을 참조합니다. 측정 주소는 접속 가능 여부와 응답 안정성을 확인한 대상으로 바꿀 수 있습니다. 간격은 초 단위이며, 허용 오차는 작은 차이로 선택이 계속 바뀌는 상황을 줄이는 값이지 실제 서비스 응답을 보장하지는 않습니다. 노드가 많다면 측정 빈도를 조절하세요. 기본값이나 보수적인 간격으로 먼저 확인한 다음 기기 자원과 네트워크 환경에 맞춰 조정하는 것이 좋습니다.

빈 그룹, 순환 참조, 규칙 적용 대상 확인

필터링 후 프록시 그룹에 후보가 남지 않는다면 노드 목록이 아직 로드되지 않았거나 이름이 다르거나 정규식에 일치하는 노드가 없는 경우가 흔합니다. 필터를 잠시 제거해 실제 후보를 확인한 뒤 조건을 다시 적용하세요. 그룹끼리 계층적으로 참조할 수는 있지만 순환 구조를 만들면 안 됩니다. 예를 들어 전체 진입 그룹이 자동 그룹을 포함하고 자동 그룹이 다시 전체 진입 그룹을 참조하면 출구를 확인할 수 없습니다. '서비스 그룹 → 선택 그룹 → 노드 또는 그룹'처럼 한 방향으로 구성하면 점검하기 쉽습니다.

검증할 때는 작동이 확인된 후보를 하나 고정하고 대상 서비스에 접속해 규칙이 예상한 그룹으로 전달되는지 확인한 다음 자동 선택을 시험하세요. 이렇게 하지 않으면 연결 실패의 원인이 규칙, DNS, 노드 중 어디에 있는지 모른 채 자동 그룹만 의심하게 됩니다. 플랫폼별 화면과 커널 기능을 비교하려면 클라이언트 비교를 확인하세요. 각 그룹 유형을 화면에서 직접 편집할 수 있는지는 사용하는 클라이언트의 설정 방법을 따르세요.

규칙 세트를 구독으로 관리하기

매칭 데이터와 처리 정책을 나눠 관리하기

도메인과 IP 대역 목록이 늘어나면 모든 항목을 기본 설정에 적어 두기가 점점 번거로워집니다. rule-providers를 사용하면 매칭 데이터를 규칙 세트로 분리하고 기본 설정에는 출처와 호출 순서만 남길 수 있습니다. 규칙 세트는 어떤 대상이 한 범주에 속하는지 정의하고, RULE-SET 규칙은 해당 범주를 어떤 정책으로 보낼지 정합니다. 대상 목록을 업데이트하면서 프록시 그룹을 바꾸지 않거나, 전체 도메인 데이터를 다시 작성하지 않고 출구 정책을 변경할 수 있습니다.

규칙은 위에서 아래로 확인되며, 보통 처음 일치한 규칙이 연결의 처리 방식을 결정합니다. 특정 도메인에 대한 예외는 범위가 넓은 규칙보다 앞에 두고 MATCH는 마지막 기본 규칙으로 둡니다. 규칙 세트의 호출 위치도 내부 데이터만큼 중요합니다. 올바른 차단 목록도 기본 규칙 뒤에 있으면 적용되지 않고, 넓은 범위의 직접 연결 규칙을 프록시 규칙보다 앞에 두면 연결이 먼저 빠져나갈 수 있습니다. 규칙을 바꾸기 전에 적용 우선순위부터 정리하세요.

올바른 동작 방식과 데이터 형식 선택

rule-providers:
  내부 도메인:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/internal.yaml

rules:
  - DOMAIN-SUFFIX,github.com,프록시 진입점
  - RULE-SET,내부 도메인,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,프록시 진입점

위 기본 설정은 로컬 파일을 참조하며 '프록시 진입점' 그룹이 이미 있다고 가정합니다. 해당하는 rules/internal.yaml은 다음처럼 작성할 수 있습니다. 예제 전용 도메인을 사용하므로 실제 서비스에 의존하지 않습니다. +.example.com은 루트 도메인과 하위 도메인을 뜻합니다. 실제 배포 시 관리할 대상으로 바꾸고 커널이 접근할 수 있는 위치에 파일을 두세요. 클라이언트의 설정 디렉터리에 접근이 제한되어 있다면 가져오기 또는 규칙 세트 관리 기능을 우선 사용하세요.

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

behavior: domain은 도메인 데이터, ipcidr은 IP 대역, classical은 서로 다른 유형의 규칙 표현식에 사용합니다. 세 형식의 데이터 작성법은 서로 바꿔 쓸 수 없습니다. 도메인 목록에 완전한 DOMAIN-SUFFIX 규칙 행을 넣으면 안 됩니다. 기존 규칙 형식의 세트에는 보통 매칭 조건만 작성하고 정책은 이를 호출하는 RULE-SET에서 지정합니다. 기본 규칙 목록처럼 각 세트 항목 끝에 대상 정책을 덧붙이지 마세요.

형식 필드도 데이터 내용과 일치해야 합니다. YAML 형식은 보통 payload 목록을 사용하고, 텍스트 형식은 해당 규격에 따라 한 줄씩 데이터를 저장합니다. 바이너리 규칙 형식은 알맞은 동작 방식과 생성 도구가 필요합니다. 다운로드에 성공했다고 콘텐츠가 올바르게 파싱된다는 뜻은 아닙니다. 오류 페이지, 로그인 페이지, 리디렉션 뒤의 HTML이 캐시에 저장될 수도 있습니다. 업데이트가 실패하면 네트워크 요청이 완료됐는지만 보지 말고 파싱 로그와 파일 첫 부분, 실제 응답 내용을 확인하세요.

원격 업데이트, 캐시, 시작 시 의존성

원격 규칙 세트를 사용할 때는 type: http, 실제 다운로드 주소, 캐시 경로, 업데이트 간격을 설정하세요. 업데이트할 때 파일이 서로 덮어쓰이지 않도록 세트마다 캐시 파일을 따로 지정합니다. 처음 시작할 때 규칙 출처에 접속하려면 프록시가 필요한데 프록시 연결은 아직 다운로드되지 않은 규칙에 의존한다면 시작 의존성이 생깁니다. 규칙 다운로드에 사용할 수 있는 출구를 명시하거나 로컬 캐시를 먼저 준비하세요. 무한 재시도로 의존성 순환을 가리지 말고, 간소화한 규칙으로 기본 프록시가 작동하는지 먼저 확인하세요.

이미 확보한 대상 IP 주소에만 매칭하려는 IP 규칙에는 필요에 따라 no-resolve를 사용할 수 있습니다. 해당 규칙을 테스트하기 위해 도메인을 추가로 조회하지 않게 해 줍니다. 다만 도메인 정보만 있고 실제 IP를 아직 얻지 못한 연결은 이 규칙을 건너뛸 수 있습니다. 일반적인 속도 향상 옵션이 아니라 매칭 시점을 바꾸는 설정입니다. 도메인 규칙, DNS 정책, IP 규칙을 함께 확인하세요. 특히 Fake-IP 모드에서는 합성 주소를 서버의 실제 주소로 착각해 대역별 분기 규칙을 만들지 마세요.

회귀 테스트에는 프록시로 보내야 할 대상, 직접 연결해야 할 대상, 명시적으로 차단할 테스트 대상이 각각 하나 이상 포함되어야 합니다. 웹페이지가 열리는지만 보지 말고 연결 세부 정보에서 규칙 유형, 세트 이름, 최종 정책을 확인하세요. 규칙은 올바르게 적용됐는데 서비스가 여전히 작동하지 않으면 프록시 그룹 출구, DNS 응답, 기존 연결 캐시를 확인하세요. 중복 규칙을 바로 추가하면 예외 목록이 길어져 다음 문제 해결이 더 어려워집니다.

DNS 설정 최적화와 조회 경로

조회 요청이 거치는 경로부터 정리하기

DNS를 설정할 때는 세 가지를 함께 고려해야 합니다. 앱이 조회를 어디로 보내는지, 커널이 어떤 상위 DNS를 선택하는지, 상위 DNS 서버의 도메인은 어디서 조회하는지입니다. 시스템 DNS, 브라우저 보안 DNS, 앱 자체 리졸버, mihomo DNS가 동시에 동작할 수 있으므로 상위 DNS를 바꿔도 모든 앱의 동작이 달라지지는 않습니다. 최적화 전에 연결이 커널을 통과하는지, 로그에 해당 조회가 기록되는지 확인하세요. 요청이 커널에 들어오지 않는다면 커널 캐시나 상위 DNS 순서를 반복해서 바꿔도 해결되지 않습니다.

nameserver는 일반 조회에 사용할 상위 DNS를 지정하고 default-nameserver는 주로 DNS 서버 자체의 도메인을 조회하는 시작 단계에 사용됩니다. 암호화 DNS 주소를 상위 서버로 지정해도 호스트 이름을 실제 IP 주소로 먼저 확인해야 합니다. 이 단계가 실패하면 전체 조회가 시간 초과되는 것처럼 보일 수 있습니다. 현재 네트워크에서 접속할 수 있는 시작용 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:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - 223.5.5.5
  fake-ip-filter:
    - '*.lan'
    - '*.local'

예제에서는 DNS가 로컬 호스트에서만 수신하고 예제 도메인에는 별도의 상위 DNS를 지정합니다. 수신 포트를 열어도 시스템 DNS가 자동으로 바뀌거나 다른 기기의 조회까지 자동으로 처리되지는 않습니다. 시스템 설정, 클라이언트의 네트워크 트래픽 처리 기능, 앱 프록시 경로가 요청을 이곳으로 전달해야 동작합니다. 상위 DNS에 연결할 수 있는지는 네트워크 환경에 따라 다르므로 도메인별 정책을 추가하기 전에 기본 경로부터 확인하세요. LAN 내부 도메인은 내부 레코드를 알고 있는 DNS 서버로 보내고 공용 DNS에 맡기지 마세요.

nameserver-policy는 도메인에 따라 조회에 사용할 DNS를 선택합니다. 바뀌는 것은 DNS 경로이지 연결 출구가 아닙니다. 지정한 DNS가 도메인의 IP 주소를 반환해도 연결은 규칙에 따라 프록시 또는 직접 연결로 처리됩니다. 반대로 도메인이 프록시 규칙에 일치한다고 해서 DNS 조회까지 같은 프록시 출구를 사용하는 것은 아닙니다. DNS 정책과 라우팅 정책을 별도 목록으로 작성해 확인하면 'DNS 지정'과 '프록시 노드 지정'을 같은 설정으로 혼동하지 않을 수 있습니다.

프록시 노드 조회와 대체 DNS의 범위

노드 서버를 도메인으로 지정한 경우 해당 도메인 조회는 프록시 연결을 시작하기 위한 준비 단계입니다. 별도 처리가 필요하면 proxy-server-nameserver로 프록시 서버 도메인 조회에 사용할 DNS를 지정해 노드 도메인 조회가 노드 자체에 의존하지 않도록 하세요. 규칙에 따라 DNS 출구를 선택하는 기능을 사용한다면 이 항목도 함께 확인해야 합니다. 다중 프록시, 원격 세트 다운로드, 암호화 상위 DNS를 함께 사용할 때는 모든 요청에 같은 경로를 적용하기보다 순환 의존성이 없는지 확인하는 것이 중요합니다.

fallback과 fallback-filter는 함께 이해해야 합니다. 후자는 어떤 응답에 대체 DNS를 사용할지 판단하는 데 관여하므로 '기본 DNS가 실패하면 무조건 전환하는 순서 목록'으로만 볼 수 없습니다. 필터 조건이 지나치게 넓으면 많은 도메인이 대체 응답을 사용해 조회 부담이 늘어날 수 있습니다. 분명한 요구 사항이 없다면 검증하기 쉬운 단일 경로부터 사용하세요. 특정 도메인이나 주소 응답을 특별히 처리해야 하는 이유를 설명할 수 있을 때 조건을 하나씩 추가하세요.

암호화 DNS는 조회 전송을 보호하지만 올바른 출구 선택을 대신하거나 원격 응답이 현지 네트워크에 적합하다고 보장하지는 않습니다. IPv6도 전체 경로가 지원되어야 합니다. 시스템에서 IPv6 주소를 받더라도 프록시 노드, 라우팅, 대상 서비스에 사용할 수 있는 경로가 있다는 뜻은 아닙니다. 일부 웹사이트에서만 지연이 생긴다면 AAAA 응답과 실제 IPv6 연결을 확인한 뒤 커널 DNS의 IPv6 설정을 조정하세요. 모든 문제를 DNS 서버 품질 탓으로 돌리지 마세요.

조회 진입점과 캐시 영향 확인하기

테스트할 때는 시스템 기본 DNS와 지정한 수신 포트로 각각 조회해 같은 경로를 사용하는지 비교하세요. 포트를 지정할 수 있는 도구에서는 dig @127.0.0.1 -p 1053 example.com을 사용할 수 있습니다. 이 도구는 별도로 설치해야 하며 클라이언트에 반드시 포함되는 것은 아닙니다. Fake-IP 모드에서는 합성 주소가 정상적으로 반환될 수 있으므로 공용 DNS의 응답과 다르다는 이유만으로 설정 오류라고 판단하지 마세요. 조회 로그, 도메인과 주소의 매핑, 이후 연결 결과가 서로 일치하는지 확인하는 편이 정확합니다.

변경한 뒤 앱 연결을 새로 만들고 필요하면 앱 자체 DNS 캐시를 지우세요. 브라우저의 보안 DNS가 시스템 조회 경로를 우회하는지도 확인해야 합니다. 테스트 기록에는 조회 진입점과 사용한 상위 DNS를 적어 서로 다른 경로의 결과를 직접 비교하지 않도록 하세요. 내부 도메인만 실패하면 로컬 DNS와 도메인별 정책을 먼저 확인하고 모든 도메인이 실패하면 상위 DNS의 시작 경로, 수신 포트, 네트워크 연결 가능 여부부터 점검하세요.

TUN, Fake-IP, 네트워크 트래픽 처리

시스템 프록시와 가상 네트워크 카드 구분하기

시스템 프록시는 시스템 설정을 따르는 앱에 HTTP 또는 SOCKS 프록시 진입점을 제공합니다. 모든 연결이 커널을 통과한다고 보장하지는 않습니다. TUN은 가상 네트워크 카드와 라우팅 규칙으로 트래픽을 받아 프록시를 직접 설정할 수 없는 앱에 적합합니다. 두 방식은 서로 배타적이지 않지만 동시에 켤 때는 각 연결이 어디로 들어오는지 알아야 합니다. TUN 스위치가 켜져 있다는 사실만으로는 기능이 제대로 작동한다고 볼 수 없습니다. 네트워크 카드, 라우팅, DNS, 권한이 함께 적용되는지 확인하세요.

데스크톱에서는 가상 네트워크 카드와 라우팅을 관리하기 위해 관리자 권한, 서비스 모드, 보조 구성 요소가 필요한 경우가 있습니다. 구체적인 설정 경로는 클라이언트에 따라 다릅니다. Android는 보통 VpnService로 네트워크 트래픽을 처리하며, 백그라운드에서 계속 실행할 수 있는지는 시스템 배터리 절약 정책의 영향도 받습니다. 데스크톱용 YAML 라우팅 항목을 모바일 화면에 그대로 적용하지 마세요. 기업 VPN이나 다른 네트워크 제어 도구가 실행 중이라면 설정을 바로 겹쳐 적용하지 말고 각각 어떤 라우팅 범위를 제어하는지 먼저 확인하세요.

보수적인 TUN 설정부터 시작하기

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

예제는 네트워크 트래픽 처리와 DNS의 연관성을 보여 줍니다. 실제 설정에서는 기존 tun 및 dns 항목에 합쳐야 합니다. auto-route는 라우팅 자동 설정에, auto-detect-interface는 출구 네트워크 카드 식별에 사용합니다. 스택 유형은 플랫폼 지원과 커널 로그를 바탕으로 선택하세요. 클라이언트가 이미 관련 항목을 관리한다면 클라이언트 설정 화면에서 변경해 로컬 오버라이드와 화면 설정이 서로 덮어쓰지 않도록 하세요. 예제에서 사용한 스택이 모든 기기에 가장 적합하다고 단정할 수는 없습니다.

dns-hijack는 지정한 일반 DNS 요청을 커널 리졸버로 전달하는 기능입니다. 모든 DNS 요청을 가로챌 수 있다는 뜻은 아닙니다. 앱이 HTTPS나 다른 암호화 채널로 조회하면 일반적인 목적지 포트 DNS 요청으로 나타나지 않으므로 라우팅과 앱 설정을 함께 확인해야 합니다. 내부 DNS, 라우터 도메인, 특수 네트워크에는 예외가 필요할 수 있습니다. 먼저 조회 진입점을 확인하고 가로챌 범위를 정하세요. 원인을 찾는 대신 처리 범위를 넓히지 마세요.

Fake-IP는 매핑용 주소이며 실제 서비스 주소가 아닙니다

Fake-IP는 도메인에 합성 주소를 할당하고 커널은 도메인과 주소의 매핑을 저장합니다. 이후 앱 연결을 원래 도메인에 연결해 처리합니다. 일부 환경에서는 실제 주소를 미리 조회할 필요를 줄이고 도메인 규칙도 적용하기 쉽습니다. 하지만 합성 주소는 원격 서버 주소가 아니므로 원격 방화벽 허용 목록에 넣거나 같은 커널을 거치지 않는 다른 기기에서 사용하면 안 됩니다. 앱에 매핑이 캐시되어 있는데 연결이 해당 커널로 돌아오지 않으면 접속할 수 없는 문제가 생길 수 있습니다.

fake-ip-filter는 지정한 도메인에 Fake-IP를 할당하지 않도록 설정합니다. LAN 기기 검색, 내부 서비스, 호환되지 않는 서비스에 사용할 수 있습니다. 필터에 포함된 도메인은 실제 DNS 응답을 받지만 연결은 여전히 라우팅과 규칙에 따라 처리되므로 자동으로 직접 연결되는 것은 아닙니다. 실제 문제가 발생한 도메인부터 예외에 추가하고 올바른 DNS 응답을 받을 수 있는지 확인하세요. 자주 사용하는 도메인 범위를 전부 필터에 넣으면 모드의 동작 방식이 달라지고 도메인 매핑이 다른 정보에 더 의존하게 됩니다.

사설 네트워크 대역, 컨테이너 네트워크, 기업 VPN은 합성 주소 범위나 자동 라우팅과 충돌할 수 있습니다. 특정 주소 대역에 연결할 수 없다면 DNS를 전부 바꾸기 전에 시스템 라우팅 테이블과 현재 네트워크 카드를 확인하세요. 사용자 지정 주소 풀을 쓰기 전에 기존 네트워크와 겹치지 않는지 확인하고 클라이언트가 지원하는 방식으로 라우팅 제외를 설정하세요. 특정 대역을 제외하면 해당 트래픽이 커널에 들어오지 않을 수 있고, 이후 커널 규칙으로 분기할 수도 없습니다. 이 경계를 미리 파악해야 합니다.

네트워크 카드, 라우팅, DNS, 연결 순서로 문제 해결하기

TUN을 켠 뒤 인터넷이 완전히 끊기면 먼저 TUN을 끄고 원래 네트워크를 복구한 다음 커널 권한과 가상 네트워크 카드 생성 여부를 확인하세요. 그다음 기본 출구를 잘못 감지했는지 확인합니다. 여러 네트워크 카드, 핫스팟 공유, VPN을 함께 사용하는 기기에서 특히 중요합니다. 기본 라우팅을 확인한 뒤 DNS를 테스트하세요. 도메인은 조회되는데 연결되지 않으면 적용된 규칙과 노드 프로토콜 지원을 확인하세요. 로그를 보기 전에 스택과 DNS를 여러 번 바꾸지 말고 각 단계마다 재현 가능한 요청 하나로 확인하세요.

Android에서만 백그라운드 연결이 끊긴다면 시스템 권한과 배터리 절약 정책을 추가로 확인하고 Android VpnService와 백그라운드 연결 유지 안내를 참고하세요. LAN 기기에만 문제가 있다면 공유 프록시 포트, 방화벽, 수신 주소를 따로 점검하세요. 컴퓨터의 TUN이 작동한다고 다른 기기도 프록시에 연결된 것은 아닙니다.

도메인 스니핑과 규칙 식별

스니핑은 도메인 정보를 보완할 뿐 DNS를 대체하지 않습니다

연결이 커널에 들어와도 사용할 수 있는 도메인 정보가 항상 포함되는 것은 아닙니다. 앱이 IP 주소에 바로 연결하거나 DNS 조회가 커널 밖에서 이뤄지면 규칙 엔진에는 대상 주소만 보일 수 있습니다. 도메인 스니핑은 연결 초기 데이터에서 호스트 정보를 추출해 규칙 매칭에 필요한 단서를 보완합니다. 앱에 일반적인 도메인 조회 기능을 제공하지 않으며 모든 연결을 식별할 수 있는 것도 아닙니다. 문제를 해결하려면 먼저 도메인 정보가 어느 단계에서 누락되는지 확인한 다음 스니핑이 필요한지 판단하세요.

일반적인 정보 출처는 HTTP 요청의 호스트 필드와 TLS 핸드셰이크에서 확인할 수 있는 서버 이름입니다. QUIC 식별은 프로토콜 지원 여부와 데이터 파싱 가능 여부에 따라 달라집니다. 암호화된 클라이언트 인사, 비표준 핸드셰이크, 도메인 없는 프로토콜, 이미 연결된 세션에서는 식별이 제한될 수 있습니다. 따라서 스니핑 성공률만으로 설정이 올바른지 판단하면 안 됩니다. 식별하지 못한 연결도 적절한 IP 규칙과 기본 정책으로 처리해야 하며 모든 정보를 스니핑으로 보완할 수는 없습니다.

대상 범위를 넓히기 전에 프로토콜과 포트를 제한하기

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

예제는 일반적인 HTTP 및 TLS 포트에서만 식별을 사용하고 목적지 주소 덮어쓰기는 끕니다. 제외 항목에는 예제 도메인을 사용했으므로 실제로 호환성 문제가 있는 대상으로 바꿔야 합니다. 포트 목록은 식별 범위이지 방화벽에서 포트를 허용하거나 해당 연결을 자동으로 프록시에 보내는 설정이 아닙니다. 연결의 목적지는 여전히 규칙 목록에 따라 정해집니다. 많은 포트에 바로 적용하기보다 제한된 범위에서 먼저 확인해야 어떤 프로토콜이 동작을 바꿨는지 파악하기 쉽습니다.

override-destination은 스니핑한 도메인으로 연결 목적지를 덮어쓸지 정하는 설정입니다. 매칭에 사용할 도메인 정보를 얻는 것과는 다른 단계입니다. 원래 IP로 연결하던 서비스에 적용하면 다시 조회해 다른 주소로 접속할 수 있습니다. 고정 주소를 사용하는 서비스, 특수 CDN 라우팅, 내부 게이트웨이에서는 호환성 문제가 생길 수 있습니다. 보수적인 설정으로 시작하고 실제 서비스에 덮어쓰기가 필요하다고 확인한 뒤 프로토콜이나 도메인 범위를 좁혀 조정하세요.

잘못된 식별과 서비스별 예외 처리

일부 서비스는 연결을 재사용하거나 접속에 입력한 주소와 다른 이름으로 핸드셰이크를 하며 중간 게이트웨이로 서비스를 전달하기도 합니다. 스니핑한 이름이 사용자가 입력한 도메인과 다를 수 있어 규칙이 다른 분류에 들어갈 수 있습니다. 스니핑을 켠 뒤 특정 서비스에 문제가 생기면 스니핑 전후의 도메인, 목적지 주소, 적용된 정책을 기록하고 해당 대상만 예외 처리하세요. 모든 도메인 규칙을 바로 끄거나 서비스 전체를 직접 연결로 강제하지 마세요. 변경 범위가 필요 이상으로 커집니다.

force-domain이나 순수 IP 연결 식별은 추가 제어 기능이며 실제 연결 경로와 커널 지원 여부에 따라 필요성이 달라집니다. 전체 도메인을 대상으로 강제 적용하지 마세요. 합리적인 요구라면 '특정 앱의 특정 도메인 매핑이 없어 식별 정보를 보완해야 한다'처럼 구체적으로 설명할 수 있어야 합니다. 영향을 받는 연결을 특정할 수 없다면 DNS 진입점과 Fake-IP 매핑부터 확인하세요. 강제 스니핑이 필요해 보이는 문제도 실제로는 DNS와 연결이 같은 경로를 거치지 않는 경우가 많습니다.

스니핑은 연결 초기 처리에도 관여합니다. 응답 시간에 민감한 앱에서는 프로토콜 대기나 식별 실패가 연결 동작을 바꿀 수 있으므로 실제로 사용하는 전송 프로토콜을 포함해 테스트하세요. 브라우저에서 홈페이지를 열어 보는 것만으로 앱 내 음성, 영상, 기타 장시간 연결이 정상이라고 판단할 수는 없습니다. 문제 해결 중에만 로그 상세도를 잠시 높이고 완료 후에는 일반 수준으로 되돌리세요. 도메인과 연결 정보를 불필요하게 장시간 수집하지 않도록 합니다.

식별 결과를 전체 트래픽 분기 과정에서 검증하기

반복해서 테스트할 수 있는 대상을 고른 다음 먼저 스니핑을 끄고 기준 결과를 확인하세요. 이어서 스니핑을 켜고 새로 연결해 적용 규칙이 예상대로 달라지는지 비교합니다. 목적지에 도메인 정보가 없어도 IP 규칙이 올바르게 처리한다면 화면에 도메인을 표시하려고 복잡한 설정을 추가할 필요는 없습니다. 도메인을 식별했는데도 기본 규칙에 일치한다면 규칙 순서, 이름 표기, 규칙 세트 내용을 확인하세요. 식별에 성공했다고 해당 도메인의 분기 규칙이 자동으로 만들어지는 것은 아닙니다.

고정 IP, 인증서 오류, 프록시 게이트웨이를 사용하는 서비스는 프록시 연결 여부만 보지 말고 앱 계층 오류도 확인해야 합니다. 커널은 보통 스니핑을 위해 서비스 본문을 복호화하지 않으며 서버 인증서나 계정 권한 문제를 해결해 주지도 않습니다. '도메인 정보 확인', '정책 선택', '연결 목적지', '앱 요청 성공'을 별개의 결과로 기록하면 이후 서비스 오류를 스니핑 실패로 잘못 판단하지 않을 수 있습니다.

원래 목적지 주소를 유지해야 하는 내부 시스템에는 명확한 도메인 규칙, 내부 DNS, 제한적인 스니핑 제외 목록을 우선 사용하세요. 복잡한 서비스에서 전역 스위치 하나로 모든 결과를 통일하려고 하지 마세요. 스니핑을 끄기로 했다면 설정을 삭제하는 데서 끝내지 말고 기존에 스니핑으로 식별하던 연결이 적절한 기본 규칙에 들어가는지 다시 확인하세요. 기본 용어는 용어 설명에서 찾아볼 수 있습니다.

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

원격 입력과 로컬 관리 범위 명확히 하기

구독을 업데이트하면 보통 원격 콘텐츠를 다시 다운로드하므로 내려받은 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 지속적으로 유지할 설정은 클라이언트에서 제공하는 오버라이드, 병합, 스크립트 기능에 두세요. 다만 이러한 기능의 화면과 동작 방식은 mihomo에서 통일해 정의하지 않습니다. Clash Plus, Clash Verge Rev, FlClash 등은 처리 시점과 항목 병합 방식이 다를 수 있습니다. 이름이 비슷한 기능이라고 같은 규칙을 따른다고 가정하지 말고 변경 전에 최종 설정을 확인하세요.

로컬에서 관리하기 적합한 항목은 수신 범위, DNS 설정, 내부 도메인 규칙, 고정된 프록시 그룹 구조입니다. 노드 매개변수와 외부 규칙 데이터는 원격 업데이트에 맡길 수 있습니다. 두 영역을 나눠 두면 노드를 업데이트할 때마다 로컬 설정이 바뀌지 않습니다. 원격 설정에 규칙 구조가 이미 완성되어 있다면 오버라이드를 설정하기 전에 해당 구조를 유지할지 자체 구조를 사용할지 정하세요. 두 구조가 서로 중첩되어 어느 쪽이 최종 제어권을 갖는지 불명확해지는 상황을 피해야 합니다.

프록시 그룹으로 여러 노드 출처 구성하기

proxy-providers:
  출처 A:
    type: file
    path: ./providers/source-a.yaml
  출처 B:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 구독 A
    type: select
    use:
      - 출처 A
  - name: 구독 B
    type: select
    use:
      - 출처 B
  - name: 프록시 진입점
    type: select
    proxies:
      - 구독 A
      - 구독 B
      - DIRECT

예제에서는 로컬 프록시 그룹을 사용하며 두 파일 모두 유효한 proxies 목록을 포함해야 합니다. 출처별로 먼저 확인한 뒤 상위 진입점에서 출처를 선택하는 구조입니다. 전체 Clash 설정, 노드만 포함된 YAML, Base64 목록, 프로토콜 공유 링크는 서로 바꿔 쓸 수 있는 파일 형식이 아닙니다. 어떤 구독 주소든 그룹에 입력한다고 커널이 자동으로 인식하는 것은 아닙니다. 응답 형식을 먼저 확인하고 필요하면 신뢰할 수 있는 로컬 처리 방식을 사용하세요. 자세한 내용은 구독 형식 차이를 참고하세요.

원격 프록시 그룹을 사용하려면 실제 구독 주소, 캐시 경로, 업데이트 간격을 설정하고 시작할 때 어떤 경로로 다운로드할지도 고려해야 합니다. 구독 주소에는 계정 인증 정보가 포함되는 경우가 많으므로 로컬의 비공개 설정에만 저장하세요. 공개 변환 사이트나 문제 화면에 붙여 넣지 마세요. 예제나 공유 자료에서는 실제 주소, 인증 정보, 계정을 복구할 수 있는 매개변수를 제거해야 합니다. 노드 비밀번호를 공개하지 않았더라도 전체 구독 링크만으로 접근 권한이 부여될 수 있으므로 일반 공개 웹 주소처럼 취급하지 마세요.

목록 병합은 단순한 텍스트 이어 붙이기가 아닙니다

딕셔너리 항목은 키를 기준으로 덮어쓸 수 있지만 목록에는 교체, 앞쪽 추가, 뒤쪽 추가 등 서로 다른 병합 방식이 있습니다. 로컬 규칙을 원격 MATCH 뒤에 추가해도 예외 우선 처리가 되지 않는 경우가 많습니다. DNS 목록을 통째로 교체하면 기존 설정의 내부 DNS가 사라질 수도 있습니다. 오버라이드하기 전에 원하는 작업을 정하고 클라이언트가 해당 방식을 지원하는지 확인하세요. 전체 항목 교체만 지원한다면 일부만 제출하고 나머지가 자동으로 유지된다고 가정하지 말고 대상 항목 전체를 관리해야 합니다.

여러 출처에 같은 이름의 노드나 프록시 그룹이 있을 수 있습니다. 화면에서 이름이 겹치면 구분이 어렵고 규칙이나 그룹 참조도 모호해질 수 있습니다. 출처별로 이름을 명확히 구분하고 클라이언트가 지원하는 경우에만 이름 접두사 같은 수정 기능을 사용하세요. 화면에 보이는 이름만 바꾸고 기존 참조를 그대로 두지 마세요. 병합 후에는 정규식 필터도 확인해야 합니다. 새 접두사, 출처 변경, 이름의 언어가 바뀌면 기존에 작동하던 표현식이 결과를 찾지 못할 수 있습니다.

상태 점검도 계층을 나눠야 합니다. 프록시 그룹에서 노드 점검을 수행하고 자동 선택 그룹도 측정을 시작할 수 있어 같은 점검을 중복하면 요청이 늘어납니다. 모든 수동 선택 그룹에 자동 테스트를 추가할 필요는 없습니다. '그룹 내 노드에 연결할 수 있는지'와 '자동 그룹이 어떤 후보를 골라야 하는지' 중 확인할 대상을 먼저 정하고 알맞은 점검을 설정하세요. 여러 구독을 동시에 사용하면 각 출처가 정상이어도 공유 상위 그룹이 올바르게 구성됐다는 뜻은 아닙니다. 최종 후보와 규칙 참조까지 확인해야 합니다.

반복 가능한 업데이트 및 복구 절차 만들기

병합한 뒤 YAML 파싱, 그룹 로드, 프록시 후보, 규칙 순서, DNS 결과를 차례로 확인하고 최종 설정 미리보기를 저장하세요. 그다음 구독을 직접 업데이트하고 동일한 항목을 다시 확인해 로컬 설정이 유지되는지 검증합니다. 업데이트 후에도 유지되는 것을 확인한 오버라이드만 지속 설정으로 볼 수 있습니다. 현재 세션에서만 적용되는 화면 선택은 클라이언트가 실행 상태를 저장하는지에 따라 달라질 수 있으므로 재시작 후 동작도 따로 확인하세요.

기존 클라이언트에서 옮길 계획이라면 로컬 오버라이드와 필요한 프록시 선택 기록을 먼저 내보낸 뒤 새 클라이언트에서 항목별로 검증하세요. 클라이언트마다 설정 데이터베이스를 그대로 공유할 수 있다고 가정하지 마세요. 다운로드 페이지에서 현재 플랫폼에 맞는 클라이언트를 선택할 수 있습니다. 먼저 구독 하나로 연결을 확인하고 두 번째 출처를 추가한 다음 복잡한 규칙을 복원하면 각 단계의 검증 범위를 명확히 할 수 있습니다.

외부 컨트롤러와 API 보안

컨트롤 포트와 프록시 포트의 용도 구분하기

혼합 포트는 앱 연결을 프록시로 전달하고 외부 컨트롤 포트는 상태 조회와 관리 작업에 사용합니다. 패널은 컨트롤 API로 프록시 그룹, 연결, 로그를 확인하고 모드 변경이나 설정 다시 불러오기를 수행할 수도 있습니다. 브라우저의 프록시 입력란에 넣는 포트가 아닙니다. 같은 주소에서 두 서비스가 동일한 포트를 사용할 수는 없습니다. 시작 시 충돌이 발생하면 프록시, DNS, 컨트롤 수신 포트를 각각 확인하세요. 시스템 프록시에 입력한 숫자만 바꿔서는 해결되지 않습니다.

컨트롤 API에 접근할 수 있는 프로그램은 트래픽 처리 방식을 바꿀 수도 있으므로 일반 상태 페이지보다 높은 권한을 가집니다. 데스크톱에서는 보통 로컬 루프백 주소에만 바인딩하면 됩니다. 원격으로 관리해야 한다면 인증된 터널이나 통제된 네트워크를 먼저 고려하세요. 모든 네트워크 카드에서 수신하도록 설정해도 접근 제어가 자동으로 생기지는 않습니다. 패널 화면이 다른 사람에게 보이지 않는다고 안전한 것도 아닙니다. 실제 접근 범위는 수신 주소, 방화벽, 인증 설정에 따라 결정됩니다.

로컬 수신 및 인증 설정

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

예제 비밀번호는 설명을 위한 임시 값입니다. 실제로 배포할 때는 로컬에서 별도의 강력한 비밀번호로 바꾸고 노드 인증 정보나 다른 계정 비밀번호를 재사용하지 마세요. 클라이언트가 컨트롤 주소와 인증 항목을 직접 관리할 수도 있습니다. 직접 오버라이드한 뒤 패널 연결이 끊기면 인증을 바로 지우지 말고 화면에 저장된 연결 매개변수가 일치하는지 확인하세요. 수신 주소나 인증을 변경하면 기존 패널의 연결 설정도 함께 바꿔야 합니다. 여러 패널에 서로 다른 이전 값이 저장되어 있으면 연결이 간헐적으로 실패할 수 있습니다.

클라이언트에 로컬 패널이 내장되어 있다면 클라이언트가 제공하는 실행 방법을 우선 사용하세요. 커널을 직접 실행하는 경우 external-ui로 미리 준비한 로컬 정적 패널 디렉터리를 지정할 수 있습니다. 하지만 해당 디렉터리에 유효한 페이지 파일이 있어야 하며 경로를 입력한다고 패널이 자동으로 생성되지는 않습니다. 상대 경로는 커널 작업 디렉터리를 기준으로 확인하고 설정 파일을 옮긴 뒤에는 리소스 경로도 점검하세요. 페이지를 열기 위해 설정 디렉터리 전체의 파일 권한을 함부로 완화하지 마세요.

네트워크 연결 실패, 인증 실패, 브라우저 제한 구분하기

패널에 연결할 수 없다면 커널이 실행 중인지, 컨트롤 주소가 실제로 수신 중인지 먼저 확인하세요. 그다음 패널에 입력한 프로토콜, 호스트, 포트, 인증 값을 점검합니다. 로컬에서는 접속되지만 다른 기기에서는 안 된다면 바인딩 범위와 방화벽을 확인하세요. 연결은 되지만 인증 실패가 반환되면 인증 설정이 우선 점검 대상입니다. 패널 페이지는 열리는데 상태가 비어 있다면 페이지 리소스는 정상이어도 API 연결이 실패했을 수 있습니다. 화면이 보인다고 컨트롤 연결이 성립한 것은 아닙니다.

브라우저의 교차 출처 정책이나 혼합 콘텐츠 제한이 원인일 수도 있습니다. HTTPS로 열린 패널에서 일반 HTTP 컨트롤 API를 호출하면 요청이 커널에 도달하기 전에 브라우저가 차단할 수 있습니다. 브라우저 개발자 도구의 네트워크 탭에서 구체적인 원인을 확인한 뒤 동일 출처 배포, 클라이언트 내장 기능, 보호된 프록시 방식 중 알맞은 방법을 선택하세요. 모든 브라우저 오류를 커널 미지원으로 단정하지 말고 오류를 없애려고 허용 출처와 네트워크 수신 범위를 무조건 넓히지도 마세요.

교차 출처 접근이 꼭 필요하다면 커널과 패널이 지원하는 방식으로 허용 출처를 제한하고 인증을 유지하세요. 리버스 프록시로 원격 접속점을 제공할 때는 WebSocket 등의 연결도 제대로 전달되는지 확인해야 합니다. 일반 요청은 성공해도 실시간 로그 연결이 계속 끊길 수 있습니다. 접속점을 보호할 때는 전송 암호화와 접근 범위를 모두 고려하세요. 패널 앞에 로그인 화면만 추가하고 기본 컨트롤 포트를 신뢰할 수 없는 네트워크에 그대로 노출해서는 안 됩니다. 배포 경계를 잘 모른다면 로컬 수신을 유지하는 편이 안전합니다.

연결 세부 정보로 문제 해결 과정을 좁히기

컨트롤 패널에서 가장 유용한 정보는 연결 진입점, 대상 도메인 또는 주소, 일치한 규칙, 최종 정책 경로입니다. 실패한 요청을 조사할 때는 연결을 새로 만든 뒤 목록에서 해당 항목을 찾아 예상한 서비스 그룹에 들어갔는지 확인하세요. 기록이 전혀 없다면 앱이 프록시나 TUN을 거치는지 먼저 확인합니다. 기록은 있지만 규칙이 잘못됐다면 규칙 순서를 살펴보세요. 규칙은 맞는데 전송 연결을 만들지 못한다면 노드, DNS, 프로토콜 지원을 점검합니다. 이 순서를 따르면 관찰 가능한 단계로 원인을 좁힐 수 있습니다.

프록시 그룹을 바꿔도 이후 연결에만 새 선택이 적용되고 기존 연결은 이전 출구를 계속 사용할 수 있습니다. 검증할 때는 테스트 대상 연결만 종료하고 다시 요청하면 됩니다. 모든 연결을 한꺼번에 끊을 필요는 없습니다. 상세 로그를 임시로 켤 때는 재현 시간과 대상을 기록하고 점검 후 일반 로그 수준으로 되돌리세요. 화면을 캡처하거나 로그를 내보내기 전에 구독 주소, 인증 항목, 내부 도메인, 불필요한 대상 정보를 제거하세요. 진단에 필요한 것은 오류와 관련된 증거이지 사적인 네트워크 기록 전체가 아닙니다.

최종 유지 관리 절차는 정상 설정 저장, 항목별 변경, 문법 확인, 통제된 다시 불러오기, 규칙 적용 검증, 구독 업데이트, 재검증, 복구 지점 기록 순으로 진행할 수 있습니다. 문제가 생길 때마다 진입, DNS 조회, 규칙 매칭, 출구의 네 계층을 확인하고 클라이언트를 재설치하거나 구독을 한꺼번에 바꾸지 마세요. 일반적인 설치 및 사용 문제는 도움말 센터에서 확인할 수 있습니다. 구독 가져오기와 연결 과정을 다시 살펴보려면 빠른 시작 가이드로 돌아가세요.