완전 정복
Clash 핸드북

핵심 개념: 네 가지 용어의 역할부터 명확히

Clash를 처음 시작할 때 막히는 사람들의 90%는 조작이 아니라 용어에서 막힙니다. 코어, 클라이언트, 구독, 규칙 — 이 네 단어는 각각 다른 역할을 맡습니다. 역할을 먼저 정리하면 이후 모든 챕터가 수월해집니다.

코어와 클라이언트: 하나의 엔진, 여러 개의 얼굴

실제로 트래픽을 처리하는 것은 코어입니다 — 현재 주류 구현체는 mihomo(커뮤니티에서는 흔히 Clash Meta 코어라 부름)입니다. 코어는 명령줄 프로그램으로, YAML 설정 파일을 읽어 로컬 포트를 감시하고 규칙에 따라 각 연결을 프록시 또는 다이렉트로 전달합니다. 화면이 없고 미관을 신경 쓰지 않으며 오직 전달만 담당합니다.

데스크톱이나 모바일에서 열어보는 Clash Plus, Clash Verge Rev, FlClash 같은 프로그램은 모두 클라이언트입니다. 이들은 코어를 내장하거나 호출하여 "설정 파일 수정"을 스위치와 버튼으로, "로그 확인"을 그래프와 목록으로 바꿔줍니다. 클라이언트를 바꿔도 코어는 바뀌지 않고, 설정 파일은 대부분의 클라이언트 사이에서 호환됩니다 — 이것이 바로 이 핸드북의 원리 부분이 모든 클라이언트에 적용되는 이유입니다.

노드, 구독, 설정 파일: 세 겹의 그릇

노드는 프록시 서버의 연결 파라미터입니다: 주소, 포트, 프로토콜, 비밀번호. 구독은 URL로, 접속하면 여러 노드가 반환됩니다(보통 완전한 설정으로 패키징됨). 서비스 제공자가 관리하며 노드가 바뀌면 구독만 새로고침하면 됩니다. 설정 파일(Profile)은 코어가 실제로 읽는 YAML로, 노드 외에도 포트 설정, DNS, 프록시 그룹, 규칙을 포함합니다 — 구독으로 받아온 내용은 최종적으로 하나의 Profile로 정리됩니다. 세 겹의 관계: 노드는 구독에 담기고, 구독은 설정 파일을 생성하며, 설정 파일은 코어에 공급됩니다.

프록시 그룹과 규칙: 트래픽의 관제탑

프록시 그룹은 여러 노드를 선택 가능한 대열로 묶습니다. 예를 들어 "수동 선택" 그룹은 직접 고를 수 있게 하고, "자동 테스트" 그룹은 지연 시간에 따라 자동으로 전환합니다. 규칙은 위에서 아래로 매칭되는 목록으로, 어떤 연결이 어떤 프록시 그룹으로 갈지 또는 다이렉트로 갈지를 결정합니다: 국내 사이트는 다이렉트, 특정 도메인은 프록시, 나머지는 기본 규칙으로 처리합니다. 규칙이 누구에게 매칭되느냐에 따라 트래픽이 결정됩니다 — 이 메커니즘은 CH-06에서 자세히 다룹니다.

용어는 이뿐만이 아닙니다. DNS 오염, Fake-IP, GeoIP 같은 용어는 마주쳤을 때 찾아보면 되고 미리 외울 필요는 없습니다. 사이트 내 카테고리별로 정리된 용어집이 있으니 핸드북을 읽는 중 언제든 갈아탈 수 있습니다.

클라이언트 선택: 플랫폼에 맞게 고르기

클라이언트 선택은 두 가지 질문에 답하면 됩니다: 어떤 시스템을 쓰는가, 어느 정도의 커스터마이징이 필요한가. 전 플랫폼 공통 우선 추천은 Clash Plus입니다 — Windows, macOS, Android, iOS 버전이 모두 있고 인터페이스가 통일되어 있으며, 구독 가져오기, 모드 전환, TUN 활성화가 모두 원클릭으로 되어 있어 초보자부터 숙련자까지 충분합니다. 아래는 플랫폼별로 이 사이트 다운로드 페이지에 수록된 조합입니다.

선택할 때 무엇을 볼지

세 가지 기준으로 충분합니다: 유지관리 상태 — 여전히 활발히 업데이트되는 클라이언트를 우선 선택하세요. Clash for Windows와 ClashX Meta는 유지관리가 중단되어 다운로드 페이지에 아카이브 링크만 남겨두었으며 신규 사용자가 이것들부터 시작하는 것은 권장하지 않습니다; 코어 버전 — 클라이언트가 mihomo 코어를 사용하는지 확인해야 새 프로토콜과 새 규칙 유형을 완전히 지원할 수 있습니다; 기능 커버리지 — TUN 모드가 필요하면 해당 플랫폼 버전에서 제공되는지 확인하고, 세밀한 규칙 편집이 필요하면 Verge Rev 계열 도구가 더 적합합니다.

항목별 파라미터 비교, 인터페이스 스타일 차이, 이전 권장사항은 사이트 내 종합 비교 페이지에 자세히 정리되어 있습니다. 결정했다면 클라이언트 다운로드 페이지에서 플랫폼별로 다운로드하세요.

설치: 다섯 플랫폼의 핵심 포인트

설치 자체는 어렵지 않지만 각 플랫폼의 보안 메커니즘이 다른 지점에서 막을 수 있습니다. 이 챕터는 플랫폼별 설치 경로와 허용 방법을 정리했습니다. 설치 후 한 번 실행해서 메인 화면이 열리는지 확인한 다음 다음 챕터에서 구독을 가져오세요.

Windows

다운로드 페이지 Windows 영역에서 설치 파일을 받아 더블클릭으로 실행합니다. 설치 경로는 한글이나 공백이 포함된 폴더를 피해 이후 코어가 설정을 읽을 때 발생하는 경로 문제를 줄이세요. 첫 실행 시 SmartScreen 알림이 뜨면 "추가 정보 → 실행"을 클릭하고, 방화벽이 네트워크 권한을 물으면 전용 네트워크와 공용 네트워크 모두 체크하세요. 그렇지 않으면 로컬 네트워크 관련 기능이 동작하지 않습니다.

macOS

dmg를 다운로드한 뒤 앱을 "응용 프로그램" 폴더로 드래그하세요. 아키텍처에 주의: Apple Silicon(M 시리즈 칩)은 ARM 버전, Intel 기종은 x64 버전을 선택하세요. 아키텍처를 잘못 선택하면 눈에 띄게 느려지거나 실행되지 않습니다. 처음 열 때 개발자를 확인할 수 없다는 알림이 뜨면 "시스템 설정 → 개인정보 보호 및 보안"으로 이동해 페이지 하단의 "그래도 열기"를 클릭하세요. 클라이언트가 처음 시스템 프록시를 설정하거나 보조 서비스를 설치할 때 관리자 비밀번호를 요구하는데 한 번 입력하면 됩니다.

Android

APK를 다운로드해 설치할 때 시스템이 "알 수 없는 앱 설치 허용"을 요구합니다. 팝업으로 뜨는 설정 페이지에서 브라우저나 파일 관리자에 한 번 권한을 부여하세요. 처음 연결을 클릭하면 시스템이 VPN 연결 요청을 표시하는데 — 이것이 Android가 트래픽을 가져가는 표준 방식이므로 반드시 허용해야 프록시가 작동합니다. 국내 제조사 시스템에서는 두 가지에 주의하세요: 클라이언트를 배터리 최적화 화이트리스트에 추가하고 백그라운드 실행을 허용해 잠금화면 상태에서 프록시가 시스템에 의해 종료되지 않도록 하세요.

iOS

iOS용 Clash Plus는 App Store를 통해 배포됩니다. 다운로드 페이지 iOS 영역에서 스토어 페이지로 이동해 설치하세요. 처음 실행 시 안내에 따라 VPN 설정 프로필을 추가하고, 시스템이 비밀번호나 Face ID로 한 번 인증을 요구합니다. 설치 완료 후 구독 가져오기 단계는 다른 플랫폼과 동일하며 다음 챕터에서 설명합니다.

Linux

데스크톱 배포판에는 Clash Verge Rev의 deb 패키지를 추천합니다: sudo apt install ./패키지파일명.deb 한 줄로 완료되며 의존성이 자동으로 해결됩니다. Arch 계열은 AUR에서 커뮤니티가 관리하는 버전을 받을 수 있습니다. 데스크톱 환경이 없는 서버와 라우터 시나리오에서는 GUI를 설치하지 않고 mihomo 코어를 직접 실행합니다. 방법은 CH-09를 참고하세요.

구독과 설정 파일: 노드를 클라이언트에 담기

클라이언트를 설치한 것은 빈 차일 뿐, 구독이 있어야 승객이 생깁니다. 이 챕터는 가져오기 방법, Profile 내부 구조, 여러 설정을 동시에 관리하는 방법을 다룹니다.

구독 가져오기의 표준 동작

서비스 제공자로부터 구독 URL을 복사하세요. 클라이언트의 "설정 / Profiles" 페이지를 열고 "URL에서 가져오기"를 선택해 링크를 붙여넣고 확인하세요. 클라이언트가 구독 내용을 다운로드해 하나의 Profile로 파싱하고 자동으로 활성화합니다. 가져오기 성공의 표시는 프록시 페이지에 노드 목록이 나타나고 노드 이름이 비어있지 않은 것입니다. 가져오기 실패 시 먼저 링크가 완전한지 확인하고(많은 입력란이 줄 끝 문자를 잘라먹습니다), 구독 업데이트 실패 해결법 글을 참고해 항목별로 확인하세요.

Profile의 세 가지 구조

구독으로 받아온 YAML은 보통 세 개의 큰 섹션을 포함합니다: proxies는 노드를 정의하고, proxy-groups는 프록시 그룹을 정의하며, rules는 분流 규칙을 정의합니다. 기본 구조는 다음과 같습니다(값은 예시입니다):

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

proxies:
  - name: "HK-01"
    type: ss
    server: server.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - HK-01

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

한 줄씩 살펴보면: mixed-port는 로컬 감시 포트로, HTTP와 SOCKS 요청이 모두 여기로 들어옵니다; mode는 시작 시의 프록시 모드입니다; proxy-groups의 PROXY라는 이름의 select 그룹은 화면에서 수동으로 노드를 고르는 드롭다운 목록입니다; rules는 위에서 아래로 매칭되고 마지막 MATCH가 기본값으로 처리됩니다. 이 기본 구조를 이해하면 어떤 구독이 생성한 설정이든 이해할 수 있습니다.

다중 설정 관리와 자동 업데이트

여러 구독을 동시에 가져올 수 있지만 한 시점에는 하나의 Profile만 활성화됩니다. 전환하면 전체가 교체됩니다 — 노드와 규칙이 함께 바뀌고, 두 설정의 규칙이 겹쳐 적용되는 일은 없습니다. 관리 팁: 각 설정에 구분 가능한 이름을 붙이세요(서비스 제공자 + 용도), 폐기된 것은 즉시 삭제해 오래된 설정으로 잘못 전환하는 것을 피하세요. 명명 습관과 규칙 덮어쓰기 문제는 다중 설정 전환 관리 글을 참고하세요.

자동 업데이트는 설정 편집 페이지에서 설정하며 보통 "업데이트 간격 / Update Interval" 필드로 불립니다. 12~24시간을 권장합니다: 너무 짧으면 요청이 낭비되고, 너무 길면 서비스 제공자의 노드 교체를 놓칠 수 있습니다. 수동 업데이트 버튼은 보통 설정 카드의 새로고침 버튼에 있으며, 업데이트 전후 타임스탬프 변화를 확인해 실제로 새 내용을 받았는지 확인하세요.

프록시 모드: 규칙, 글로벌, 다이렉트 중 선택

모드는 "규칙 목록이 결정에 참여할지 여부"를 결정합니다. 세 가지 모드, 세 가지 동작:

일상적으로는 규칙 모드를 유지하세요. 글로벌 모드로 국내 사이트에 접속하면 눈에 띄게 느려지고 트래픽도 헛되이 소모됩니다 — "모든 것이 프록시를 탄다"는 것을 발견하면 가장 먼저 모드가 Global로 바뀌었는지 확인하세요.

시스템 프록시: 모드가 작동하는 전제조건

모드를 선택했다면 애플리케이션이 트래픽을 넘겨주도록 해야 합니다. 클라이언트의 "시스템 프록시" 스위치를 켜면 클라이언트가 운영체제에 127.0.0.1:7890(포트는 설정에 따라 다름)을 프록시 서버로 등록하고, 시스템 프록시 설정을 따르는 브라우저 등 애플리케이션이 자동으로 요청을 이 포트로 보냅니다. 경계에 주의하세요: 시스템 프록시를 따르는 애플리케이션만 가져올 수 있습니다. 많은 명령줄 도구와 게임 클라이언트는 이 설정을 무시합니다 — 이것이 바로 CH-07 TUN 모드가 해결하는 문제입니다.

프록시가 작동하는지 확인하기

느낌으로 판단하지 말고 명령어로 확인하세요. 터미널에서 실행:

curl -x http://127.0.0.1:7890 -I https://www.google.com

HTTP/2 200 같은 상태 줄이 반환되면 "로컬 포트 → 노드 → 대상 사이트" 전체 경로가 연결되었다는 뜻입니다; 멈추거나 오류가 나면 문제는 노드나 설정에 있는 것이며 브라우저 문제가 아닙니다. 연결은 성공했는데 웹페이지가 열리지 않는 경우의 전체 점검 순서는 9가지 점검 리스트를 참고하세요.

규칙 분流: 트래픽마다 각자의 길로

규칙 분流는 Clash가 "원클릭 전체 프록시" 도구와 비교해 갖는 핵심적인 차이입니다: 같은 시점에 국내 트래픽은 다이렉트, 해외 트래픽은 프록시, 광고 도메인은 즉시 차단되며 서로 간섭하지 않습니다. 이를 이해하려면 두 가지만 알면 됩니다 — 규칙이 어떻게 생겼는지, 어떤 순서로 매칭되는지.

자주 쓰는 규칙 유형

매칭 순서: 위에서 아래로, 처음 매칭되면 정지

규칙 목록은 첫 줄부터 순서대로 비교하며 매칭되면 즉시 실행하고 이후는 보지 않습니다. 따라서 순서가 곧 우선순위입니다: 정확한 규칙을 앞에, 범위가 넓은 규칙을 뒤에, MATCH는 항상 맨 마지막에 둡니다. 전형적인 규칙 영역:

rules:
  - DOMAIN,dl.example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

읽는 법: 먼저 반드시 다이렉트해야 하는 다운로드 도메인을 허용하고; GitHub 전체 도메인과 google 키워드를 포함한 도메인을 프록시로 보내고; 로컬 네트워크 대역은 다이렉트하며 DNS 해석을 하지 않고(no-resolve로 내부 주소가 해석되어 전송되는 것을 방지); IP 소속이 중국 본토인 것은 다이렉트하고; 나머지 전부는 프록시로 보냅니다. 어떤 사이트가 잘못된 경로로 갔다면 위에서부터 그 사이트를 매칭시킨 첫 번째 줄을 찾으면 답이 그 줄에 있습니다.

사용자 규칙을 추가하는 올바른 방법

구독은 매번 업데이트될 때 Profile 전체를 덮어씁니다. 구독 파일 안의 규칙을 직접 수정하면 다음 업데이트 때 사라집니다. 올바른 방법은 클라이언트가 제공하는 영구 저장 메커니즘을 사용하는 것입니다: Clash Verge Rev의 "전역 확장 설정 / Merge", 각 클라이언트의 오버라이드(Override) 기능은 모두 사용자 규칙을 구독 업데이트마다 자동으로 맨 앞에 병합해줍니다. 원칙은 동일합니다: 사용자 규칙을 구독 규칙보다 앞에 두어야 우선적으로 매칭됩니다.

GeoIP 데이터베이스

GEOIP,CN,DIRECT가 작동하는 것은 로컬에 있는 IP 소속 국가 데이터베이스 덕분입니다. 데이터베이스가 오래되면 새로 할당된 국내 IP를 해외로 오판해 "국내 사이트인데 이상하게 프록시를 탄다"는 현상이 나타납니다. 클라이언트 설정에 보통 "GeoIP / Geo 데이터 업데이트" 버튼이 있으니 한두 달에 한 번 클릭하면 됩니다. 업데이트 후에는 코어를 재시작해야 적용됩니다.

TUN 모드: 시스템 프록시가 관리하지 못하는 트래픽 처리

CH-05에서 시스템 프록시의 경계를 언급했습니다: 그것은 "신사협정"으로 따르려는 애플리케이션만 규제합니다. 명령줄 도구, 일부 데스크톱 소프트웨어, 게임 클라이언트는 종종 이를 우회해 직접 네트워크에 접속합니다. TUN 모드는 다른 접근 방식으로 네트워크 계층에서 문제를 해결합니다.

원리: 가상 네트워크 카드 하나

TUN을 켜면 코어가 시스템 안에 가상 네트워크 카드를 만들고 기본 경로를 그곳으로 향하게 합니다 — 이후 모든 아웃바운드 트래픽은 애플리케이션이 협조하든 안 하든 먼저 이 가상 카드를 거쳐 코어로 들어가고 동일한 규칙 세트로 분流됩니다. 시스템 프록시는 "애플리케이션이 저를 찾아오세요"이고, TUN은 "모든 차량은 반드시 이 검문소를 지나야 합니다"입니다. 대가는 더 높은 권한이 필요하다는 점입니다(Windows에서는 보통 서비스 모드 설치가 필요하고, macOS에서는 시스템 확장 권한이 필요함) 그리고 이에 맞춘 DNS 설정도 필요합니다.

DNS와 Fake-IP

TUN 환경에서는 반드시 코어 DNS를 활성화해야 합니다. 그렇지 않으면 도메인 해석이 코어를 거치지 않아 규칙 속 도메인 유형이 작동하지 않습니다. Fake-IP 모드를 권장합니다: 코어가 먼저 예약된 대역의 가짜 IP를 반환해 연결이 즉시 성립되고, 실제 해석은 전달 시점으로 미뤄져 대기 시간을 줄입니다. 설정 예시:

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query

활성화 단계와 확인 방법

주요 클라이언트는 이 설정을 스위치로 만들어두어 직접 작성할 필요가 없습니다. Windows: 설정에서 먼저 "서비스 모드"를 설치하고(관리자 권한 필요) 상태가 실행 중으로 바뀐 뒤 TUN 스위치를 켜세요; macOS: TUN 스위치를 켜고 시스템 안내에 따라 네트워크 확장 권한을 부여하며 비밀번호를 한 번 입력하세요. 확인 방법: 시스템 프록시 스위치를 끄고 TUN만 남긴 뒤 터미널에서 시스템 프록시를 거치지 않는 명령을 실행하세요(예: nslookup github.com). 해석 결과가 198.18로 시작하는 가짜 IP 대역에 떨어지면 DNS 하이재킹이 작동하고 TUN이 제자리에 있다는 뜻입니다.

일상 유지관리: 프록시를 장기적으로 안정시키는 정기 작업

설정을 마친 것은 시작일 뿐입니다. 프록시는 장기적으로 운영되는 인프라이므로 주기적으로 몇 가지 작은 작업을 해두면 "어제까지는 괜찮았는데" 식의 대부분의 문제를 피할 수 있습니다.

노드 속도 테스트와 자동 전환

프록시 페이지의 지연 테스트 버튼은 모든 노드에 한 번씩 테스트 요청을 보내며, 수치는 "로컬 → 노드 → 테스트 주소"의 왕복 밀리초입니다. 경험치: 200ms 이내면 일상 사용에 원활하고 500ms를 넘거나 타임아웃이면 교체하세요. 직접 고르고 싶지 않다면 자주 쓰는 애플리케이션을 url-test 유형의 자동 테스트 그룹으로 지정하면 코어가 주기적으로 최적의 노드를 선택합니다. 지연은 응답 속도만 반영하고 대역폭을 나타내지 않으므로, 영상이 끊기는지는 노드 자체의 품질도 함께 봐야 합니다.

로그로 문제 찾기

클라이언트의 로그(또는 연결) 페이지가 문제 조사의 첫 현장입니다: 각 기록에는 대상 도메인, 매칭된 규칙, 사용된 노드가 포함됩니다. "특정 사이트가 열리지 않음"이 발생하면 먼저 여기서 도메인을 검색하세요 — DIRECT가 매칭됐는데 프록시가 필요하면 규칙 문제이고, 프록시 그룹이 매칭됐는데 타임아웃이면 노드 문제입니다. 방향이 정해지면 수정도 빨라집니다.

부팅 시 자동 실행

데스크톱에서는 설정에서 "부팅 시 시작"을 켜고, 보통 "조용히 시작"과 함께 사용해 트레이 아이콘만 남깁니다. Windows에서 자동 시작이 실패하면 작업 관리자의 시작 항목이 타사 최적화 소프트웨어에 의해 비활성화되었는지 확인하세요; Android는 CH-03의 백그라운드 생존 설정을 참고하세요. 더 많은 빈출 질문은 자주 묻는 질문 페이지에서 "기본 개념 / 설치 설정 / 사용 팁 / 문제 해결" 네 가지로 분류되어 있습니다.

심화 로드맵: 사용에서 이해로, 이해에서 직접 작성으로

앞의 여덜 챕터를 마치면 일상 사용에는 이미 문제가 없습니다. 더 나아가고 싶다면 세 가지 방향을 순서대로 진행하세요.

방향 하나: 직접 작성하고 오버라이드하기

구독을 더 이상 블랙박스로 취급하지 마세요. CH-04의 기본 구조를 현재 적용 중인 Profile과 대조하며 한 단락씩 이해하세요. 그다음 작은 변경부터 시작하세요 — 오버라이드 메커니즘으로 자신의 규칙을 추가하거나, 어떤 프록시 그룹을 select에서 url-test로 바꾸거나, DNS의 nameserver 목록을 조정하세요. 하나씩 바꿀 때마다 설정을 다시 불러오고 로그로 예상대로 동작하는지 확인하세요. 설정을 직접 작성할 수 있으면 어떤 클라이언트도 손안에서 같은 대상이 됩니다.

방향 둘: 코어 직접 실행

서버, NAS, 라우터에는 GUI가 없으니 mihomo 코어를 직접 실행합니다. 다운로드 페이지 코어 영역에서 해당 아키텍처의 압축 파일을 받아 압축을 푼 뒤:

mkdir -p ~/.config/mihomo
mv config.yaml ~/.config/mihomo/
./mihomo -d ~/.config/mihomo

-d는 작업 디렉터리를 지정하며 코어는 여기서 config.yaml과 Geo 데이터 파일을 읽습니다. 포그라운드로 실행이 확인되면 systemd 서비스를 설정해 부팅 시 자동 시작과 크래시 시 재시작을 구현하세요. 로컬 네트워크의 다른 기기는 프록시를 이 기기의 IP와 포트로 지정하면 되는데, 설정에서 allow-lan: true를 기억하세요. 한 대의 기기로 온 집안의 기기를 처리할 수 있습니다.

방향 셋: 외부 제어 API

설정에서 external-controller: 127.0.0.1:9090을 선언하면 코어가 RESTful 인터페이스 세트를 노출합니다 — 노드 전환, 연결 조회, 설정 재로드 모두 HTTP 요청으로 처리할 수 있습니다:

curl http://127.0.0.1:9090/proxies

metacubexd 같은 각종 웹 패널이 이 API를 기반으로 구축되어 있습니다. 이를 활용할 수 있다면 정기 전환, 이상 알림 같은 자동화 스크립트를 작성할 수 있습니다 — 이 단계에 이르면 이미 사용자에서 구축자로 넘어간 것입니다.

로드맵 마무리

1. GUI 클라이언트 하나에 익숙해지고 규칙 모드로 일상 사용에 불편함이 없어지기(CH-01~05);
2. 규칙과 로그를 이해해 "왜 이 사이트가 잘못된 경로로 갔는지" 스스로 파악하기(CH-06, 08);
3. TUN을 켜서 네트워크 계층 인터셉트와 DNS 협업을 이해하기(CH-07);
4. 설정 직접 작성, 코어 직접 실행, API 자동화(본 챕터).

모든 단계는 이전 단계 위에 세워집니다. 어느 역에 도착했든 그 역의 도구를 사용하세요. 직접 손을 대야 할 때는 사용 가이드로 돌아가 대조해가며 작업하고, 장비를 고를 때는 클라이언트 다운로드로 가세요. 노선도는 여기 있으니 출발 시간은 당신이 정하면 됩니다.