Clash 고급 설정 가이드

설정 계층과 Clash 포트 설정

변경하기 전에 실제 적용되는 설정을 먼저 확인하세요. 구독에서 다운로드한 파일, 클라이언트가 저장한 설정, 병합 후 실행 중인 설정은 서로 다를 수 있습니다. 구독은 프록시와 기본 정책을 제공하고, 클라이언트 설정은 포트, 모드, DNS 또는 TUN을 관리할 수 있으며, 로컬 오버라이드는 규칙을 추가합니다. 편집기에 항목이 보인다고 해서 커널이 해당 값을 적용한 것은 아닙니다. 실행 설정과 앱 설정 화면, 시작 로그를 함께 확인해 최종값을 파악하세요. 실행 설정을 확인할 방법이 없다면 관련 관리 옵션이 클라이언트에서 켜져 있는지 기록해 두세요.

YAML 들여쓰기와 항목의 위치

YAML은 공백으로 계층을 표현합니다. 같은 계층의 항목은 들여쓰기를 맞추고, 목록 항목은 하이픈으로 시작합니다. 탭 문자를 섞어 쓰지 말고 같은 계층에 dns나 rules를 두 번 작성하지 마세요. 중복 키는 거부되거나 뒤에 나온 값만 남을 수 있습니다. 콜론과 공백이 포함된 문자열처럼 특수 문자가 있는 이름은 따옴표로 묶는 것이 좋습니다. 수정할 때는 원본 구조를 유지하고 필요한 항목만 변경하세요. 구독 전체를 한 줄로 압축하면 들여쓰기 오류와 잘못된 덮어쓰기를 찾기 어려워집니다.

먼저 파일을 로컬에 백업한 뒤 설정 검사를 실행하세요. 명령줄 커널을 사용하는 경우 아래 명령을 실행할 수 있습니다. ./config.yaml은 현재 디렉터리에 있는 설정 파일을 뜻하므로, 파일이 다른 위치에 있다면 경로를 바꾸세요. 검사를 통과했다는 것은 문법과 기본 참조를 불러올 수 있다는 뜻일 뿐, 서버 연결이나 시스템 권한, DNS 경로까지 정상이라는 의미는 아닙니다. 클라이언트에 설정 검증 버튼이 있다면 적용하기 전에 먼저 검증해 기존 연결까지 끊기지 않도록 하세요.

mihomo -t -f ./config.yaml

혼합 포트와 수신 주소

mixed-port를 설정하면 HTTP 프록시와 SOCKS 프록시가 하나의 수신 포트를 함께 사용합니다. 이 포트는 로컬 앱이 커널에 연결하는 입구이지, 원격 노드의 서버 포트나 컨트롤 패널 포트가 아닙니다. 아래 설정은 루프백 주소에서만 수신하므로 한 대의 기기에서 사용하기에 적합합니다. 브라우저는 보통 시스템 프록시를 통해 연결하고, 명령줄 도구는 프록시 환경 변수를 별도로 설정해야 할 수 있습니다. 시스템 프록시 자동 설정은 클라이언트가 담당하므로 mixed-port를 설정하는 것만으로 자동 적용되지는 않습니다.

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

포트 오류가 발생하면 다른 프록시 프로그램이나 남아 있는 커널 프로세스가 포트를 사용 중인지 먼저 확인하세요. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요. 중복 실행된 클라이언트를 닫고 프로세스가 사라졌는지 확인한 뒤 다시 시작하세요. 포트를 바꿔야 한다면 시스템 프록시, 브라우저 확장 프로그램, 터미널 환경 변수도 함께 변경해야 합니다. YAML만 바꾸고 시스템 프록시를 그대로 두면 커널은 정상 실행되지만 브라우저에서는 연결이 거부될 수 있습니다. 관련 명령은 포트 사용 중 문제 해결 가이드를 참고하세요.

되돌릴 수 있는 변경 절차 마련하기

한 번에 한 종류의 동작만 조정하세요. 예를 들어 수신 포트를 먼저 바꾸고, DNS를 다음으로 조정한 뒤, 마지막에 TUN을 활성화합니다. 적용 후에는 새 연결을 만들어 확인하고, 기존 브라우저의 장시간 연결에 의존하지 마세요. 변경 전후의 항목, 문제가 발생한 앱, 로그 시간을 기록하면 되돌릴 때 어느 계층을 복구해야 하는지 알 수 있습니다. 도움을 요청할 때는 최소한의 설정 조각만 공유하세요. 구독 주소, 인증 정보, 개인 네트워크 정보는 삭제하되 항목 구조와 오류 상황은 남겨 두세요.

설정이 실제로 적용됐는지 판단하려면 새 연결이 커널에 도달했는지, 어떤 규칙과 일치했는지, 어느 출구를 선택했는지 확인해야 합니다. 스위치가 켜진 것, 파일이 저장된 것, 설정 검사를 통과한 것은 각각 다른 단계가 완료됐다는 뜻입니다. 각 계층을 나누어 확인하면 포트 문제를 구독 문제로 오해하거나 화면 표시 하나 때문에 전체 설정을 다시 작성하는 일을 피할 수 있습니다.

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

규칙은 트래픽을 어디로 보낼지 결정하고, 프록시 그룹은 사용할 출구를 선택합니다. 먼저 서비스별로 고정된 그룹 이름을 정한 다음 그룹 안의 노드를 변경하면 구독이 업데이트돼도 규칙을 반복해서 수정할 필요가 없습니다. 그룹 이름은 대소문자, 공백, 문장 부호까지 규칙의 대상과 정확히 일치해야 합니다. 그룹이 다른 그룹을 참조할 수는 있지만 순환 참조는 허용되지 않습니다. 예를 들어 수동 선택 그룹이 자동 선택 그룹을 포함하는 구성은 흔하지만, 자동 그룹이 다시 수동 그룹을 포함하면 정상적으로 해석할 수 없는 의존 관계가 생깁니다.

수동 선택과 자동 선택

select는 출구를 고정해야 할 때 적합하며, 사용자가 클라이언트에서 구성원을 선택합니다. url-test는 후보 출구의 테스트 지연 시간을 주기적으로 비교하므로 자동으로 선택을 조정하려는 경우에 적합합니다. fallback은 목록 순서에 따라 사용 가능한 구성원을 선택해 명확한 주·보조 구성을 만들 수 있습니다. load-balance는 여러 연결을 구성원에게 분산할 뿐, 한 번의 다운로드 대역폭을 단순 합산하지는 않습니다. 자동 그룹이 편리해 보인다는 이유만으로 모든 앱을 넣지 말고, 먼저 필요한 동작을 선택한 뒤 테스트 주기를 정하세요.

아래는 참조 관계를 이해하기 위한 최소 예제입니다. 구성원은 내장 항목인 DIRECT뿐이므로 프록시 출구가 만들어지지 않습니다. 실제 구독을 가져온 뒤 구독에 이미 포함된 프록시나 다른 그룹을 구성원 목록에 추가할 수 있습니다. 이 예제는 구조를 명확히 설명하기 위한 것이며, 가짜 서버를 만들어 연결 가능한 것처럼 보이게 하려는 목적이 아닙니다. 실제 사용에서는 안정적인 그룹 이름을 유지하고 구성원은 구독이나 로컬 설정에서 관리하세요.

proxy-groups:
  - name: 출구 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,출구 선택
  - MATCH,DIRECT

속도 테스트 값이 사용 경험을 그대로 보여주지는 않습니다

자동 테스트에는 보통 url, interval 등의 매개변수가 필요하며, tolerance를 사용하면 지연 시간의 작은 변화로 인해 선택이 자주 바뀌는 일을 줄일 수 있습니다. 후보 출구에서 안정적으로 접속할 수 있는 가벼운 리소스를 테스트 주소로 사용하세요. 예제 도메인은 항목의 위치를 설명할 뿐, 신뢰할 수 있는 속도 테스트 서비스가 아닙니다. 실제 설정에서는 사용 중인 네트워크에서 접근할 수 있는 주소를 선택하세요. 테스트를 너무 자주 하면 요청이 늘고 모바일 기기의 배터리도 더 빨리 소모됩니다. 반대로 너무 드물면 장애 상태가 늦게 반영되므로 사용 환경에 맞춰 조정해야 합니다.

테스트 성공은 해당 출구가 특정 요청을 처리할 수 있다는 뜻이지, 모든 사이트에 접속할 수 있다는 의미는 아닙니다. 어떤 출구는 핸드셰이크가 빠르지만 저녁 시간대 대역폭이 제한될 수 있고, 웹에는 적합해도 지연 변동에 민감한 음성 통화에는 맞지 않을 수 있습니다. 자동 그룹을 비교할 때는 같은 대상과 비슷한 시간대를 사용하고 새 연결로 확인하세요. 지연 시간의 의미와 측정 범위는 노드 지연 테스트와 실제 인터넷 속도의 차이에서 더 살펴볼 수 있습니다. 밀리초 수치만으로 장기간 사용할 출구를 결정하지 마세요.

서비스 그룹과 노드 출처 분리

장기간 사용할 설정은 두 계층으로 나눌 수 있습니다. 하위 그룹은 노드를 모으고 자동 테스트나 주·보조 전환을 담당하며, 상위 그룹은 웹이나 업무 서비스 등 사용 목적에 맞춰 선택하도록 합니다. 규칙은 상위 그룹만 참조하므로 노드 이름이 바뀌어도 영향이 하위 그룹에 한정됩니다. proxy-providers를 사용할 때 그룹은 use로 선언된 출처를 참조할 수 있습니다. 출처 이름은 노드 이름이 아니므로 전체 설정에서 먼저 선언해야 합니다. 클라이언트가 그룹을 자동 생성한다면 사용자 지정 그룹이 유지되는지 확인하세요. 업데이트 과정에서 같은 이름의 구조가 덮어써질 수 있습니다.

로그인 상태를 유지해야 하는 서비스에는 수동 그룹이나 명확한 주·보조 그룹을 우선 사용하세요. 출구를 자주 바꾸면 추가 인증이 요구될 수 있고, 출발지 주소를 기준으로 한 접근 판단도 달라질 수 있습니다. 그룹 구성원을 변경해도 이미 연결된 세션은 기존 경로를 유지하는 경우가 많으며 새 연결부터 새 선택이 적용됩니다. 필요하다면 연결 목록에서 해당 세션을 종료하세요. 전환이 저장되지 않았다고 오해하지 않도록 주의하세요. 로드 밸런싱을 활성화하기 전에는 서로 다른 요청이 다른 출구에서 와도 서비스가 허용하는지 확인하세요.

설정을 마친 뒤 명확한 도메인 규칙 하나로 서비스 그룹을 확인하고, 다음으로 기본 규칙을 점검하세요. 전역 모드에서는 기존 규칙 분기가 적용되지 않을 수 있고, 직접 연결 모드에서는 서비스 그룹이 예상대로 사용되지 않습니다. 따라서 그룹 동작을 문제 해결할 때는 먼저 규칙 모드인지 확인하세요. 클라이언트 목록에 그룹이 보이는 것만으로는 어떤 트래픽이 그룹을 참조한다고 볼 수 없습니다. 연결 상세 정보에 표시되는 규칙과 경로가 최종 기준입니다.

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

규칙 세트는 규칙의 출처와 업데이트를 관리하는 기능이지 프록시 노드를 제공하는 기능이 아닙니다. rule-providers는 규칙 데이터를 선언하고, rules는 언제 이를 참조할지와 참조 후 어떤 정책을 적용할지 결정합니다. 두 역할을 혼동하면 안 됩니다. 규칙 파일만 다운로드하고 RULE-SET을 작성하지 않으면 자동으로 매칭에 사용되지 않습니다. 반대로 참조는 작성했지만 출처가 불러와지지 않으면 설정 자체가 실패할 수 있습니다. 먼저 작은 로컬 규칙 세트로 동작을 확인한 뒤 원격에서 관리되는 세트를 추가하면 형식 문제와 네트워크 문제를 더 쉽게 구분할 수 있습니다.

동작 유형과 파일 형식

behavior는 세트에 어떤 규칙이 들어 있는지 나타냅니다. domain은 도메인 목록, ipcidr은 네트워크 대역 목록에 적합합니다. classical은 DOMAIN-SUFFIX,example.com처럼 규칙 유형이 포함된 항목을 저장합니다. 규칙 대상은 보통 바깥쪽의 RULE-SET에서 지정하므로 classical 세트 항목에 프록시 그룹 이름을 넣지 마세요. format은 파일의 인코딩 형식을 설명합니다. YAML, 일반 텍스트, 바이너리 형식은 확장자만 바꿔 서로 변환할 수 없으며, 동작 유형도 해당 형식이 지원하는 범위와 맞아야 합니다.

아래 예제는 로컬 YAML 파일을 사용하므로 구조를 먼저 확인하기에 적합합니다. 상대 경로는 보통 커널의 작업 디렉터리를 기준으로 해석됩니다. GUI 클라이언트에는 별도의 설정 디렉터리나 파일 접근 제한이 있을 수 있으므로 편집기의 현재 디렉터리와 같다고 단정하지 마세요. 해당 디렉터리에 rules 폴더를 만들고 규칙 파일을 저장한 다음 provider 선언을 전체 설정에 병합하세요. 기본 규칙 앞에 서비스 규칙을 배치하며, 예제의 대상은 외부 프록시 그룹에 의존하지 않는 직접 연결입니다.

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

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

위 규칙 파일의 내용은 다음과 같습니다. 매칭 조건만 포함하며 프록시 서버, 그룹 정의, 전역 DNS 설정은 들어 있지 않습니다. domain 유형을 사용한다면 해당 유형의 도메인 목록 문법에 맞춰 작성해야 합니다. classical 파일에서 항목 하나만 바꾸어 다른 유형으로 사용할 수는 없습니다. 불러오기 오류가 발생하면 provider의 동작 유형과 파일 형식을 먼저 대조하고 파일 내용을 확인한 뒤, 마지막으로 규칙 자체가 의도에 맞는지 점검하세요.

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

로컬 파일에서 원격 출처로 전환하기

원격으로 관리하려면 출처 유형을 http로 바꾸고 실제 규칙 주소를 지정한 뒤 별도의 캐시 경로와 적절한 업데이트 간격을 설정하세요. interval의 단위는 분이 아니라 초입니다. 각 provider에 서로 다른 경로를 지정해 한 세트가 업데이트될 때 다른 세트를 덮어쓰지 않도록 하세요. 원격 출처에는 규칙 파일의 실제 콘텐츠 주소를 사용해야 하며 웹 미리보기 주소는 사용할 수 없습니다. 다운로드 요청이 성공하더라도 HTML 로그인 페이지나 접근 안내 페이지는 규칙 데이터로 불러올 수 없습니다.

출처를 고를 때는 세트의 크기보다 관리 범위, 항목 유형, 업데이트 방식을 확인하세요. 지나치게 넓은 범위를 다루는 세트는 예상한 트래픽 분기를 바꿀 수 있으며 특히 업무 네트워크, 내부 도메인, 특정 앱의 로그인 동작에 영향을 줄 수 있습니다. 처음 도입할 때는 개인 예외 규칙을 세트보다 앞에 두고 소수의 대상으로 확인한 뒤 적용 범위를 넓히세요. 최근 정상 작동한 로컬 설정을 보관하고, 캐시 동작은 실제 커널과 클라이언트를 기준으로 확인하세요. 네트워크 연결이 끊겨도 빈 캐시에서 반드시 시작할 수 있다고 가정하지 마세요.

규칙 순서와 파싱 시 주의점

규칙은 위에서 아래로 확인하며 먼저 일치하는 규칙에서 멈춥니다. 정확한 도메인 예외를 먼저 두고, 범위가 넓은 도메인 접미사 규칙과 규칙 세트는 뒤에 배치하며, 마지막에 MATCH로 나머지 트래픽을 처리하세요. IP 유형 규칙은 도메인을 확인하기 위해 먼저 이름을 해석해야 할 수 있어 추가 대기 시간이 생깁니다. 해당 규칙에서 no-resolve를 사용하면 규칙 판정을 위해 직접 해석을 시작하지 않도록 할 수 있지만 모든 규칙에 적용되는 만능 옵션은 아닙니다. 도메인 기준으로 정책을 선택해야 한다면 일반적으로 도메인 규칙을 먼저 두고 주소 판정이 필요한 규칙을 뒤에 배치하세요.

특정 대상의 트래픽 분기가 잘못되면 연결 상세 정보에서 실제로 일치한 규칙을 먼저 확인하세요. 앞쪽의 범위가 넓은 세트와 일치했다면 뒤에 있는 개인 예외는 실행되지 않습니다. 기본 규칙만 일치했다면 도메인 정보가 있는지, 규칙 파일이 로드됐는지, 대상이 다른 관련 도메인을 사용하는지 확인하세요. 로그에 규칙 다운로드 실패가 표시되면 출처 접속과 캐시 디렉터리 권한을 점검하세요. 대상 하나가 매칭되지 않는다는 이유로 모든 규칙 세트를 한꺼번에 바꾸지 마세요. 문제 범위만 커집니다.

장기적으로 관리하려면 각 출처의 용도와 예상되는 대상 정책을 기록하세요. provider를 삭제하기 전에 모든 RULE-SET 참조를 검색하고, 그룹 이름을 바꿀 때는 참조 대상도 함께 수정하세요. 개인 예외는 작은 로컬 세트에, 일반 분류는 원격 세트에 관리하면 업데이트 위험을 명확한 범위로 제한할 수 있습니다. 복잡한 트래픽 분기에 필요한 용어는 개념 빠른 참조에서 확인한 뒤 연결 기록으로 결과를 검증하세요.

DNS 경로와 이름 해석 최적화

먼저 누가 이름을 해석하는지 구분한 다음 DNS 서버를 선택하세요. 앱은 시스템 DNS, 브라우저 내장 암호화 DNS를 사용하거나 자체 DNS 서버에 직접 요청할 수 있습니다. 커널도 프록시 서버 주소나 규칙 판정을 위해 별도의 조회를 시작할 수 있습니다. 이 요청들이 자동으로 같은 경로를 사용하는 것은 아닙니다. nameserver만 바꿔도 앱이 커널을 우회해 이름을 해석한다면 화면의 설정값이 맞더라도 실제 결과는 달라지지 않습니다. 문제를 확인할 때는 먼저 대상의 DNS 조회가 커널에 들어오는지 확인하고, 다음으로 어떤 상위 DNS 서버가 선택되는지 살펴보세요.

기본 DNS, 상위 서버, 노드 도메인

default-nameserver는 주로 도메인으로 지정된 DNS 상위 서버의 주소를 조회하는 데 사용하며, 일반적으로 직접 연결할 수 있는 IP 주소를 지정합니다. nameserver는 일반적인 상위 DNS 서버 목록입니다. proxy-server-nameserver는 프록시 서버 도메인을 해석할 때 사용할 수 있어, 아직 연결되지 않은 프록시 경로에 다시 의존하는 문제를 방지합니다. 네트워크마다 접속할 수 있는 DNS 서버가 다릅니다. 공용 DNS 주소는 선택 예시일 뿐이므로 사용 전에 접근 가능한지, 올바른 응답을 받을 수 있는지 확인하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

여기에 설정하는 로컬 수신 포트는 DNS 서비스를 제공하며 HTTP 프록시 연결 포트가 아닙니다. 1053으로 설정해도 시스템 DNS가 자동으로 이 포트를 사용하지는 않습니다. 운영체제의 일반 DNS 설정은 보통 표준 포트를 사용하므로 다른 포트를 연결하려면 클라이언트 통합, 포워딩 또는 TUN 가로채기가 필요합니다. 먼저 클라이언트가 시스템 DNS 요청을 어떻게 처리하는지 확인한 다음 수신 주소를 검토하세요. 다른 기기에서 접근하도록 모든 주소에서 수신하게 바꾸지 마세요. DNS 서비스도 접근 범위를 제한해야 합니다.

도메인별 DNS 경로 지정

nameserver-policy는 내부 도메인, 특수 서비스, 특정 DNS 서버의 응답이 필요한 도메인에 적합합니다. 회사 내부 도메인은 사내 DNS만 해석할 수 있어 공용 DNS에 보내면 존재하지 않는 주소로 응답할 수 있습니다. 공용 서비스에는 안정적인 암호화 DNS 경로가 필요할 수 있습니다. 정책 매칭에는 해당 필드가 지원하는 도메인 문법을 사용하세요. 일반 rules 항목을 그대로 넣으면 안 됩니다. 명확한 도메인 접미사 하나에 정책을 설정해 응답을 확인한 뒤 적용 범위를 넓히세요.

respect-rules를 활성화하면 DNS 상위 서버 요청이 규칙에 따라 경로를 선택하므로 프록시 서버 도메인을 안정적으로 해석할 방법도 마련해야 합니다. 그렇지 않으면 프록시 연결을 위해 서버 주소를 해석해야 하지만 DNS 서버에 접속하려면 이미 프록시가 작동해야 하는 순환 의존성이 생길 수 있습니다. 이 문제를 점검할 때는 프록시 서버 이름 조회를 직접 연결할 수 있는 상위 서버로 분리한 뒤 DNS 서비스가 복구되는지 확인하세요. 상위 DNS 서버 목록이 길다고 신뢰성이 높아지는 것은 아닙니다. 서버가 많으면 응답 차이와 문제 해결의 복잡성만 커질 수 있습니다.

캐시, IPv6, 문제 진단

DNS를 변경한 뒤에도 브라우저, 운영체제, 커널이 이전 캐시를 보관할 수 있습니다. 확인할 때는 기존 연결을 닫고 클라이언트가 지원하는 방법으로 캐시를 지운 다음 새 조회를 실행하세요. 이전에 열었던 페이지를 한 번 새로고침한 결과만으로 새 설정이 작동하지 않는다고 판단하지 마세요. 시스템 조회 도구에서 확인한 결과는 해당 도구의 DNS 경로만 보여줍니다. 브라우저에서 별도의 보안 DNS를 사용하면 결과가 다를 수 있습니다. 필요하면 테스트하는 동안 DNS 경로를 일시적으로 통일하고 완료한 뒤 평소 설정으로 되돌리세요.

IPv6는 DNS가 IPv6 주소를 반환하는지, 시스템에 사용 가능한 경로가 있는지, 프록시 노드가 해당 목적지 주소를 지원하는지, TUN이 관련 트래픽을 처리하는지를 함께 살펴야 합니다. DNS 항목 하나만 끈다고 다른 앱에서 IPv6 요청을 더 이상 보내지 않는 것은 아닙니다. 일부 사이트가 열리기까지 기다려야 한다면 연결이 먼저 접근할 수 없는 주소를 시도한 뒤 다른 주소 체계로 전환하는지 확인하세요. 원인을 파악한 뒤 조정하고 모든 대기 시간을 노드 지연 탓으로 돌리지 마세요.

로그에 DNS 시간 초과가 표시되면 상위 서버 주소에 접속할 수 있는지와 DNS 순환 의존성을 먼저 확인하세요. 주소를 받았는데 연결에 실패하면 규칙의 출구와 대상 서비스를 점검하세요. 내부 도메인만 문제가 있다면 전체 프록시 그룹을 바꾸기보다 도메인 정책과 사내 DNS를 우선 확인하세요. DNS 요청 진입, 상위 서버 선택, 주소 응답, 서비스 연결 순서로 살펴보면 공용 DNS를 계속 바꾸는 것보다 효과적입니다. 자세한 로그 확인 방법은 실행 로그 읽는 방법을 참고하세요.

TUN 전체 트래픽 처리와 Fake-IP

TUN은 트래픽이 들어오는 경로이고 Fake-IP는 DNS 매핑 방식이므로 같은 스위치가 아닙니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 조정해 시스템 프록시를 따르지 않는 프로그램의 트래픽도 커널로 전달할 수 있습니다. Fake-IP는 도메인에 매핑 주소를 반환하고 커널이 연결을 받으면 해당 도메인으로 다시 연결합니다. 함께 사용하면 도메인 정보를 유지하는 데 도움이 되지만 모든 기기와 앱에 적합한 것은 아닙니다. 브라우저가 이미 시스템 프록시를 정상적으로 사용하고 있다면 실제 필요에 따라 TUN 도입 여부를 결정하세요.

활성화 조건과 최소 처리 설정

데스크톱 플랫폼에서는 보통 관리자 권한, 서비스 모드 또는 네트워크 설정 권한이 필요하고, 모바일 플랫폼에서는 시스템 VPN 인터페이스를 사용합니다. 권한 부족, 서비스 미실행, 다른 VPN의 네트워크 인터페이스 점유는 트래픽 처리에 영향을 줍니다. 먼저 클라이언트에서 서비스 상태를 확인한 다음 TUN을 활성화하세요. enable을 true로 바꾸는 것만으로 경로가 설정되지는 않습니다. 아래는 자주 사용하는 mihomo 항목입니다. YAML에서 직접 관리할 수 있는지, 클라이언트가 같은 이름의 설정을 관리하는지 먼저 확인하세요.

tun:
  enable: true
  stack: system
  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는 출구 인터페이스를 식별합니다. 여러 네트워크 어댑터, 가상 머신, 기업 VPN 환경에서는 적절하지 않은 인터페이스가 선택될 수 있습니다. dns-hijack는 가로챌 수 있는 일반 DNS 요청을 대상으로 하며 앱 자체의 DoH를 자동으로 해독하지는 않습니다. stack은 프로토콜 스택 구현을 선택하는 항목입니다. system, gvisor 등 지원되는 방식의 사용 가능 여부는 플랫폼과 커널 빌드에 따라 다르므로 이름만 보고 어느 쪽이 더 빠르다고 판단하지 마세요.

Fake-IP 매핑과 호환성 예외

Fake-IP 주소는 대상 서버의 실제 주소가 아니므로 일반적인 공용 인터넷 주소 연결 테스트에 사용하지 마세요. Fake-IP는 커널이 도메인과 매핑 주소의 관계를 보관하는 방식이므로 DNS 조회와 이후 연결이 같은 처리 체계에 들어와야 합니다. 앱이 이전 매핑을 캐시하고 있는데 커널의 매핑 상태가 바뀌면 잠시 접속 문제가 발생할 수 있습니다. 주소 범위를 변경하거나 DNS 모드를 바꾼 뒤에는 필요에 따라 캐시를 지우고 연결을 다시 만들어 매핑 불일치를 규칙 오류로 오해하지 않도록 하세요.

일부 로컬 네트워크 서비스, 기기 검색, 게임 또는 실제 주소 확인이 필요한 앱은 fake-ip-filter에 추가해야 합니다. 위 예제는 흔히 쓰이는 로컬 도메인 접미사일 뿐 모든 내부 네트워크를 포함하지는 않습니다. 실제 문제가 발생한 도메인을 기준으로 예외를 추가하고 모든 도메인을 필터링하지 마세요. 필터링한 도메인은 보통 실제 DNS 응답을 받습니다. 이후에도 도메인 기준으로 트래픽을 분기할 수 있는지는 조회 경로, 캐시 연결, 스니핑 기능에 따라 달라집니다. 이는 호환성을 위한 설정이지 직접 연결을 강제하는 규칙이 아닙니다.

트래픽, DNS, 라우팅을 단계별로 점검

활성화한 뒤 새 연결이 커널에 들어오는지 먼저 확인하세요. 연결 기록이 전혀 없다면 권한, 라우팅, 앱 제외 목록을 점검합니다. 연결은 있지만 주소만 표시된다면 DNS가 예상한 경로를 거치는지 확인하세요. 도메인은 식별되지만 출구가 잘못됐다면 규칙 순서와 프록시 그룹을 살펴보세요. 일부 UDP 앱만 문제가 있다면 노드 프로토콜과 서버가 해당 트래픽을 지원하는지도 확인해야 합니다. 웹페이지가 열린다는 사실만으로 모든 프로토콜이 작동한다고 볼 수는 없습니다.

TUN을 끈 뒤에도 인터넷에 연결되지 않으면 커널이 정상적으로 종료됐는지, 시스템 경로가 복구됐는지, DNS가 중지된 서비스 주소를 계속 가리키는지 확인하세요. 먼저 클라이언트에서 서비스를 종료하고 네트워크 설정을 재설정하세요. 가상 네트워크 어댑터를 전부 삭제하는 방법부터 시도하지 마세요. 트래픽 처리의 기본 원리와 프로토콜 스택 선택은 TUN 가상 네트워크 어댑터의 전체 트래픽 처리 방식에서 확인한 뒤 플랫폼에 맞는 설정 범위를 정하세요.

신뢰할 수 있는 확인을 위해 일반 웹페이지, 기존에 시스템 프록시를 사용하지 않던 대상 앱, 로컬 네트워크 서비스, 절전 모드에서 깨어난 뒤의 연결을 모두 테스트하세요. 각 테스트에서 새 연결을 사용하고 실제 규칙과 출구를 확인해야 합니다. TUN은 더 많은 트래픽을 처리하는 만큼 문제 범위도 넓어집니다. 필요한 앱만 처리하고 적절한 예외를 두는 편이 모든 트래픽을 무조건 넣는 것보다 관리하기 쉽습니다.

도메인 스니핑과 규칙 매칭 보완

도메인 스니핑은 연결 대상 정보를 보완하는 기능이지 암호화된 콘텐츠를 모두 읽는 기능이 아닙니다. 앱이 주소에 직접 연결하거나 DNS 요청이 커널을 거치지 않거나 대상 도메인 정보가 사라지면 규칙에서 IP 주소만 확인할 수 있습니다. 스니핑은 HTTP의 Host, 일부 TLS의 SNI, 식별 가능한 QUIC 핸드셰이크 정보처럼 프로토콜 핸드셰이크나 요청 헤더에서 호스트 이름을 가져오려고 시도합니다. 결과는 프로토콜 구현과 개인정보 보호 기능에 따라 달라지므로 모든 연결에서 도메인을 알아낼 수 있는 것은 아닙니다.

먼저 도메인 정보가 없는지 확인하세요

연결 기록에 주소만 계속 표시되고 관련 도메인 규칙도 적용되지 않을 때 스니핑을 우선 고려하세요. 기록에 올바른 도메인이 이미 있다면 규칙 순서, 그룹 선택, 대상에 연결할 수 있는지 확인하는 편이 좋습니다. 스니핑을 활성화하기 전에 DNS와 트래픽 진입 설정이 적절한지 확인하세요. 스니핑은 정보를 보완할 뿐 DNS 서비스를 대신하거나 연결이 커널에 도달하지 않는 문제를 해결하지 않습니다. 보조 계층으로 다뤄야 문제 해결 순서를 명확히 유지할 수 있습니다.

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 매핑 상황의 스니핑 동작과 관련됩니다. override-destination은 스니핑으로 얻은 도메인으로 연결 대상을 덮어쓸지 결정합니다. 먼저 false로 설정하면 대상 정보와 연결 방식이 동시에 바뀌는 일을 피할 수 있습니다. 필요성을 확인한 다음 조정하세요.

대상을 덮어쓰는 방식과 식별 정보만 보완하는 방식

대상을 덮어쓰면 이후 연결이 새 도메인을 기준으로 다시 처리될 수 있어 일부 트래픽 분기 상황에 유용하지만, 앱이 선택한 주소가 달라질 수도 있습니다. 같은 도메인이라도 DNS 서버에 따라 연결 주소가 다를 수 있어 앱이 선택한 주소와 커널이 다시 해석한 주소가 일치하지 않을 수 있습니다. 접속 결과가 바뀌었다면 스니핑된 도메인, 원래 주소, 최종 출구를 모두 확인하세요. 규칙이 IP 규칙에서 도메인 규칙으로 바뀌었다는 사실만으로 수정이 성공했다고 판단하지 마세요.

앱이 암호화된 ClientHello처럼 핸드셰이크의 호스트 이름을 숨기는 방식을 사용하거나 프로토콜 데이터가 스니퍼가 지원하는 형식과 맞지 않으면 커널이 유효한 도메인을 얻지 못할 수 있습니다. 이때 모든 포트 범위를 넓혀도 해결되지 않을 수 있고 오히려 대기 시간과 오인식이 늘어날 수 있습니다. 대상이 처음부터 IP 주소로 지정된 서비스라면 복원할 호스트 이름이 없을 수도 있습니다. 필요한 IP 규칙을 유지하거나 앱 요구에 맞게 트래픽 진입 방식을 조정하세요. 스니핑에 실패할 때마다 설정 오류라고 단정하지 마세요.

스니핑 예외와 확인 방법

로컬 네트워크 기기, 특수 TLS 서비스, 초기 핸드셰이크 시점에 민감한 앱은 실제 도메인에 따라 스니핑 제외 목록에 추가할 수 있습니다. 먼저 문제를 재현한 다음 범위를 좁혀 예외를 설정하세요. 하나의 예외 때문에 공용 서비스 전체를 제외하지 마세요. 제외 목록은 스니핑 과정에만 영향을 주며 직접 연결 규칙을 의미하지 않습니다. 직접 연결이 필요한 트래픽은 rules에서 대상을 명시해야 합니다. 클라이언트에 따라 모든 스니핑 항목을 설정할 수 없는 경우도 있으므로 화면 설정이 아니라 최종 실행 설정을 기준으로 확인하세요.

확인할 때는 먼저 스니핑을 끄고 대상 앱에서 새 연결 기록을 저장하세요. 그런 다음 같은 범위에서 스니핑을 켜고 연결을 다시 만든 뒤 도메인, 규칙, 접속 결과를 비교합니다. 브라우저로 테스트한다면 이미 만들어진 연결 풀을 재사용하지 않도록 주의하세요. 새 연결에서 예상한 도메인을 얻고 접속 동작도 안정적일 때만 적용 범위를 넓히세요. 필요하면 로그 상세 수준을 잠시 높이되 테스트가 끝나면 기본 수준으로 되돌려 출력량과 개인 접속 기록의 저장을 줄이세요.

QUIC 식별 여부는 UDP 트래픽이 실제로 커널에 들어오는지에도 달려 있습니다. 시스템 프록시만으로 모든 앱의 UDP가 프록시를 거치게 할 수는 없습니다. TUN이나 앱 자체 지원이 적절한 진입 경로를 제공할 수 있습니다. 같은 사이트의 TCP 연결은 식별되지만 UDP 연결 기록이 없다면 스니핑 포트를 반복해서 바꾸지 말고 먼저 트래픽 진입 경로를 확인하세요. 특정 프로토콜에서만 문제가 생기는 앱은 도메인만 기록하는 것보다 연결 프로토콜도 함께 기록하는 편이 유용합니다.

스니핑 정보가 없어도 합리적으로 처리할 수 있는 기본 규칙 구조를 유지하세요. 도메인 규칙으로 주된 트래픽을 분류하고, 필요한 네트워크 대역 규칙으로 명확한 주소 범위를 처리하며, 마지막 기본 규칙으로 식별되지 않은 연결을 받습니다. 스니핑은 분류 정확도를 높일 수 있지만 전체 설정에서 유일한 식별 수단이 되어서는 안 됩니다. 그래야 앱 업데이트, 네트워크 변경, 프로토콜 개인정보 보호 기능 강화 이후에도 설정 동작을 설명할 수 있습니다.

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

개인 규칙은 로컬 오버라이드에 두고 구독 원본은 업데이트에 맡기세요. 다운로드한 구독을 직접 수정하면 다음 새로고침 때 변경 내용이 사라질 수 있습니다. 구독 내용을 복사해 영구 로컬 파일로 만들면 정상적인 업데이트를 받을 수 없게 됩니다. 관리하기 쉬운 방법은 출처 계층, 클라이언트 설정 계층, 오버라이드 계층을 구분하는 것입니다. 프록시 데이터는 구독에 따라 변경하고 포트, 서비스 그룹, 개인 예외는 안정적으로 유지하세요. 기능 이름은 오버라이드, 확장, 병합, 스크립트 등 클라이언트마다 다를 수 있으므로 화면 이름만 보고 병합 방식을 판단하지 마세요.

객체, 목록, 병합 순서

객체 항목은 재귀적으로 병합되거나 통째로 교체될 수 있습니다. 목록은 뒤에 추가되거나 앞에 삽입되거나 전체가 덮어써질 수 있습니다. 특히 rules에서 개인 예외를 MATCH 뒤에 추가하면 적용되지 않습니다. 먼저 인식하기 쉬운 도메인 예외 하나로 앞쪽 삽입이 작동하는지 확인한 뒤 규칙을 추가하세요. dns를 수정할 때도 기존 상위 DNS 서버와 정책이 유지됐는지 살펴보세요. 새 항목이 보인다는 이유만으로 기존 설정도 적용되고 있다고 가정하면 안 됩니다.

아래 예제는 최종 설정에서 기대하는 규칙 순서를 보여주는 것이며 모든 클라이언트에서 사용하는 오버라이드 파일 문법은 아닙니다. 개인 예외를 앞에 두고 기존 서비스 규칙을 중간에 유지하며 마지막에는 기본 규칙 하나만 둡니다. 클라이언트에서 별도의 prepend 또는 append 형식을 요구한다면 해당 클라이언트의 안내를 따르세요. 최종 실행 설정의 일부를 모든 클라이언트가 지원하는 확장 형식으로 간주하면 안 됩니다. 병합 결과를 확인하는 공통 기준은 실행 설정입니다.

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

여러 구독을 병합할 때는 먼저 이름 충돌을 해결하세요

서로 다른 출처에서 같은 그룹 이름이나 노드 이름을 사용하는 경우가 많아 단순히 이어 붙이면 참조 대상이 불분명해질 수 있습니다. 병합 전에 각 출처에 안정적인 식별자를 정하고 이름이 겹칠 때 어떻게 처리되는지 확인하세요. 자동으로 접두사를 추가하면 수동으로 작성한 구성원 목록과 필터 표현식도 함께 수정해야 합니다. 표시 이름만 바꾸고 참조를 그대로 두면 그룹 구성원을 찾지 못할 수 있습니다. 임시 테스트 이름을 장기적인 서비스 대상으로 사용하지 마세요. 서비스 규칙은 로컬에서 정의한 안정적인 상위 그룹을 참조하도록 구성하는 편이 좋습니다.

proxy-providers를 사용하면 출처별로 관리한 뒤 그룹의 use로 출처를 참조할 수 있습니다. provider URL은 민감한 구독 정보이므로 개인 설정에만 보관하고 공개 화면 캡처나 도움 요청 자료에 포함하지 마세요. 아래 예제는 로컬 프록시 데이터 출처를 사용하며 파일에 유효한 데이터를 미리 준비해야 합니다. 완전한 구독이 아니고 사용할 수 있는 노드도 제공하지 않습니다. 출처에 프록시 항목이 없다면 출처 자체를 먼저 확인해야 합니다. 그룹에서 자동으로 출구가 만들어지기를 기대하지 마세요.

proxy-providers:
  personal-source:
    type: file
    path: ./providers/personal.yaml

proxy-groups:
  - name: 구독 출구
    type: select
    use:
      - personal-source

원격 프록시 출처에는 커널이 지원하는 프록시 모음 형식의 데이터를 제공해야 합니다. 완전한 GUI 설정을 provider 콘텐츠로 바로 사용할 수 있는 것은 아닙니다. 구독 변환이나 클라이언트 가져오기 과정에서 프록시 항목을 추출할 수도 있지만 지원 여부는 구현에 따라 다릅니다. 출처는 정상적으로 불러왔는데 구성원이 없다면 DNS를 바꾸기 전에 데이터 구조, 필터 조건, 이름 변경 규칙을 확인하세요. 필터 조건이 너무 넓으면 원하지 않는 구성원이 포함되고, 너무 좁으면 출처가 비어 있을 수 있습니다.

오버라이드 스크립트의 범위

스크립트는 중복 제거, 이름 통일, 규칙 일괄 삽입에 적합하지만 입력과 출력 범위가 명확해야 합니다. 배열을 수정하기 전에 항목이 있는지 확인하고, 규칙을 추가하기 전에 이미 들어 있는지 확인해 업데이트할 때마다 중복 규칙이 쌓이지 않도록 하세요. 출처에 문제가 생겨도 진단 가능한 오류 정보를 유지해야 하며 빈 설정을 반환해서는 안 됩니다. 클라이언트마다 스크립트 인터페이스가 다릅니다. 고정 포트 하나를 설정하기 위해 복잡한 스크립트를 도입할 필요는 없습니다.

병합을 마친 뒤 세 가지 상황을 확인하세요. 개인 예외가 일반 규칙보다 앞에 있는지, 서비스 그룹에 예상한 출처가 포함됐는지, 구독을 업데이트한 뒤에도 오버라이드가 유지되는지 살펴봅니다. 빈 출처나 출처 다운로드 실패도 테스트해 사용할 수 없는 구조를 화면에서 정상 설정으로 취급하지 않는지 확인하세요. 구독이 여러 개면 서로 독립적인 장애 지점도 늘어납니다. 단일 출처로 작동하는 설정을 하나 보관해 두면 문제가 생겼을 때 범위를 빠르게 좁힐 수 있습니다.

이전 클라이언트에서 옮길 때는 구독 주소와 필요한 서비스 규칙부터 이전한 다음 DNS, TUN, 스크립트를 하나씩 복원하세요. 이전 파일의 UI 항목이나 확장 문법은 새 클라이언트에서 인식되지 않을 수 있으므로 파일 확장자가 같다는 이유만으로 전체 설정을 교체하지 마세요. 기존 Clash for Windows와 ClashX Meta는 유지 관리가 중단된 아카이브 선택지입니다. 이전 방법은 지원 종료 후 설정 이전 가이드를 참고하고 플랫폼에 맞는 앱은 클라이언트 비교에서 확인하세요.

외부 컨트롤 패널과 실행 진단

외부 컨트롤러는 커널 관리 인터페이스를 제공하며 패널은 이를 통해 상태 확인, 프록시 그룹 전환, 연결 조회를 수행합니다. 프록시 연결 포트도 DNS 수신 포트도 아닙니다. 브라우저의 프록시를 컨트롤러 포트로 지정해도 정상적인 프록시 연결이 되지 않습니다. 패널 연결 주소에 혼합 포트를 지정해도 커널을 관리할 수 없습니다. 패널을 설정하기 전에 포트별 역할부터 구분하세요. 대부분의 데스크톱 사용자는 클라이언트 내장 패널을 사용하면 됩니다. 서버나 독립 커널 환경에서만 별도의 관리 접근을 열어야 할 수 있습니다.

로컬 수신과 접근 인증

일반적인 단일 기기 설정은 루프백 주소에서 수신하는 것이 좋습니다. 아래 예제의 secret은 설명을 위한 임의의 값입니다. 사용 전에 충분히 강한 무작위 값으로 바꾸고 개인 설정에만 저장하세요. secret은 제어 인터페이스를 보호하기 위한 값이지 로컬 네트워크 프록시 인증을 대신하지 않습니다. 로컬에서만 수신하더라도 다른 로컬 프로그램이 접근할 위험을 고려해야 합니다. 원격 관리가 필요하면 관리 포트를 직접 공개하는 대신 통제된 터널을 통해 접속하세요.

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"
log-level: info

클라이언트가 컨트롤러 주소와 인증을 자동으로 설정할 수 있으므로 직접 작성한 항목이 최종값이 아닐 수 있습니다. 패널에 연결하기 전에 실행 설정이나 클라이언트의 관리 연결 정보를 확인하세요. 패널 설정의 호스트, 포트, 프로토콜, 인증은 같은 커널 인스턴스에 해당해야 합니다. 컴퓨터에서 클라이언트를 여러 개 실행 중이면 패널이 이전 인스턴스에 연결돼 그룹을 바꿔도 반영되지 않는 것처럼 보일 수 있습니다. 먼저 현재 인스턴스를 확인한 다음 인터페이스가 작동하는지 살펴보세요.

패널 파일과 브라우저 접근 제한

external-ui는 로컬 패널 리소스 디렉터리를 지정합니다. 해당 디렉터리에는 페이지와 관련 정적 파일이 모두 있어야 합니다. 존재하지 않는 폴더를 임의로 지정하거나 클라이언트 설치 디렉터리를 패널 경로로 사용하지 마세요. 서버에 배포할 때는 패널 리소스, 커널 설정, 캐시 경로의 권한을 각각 관리하고 패널을 업그레이드한 뒤 리소스 경로가 여전히 올바른지 확인하세요. 내장 패널만 사용하는 경우에는 보통 이 항목을 직접 설정할 필요가 없습니다.

브라우저에서 연결에 실패하면 인증 오류, 교차 출처 제한, 혼합 콘텐츠 차단이 원인일 수 있습니다. HTTPS 페이지에서 HTTP 컨트롤러에 접속하면 포트가 열려 있어도 브라우저가 요청을 차단할 수 있습니다. 다른 출처의 별도 패널은 커널의 교차 출처 설정도 충족해야 합니다. 편의를 위해 모든 출처를 허용하고 컨트롤러를 노출하지 마세요. 가장 쉽게 확인할 방법은 클라이언트가 제공하는 로컬 주소나 동일 출처 패널을 사용하는 것입니다. 먼저 정상 작동을 확인한 뒤 원격 접근 방식을 확장하세요.

실행 기록으로 문제 해결 과정을 마무리하세요

먼저 연결 목록에서 대상 도메인이나 주소, 일치한 규칙, 프록시 그룹 경로, 출구를 확인하세요. 설정 결과를 판단하는 핵심 정보입니다. 같은 시간대의 로그를 살펴 DNS 시간 초과, 연결 시도 실패, 연결 거부, 규칙 불일치를 구분합니다. 로그 수준을 info에서 debug로 잠시 높인 뒤 대상 문제를 한 번만 재현하고 필요한 정보를 수집한 다음 기본 수준으로 되돌리세요. 상세 로그를 계속 활성화하면 저장 공간을 더 사용하고 접속 메타데이터도 더 많이 보관할 수 있습니다.

문제를 재현할 때는 시간, 앱, 대상, 현재 모드, 트래픽 진입 방식, 예상 정책을 기록하세요. 웹페이지가 열리지 않는데 연결 목록에 기록이 전혀 없다면 앱의 진입 경로와 시스템 프록시를 확인하세요. 기록은 있지만 도메인이 없다면 DNS와 스니핑을 살펴봅니다. 규칙은 맞지만 연결 시도가 실패하면 노드와 원격 대상을 확인하세요. 전환 후에도 이전 출구를 사용하면 장시간 연결을 점검합니다. 이 순서대로 확인하면 DNS 문제를 해결하려고 노드를 계속 바꾸거나 노드 문제 때문에 라우팅을 반복해서 수정하는 일을 피할 수 있습니다.

진단 자료를 공유할 때는 관련 연결과 짧은 구간의 로그만 캡처하고 구독 주소, 인증 정보, 개인 접속 기록을 숨기세요. 규칙 이름과 그룹 이름은 경로 구조를 설명하는 데 필요한 경우 남겨도 됩니다. 프록시 서버 정보는 실제 개인정보 보호 요구에 따라 처리하세요. 실행 디렉터리 전체를 업로드하지 마세요. 캐시, 구독 정보, 클라이언트 설정이 함께 포함돼 있을 수 있습니다. 문제를 재현하는 데 필요한 최소 자료만 공유하면 정보 노출을 줄이고 문제도 정확히 전달할 수 있습니다.

유지 관리가 끝나면 정상적으로 작동하는 기본 상태로 돌아가세요. 규칙 모드, 기본 로그 수준, 필요한 수신 범위, 예비 설정을 확인합니다. 클라이언트를 한 번 다시 시작해 설정이 현재 세션에서만 유효한 것이 아닌지 확인하고 구독을 새로고침한 뒤에도 개인 규칙이 유지되는지 점검하세요. 처음 설정하는 중이라면 시스템 프록시 시작하기를 참고하세요. 항목의 의미는 개념 빠른 참조에서 확인할 수 있습니다. 고급 설정의 목표는 가능한 한 많은 스위치를 추가하는 것이 아니라 동작을 설명하고 변경을 검증하며 문제 발생 시 되돌릴 수 있게 하는 것입니다.