Clash 설정 총정리

1. YAML 개요: 파일 구조에서 적용 설정까지

Clash 설정은 단순한 노드 주소 목록이 아니라 서로 참조하는 객체들의 집합입니다. 공통 필드는 진입점과 동작 모드를 선언하고, DNS 필드는 코어의 도메인 해석 방식을 정하며, 프록시 노드는 사용할 출구를 정의하고, 프록시 그룹은 출구를 구성하며, 규칙은 연결을 지정된 대상으로 보냅니다. 낯선 설정을 읽을 때는 먼저 최상위 키를 확인한 뒤 이름 참조를 따라가세요. 수백 개의 규칙부터 읽으면 연결 경로를 실제로 결정하는 진입 설정과 최종 정책을 놓치기 쉽습니다.

들여쓰기, 매핑 및 목록

YAML은 들여쓰기로 계층을 표현합니다. 콜론 뒤에 공백 하나를 두면 키와 값이 구분되고, 보통 하이픈으로 시작하는 항목은 목록 요소입니다. 들여쓰기는 두 칸으로 통일하고 탭은 섞지 마세요. 같은 계층은 반드시 맞춰야 합니다. 최상위의 dns와 rules는 같은 수준에 있고, enable은 DNS 아래에 배치됩니다. 중국어 이름도 사용할 수 있지만 이름 안의 공백, 문장 부호와 대소문자는 참조 내용이므로 다른 곳에서 임의로 바꾸면 안 됩니다.

포트에는 정수를 사용하고, 스위치 값은 따옴표 없는 true 또는 false로 작성합니다. 도메인 패턴, 비밀번호, 콜론이나 샵이 포함된 문자열은 매핑·주석·다른 형식으로 해석되지 않도록 따옴표를 권장합니다. 샵은 문자열 바깥에서만 주석 기호로 작동합니다. 최상위 키를 중복 선언하는 것도 피하세요. 파서에 따라 오류가 나거나 한 항목만 남을 수 있으므로, 규칙 목록 두 개를 반복 작성해 내용을 추가할 수는 없습니다.

# 직접 연결 테스트용 전체 설정이며 원격 프록시 노드는 포함하지 않습니다
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: false

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

이 설정은 해당 필드를 지원하는 코어의 기본 시작 테스트에 사용할 수 있습니다. 포트가 사용 중이 아니면 로컬 혼합 프록시 진입점을 만들지만, 일치하는 모든 연결은 계속 직접 연결됩니다. 애플리케이션도 이 진입점을 명시적으로 사용해야 요청 처리에 참여합니다. 원격 출구를 제공하지 않으며 코어 DNS도 활성화하지 않습니다. 별도의 테스트 파일로 저장하고, 사용 중인 구독을 직접 덮어쓰는 데 사용하지 마세요. 기존 노드와 규칙이 삭제될 수 있습니다.

먼저 입력 파일이 어느 계층에 속하는지 확인하기

구독 URL은 콘텐츠를 가져오는 주소일 뿐, 반환 내용이 반드시 전체 YAML이라는 뜻은 아닙니다. 전체 설정을 반환하는 경우도 있고, 노드 목록만 반환하거나 인코딩된 텍스트 또는 단일 노드 공유 링크를 반환하는 경우도 있습니다. 전체 설정은 설정 가져오기 진입점에 넣고, 노드 집합은 클라이언트 변환이 필요하거나 proxy-providers에서 참조해야 할 수 있습니다. 진입점을 잘못 선택하면 주소를 다운로드할 수 있어도 필드 누락, 파싱 실패 또는 존재하지 않는 규칙 대상 문제가 발생할 수 있습니다.

설정 파일은 클라이언트에서 한 번 더 가공될 수 있습니다. 구독 원문에는 서비스 제공자가 전달한 내용이 저장되고, 로컬 설정에는 포트와 트래픽 가로채기 방식 같은 기본 설정이 저장되며, 오버라이드 파일은 일부 필드를 삽입하거나 교체합니다. 최종 생성 파일이 코어로 전달됩니다. 어느 계층을 편집했든 클라이언트의 실행 설정 미리보기나 내보내기 기능에서 변경 사항이 최종 파일에 반영됐는지 확인하세요. 화면에 특정 값이 표시된다고 해서 구독 파일의 같은 이름 필드가 최종 우선순위를 갖는 것은 아닙니다.

문법만 보지 말고 참조 관계를 점검하기

규칙의 정책 이름은 노드, 프록시 그룹 또는 내장 대상과 일치해야 하며, 프록시 그룹 안의 노드 이름도 실제로 존재해야 합니다. 이름이 맞는 것만으로는 충분하지 않습니다. 그룹끼리 순환 참조를 만들 수 없기 때문입니다. 노드, 프록시 그룹, 규칙 순서로 읽는 것을 권장합니다. 먼저 출구가 무엇인지 확인하고, 다음으로 출구 선택 방식을 파악한 뒤, 어떤 연결이 그곳으로 전달되는지 확인하세요. 규칙 제공자나 프록시 제공자가 있다면 최상위 선언만 보고 로드가 완료됐다고 판단하지 말고 경로, 형식 및 로드 결과까지 확인해야 합니다.

수정하기 전에 현재 클라이언트 이름, 코어 유형과 설정 출처를 기록하고 복구 가능한 사본을 내보내세요. 작동 중인 설정을 우선 보존하고, 한 번에 한 주제만 변경한 뒤 차이를 확인합니다. 아직 클라이언트가 없다면 클라이언트 다운로드 페이지에서 먼저 Clash Plus를 검토한 다음 플랫폼과 필요한 기능에 따라 다른 선택지를 비교하세요. 가져오기 형식의 자세한 구분은 구독 링크와 YAML 가져오기 안내를 참고하세요.

2. 공통 필드: 포트, 모드 및 접근 범위

공통 필드는 로컬 프로그램이 프록시에 어떻게 연결되는지, 그리고 코어가 연결을 받은 뒤 어떤 처리 모드를 사용할지를 결정합니다. 가장 자주 혼동하는 부분은 로컬 수신 포트와 원격 노드 포트입니다. 전자는 기기의 코어가 제공하고, 후자는 서버 연결 매개변수입니다. 노드 서버 포트를 시스템 프록시 설정에 입력해도 연결이 자동으로 만들어지지 않습니다. 시스템 프록시에는 보통 로컬 수신 주소와 해당 HTTP 프록시 포트를 입력하고, 노드 포트는 노드 정의 안에 그대로 둡니다.

수신 진입점을 선택하고 실제 사용 여부 확인하기

일반적인 데스크톱 학습용 설정에서는 먼저 혼합 포트 하나를 사용하는 편이 문제를 찾기 쉽습니다. 애플리케이션에 별도 진입점이 꼭 필요할 때만 HTTP 또는 SOCKS 포트를 추가하세요. 서로 다른 수신 필드가 같은 포트를 중복 사용하게 만들지 말고, 그래픽 클라이언트가 이미 실행 중일 때 같은 포트의 코어를 또 시작하지 마세요. 수신에 실패하면 먼저 포트를 점유한 프로세스를 확인해야 합니다. 무작정 포트만 바꾼 뒤 시스템 프록시를 업데이트하지 않으면 오류가 시작 단계에서 연결 단계로 옮겨갈 뿐입니다.

# 공통 필드 조각이며 수신 포트는 학습용입니다
mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

여기서는 수신을 로컬 용도로 제한합니다. bind-address가 각 진입점에 미치는 구체적인 영향은 코어와 클라이언트가 생성한 결과를 함께 확인해야 하며, 파일만 보고 외부 접근 가능 여부를 판단할 수 없습니다. 애플리케이션은 원격 노드가 아니라 127.0.0.1:7890에 연결해야 합니다. 데스크톱 시스템의 프록시 설정, 브라우저의 독립 프록시 설정, 터미널 환경 변수는 서로 다를 수 있으므로 같은 기기에서도 프로그램마다 다른 경로를 사용할 수 있습니다.

모드 선택과 트래픽 가로채기는 별개의 문제

rule은 코어에 들어온 연결을 규칙 순서에 따라 대상에 배정하고, global은 전체 정책으로 처리하며, direct는 직접 연결을 사용합니다. 전체 모드는 운영체제 수준의 전면 가로채기가 아니므로 모든 프로그램이 프록시로 들어간다고 보장하지 않습니다. 반대로 TUN을 켠다고 해서 모든 요청이 원격 노드로 가는 것도 아닙니다. 트래픽이 코어에 들어온 뒤에도 규칙에 따라 직접 연결, 거부 또는 프록시가 선택됩니다.

시스템 프록시는 주로 시스템 프록시 설정을 따르는 애플리케이션에 영향을 줍니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 가로채며, 관리자 권한·서비스 구성 요소 또는 모바일 플랫폼의 VPN 승인이 필요할 수 있습니다. 웹페이지 하나를 확인하려고 시스템 프록시, TUN, DNS와 모드를 한꺼번에 바꾸지 마세요. 먼저 하나의 애플리케이션이 명확한 로컬 포트로 접속되는지 확인한 뒤 가로채기 범위를 넓힐지 결정하세요. 구체적인 설치와 승인 절차는 모드 및 가로채기 튜토리얼에서 확인할 수 있습니다.

로컬 네트워크 공개, 로그 및 IPv6

신뢰할 수 있는 다른 기기가 로컬 프록시를 사용해야 할 때만 로컬 네트워크 접근을 고려하세요. 이 경우 수신 네트워크 카드, 방화벽 인바운드 규칙과 프록시 인증도 확인하고, 라우터가 해당 진입점을 인터넷에 노출하지 않도록 해야 합니다. 프록시 진입점과 제어 인터페이스는 같은 서비스가 아닙니다. 제어 인터페이스에는 정책 전환, 연결 정보 조회 및 설정 수정 권한이 있을 수 있습니다. 원격 관리가 필요하지 않다면 제어 인터페이스는 로컬에서만 사용하도록 유지하고, 연결 문제를 해결하려고 관리 권한을 넓히지 마세요.

log-level: info는 일상적인 관찰에 적합합니다. 문제를 해결할 때는 잠시 로그 상세도를 높이면 오류 맥락을 더 많이 볼 수 있지만, 로그에 도메인, 노드 주소와 연결 메타데이터가 포함될 수 있으므로 공유 전에 비식별화해야 합니다. 문제 해결이 끝나면 로그 수준을 되돌려 불필요한 기록이 계속 쌓이지 않게 하세요. 로그 저장 여부, 보존 기간과 위치는 보통 클라이언트도 관리하므로 코어의 수준 필드만 확인해서는 안 됩니다.

최상위 ipv6와 DNS 영역의 같은 이름 필드는 적용 계층이 다르며, 운영체제 자체가 IPv6을 계속 사용할 수도 있습니다. 예제에서 이를 끄는 것은 테스트 경로를 단순화하기 위한 것이지 일반적인 네트워크 최적화 권장 사항이 아닙니다. 듀얼 스택 접속이 필요하다면 해석 결과, 라우팅, 가로채기 범위와 노드의 목적지 도달 여부를 함께 확인하세요. 스위치 하나만 바꿔서는 프록시를 우회하는 연결이 없다고 증명할 수 없습니다. 공통 필드 변경은 최종 수신 상태와 실제 요청 경로를 기준으로 확인해야 합니다.

3. DNS 처리: 해석 진입점, 상위 서버 및 Fake-IP

DNS 설정은 누가 질의를 시작하고, 누가 질의를 받으며, 상위 서버에 어떻게 도달하는지를 먼저 정해야 합니다. 코어에서 DNS 서비스를 켠다고 해서 시스템과 모든 애플리케이션이 자동으로 이를 사용하는 것은 아닙니다. 브라우저 내장 암호화 DNS, 애플리케이션 자체 해석기 및 다른 VPN이 별도의 경로를 만들 수 있습니다. 문제를 추적할 때는 애플리케이션, 시스템 해석기, 코어 DNS와 상위 서버 사이의 순서를 그려 보고, 요청이 실제로 원하는 진입점에 들어오는지 먼저 확인한 뒤 반환 주소가 올바른지 살펴보세요.

기본 필드와 해석 의존성

# DNS 조각이며 운영체제의 DNS 설정을 자동으로 바꾸지 않습니다
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
  fake-ip-filter:
    - "*.lan"
    - "*.local"

listen은 코어 DNS의 수신 주소를 선언합니다. 예제는 로컬의 비표준 포트를 사용하므로 명시적 질의 테스트에는 적합하지만, 대부분의 시스템 네트워크 설정에는 이런 포트를 직접 입력할 수 없습니다. 일반 애플리케이션이 이를 사용하게 하려면 클라이언트가 제공하는 DNS 가로채기, 전달 또는 TUN 가로채기 기능이 추가로 필요합니다. 표준 포트에서 수신하지 않는 주소를 시스템 DNS에 적는 것만으로는 충분하지 않습니다. 예제의 상위 서버는 교체 가능한 대상일 뿐이며, 접근 가능 여부는 현재 네트워크에 따라 달라집니다.

nameserver는 일반 해석을 위한 상위 서버를 설정하고, default-nameserver는 상위 DNS 주소 자체가 도메인 이름일 때 이를 해석하는 데 사용됩니다. 암호화 DNS 서버 주소가 도메인 이름으로 되어 있다면 코어는 암호화 연결을 만들기 전에 해당 도메인의 IP를 알아야 합니다. 이 초기 해석을 아직 만들어지지 않은 같은 해석 채널에 전적으로 의존하면 순환 의존성이 생길 수 있습니다. 상위 서버를 바꾸기 전에 현재 네트워크에서 실제로 접근 가능한지 확인하세요.

Fake-IP는 도메인 매핑 관계를 저장합니다

Fake-IP 모드는 도메인에 가상 주소를 반환하고, 코어는 그 주소와 도메인의 매핑을 보관합니다. 이후 애플리케이션이 가상 주소에 연결하면 코어가 이를 바탕으로 도메인 정보를 복원해 후속 처리를 수행합니다. 가상 주소는 대상 웹사이트의 실제 서버 주소가 아니므로 시스템 조회 결과에 가상 주소가 보인다고 해서 곧바로 DNS 오염으로 판단해서는 안 됩니다. 연결 가능 여부는 해당 연결이 같은 코어에 의해 가로채어지는지와 매핑이 유효한지에도 달려 있습니다.

기존의 실제 주소 반환 방식은 실제 IP를 요구하는 프로그램과 호환되기 쉽지만, 연결 단계에서 도메인 정보를 유지하거나 복원하려면 다른 메커니즘이 필요할 수 있습니다. 모드를 선택할 때는 애플리케이션 호환성과 가로채기 구성을 기준으로 삼고, 특정 모드가 반드시 더 빠르다고 보지 마세요. 향상된 모드로 전환한 뒤에도 시스템이나 애플리케이션이 이전 결과를 캐시할 수 있습니다. 관련 캐시를 먼저 정리하고 연결을 새로 만든 뒤 현상을 비교해야 캐시 차이를 모드 차이로 오해하지 않습니다.

fake-ip-filter는 가상 주소를 반환하기 부적합한 도메인을 제외하는 데 사용하며, 일반적인 시작점은 로컬 네트워크 서비스와 실제 주소에 의존하는 애플리케이션입니다. 예제는 목록 구조만 보여 줄 뿐 모든 내부 네트워크 이름을 포함한다고 보장하지 않습니다. 특히 .local 서비스는 멀티캐스트 DNS에 의존할 수 있으므로 제외 항목을 추가하는 것만으로 모든 검색 문제를 해결할 수 없습니다. 가상 주소에서 제외한다고 해서 직접 연결이 지정되는 것도 아닙니다. 해석 방식과 연결 정책은 따로 확인해야 합니다.

도메인별 상위 서버 선택과 DNS 누출 판단

# 기존 dns 매핑에 병합하고 두 번째 dns 최상위 키를 추가하지 마세요
# 내부 네트워크 DNS 주소는 학습용 값이며 실제 접근 가능한 주소로 바꿔야 합니다
nameserver-policy:
  "+.corp.example":
    - 192.168.1.1

이 정책은 특정 도메인을 특정 해석기에 맡길 수 있다는 점을 보여 주며, 내부 이름이 있는 네트워크에 적합합니다. 내부 네트워크 해석기는 해당 도메인을 알고 있어야 하고 현재 기기의 네트워크에서 접근 가능해야 합니다. 외부 네트워크로 전환하면 이전에 작동하던 내부 주소가 더 이상 존재하지 않을 수 있으므로, 타임아웃을 바로 원격 프록시 노드 탓으로 돌리면 안 됩니다. 정책 키의 매칭 문법은 규칙 목록 문법과도 다르므로 DOMAIN-SUFFIX 규칙을 그대로 여기에 넣지 마세요.

관련 필드를 지원하는 mihomo에서는 proxy-server-nameserver로 프록시 노드 서버 도메인을 해석할 수 있고, respect-rules를 사용하면 DNS 상위 서버 연결이 라우팅 규칙을 따르게 됩니다. 이때 노드 해석과 프록시 연결 사이의 의존성을 특히 주의해야 합니다. fallback도 첫 번째 서버가 타임아웃된 뒤 순서대로 대체하는 기능으로 단순화해서 이해해서는 안 되며, 필터 조건에 따라 결과를 선택할 수 있습니다. 구현을 확인하기 전에는 해석 경로를 적게 구성하는 것이 좋습니다.

확인할 때는 일반 도메인, 내부 네트워크 도메인과 프록시가 필요한 도메인을 각각 테스트하고 해석 결과와 이후 연결에서 적중한 규칙을 기록하세요. 로컬 네트워크 애플리케이션만 이상하다면 먼저 제외 범위를 좁히고, 모든 요청이 해석 단계에서 대기한다면 상위 서버 접근성과 순환 의존성을 확인합니다. 가상 주소의 질의와 연결 과정은 Fake-IP 매핑 및 제외 항목 안내에서 계속 확인할 수 있습니다.

4. 프록시 노드: 프로토콜 필드와 연결 조건

proxies는 원격 서비스에 연결하는 방식을 노드별로 설명하는 정적 목록입니다. 노드는 프록시 그룹이 아니며 어떤 웹사이트가 이를 사용할지도 결정하지 않습니다. 규칙이 직접 참조하거나 프록시 그룹이 선택해야 해당 연결에 참여합니다. 노드 정의를 점검할 때는 서비스 주소, 인증 정보, 전송 방식과 TLS 매개변수를 나누어 확인하세요. 클라이언트에 이름이 표시된다고 해서 프로토콜 매개변수까지 연결 검증을 통과했다고 볼 수는 없습니다.

공통 필드와 프로토콜별 필드

# 노드 학습용 조각이며 예제 도메인과 비밀번호는 실제 연결에 사용할 수 없습니다
proxies:
  - name: "학습용 노드"
    type: ss
    server: edge.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

name은 로컬에서 참조하는 식별자이므로 안정적이고 고유하게 지정하는 것이 좋습니다. 서버 도메인과 같을 필요는 없습니다. type은 코어가 사용할 프로토콜과 이후 필드의 해석 방식을 결정합니다. server와 port는 서버가 실제로 수신하는 위치와 일치해야 하며, 웹 주소나 구독 API 경로에서 추측할 수 없습니다. 예제의 예약 도메인과 학습용 비밀번호는 합법적으로 발급받은 실제 값으로 바꿔야 합니다. 이름을 바꾼다고 서버 연결성이 좋아지지는 않습니다.

프로토콜별 필드는 한 세트로 맞아야 합니다. Shadowsocks의 암호화 방식과 비밀번호는 서버 측 설정과 일치해야 하며, 다른 프로토콜에는 UUID, 인증 비밀번호, 추가 핸드셰이크 매개변수 또는 다른 전송 계층 설정이 필요할 수 있습니다. 특정 노드의 type만 다른 프로토콜로 바꾸고 나머지 필드를 그대로 사용해서는 안 됩니다. 클라이언트가 공유 링크를 인식한다는 것은 해당 가져오기 로직이 있다는 뜻일 뿐이며, 최종적으로 생성된 필드가 현재 코어에서 지원되는지 확인해야 합니다.

TLS 이름과 전송 매개변수를 혼용하지 않기

# 독립적인 프록시 목록 조각이며 앞의 최상위 proxies와 중복해 붙여 넣지 마세요
proxies:
  - name: "TLS 학습용 노드"
    type: trojan
    server: edge.example.com
    port: 443
    password: "your-password"
    sni: edge.example.com
    skip-cert-verify: false
    udp: true

TLS를 사용하는 프로토콜에서는 연결 주소와 인증서 검증 이름이 서로 관련될 수 있지만 항상 같은 것은 아닙니다. SNI는 TLS 핸드셰이크에서 서비스 이름을 선택하는 데 사용되고, HTTP Host와 WebSocket 경로는 다른 계층에 있습니다. 서비스 제공자가 서로 다른 값을 명시적으로 요구한다면 해당 매개변수에 맞춰 입력하세요. 오류를 없애려고 도메인을 임의로 바꾸면 안 됩니다. 인증서 오류가 발생하면 시스템 시간, 서버 인증서와 중간 장비도 확인해야 하며 인증서 검증을 장기간 비활성화해서는 안 됩니다.

udp: true는 노드가 지원하는 UDP 기능을 사용할 수 있음을 뜻할 뿐, UDP를 지원하지 않는 서버에 기능을 추가하지는 않습니다. 게임, 음성 통화 또는 다른 애플리케이션에 문제가 생기면 애플리케이션이 프록시에 들어가는지, 프로토콜이 지원되는지, 서버가 허용하는지와 사용 중인 가로채기 진입점이 해당 트래픽을 처리할 수 있는지를 함께 확인해야 합니다. 웹 테스트는 보통 일부 전송 경로만 다루므로 웹페이지 한 번의 성공으로 노드가 모든 애플리케이션에 적합하다고 판단할 수 없습니다.

정적 노드와 프록시 제공자 선택

고정 노드가 적다면 proxies에 직접 작성하는 편이 읽고 비교하기 쉽습니다. 주기적으로 갱신되는 노드 집합은 proxy-providers가 관리하게 한 뒤 프록시 그룹에서 use로 참조할 수 있습니다. 제공자 다운로드 주소의 반환 내용은 요구 형식에 맞아야 하며, 일반적으로 노드 집합과 전체 설정은 서로 다른 입력입니다. 전체 구독을 노드 집합만 받는 진입점에 넣으면 네트워크 다운로드 오류가 아니라 필드 구조 불일치가 발생할 수 있습니다.

제공자는 갱신 주기, 캐시 경로와 상태 확인도 포함합니다. 원격 콘텐츠 갱신에 실패해도 코어가 기존 캐시를 계속 사용할 수 있으므로 화면에 노드가 표시된다고 방금 갱신에 성공했다는 뜻은 아닙니다. 마지막 로드 결과와 캐시 내용을 확인해야 하며 목록 항목 수만 세어서는 안 됩니다. 프록시를 통해 제공자를 다운로드해야 하는데 프록시를 얻으려면 해당 제공자가 필요한 경우 최초 로드 의존성 문제가 생기므로, 사용 가능한 초기 경로를 남겨 두어야 합니다.

노드 이름을 바꾼 뒤에는 프록시 그룹 구성원, 규칙의 직접 참조와 클라이언트에 저장된 선택 기록을 함께 확인하세요. 문제 해결 시에는 매개변수가 완전하고 신뢰할 수 있는 노드 하나를 먼저 남겨 서비스 상태와 인증 유효성을 확인한 뒤 목록을 단계적으로 복원합니다. 설정을 공유할 때는 구독 URL의 접근 자격 증명, 노드 비밀번호와 식별 가능한 개인정보를 삭제하세요. 공개 토론용 예제는 화면 일부를 가리는 대신 학습용 값으로 바꿔야 합니다.

5. 프록시 그룹: 노드 구성과 규칙 진입점 유지

프록시 그룹은 규칙과 노드 사이의 안정적인 인터페이스입니다. 규칙은 계속 “출구 선택”이라는 이름의 그룹을 가리킬 수 있고, 그룹 안의 노드는 구독 갱신이나 사용자 선택에 따라 바뀔 수 있습니다. 이렇게 하면 규칙이 특정 노드 이름에 의존하는 일을 줄이고, 서로 다른 업무에 서로 다른 출구를 사용할 수 있습니다. 프록시 그룹 자체가 원격 연결을 자동으로 만들지는 않습니다. 최종적으로 실제 노드나 내장 대상에 도달해야 합니다. 프록시 그룹을 읽을 때는 화면의 이름만 보지 말고 유형, 구성원 출처와 최종 도달 지점을 함께 확인하세요.

수동 선택 그룹과 내장 대상

# 이 조각은 외부 노드에 의존하지 않아 그룹과 규칙 참조를 확인하기 쉽습니다
proxy-groups:
  - name: "출구 선택"
    type: select
    proxies:
      - DIRECT
      - REJECT

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

select 그룹은 사용자가 구성원을 직접 선택하게 합니다. 여기서는 원격 서비스에 의존하지 않도록 직접 연결과 거부라는 두 내장 대상만 넣어 구조를 테스트합니다. 거부를 선택하면 해당 그룹에 적중한 연결이 차단되며 다른 구성원으로 자동 전환되지 않습니다. 실제로 사용할 때는 이미 정의된 노드 이름을 목록에 추가할 수 있습니다. 설정의 구성원 순서와 클라이언트에 저장된 선택 상태가 최초 표시 결과에 함께 영향을 줄 수 있으므로, 매번 다시 불러올 때 첫 번째 항목이 선택된다고 가정하지 마세요.

DIRECT는 현재 기기가 대상에 직접 연결함을 뜻하고, REJECT는 일치한 연결을 거부함을 뜻합니다. 그룹 이름에 내장 대상 이름을 재사용하지 말고, 이름과 프로토콜 유형을 혼동하지도 마세요. 규칙 대상에 “자동 선택”이라고 썼다면 설정에 완전히 같은 이름의 객체가 있어야 합니다. 글자 하나, 공백 또는 문장 부호 차이만으로도 참조가 작동하지 않을 수 있습니다. 중국어 이름은 읽기 쉽지만 갱신 경로가 복잡할수록 이름을 안정적으로 유지해야 합니다.

자동 선택, 장애 조치 및 부하 분산

# 전제: proxies에 “학습용 노드”가 이미 정의되고 검증되어 있어야 합니다
proxy-groups:
  - name: "자동 선택"
    type: url-test
    proxies:
      - "학습용 노드"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "출구 선택"
    type: select
    proxies:
      - "자동 선택"
      - "학습용 노드"
      - DIRECT

url-test는 지정한 주소로 연결성을 테스트하고 결과에 따라 구성원을 선택합니다. 예제의 간격과 허용 오차는 학습용 값일 뿐입니다. 허용 오차는 작은 차이로 인해 자주 전환되는 것을 줄이는 역할이지 실제 업무 지연 시간을 보장하지 않습니다. 테스트 주소는 노드 출구를 통해 접속하므로 해당 주소가 제한되어 테스트에 실패할 수도 있으며, 노드 전체가 사용할 수 없다는 뜻은 아닙니다. 구성원이 하나뿐이면 자동 선택에도 비교할 다른 출구가 없습니다.

fallback은 구성원 순서에 따라 사용 가능 여부를 확인하는 장애 조치에 가깝고 주·보조 구성에 적합합니다. load-balance는 연결을 분산하며, 구체적인 정책과 설정 옵션은 현재 코어 문서를 확인해야 합니다. 부하 분산은 보통 하나의 다운로드 연결을 여러 노드로 나누지 않으며 대역폭이 합산된다는 뜻도 아닙니다. 로그인 세션이나 출구 주소에 민감한 애플리케이션에서는 출구가 자주 바뀌면 추가 인증이 발생할 수 있으므로 안정성을 우선하세요.

상태 확인은 특정 시간, 특정 대상과 특정 테스트 방식의 결과만 보여 줍니다. 모든 지역 제한, UDP 기능, 인증 갱신 및 장시간 연결 상태를 포괄하지는 않습니다. 지나치게 짧은 테스트 간격으로 즉각적인 상태를 얻으려 하지 마세요. 테스트는 기기와 노드의 자원을 소모하고 네트워크 변동 시 전환을 더 많이 일으킬 수 있습니다. 먼저 수동 그룹으로 안정적인 기준을 만든 뒤 업무가 정상인지 확인하고 자동 그룹을 도입해 실제 효과를 비교하는 것이 좋습니다.

제공자 참조, 중첩 및 복구 선택

노드가 프록시 제공자에서 올 때 프록시 그룹은 보통 use로 제공자 이름을 참조하고, 정적 노드는 proxies로 참조합니다. 두 참조 대상은 다르므로 다운로드 URL을 구성원 이름 자리에 넣을 수 없습니다. 노드 필터가 모든 구성원을 제외해 빈 그룹을 만들 수도 있습니다. 따라서 갱신 후에는 제공자 로드 성공 여부, 필터 조건의 일치 여부와 그룹에 실제 구성원이 있는지를 함께 확인해야 하며 구독 갱신 알림만 봐서는 안 됩니다.

프록시 그룹은 다른 그룹을 참조할 수 있지만 의존성에는 반드시 종점이 있어야 합니다. 예를 들어 수동 그룹이 자동 그룹을 참조하고 자동 그룹이 노드를 참조하는 구조는 명확하지만, 두 그룹이 서로 참조하면 순환이 됩니다. 문제 해결 경로를 추적하기 쉽도록 중첩 단계는 가능한 한 줄이세요. 화면에 “출구 선택”이 자동 그룹을 선택한 것으로 보여도 자동 그룹이 최종적으로 어떤 노드를 선택했는지 계속 확인해야 합니다. 그렇지 않으면 로그의 실제 출구가 사용자의 예상과 다를 수 있습니다.

일부 클라이언트나 코어는 정책 선택을 저장했다가 설정 갱신 후 기존 구성원을 복원하려고 합니다. 구성원 이름이 바뀌거나 삭제되면 복원 동작이 달라질 수 있습니다. 규칙과 구독을 갱신하기 전에 중요한 그룹의 선택을 기록하고, 갱신 후 실제 도달 지점을 확인하세요. “규칙은 올바르게 적중했지만 접속 결과가 이상한” 경우 먼저 그룹이 직접 연결이나 만료된 노드를 선택했는지 확인한 뒤 더 깊은 DNS와 라우팅을 점검합니다. 규칙과 프록시 그룹의 협업 흐름은 연결 확인 절차에서도 확인할 수 있습니다.

6. 규칙 문법: 매칭 조건, 순서 및 최종 대상

rules는 보통 위에서 아래 순서로 매칭하며, 일치하면 지정된 대상에 처리를 넘깁니다. 순서는 로직의 일부입니다. 정확한 예외는 넓은 규칙보다 앞에 두고 최종 기본 규칙은 마지막에 배치하세요. 규칙 목록을 자유롭게 정렬할 수 있는 분류표로 보면 안 됩니다. 앞쪽의 광범위한 규칙 하나 때문에 뒤의 세부 규칙이 실행될 기회를 영원히 잃을 수 있습니다. 수정하기 전에 어떤 연결 유형을 바꾸려는지와 기존에 어느 위치에서 적중했는지를 먼저 확인하세요.

도메인, 주소 대역 및 기본 규칙

# 일부 규칙 조각이며 내장 대상을 사용해 매칭 순서를 보여 줍니다
rules:
  - DOMAIN,blocked.example.com,REJECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,DIRECT

DOMAIN은 정확한 도메인에 사용하고, DOMAIN-SUFFIX는 도메인 접미사와 하위 도메인에 사용하며, DOMAIN-KEYWORD는 도메인 안의 키워드에 사용합니다. 키워드 범위는 예상보다 넓어 같은 문자열이 포함된 다른 도메인까지 잘못 매칭할 수 있습니다. 접미사를 명확히 알고 있다면 접미사 규칙을 우선하세요. 도메인 규칙은 전체 웹 URL의 경로, 쿼리 매개변수나 페이지 내용을 인식하지 않으므로 특정 URL 디렉터리 기준으로 직접 분기할 수 없습니다.

IP-CIDR은 IPv4 주소 대역에 사용하고, IPv6 주소 대역에는 해당 IPv6 규칙 유형을 사용합니다. 예제의 사설 주소 범위가 모든 로컬 통신을 포함한다는 뜻은 아니며, 실제 네트워크에 따라 다른 특수 범위와 라우팅도 고려해야 합니다. MATCH는 매칭 값을 사용하지 않고 최종 대상만 바로 지정하므로 마지막에 배치해야 합니다. 첫 번째 줄에 두면 뒤의 일반 규칙은 작동하지 않습니다.

도메인 정보와 no-resolve의 범위

도메인 규칙이 매칭되려면 규칙을 판단하는 시점에 코어가 해당 도메인 정보를 가지고 있어야 합니다. 애플리케이션이 먼저 직접 해석한 뒤 대상 IP만 보내면 코어가 도메인 규칙을 바로 사용하지 못할 수 있습니다. Fake-IP 매핑, 프록시 프로토콜에 포함된 호스트 이름 또는 적용 가능한 스니핑 기능이 단서를 제공할 수 있지만 모든 연결의 원래 도메인을 복원한다고 보장할 수는 없습니다. 도메인 규칙이 작동하지 않으면 먼저 로그의 대상이 도메인으로 표시되는지 주소로 표시되는지 확인하세요.

주소 규칙은 대상이 어느 주소 대역에 속하는지 판단하기 위해 해석을 발생시킬 수 있습니다. no-resolve를 추가하면 해당 주소 규칙이 능동적으로 도메인을 해석하지 않도록 할 뿐, 전역 DNS를 끄거나 이후 연결에 필요한 해석을 막는 것은 아닙니다. 연결에 대상 IP가 이미 있다면 규칙은 이를 사용해 매칭할 수 있습니다. 도메인 규칙을 먼저 두고 필요한 주소 규칙을 뒤에 두면 불필요한 해석 의존성을 줄일 수 있지만, 구체적인 순서는 업무 목적에 따라야 합니다.

규칙 제공자와 로컬 규칙 관리

# 전제: 해당 위치에 규칙 파일을 이미 만들어 두었습니다
rule-providers:
  local-policy:
    type: file
    behavior: classical
    path: ./rules/local-policy.yaml

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

# rules/local-policy.yaml의 내용이며 주 설정이 아닙니다
payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

규칙 제공자는 매칭 집합을 별도 파일로 분리하고, 주 설정은 이 집합에 정책을 지정합니다. 위 예제는 classical 동작을 사용하므로 집합 안의 규칙에 최종 대상이 다시 들어가지 않습니다. 도메인 집합과 주소 집합에는 각각 맞는 동작과 콘텐츠 형식이 필요합니다. 원격 규칙은 다운로드 형식, 캐시 경로와 갱신 결과도 확인해야 합니다. 확장자가 같다고 내용 구조까지 같은 것은 아닙니다. 일반 텍스트 목록을 payload가 있는 YAML로 잘못 처리하면 로드 오류가 발생합니다.

지리 데이터, 프로세스 이름과 프로세스 경로 규칙은 모두 추가 조건에 의존합니다. 지리 분류는 데이터베이스의 범위와 갱신 시점에 영향을 받고, 프로세스 규칙은 시스템 권한·플랫폼 및 가로채기 방식의 제약을 받으므로 한 플랫폼의 작성법을 일반 해법으로 볼 수 없습니다. 규칙을 관리할 때는 추가 이유를 기록하고 최소 범위로 매칭하세요. 새 규칙을 검증할 때는 새 연결을 만들어야 합니다. 이미 만들어진 장시간 연결은 규칙을 다시 불러온 것만으로 출구를 다시 선택하지 않는 경우가 많습니다.

7. 오버라이드 및 병합: 구독 갱신과 로컬 수정을 함께 유지하기

구독 다운로드 파일을 직접 편집하면 다음 갱신 때 변경 사항이 쉽게 사라집니다. 오버라이드는 구독이 담당하는 노드와 기본 규칙을 기기의 포트, DNS 또는 규칙 설정과 분리해 관리하기 위한 기능입니다. 모든 클라이언트에 동일한 병합 알고리즘이 있는 것은 아닙니다. 어떤 클라이언트는 필드 교체를 제공하고, 어떤 클라이언트는 규칙 앞뒤 삽입을 지원하며, 어떤 클라이언트는 전체 객체를 스크립트로 처리할 수 있습니다. 사용하기 전에 해당 진입점이 YAML 조각, 전체 설정 또는 실행 가능한 스크립트 중 무엇을 처리하는지 확인하세요.

스칼라, 매핑 및 목록을 구분해 이해하기

# 원본 설정의 관련 필드
mixed-port: 7890
mode: global
allow-lan: true

# 이러한 필드 교체를 지원하는 클라이언트 오버라이드 진입점 전용
mode: rule
allow-lan: false

# 가정: 같은 이름의 스칼라는 로컬 오버라이드로 교체됩니다
mixed-port: 7890
mode: rule
allow-lan: false

이 예제는 스칼라 교체만 보여 줍니다. 원본 설정의 포트는 유지되고, 모드와 로컬 네트워크 접근은 로컬 값으로 교체됩니다. 이것만으로 중첩된 DNS 필드가 항목별로 병합된다고 볼 수 없으며, 규칙 목록이 자동으로 추가된다는 뜻도 아닙니다. 클라이언트 화면의 공통 설정이 오버라이드 이후 다시 기록되면 최종 결과가 달라질 수 있습니다. 실제 사용에서는 오버라이드 진입점의 이름으로 실행 순서를 추측하지 말고 클라이언트가 생성한 최종 설정을 대조하세요.

매핑 병합에는 얕은 교체와 재귀 병합의 차이가 있습니다. 예를 들어 원본 DNS 매핑에 상위 서버, 필터 목록과 수신 주소가 있고 로컬에는 enable: true만 작성했다고 합시다. 전체 매핑이 교체되면 다른 내용이 사라질 수 있습니다. 재귀 병합을 사용하면 언급하지 않은 키가 유지될 수도 있습니다. 필드를 삭제할 때도 null을 쓰는 것만으로 항상 해결되지는 않습니다. 어떤 방식은 빈 값을 보존하고, 어떤 방식은 입력을 거부하며, 전용 삭제 작업을 제공하는 방식도 있습니다.

목록을 추가하는 방향이 로직을 결정합니다

규칙, 노드와 프록시 그룹은 모두 목록이지만 구분 없는 하나의 추가 로직을 공유할 수는 없습니다. 규칙에는 순서 의미가 있으므로 로컬 예외를 기존 MATCH 뒤에 넣으면 보통 작동하지 않습니다. 노드 목록에서는 이름 중복을 확인해야 하고, 프록시 그룹 목록에서는 그룹 이름뿐 아니라 그룹 내부 구성원 참조도 확인해야 합니다. “병합 지원”을 같은 이름의 노드, 순환 참조와 규칙 우선순위까지 자동으로 처리한다는 뜻으로 이해하지 마세요.

# 최종 설정에서의 순서 예시이며 일반적인 오버라이드 지시문이 아닙니다
rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,출구 선택

위 예제는 원본 설정에 “출구 선택” 그룹이 이미 정의되어 있고 프린터 도메인을 직접 연결해야 한다고 가정합니다. 이 규칙을 앞에 두면 규칙 계층의 출구 선택만 처리합니다. 프린터 도메인 해석 오류, 멀티캐스트 검색 실패 또는 로컬 네트워크 라우팅 문제는 별도로 해결해야 합니다. 더 구체적인 거부 규칙이 있는 설정에서는 앞에 둔 규칙이 원래 차단하려던 대상을 실수로 허용하지 않는지도 확인해야 합니다.

반복 가능하고 되돌릴 수 있는 처리 절차 만들기

구독 원문, 로컬 오버라이드와 최종 실행 설정을 각각 저장하는 것이 좋습니다. 원문은 서비스 제공자가 구조를 바꿨는지 판단하는 데 사용하고, 오버라이드는 로컬 의도를 추적하며, 최종 파일은 코어 테스트에 사용합니다. 한 번에 처리 단계 하나만 추가하고 해당 단계가 의존하는 그룹 이름이나 필드를 기록하세요. 원문에서 서비스 제공자가 그룹 이름을 바꾸면 로컬 규칙이 문법적으로 올바르더라도 대상이 사라질 수 있으므로 구독 갱신 후 참조 관계를 다시 확인해야 합니다.

스크립트 오버라이드는 멱등성을 갖춰야 합니다. 같은 입력을 한 번 처리하든 반복 처리하든 결과가 같아야 합니다. 흔한 오류는 실행할 때마다 규칙 목록에 같은 항목을 삽입해 내용이 계속 누적되는 경우입니다. 공유 객체를 직접 수정해 이후 단계가 예상하지 못한 상태를 읽게 만드는 경우도 있습니다. 필드 누락과 유형 변경에도 대비해야 하며 모든 구독에 DNS 매핑이나 같은 이름의 프록시 그룹이 있다고 가정해서는 안 됩니다. 스크립트 동작을 설명하기 어렵다면 더 단순한 필드 조작을 우선하세요.

클라이언트 업그레이드, 코어 전환과 구독 갱신은 모두 병합 경로를 바꿀 수 있습니다. 정식 적용 전에 사본에서 결과를 생성하고 포트, 모드, DNS, 그룹 이름과 마지막 규칙을 비교하세요. 기존 제공자 경로나 보안 설정이 삭제되지 않았는지도 확인해야 합니다. 문제가 생기면 최근 추가한 오버라이드를 먼저 비활성화하고 원본 설정과 정상 작동이 확인된 선택을 복구한 뒤 처리 단계를 하나씩 다시 시작하세요. 전체 설정을 반복해서 복사하는 것보다 변경 범위를 최소화하는 편이 문제를 찾기 쉽습니다.

8. 검증 및 문제 해결: 문법 검사에서 실제 연결까지

검증은 단계적으로 진행해야 합니다. 파일이 파싱되는지, 참조가 로드되는지, 수신이 시작되는지, 애플리케이션이 진입점으로 들어오는지, 규칙이 적중하는지, 출구가 대상에 도달하는지를 순서대로 확인하세요. 앞 단계가 통과했다고 뒤 단계까지 성공한 것은 아닙니다. 특히 설정 테스트 명령은 형식과 로드 가능성을 주로 확인하며 모든 노드의 온라인 인증과 실제 업무 테스트를 대신하지 않습니다. 장애가 어느 단계에서 발생했는지 먼저 기록한 뒤 가장 짧은 검증 경로를 선택하면 불필요한 재설치와 무관한 매개변수 수정을 줄일 수 있습니다.

같은 코어로 최종 설정 확인하기

# macOS / Linux: 현재 디렉터리에 실행 가능한 mihomo가 있습니다
# check.yaml은 내보낸 최종 설정 사본입니다
./mihomo -t -f ./check.yaml

# Windows PowerShell: 현재 디렉터리에 mihomo.exe가 있습니다
.\mihomo.exe -t -f .\check.yaml

실행하기 전에 명령이 클라이언트 실행 환경과 동일한 코어를 가리키는지 확인하고, 해당 실행 파일의 도움말에서 매개변수를 확인하세요. 그래픽 클라이언트 이름과 실행 파일 이름은 같지 않을 수 있으며, 시스템에 있는 다른 동명의 프로그램은 지원 필드가 다를 수 있습니다. 테스트는 통제된 디렉터리에서 진행하고 제공자, 규칙 파일과 데이터베이스 같은 의존성에도 접근할 수 있어야 합니다. 상대 경로는 보통 코어의 작업 디렉터리나 설정 처리 방식에 의존하므로 주 파일 하나만 옮긴다고 테스트 환경이 같아지는 것은 아닙니다.

오류 행 번호가 표시되면 해당 행과 그 앞의 몇 줄을 함께 확인하세요. 닫히지 않은 따옴표, 잘못된 들여쓰기와 목록 계층의 어긋남은 다음 필드에서야 감지될 수 있습니다. 참조 오류가 있으면 이름을 따라 위로 올라가 그룹 이름, 노드 이름과 제공자 이름을 확인하세요. 리소스가 없으면 경로, 권한과 콘텐츠 형식을 점검합니다. 모든 오류를 YAML 들여쓰기 탓으로 돌리지 말고, 테스트를 통과시키려고 이해하지 못한 보안 또는 라우팅 필드를 삭제하지도 마세요.

진입점, 규칙, 출구를 단계별로 확인하기

# 전제: mixed-port가 7890이고 코어가 정상적으로 시작되었습니다
curl --proxy http://127.0.0.1:7890 --head https://example.com/

# Windows에서는 명령 별칭 차이를 피하기 위해 curl.exe를 사용합니다
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

프록시 진입점을 명시하면 시스템 프록시 설정이 실제로 적용됐는지 여부를 잠시 변수에서 제외할 수 있습니다. HTTP 응답을 받았다는 것은 해당 요청의 연결 경로가 완료됐다는 뜻이지만, 응답 상태가 항상 성공 상태일 필요는 없으며 모든 애플리케이션이 가로채어졌다는 증거도 아닙니다. 테스트 도메인은 일반적인 연결성 확인 대상일 뿐입니다. 특정 업무를 검증하려면 해당 업무에서 허용하는 실제 주소를 사용하고, 클라이언트 연결 기록에서 적중 규칙과 최종 정책을 확인하세요.

명시적 프록시는 성공하지만 브라우저가 실패한다면 브라우저의 독립 프록시, 암호화 DNS, 확장 프로그램과 시스템 설정을 중점적으로 확인하세요. 둘 다 실패하면 먼저 코어가 수신 중인지와 포트가 일치하는지 확인한 뒤 DNS와 원격 연결 오류를 살펴봅니다. 직접 연결은 정상인데 프록시 노드가 타임아웃된다면 전체 규칙 체계를 바로 바꾸지 말고 구독 유효성, 노드 주소, 인증 매개변수와 상위 네트워크를 확인하세요. 단계별 순서는 프록시 노드 타임아웃 문제 해결을 참고하세요.

캐시, 로그 및 안전한 롤백

DNS, Fake-IP 모드 또는 규칙을 바꾼 뒤에는 연결을 새로 만들어야 합니다. 브라우저 연결 풀, 애플리케이션의 장시간 연결, 시스템 DNS 캐시와 코어 캐시 때문에 이전 상태가 잠시 계속될 수 있습니다. 먼저 대상 애플리케이션의 관련 연결을 닫고 시스템이나 클라이언트가 제공하는 적절한 캐시 정리 방법을 사용하세요. 한 번의 캐시 문제를 해결하려고 사용자 디렉터리 전체를 삭제하지 마세요. 테스트 전후 요청 시간을 각각 기록해야 로그의 이벤트와 정확히 대응할 수 있습니다.

로그에는 오류 유형, 발생 시간, 매칭 규칙과 필요한 연결 단계를 남기고 구독 자격 증명, 인증 정보와 공개할 필요가 없는 도메인은 삭제하세요. 화면 충돌과 코어 실패는 서로 다른 문제입니다. 전자는 실행 환경과 화면 구성 요소를 확인해야 하고, 후자는 설정·권한과 수신 오류를 우선 확인해야 합니다. 클라이언트를 열 수 없다면 시작 실패 및 설정 복구 절차에 따라 현장을 보존하고 데이터를 바로 삭제하지 마세요.

롤백할 때는 최근 활성화한 가로채기 방식을 먼저 끄고, 정상 작동이 확인된 설정과 정책 선택을 복구한 뒤 시스템 프록시와 DNS에 수동 설정이 남아 있는지 확인하세요. 클라이언트를 종료해도 직접 입력한 네트워크 매개변수까지 취소되지는 않으므로 변경 전 기록을 보관해야 합니다. 최종 확인에는 일반 접속, 대상 업무 접속과 로컬 네트워크 접속을 각각 한 번 이상 포함하세요. 로그와 경로가 예상대로인지 확인한 뒤 평소 로그 수준으로 되돌리고 이 설정을 백업합니다.

처음 연결만 완료하려는 경우 빠른 시작 과정으로 돌아가세요. 그래픽 클라이언트를 다시 선택해야 한다면 선택 가이드에서 설정 관리 방식을 비교한 뒤 다운로드 페이지에서 해당 플랫폼으로 이동하세요. 이 안내서의 목적은 모든 선택 필드를 한꺼번에 켜는 것이 아니라, 매번 수정할 때 명확한 전제와 확인 가능한 결과 및 복구 방법을 갖추도록 하는 것입니다.