Clash 설정 가이드

구조 안내 / 01

YAML 구조와 설정 파일의 출처

맵, 목록, 참조부터 구분하기

설정 파일은 표시된 순서대로 실행하는 명령어가 아니라 커널이 읽는 구조화된 데이터입니다. 콜론 왼쪽은 필드 이름, 오른쪽은 필드 값입니다. 값이 바로 적혀 있지 않으면 다음 단계의 들여쓰기가 하위 필드를 나타내는 경우가 많습니다. 최상위 dns는 맵, rules는 목록, proxies는 여러 노드 맵으로 이루어진 목록입니다. 화면 위치를 보고 필드를 추측하기보다 데이터 유형부터 확인한 뒤 수정하세요.

들여쓰기는 공백으로 통일하고 탭은 사용하지 마세요. 두 칸 들여쓰기는 읽기 편한 관례일 뿐, 모든 위치에서 반드시 두 칸이어야 하는 것은 아닙니다. 같은 단계는 맞춰 쓰고 하위 단계는 상위 단계보다 더 들여쓰는 것이 중요합니다. 목록 항목의 하이픈 뒤와 일반 필드의 콜론 뒤에는 공백을 넣으세요. 중국어식 콜론, 전각 공백, 메신저에서 복사한 곡선 따옴표는 원래 문자와 비슷해 보여도 구문 분석 오류를 일으킬 수 있습니다.

mixed-port: 7890
mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip

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

rules:
  - MATCH,수동 선택

위 예시에서 name, type, proxies는 하나의 프록시 그룹에 속합니다. 그룹 안의 proxies에는 노드 연결 매개변수가 아니라 이름 목록을 적습니다. 아래 규칙의 “수동 선택”은 그룹 이름과 공백, 대소문자, 문장 부호까지 정확히 일치해야 합니다. YAML 구문 분석에 성공해도 참조 대상 이름이 없으면 커널이 설정을 불러오지 못할 수 있습니다.

문자열과 중복 필드 주의하기

이름에 특수 문장 부호가 포함되면 따옴표로 감싸는 것이 좋습니다. 비밀번호에 샵 기호, 콜론, 앞뒤 공백이 있다면 문자열임을 명확히 표시하세요. 큰따옴표는 백슬래시 이스케이프를 처리하며, 작은따옴표는 내용을 문자 그대로 유지할 때 적합하지만 작은따옴표 자체는 짝을 맞춰 이스케이프해야 합니다. 포트는 정수로, 불리언 값은 true 또는 false로 쓰세요. 보기 좋게 맞추려고 모든 값을 따옴표로 감싸지는 마세요.

하나의 맵 안에 같은 필드를 중복해서 쓰지 마세요. 예를 들어 파일 앞부분에 dns가 있는데 맨 아래에 다시 dns를 추가하면, 파서에 따라 읽기가 거부되거나 나중에 쓴 값만 남을 수 있습니다. 중복 키 덮어쓰기에 기대기보다 기존 맵에 항목을 추가하는 편이 안전합니다. 샵 기호로 시작하는 주석은 수정 목적을 설명하는 용도입니다. 주석은 실행 설정이 아니며, 잘못된 참조를 주석 처리해 문제를 숨기는 방법으로 사용해서는 안 됩니다.

현재 편집 중인 파일 확인하기

클라이언트는 보통 구독 원본, 로컬 편집본, 최종 실행 설정을 각각 보관합니다. 구독 원본은 원격 업데이트에 사용되고, 로컬 편집본은 수정에만 쓰일 수 있습니다. 최종 실행 설정은 클라이언트가 포트, 제어 인터페이스, 덮어쓰기 내용을 더해 생성합니다. 먼저 클라이언트에서 현재 활성 항목을 확인한 다음 실행 설정이나 커널 로그에서 실제로 불러온 경로를 살펴보세요. 파일 탐색기에 config.yaml이 있다고 해서 현재 적용 중인 파일이라고 단정하지 마세요.

수정 전에 원본 파일을 복사하고 용도가 드러나는 파일 이름을 붙이세요. 편집 후 저장한 다음 클라이언트에서 다시 불러와야 합니다. 편집기만 닫는다고 커널이 설정을 다시 읽지는 않습니다. 화면에는 저장됐지만 동작이 바뀌지 않았다면 활성 항목, 생성 경로, 다시 불러온 결과부터 확인하고 규칙 자체를 바로 의심하지 마세요. 구독 업데이트로 원본 파일이 다시 생성될 수 있으므로 계속 유지할 변경 사항은 클라이언트가 지원하는 설정 덮어쓰기 기능에 넣어야 합니다.

이 페이지는 필드 의미를 기준으로 구성했으며, 모든 클라이언트가 모든 옵션을 제공하는 것은 아닙니다. 먼저 커널이 mihomo인지 확인하고 현재 커널에서 지원하는 필드와 대조하세요. 구형 Clash 클라이언트가 현재 mihomo 구현과 동일하다고 볼 수는 없습니다.

알 수 없는 필드를 발견하면 먼저 해당 설정이 커널, 클라이언트, 외부 도구 중 어디에 속하는지 확인하고 범위를 좁히세요. 클라이언트 전용 필드를 커널 설정에 넣으면 무시되거나 오류가 발생할 수 있습니다. 기본 개념부터 확인해야 한다면 용어 빠른 안내를 읽은 뒤 관련 장으로 돌아오세요. 모든 필드를 한 번에 이해할 필요는 없습니다.

실행 설정 / 02

포트, 실행 모드와 제어 인터페이스

로컬 포트 수신과 시스템 프록시는 다릅니다

mixed-port는 하나의 포트에서 HTTP 프록시와 SOCKS5 프록시 요청을 모두 받으므로 데스크톱 앱에 같은 포트를 입력할 때 편리합니다. port는 HTTP 전용 프록시 포트, socks-port는 SOCKS 전용 포트입니다. 일반적으로 혼합 포트 하나면 충분하므로 모든 포트를 동시에 열 필요는 없습니다. 포트 번호는 로컬에서 요청을 받는 위치일 뿐, 서버 주소나 노드 품질 또는 특정 프로토콜 지원 여부를 뜻하지 않습니다.

커널이 포트를 열었다고 해서 운영체제가 요청을 자동으로 커널에 보내는 것은 아닙니다. 시스템 프록시 스위치는 보통 클라이언트가 관리하며 시스템의 프록시 설정을 갱신합니다. 이 설정을 읽는 프로그램도 있고, 별도 설정을 쓰거나 직접 연결하는 프로그램도 있습니다. 문제를 확인할 때는 먼저 포트가 열렸는지, 다음으로 앱이 해당 프록시를 사용하는지 확인하세요. “시스템 프록시가 켜져 있다”와 “모든 프로그램이 프록시를 사용한다”는 같은 뜻이 아닙니다.

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false
external-controller: "127.0.0.1:9090"

규칙, 전역, 직접 연결 모드 구분하기

mode: rule은 규칙 순서에 따라 연결 경로를 결정하며, 규칙 기반 라우팅을 이해하는 출발점입니다. 전역 모드는 일반 연결을 전역 정책으로 보내지만, 전역 정책에서도 적절한 출구를 선택해야 합니다. 작동하지 않는 노드를 자동으로 고쳐 주지는 않습니다. 직접 연결 모드는 프록시를 잠시 우회해 비교할 때 유용합니다. 모드를 바꿔도 기존 장기 연결은 이전 경로를 계속 사용할 수 있으므로, 검증할 때는 기존 연결을 새로 고치는 대신 새 요청을 보내세요.

log-level: info는 시작 상태와 연결 상태를 평소에 확인하기에 적합합니다. 디버깅할 때는 잠시 로그 상세 수준을 높일 수 있지만 로그가 많아지고 접속 대상 같은 민감한 정보가 포함될 수 있습니다. 문제를 해결한 뒤에는 원래 설정으로 되돌리고, 로그를 공유하기 전에 구독 주소와 인증 정보를 지우세요. ipv6: false는 운영체제에서 IPv6를 완전히 비활성화한다는 뜻이 아니며, 앱이 다른 경로로 IPv6를 사용하는 것을 단독으로 막아 주지도 않습니다. DNS와 트래픽을 가로채는 범위도 함께 확인해야 합니다.

LAN 공유와 관리 인터페이스는 따로 설정하기

allow-lan은 LAN 접속을 허용할지 결정하고 bind-address는 수신 주소를 지정합니다. 예시는 루프백 주소에만 바인딩하므로 로컬 연결에 적합합니다. LAN 허용을 켜더라도 다른 기기에서 접속할 수 있는 수신 주소인지 별도로 확인해야 합니다. 공유하려면 해당 로컬 인터페이스나 필요한 수신 범위를 명시하고, 가정용·사무실 네트워크 등 환경에 맞게 방화벽의 접속 출처를 제한하세요.

LAN 접속을 허용한 뒤 휴대폰에는 컴퓨터의 LAN 주소와 프록시 포트를 입력해야 합니다. 127.0.0.1을 입력하면 휴대폰 자신을 가리킵니다. 컴퓨터 주소 변경, 게스트 네트워크 격리, 절전 모드, 방화벽 차단으로 공유가 중단될 수 있습니다. 설정 방법은 혼합 포트와 LAN 공유 안내를 참고하세요. 공유하기 전에 네트워크 사용 규칙을 확인하고, 신뢰할 수 없는 네트워크에서는 접속을 열어 두지 마세요.

external-controller는 클라이언트나 패널이 커널을 관리하는 인터페이스이지, 브라우저가 인터넷에 접속할 때 사용하는 프록시 포트가 아닙니다. 루프백 주소에서 수신하도록 두면 보통 데스크톱 클라이언트에 충분합니다. 원격 제어가 꼭 필요하다면 강력한 인증을 별도로 설정하고 네트워크 접근 범위를 제한하세요. 휴대폰에서 프록시를 쓰려고 관리 인터페이스까지 노출하지 마세요. 화면에서 커널에 연결할 수 없다면 관리 포트와 프록시 포트를 각각 확인해 잘못된 항목을 수정하지 않도록 하세요.

포트 충돌이 발생하면 먼저 실행 중인 다른 프록시 인스턴스를 종료한 뒤 다시 불러오세요. 포트를 꼭 변경해야 한다면 시스템 프록시, 앱 자체 프록시, LAN 기기의 설정도 함께 바꿔야 합니다. YAML만 바꾸고 시스템 프록시가 이전 포트를 계속 가리키면 커널은 정상 실행되는데 브라우저는 연결되지 않을 수 있습니다. 관련 필드를 한 번에 한 묶음씩 바꾸면 원인을 찾기 쉽습니다.

이름 해석 / 03

DNS, fake-ip와 이름 해석 경로

먼저 누가 DNS 조회를 하는지 확인하기

DNS는 도메인 이름을 IP 주소로 바꾸지만 실제 조회는 앱, 운영체제, 브라우저, 프록시 커널 또는 원격 프록시 서버에서 일어날 수 있습니다. 커널 DNS를 켰다는 것은 커널이 DNS 조회를 처리할 수 있다는 뜻일 뿐, 모든 앱의 조회가 커널로 들어온다는 의미는 아닙니다. 시스템 프록시가 시스템의 모든 DNS 요청을 자동으로 가로채는 것도 아닙니다. TUN의 DNS 하이재킹에도 별도의 적용 범위가 있습니다. 요청 경로를 먼저 확인한 다음 옵션을 선택하세요. 커널 DNS를 바꾸면서 커널을 우회하는 브라우저 내장 DNS로 테스트하는 일은 피해야 합니다.

dns.enable은 커널 DNS 모듈을 켜고, listen은 수신 주소를 지정합니다. 예시는 이해하기 쉽고 일반적인 시스템 포트와 충돌하지 않도록 루프백 주소와 높은 포트를 사용합니다. 수신 항목만 작성한다고 시스템이 자동으로 해당 주소를 사용하지는 않습니다. 데스크톱 클라이언트는 TUN이나 다른 통합 방식으로 조회를 커널에 전달할 수 있으므로 실제 설정을 확인하세요. 아래 예시를 완전한 시스템 DNS 가로채기 설정으로 그대로 사용하지 마세요.

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5

fake-ip와 실제 주소 모드

fake-ip는 요청된 도메인 이름에 가상 주소를 매핑합니다. 이후 연결이 커널에 들어오면 매핑을 이용해 도메인 이름을 복원하므로 도메인 기반 라우팅이 편리해집니다. 예시의 주소 대역은 이 기능을 위해 예약된 용도이며, 노드의 server에 입력할 공용 서버 주소가 아닙니다. 조회 결과가 이 대역에 속한다면 먼저 fake-ip 모드인지 확인하세요. 곧바로 DNS 오염이라고 판단하지 마세요.

redir-host는 일반적으로 실제 조회 주소를 반환하므로 실제 주소가 필요한 상황에 적합합니다. 다만 모든 DNS 문제를 해결하는 만능 방법은 아닙니다. 모드를 바꾸면 주소 캐시와 연결 동작도 달라지며, 기존 캐시가 관찰 결과에 영향을 줄 수 있습니다. 수정 후 설정을 다시 불러오고 운영체제와 앱에 맞게 캐시를 비우거나 관련 앱을 재시작하세요. 명확한 대상 하나부터 테스트한 뒤 범위를 넓히고, 모드·업스트림·규칙을 동시에 바꾸지 마세요.

fake-ip-filter는 특정 도메인에 가상 주소를 할당하지 않도록 합니다. LAN 서비스, 기기 검색, 실제 주소에 의존하는 앱을 필요에 따라 추가할 수 있지만 범위를 넓히면 도메인 매핑의 편리함이 줄어듭니다. 필터 모드와 매칭 문법은 각각 의미가 있으므로 모든 항목을 일반 정규식으로 이해해서는 안 됩니다. 실제 문제가 확인된 도메인부터 추가하고 이유를 기록해, 나중에 설명할 수 없는 필터 목록이 쌓이지 않도록 하세요.

업스트림 DNS와 노드 도메인 조회

nameserver는 일반 DNS 조회에 사용하는 업스트림 목록이며, default-nameserver는 업스트림 DNS 서버의 도메인 이름을 조회하는 초기 경로로 사용할 수 있습니다. 모든 업스트림을 도메인 이름으로만 지정하고 처음 이름을 조회할 경로가 없으면 시작 단계에서 의존성 문제가 생길 수 있습니다. proxy-server-nameserver는 프록시 서버의 도메인을 조회하므로 노드 주소를 아직 연결되지 않은 프록시에 의존하지 않아도 됩니다. 업스트림은 현재 네트워크에서 접속 가능한지 기준으로 선택하세요. 많을수록 안정적인 것은 아닙니다.

nameserver-policy를 사용하면 특정 도메인이나 매칭 범위에 사용할 업스트림을 지정할 수 있습니다. fallback과 관련 필터는 조건에 따라 조회 결과를 판단하는 데 사용됩니다. 단순히 “첫 번째가 실패하면 두 번째에 묻는다”는 뜻은 아닙니다. 명확한 요구가 없다면 이해하기 쉬운 단일 경로부터 사용하세요. 라우팅 규칙으로 DNS 업스트림 연결을 제어하려면 관련 필드의 지원 여부와 노드 도메인 조회 방식도 확인해 DNS와 프록시가 서로를 기다리는 상황을 피해야 합니다.

암호화 DNS는 일부 구간의 DNS 전송 방식만 바꿉니다. 앱을 자동으로 가로채거나 모든 네트워크 출구를 하나로 통합하지는 않습니다. 검사 결과는 시스템 DNS, 브라우저 설정, 현재 연결 로그와 함께 확인하세요.

문제를 확인할 때는 먼저 도메인 조회가 되는지, 다음으로 반환된 주소에 연결할 수 있는지, 마지막으로 요청이 어떤 출구를 이용하는지 테스트하세요. 도메인 조회만 실패하고 IP 주소로는 접속할 수 있다면 DNS 문제일 가능성이 더 큽니다. 인증서 오류나 서버의 연결 거부를 곧바로 DNS 탓으로 돌리면 안 됩니다. 자세한 방법은 DNS 누수 점검과 fake-ip 설정 실습을 참고하세요. 기존 업스트림 설정을 보관하면 항목별 비교와 복구가 쉽습니다.

출구 설정 / 04

프록시 노드와 원격 노드 모음

노드 필드는 실제 서비스 정보와 일치해야 합니다

proxies에는 노드 연결 매개변수를 저장합니다. 각 노드에는 참조할 이름과 프로토콜에 필요한 주소, 포트, 인증 필드가 있어야 합니다. 노드는 실제 출구이고 프록시 그룹은 출구를 선택하는 방법이므로 서로 바꿔 쓸 수 없습니다. 구독에 노드가 이미 포함되어 있다면 보통 하나씩 직접 작성할 필요가 없습니다. 필드를 확인하거나 자체 서비스를 연결하거나 최소 테스트 설정을 만들 때만 노드 항목을 편집하고, 먼저 원본을 보관하세요.

아래 예시는 HTTP 프록시로 필드 구조를 보여줍니다. 도메인과 인증 정보는 가상의 값이므로 실제 연결에 사용할 수 없습니다. server에는 호스트 이름이나 주소만 입력하고 https://나 웹 경로는 붙이지 마세요. port는 원격 서비스 포트이며 로컬 혼합 포트가 아닙니다. 인증 필드는 서버가 제공한 정보를 사용해야 합니다. 이름을 바꾸거나 다른 포트를 입력해 사용 가능한 설정을 추측할 수는 없습니다.

proxies:
  - name: "예시 출구"
    type: http
    server: proxy.example.com
    port: 443
    username: "your-username"
    password: "your-password"
    tls: true
    sni: proxy.example.com
    skip-cert-verify: false

name은 설정 안에서 식별자 역할을 합니다. 이름을 바꾸면 프록시 그룹과 해당 노드를 직접 참조하는 규칙도 함께 수정해야 합니다. 이름은 같고 매개변수는 다른 경우 병합할 때 혼동하기 쉽습니다. 로컬에서 추가한 노드에는 구분하기 쉬운 접두어를 붙이는 것이 좋습니다. 비밀번호, 구독 식별 코드, 개인 연락처는 이름에 넣지 마세요. 노드 이름은 화면, 로그, 스크린샷에 표시될 수 있으므로 공유될 수 있는 정보로 취급해야 합니다.

프로토콜 필드와 전송 필드를 섞지 않기

프로토콜마다 사용하는 필드가 다릅니다. Shadowsocks에는 암호화 방식과 비밀번호가 필요할 수 있고, Trojan은 인증 및 TLS 설정을 사용합니다. VMess, VLESS 등에도 각각 고유한 인증과 전송 필드가 있습니다. 다른 설정에 uuid, network, 전송 옵션이 있다고 해서 현재 노드에도 적용되는 것은 아닙니다. 프로토콜을 확인하고 서버의 전송 방식과 커널 지원 범위를 차례로 살펴보세요. 서로 다른 예시의 필드를 한 노드에 섞어 넣지 마세요.

TLS의 서버 이름과 인증서 검증은 별도로 확인해야 합니다. 주소로 연결하더라도 서버 인증서는 도메인 이름으로 발급되었을 수 있으므로 실제 서비스에 맞는 sni를 지정해야 합니다. 임의로 만들어 넣을 수 있는 값이 아닙니다. 인증서 검증을 끄면 중요한 서버 신원 확인을 포기하게 되므로 일반적인 문제 해결 방법으로 사용해서는 안 됩니다. 인증서 오류가 발생하면 시스템 시간, 서버 이름, 서버 인증서 체인을 확인하세요. 자세한 내용은 HTTPS 인증서 오류 원인과 해결 방법을 참고하세요.

노드 필드의 UDP 지원도 여러 단계로 나누어 확인해야 합니다. 커널이 특정 전송을 지원해도 원격 서비스, 사용 중인 네트워크, 대상 앱이 같은 경로를 지원한다는 뜻은 아닙니다. HTTP 프록시 예시를 모든 UDP 트래픽의 출구로 사용할 수는 없습니다. 웹페이지는 열리는데 음성 통화, 게임 또는 다른 앱이 작동하지 않는다면 실제로 사용하는 프로토콜과 원격 서비스의 지원 여부를 확인하세요. 클라이언트에 연결 성공으로 표시되는지만 보면 안 됩니다. 구독에 포함된 낯선 프로토콜 확장도 먼저 확인하고 삭제 여부를 결정하세요.

provider는 노드 모음이지 선택 정책이 아닙니다

proxy-providers를 사용하면 파일이나 원격 리소스에서 노드 모음을 불러올 수 있습니다. 프록시 그룹은 use로 모음 이름을 참조하고 그 안의 노드를 선택 대상으로 추가합니다. 원격 리소스는 커널이 인식할 수 있는 노드 모음 형식으로 제공되어야 합니다. 완전한 구독 파일과 provider 파일은 서로 바꿔 사용할 수 없는 경우가 많습니다. 리소스를 내려받았다는 것은 내용이 도착했다는 뜻일 뿐, 형식과 필드, 노드 목록이 유효한지는 별도로 확인해야 합니다.

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: "구독 출구"
    type: select
    use:
      - local-nodes

위 예시는 로컬 파일이 있어야 동작하며, 파일에는 해당하는 proxies 목록이 포함되어야 합니다. 상대 경로는 보통 커널의 작업 디렉터리나 클라이언트가 지정한 설정 디렉터리를 기준으로 해석되므로, 현재 편집기에서 연 디렉터리와 다를 수 있습니다. 다운로드, 업데이트, 상태 확인은 서로 다른 작업입니다. 업데이트는 노드 정보를 가져오고, 상태 확인은 연결 가능성을 테스트하며, 선택 정책은 실제 사용할 노드를 결정합니다. 한 단계의 성공으로 다른 단계의 결과를 대신할 수는 없습니다.

실제 구독 링크에는 개인 접속 인증 정보가 포함되는 경우가 많습니다. 공개 설정 파일, 문제 화면 캡처, 코드 저장소에 올리지 말고 구조를 보여줄 때는 가짜 값으로 바꾸세요. 업데이트에 실패하면 먼저 네트워크, 구독 유효 상태, 응답 콘텐츠 유형을 확인한 뒤 YAML을 점검하세요. 서버가 로그인 페이지나 오류 메시지를 반환한다면 파일 확장자가 YAML이어도 정상적인 노드 모음으로 불러올 수 없습니다.

선택 로직 / 05

프록시 그룹 유형과 참조 관계

먼저 수동 선택 경로부터 구성하기

proxy-groups는 노드나 다른 프록시 정책을 묶어 선택 가능한 출구로 만듭니다. 처음 작성할 때는 select 그룹 하나를 만들고 화면에서 사용 가능한지 확인한 노드를 직접 선택하세요. 이렇게 하면 노드 연결 실패와 자동 선택 로직의 문제를 구분할 수 있습니다. 규칙은 그룹 이름을 대상으로 지정하고, 그룹은 실제 노드를 선택하므로 참조 흐름이 명확해집니다. 도메인마다 노드 이름을 반복해서 입력할 필요도 없습니다.

proxy-groups:
  - name: "수동 선택"
    type: select
    proxies:
      - 예시 출구
      - DIRECT

  - name: "웹 접속"
    type: select
    proxies:
      - 수동 선택
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,웹 접속
  - MATCH,수동 선택

이 예시는 앞 장에서 정의한 “예시 출구”에 의존합니다. 예시 도메인에 접속하면 규칙이 먼저 “웹 접속” 그룹으로 보냅니다. 해당 그룹에서 “수동 선택”을 선택한 상태라면 그 그룹에서 현재 선택한 노드를 사용합니다. 그룹을 중첩하면 반복 관리가 줄지만 순환 참조는 만들지 마세요. A 그룹이 B 그룹을 참조하고 B 그룹이 다시 A 그룹을 참조하면 출구를 결정할 수 없습니다. 설정을 확인할 때는 규칙의 대상부터 노드나 내장 정책까지 따라가세요.

자동 탐색 결과가 실제 사용 환경을 보장하지는 않습니다

url-test는 탐색 결과에 따라 구성원을 선택하고, fallback은 후보 순서에 따라 사용 가능한 구성원을 선택하며, load-balance는 해당 정책에 따라 연결을 분산합니다. 해결하는 문제가 서로 다르므로 자동으로 동작한다는 이유만으로 서로 바꿔 쓰지 마세요. 속도 측정 주소는 해당 대상까지의 결과만 보여주며, 특정 동영상 사이트나 업무 서비스, 계정 로그인도 같은 성능을 보장하지 않습니다. 특정 서비스에서 문제가 발생하면 실제 서비스에 맞춰 추가로 확인하세요.

proxy-groups:
  - name: "자동 탐색"
    type: url-test
    proxies:
      - 예시 출구
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

구조를 보여주기 위해 예시에는 후보가 하나만 있습니다. 실제로 비교하려면 사용 가능한 구성원이 여러 개 필요합니다. interval은 탐색 간격, tolerance는 작은 차이로 인한 전환을 줄이는 값이며, lazy는 그룹을 사용하지 않을 때 탐색하는 방식에 영향을 줍니다. 탐색을 자주 하면 백그라운드 요청이 늘어나며 사용 환경이 항상 좋아지는 것은 아닙니다. 모바일 기기에서는 백그라운드 제한과 배터리 소모도 고려하세요. 우선 클라이언트의 합리적인 기본값을 사용하고, 확인된 문제가 있을 때 조정하는 편이 좋습니다.

자동 그룹이 바뀌어도 기존 장기 연결은 이전 출구를 계속 사용할 수 있으며 새 요청부터 변경된 선택을 따르는 경우가 많습니다. 테스트할 때는 새 연결을 만들고 연결 화면에서 실제 경로를 확인하세요. 일부 서비스는 로그인 상태를 접속 환경과 연결하므로 자주 전환하면 재인증이 필요할 수 있습니다. 세션을 안정적으로 유지해야 한다면 모든 연결이 자동 전환을 공유하게 두는 대신 해당 서비스용 수동 그룹을 따로 만드세요.

목록 참조, 필터링, 선택 상태 유지

그룹의 proxies에는 구성원 이름을 직접 나열하고, use에는 provider 이름을 지정합니다. 필터 표현식은 보통 이름을 기준으로 노드를 걸러내며, 이름에 적힌 지역이나 노드의 실제 위치, 네트워크 속성을 검증하지는 않습니다. 구독에서 이름이 바뀌면 필터 결과가 비어 있을 수 있습니다. 먼저 최종 구성원 목록을 확인한 다음 표현식을 점검하세요. 그룹 이름이 그대로 있다고 해서 안에 사용 가능한 노드가 있다고 판단하지 마세요.

내장 정책 DIRECT는 직접 연결, REJECT는 연결 거부를 뜻하며 둘 다 원격 노드가 아닙니다. DIRECT를 자동 탐색 그룹에 넣으면 후보 비교에 포함됩니다. 오류가 있을 때만 사람이 직접 전환하려는 목적이라면 바깥쪽 수동 그룹에 넣으세요. 자동 대체와 직접 연결 대체도 같은 뜻이 아닙니다. 프록시를 우회할지 여부는 라우팅 결정이므로 실제 사용 환경에 맞춰 명확히 설정해야 합니다.

일부 클라이언트는 프록시 그룹 선택을 저장해 설정을 다시 불러온 뒤에도 이전 선택을 복원합니다. 보통 그룹 이름, 구성원 이름, 저장 방식에 따라 달라집니다. 그룹 이름이 바뀌거나 구독에서 노드가 제거되면 기존 선택을 복원하지 못할 수 있습니다. 커널의 profile.store-selected가 선택 저장에 관여할 수 있지만, 클라이언트가 자체적으로 상태를 관리하기도 합니다. YAML만 보는 것보다 화면에 표시된 현재 값을 확인하는 편이 정확합니다. 파일의 나열 순서만 보고 최종 선택 항목을 추측하지 마세요.

프록시 그룹을 추가한 뒤에는 구성원이 있는지, 순환 참조가 없는지, 규칙이 올바르게 참조하는지, 현재 선택 항목을 사용할 수 있는지 차례로 확인하세요. 네 가지 모두 확인해야 실제 트래픽 경로에 그룹이 연결된 것입니다.

“규칙”, “프록시 그룹”, “노드”는 각각 매칭 조건, 선택 경로, 연결 매개변수로 구분할 수 있습니다. 규칙은 트래픽을 어디로 보낼지 정하고, 그룹은 무엇을 사용할지 고르며, 노드는 원격 연결 방법을 정합니다. 구조를 단순하게 유지하면 나중에 노드를 바꿀 때 보통 구성원만 수정하면 되고 전체 규칙을 다시 작성할 필요가 없습니다.

트래픽 매칭 / 06

규칙 순서, 규칙 모음과 최종 규칙

위에서 아래로 확인하고 일치하면 지정된 정책 사용

규칙 모드에서는 일반 라우팅 규칙을 위에서부터 순서대로 확인하며, 일치하는 규칙의 대상 정책을 사용합니다. 구체적인 예외 규칙은 보통 범위가 넓은 규칙보다 앞에 두고, 어느 규칙에도 일치하지 않는 연결은 마지막의 MATCH가 처리하도록 합니다. 최종 규칙을 앞에 두면 뒤의 규칙은 적용될 기회를 잃습니다. 도메인이 규칙 목록에 있다고 해서 해당 규칙이 실제로 적용된다는 뜻은 아닙니다. 앞에 있는 도메인 접미사 규칙, 주소 규칙, 규칙 모음이 먼저 일치할 수 있습니다.

rules:
  - DOMAIN,login.example.com,수동 선택
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,example,수동 선택
  - 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,수동 선택

위 예시는 먼저 특정 로그인 도메인을 프록시로 보내고 나머지 예시 도메인은 직접 연결합니다. 앞의 두 규칙 순서를 바꾸면 로그인 도메인이 먼저 접미사 규칙에 일치합니다. 예시에 지정된 “수동 선택” 대상이 실제로 정의되어 있어야 합니다. 규칙 문법에서 쉼표는 필드 구분자이므로 다른 쉼표로 바꾸지 마세요. 대상 이름에 설명을 덧붙이지도 마세요. 규칙을 편집한 뒤에는 명확한 대상 하나로 일치한 규칙 유형과 정책을 확인하고, 이후 다른 사이트도 검증하세요.

도메인 정보와 주소 정보가 항상 함께 있는 것은 아닙니다

도메인 규칙이 작동하려면 커널이 대상 도메인 이름을 알아야 합니다. 명시적 HTTP 프록시나 SOCKS 도메인 요청을 사용하면 정보가 비교적 명확하지만, 앱이 먼저 직접 조회한 뒤 IP 주소로 연결하면 커널에서 보는 정보가 달라질 수 있습니다. fake-ip 매핑과 스니핑은 도메인 복원에 도움이 될 수 있지만 각각 조건이 있으며 모든 암호화 트래픽을 식별할 수 있는 것은 아닙니다. 연결 화면에 실제로 어떤 정보가 표시되는지 확인한 뒤 도메인 규칙이 일치하지 않은 이유를 살펴보세요.

no-resolve는 해당하는 주소 매칭 규칙에서 그 규칙을 적용하려고 도메인 조회를 새로 발생시키지 않도록 합니다. 연결에 이미 매칭 가능한 주소가 있으면 규칙은 계속 적용될 수 있습니다. 이 옵션이 모든 DNS 조회를 차단하거나 앱 자체의 조회 방식을 바꾸는 것은 아닙니다. 주소 규칙을 앞쪽에 둘 때는 DNS 조회 발생 여부가 경로와 지연 시간에 영향을 줄 수 있으므로 도메인 규칙 순서와 함께 고려하세요. 모든 규칙에 같은 옵션을 무조건 추가하지 마세요.

규칙 모음은 선언과 사용이 모두 필요합니다

rule-providers는 재사용할 규칙 모음을 정의하고, RULE-SET은 해당 모음을 규칙 목록에 연결합니다. 선언만으로 자동 분기되지는 않습니다. behavior는 내용을 도메인, 주소 대역, 클래식 규칙 중 어떤 방식으로 해석할지 정하고 format은 파일 형식을 지정하므로 실제 파일과 일치해야 합니다. 원격 업데이트 주소와 로컬 캐시 경로도 구분하세요. 캐시 파일이 있어도 최근 업데이트에 성공했다는 뜻은 아닙니다.

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

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,수동 선택

함께 사용할 로컬 규칙 파일은 아래처럼 작성할 수 있습니다. 이 항목은 도메인 모음에 속하므로 완전한 3개 필드 라우팅 규칙이 아니며 정책 이름도 붙이지 않습니다. 클래식 규칙 한 줄을 도메인 모음에 넣으면 구문 오류가 나거나 예상과 다르게 매칭될 수 있습니다. 타사 규칙 소스를 가져올 때는 파일 이름만 보고 형식을 추측하지 말고 실제 내용을 확인하세요.

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

라우터, 컨테이너, TUN 트래픽에 프로세스 규칙을 사용하려면 실행 환경에서 프로세스 정보를 식별할 수 있는지도 확인해야 합니다. 라우터에서는 원격 기기의 연결이 보이므로 데스크톱 앱 이름 규칙을 그대로 사용할 수 있다고 단정할 수 없습니다. 배포 환경은 OpenWrt 보조 라우터 배포 개요를 참고하세요. 실제로 확인할 수 있는 정보를 기준으로 규칙을 작성하고 환경에서 제공하지 않는 필드에 의존하지 마세요.

최종 검증에는 대상 도메인, 일치한 규칙, 실제 출구를 기록하세요. 웹페이지가 열린다는 사실만으로는 프록시가 성공했는지 직접 연결이 가능했는지 구분할 수 없습니다. 문제가 생기면 먼저 정확한 규칙 하나를 임시로 추가해 확인한 뒤 매칭 범위를 넓힐지 결정하세요. 범위가 지나치게 넓은 키워드나 주소 대역을 허용하면 다른 서비스에 영향을 줄 수 있고 나중에 문제를 재현하기도 어려워집니다.

변경 사항 유지 / 07

구독 덮어쓰기, 병합과 업데이트 후 유지

먼저 설정 생성 흐름 확인하기

구독을 업데이트하면 원격 콘텐츠를 다시 가져오므로 내려받은 파일을 직접 수정한 내용은 사라질 수 있습니다. 클라이언트의 덮어쓰기, 병합, 추가 설정, 스크립트 기능은 보통 원본에 추가 처리를 하지만 적용 위치와 병합 방식은 클라이언트마다 다릅니다. 원본 구독, 클라이언트 공통 설정, 구독별 덮어쓰기, 최종 실행 설정의 적용 순서를 먼저 확인한 뒤 변경 사항을 어느 단계에 넣을지 결정하세요.

포트, 시스템 프록시, TUN 등은 클라이언트 화면에서 관리하는 경우가 많아 구독에 같은 필드가 있어도 덮어쓰일 수 있습니다. 규칙과 프록시 그룹은 구독별 확장 설정으로 추가될 수도 있습니다. 같은 필드를 여러 곳에서 동시에 수정하면 다음에 다시 불러온 뒤 어느 설정이 최종 적용됐는지 설명하기 어렵습니다. 수정할 관리 경로를 하나로 정하고 실제 실행 설정에서 결과를 확인하세요. 화면에 입력한 값은 설정 의도일 뿐 커널이 최종적으로 읽은 값과 다를 수 있습니다.

맵 병합과 목록 병합을 구분하기

맵은 필드별로 재귀 병합하거나 통째로 교체할 수 있습니다. 예를 들어 덮어쓰기 설정에 dns.enable만 적어도 어떤 방식은 기존 업스트림을 유지하지만 다른 방식은 DNS 항목 전체를 교체할 수 있습니다. 목록은 더욱 주의해야 합니다. 규칙, 노드, 프록시 그룹은 뒤에 추가하거나 앞에 삽입하거나 이름을 기준으로 병합하거나 전체를 교체할 수 있습니다. “YAML을 병합하면 기존 목록이 항상 유지된다”는 보장은 없습니다. 현재 클라이언트 안내와 실제 생성 결과를 기준으로 판단하세요.

# 원본 설정의 일부
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

# 덮어쓰기 의도: 이 항목만 변경
# 클라이언트의 별도 덮어쓰기 입력란에 작성하고 원본 파일에 반복해서 추가하지 않기
# dns:
#   enhanced-mode: redir-host

위 예시는 하나의 맵에 중복 키가 생기지 않도록 덮어쓰기 의도를 주석으로 적었습니다. 실제 수정은 클라이언트의 별도 덮어쓰기 입력란에서 해당 필드를 설정한 다음 nameserver가 유지되는지 확인하세요. 항목이 사라지면 현재 방식은 재귀 병합을 지원하지 않을 수 있으므로 DNS 전체 설정을 명시적으로 유지해야 합니다. 테스트 중에는 업스트림을 함께 바꾸지 마세요. 그래야 병합 동작에 따른 차이인지 판단할 수 있습니다.

규칙 앞에 추가하기, 중복 제거와 이름 충돌

로컬 예외 규칙은 범위가 넓은 규칙이나 MATCH보다 먼저 적용되도록 구독 규칙 앞에 두는 것이 일반적입니다. 도구가 규칙을 뒤에 추가하는 기능만 제공한다면 예외를 목록 끝에 넣어도 전혀 작동하지 않을 수 있습니다. 생성된 규칙 순서를 확인하고 최종 규칙이 맨 마지막에 있는지 점검한 뒤 실제 매칭을 테스트하세요. “중복 제거”를 위해 규칙 순서를 임의로 바꾸지 마세요. 라우팅 목록은 순서 자체가 의미이며 알파벳순으로 정렬하면 동작이 달라집니다.

프록시 그룹을 추가할 때는 구독과 충돌할 가능성이 낮은 이름을 사용하세요. 구독 업데이트 후 같은 이름의 그룹이 생기면 이름 기준 병합으로 구성원이 바뀌거나 전체 교체로 기존 선택 항목이 사라질 수 있습니다. 노드 이름으로 필터링한다면 원격에서 이름을 바꿀 가능성도 고려하세요. 중요한 서비스는 안정적인 로컬 프록시 그룹을 통해 연결하고 그 그룹이 구독 그룹을 선택하도록 구성하면, 각 사용자 규칙이 원격 노드 이름에 직접 의존하는 것보다 관리하기 쉽습니다.

스크립트를 이용한 설정 덮어쓰기는 유연하지만 구조를 망가뜨릴 위험도 큽니다. 수정하기 전에 스크립트가 객체와 문자열 중 무엇을 입력받는지, 반환값이 전체 설정이어야 하는지, 오류 발생 시 클라이언트가 이전 설정을 유지하는지 아니면 불러오기를 중단하는지 확인하세요. 출처가 불분명하거나 외부 리소스를 읽는 스크립트는 복사하지 마세요. 설정에는 구독 주소와 인증 정보가 들어갈 수 있으므로 확장 스크립트는 이런 정보에 접근할 수 있는 프로그램으로 취급해야 합니다. 단순한 주석처럼 다뤄서는 안 됩니다.

업데이트 한 번으로 변경 사항 유지 여부 확인하기

덮어쓰기를 설정한 뒤 먼저 다시 불러와 기능을 확인하고, 구독 업데이트도 한 번 직접 실행하세요. 업데이트 전후의 실행 설정을 비교해 사용자 규칙, 그룹 이름, DNS 업스트림, 포트가 예상대로인지 점검합니다. 업데이트에 성공했다고 덮어쓰기도 성공한 것은 아니며, 기존 설정이 계속 실행 중이라고 새 설정이 불러와졌다는 뜻도 아닙니다. 로그에서 생성 및 다시 불러오기 결과를 확인하고 업데이트 실패 후 남은 이전 인스턴스가 아니라 현재 파일을 대상으로 테스트했는지 확인하세요.

다음 세 가지를 보관하는 것이 좋습니다. 사용할 수 있는 원본 설정, 별도로 관리하는 덮어쓰기 내용, 변경 이유 기록입니다. 복구할 때는 먼저 원본 설정으로 돌아간 다음 덮어쓰기를 하나씩 켜세요. 그래야 구독 변경과 로컬 수정 내용을 섞지 않고 확인할 수 있습니다.

기록은 길지 않아도 되지만 수정한 필드, 예상 결과, 확인할 대상은 적어 두세요. 예를 들어 “DNS 최적화”보다 “LAN 기기는 실제 DNS 조회 결과를 사용하도록 유지”가 더 도움이 됩니다. 문제가 다시 발생했을 때 목적을 기준으로 변경이 여전히 필요한지 판단할 수 있습니다. 용도가 불분명한 기존 덮어쓰기는 계속 패치를 쌓기보다 하나씩 비활성화해 필요한지 확인하세요.

클라이언트를 옮길 때 생성된 실행 파일만 복사하지 마세요. 이전 클라이언트가 추가한 제어 인터페이스, 파일 경로, 패널 설정은 새 환경에서 작동하지 않을 수 있습니다. 먼저 클라이언트 다운로드 페이지에서 플랫폼에 맞는 클라이언트를 선택하세요. 일반 사용자는 Clash Plus를 우선 고려할 수 있습니다. 원본 구독을 다시 가져온 뒤 필요한 로컬 덮어쓰기만 옮기고, 이 페이지의 검증 절차에 따라 하나씩 확인하세요.

검증과 복구 / 08

설정 확인, 연결 테스트와 복구

먼저 구문을 확인한 뒤 트래픽 가로채기 범위 점검

파일을 저장한 뒤 클라이언트의 설정 검사나 다시 불러오기 기능을 사용해 구문 오류, 존재하지 않는 참조, 잘못된 파일 경로가 있는지 확인하세요. mihomo를 직접 실행한다면 올바른 작업 디렉터리에서 아래 테스트 명령을 실행할 수 있습니다. 실행 파일 이름과 경로는 컴퓨터의 실제 위치에 맞게 조정하세요. 명령 검사에 성공해도 모든 원격 노드에 연결할 수 있다는 뜻은 아니며 시스템 프록시나 TUN의 트래픽 가로채기를 검증하는 과정도 대신하지 않습니다.

mihomo -t -d . -f ./config.yaml

오류에 줄 번호가 표시되면 해당 줄부터 같은 단계의 들여쓰기와 바로 윗줄의 따옴표, 콜론을 확인하세요. 파서가 표시한 줄은 문제가 발견된 위치일 뿐이며 실제 원인은 앞부분에서 닫히지 않은 문자열일 수 있습니다. 정책이 없다는 메시지가 나오면 노드, 그룹, 규칙 세 단계에서 이름이 일치하는지 확인하세요. 리소스 파일을 찾을 수 없다는 메시지가 나오면 작업 디렉터리, 상대 경로, 접근 권한을 점검하세요. 빨간 오류가 보인다고 설정 전체를 바로 교체하지 마세요.

최소 직접 연결 설정으로 로컬 문제 분리하기

아래는 커널의 포트 수신과 기본 규칙 경로를 확인하기 위한 독립적인 최소 직접 연결 테스트 설정입니다. 원격 프록시는 포함되어 있지 않으므로 대상 트래픽이 자동으로 프록시 출구를 사용하지 않습니다. 원본 구독을 덮어쓰지 않도록 별도 파일로 저장해 불러오세요. 기존 클라이언트가 같은 포트를 사용 중이면 해당 인스턴스를 종료하거나 테스트 포트를 명확히 바꾸고 테스트 명령에도 동일하게 반영하세요.

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

rules:
  - MATCH,DIRECT

최소 설정도 시작되지 않으면 먼저 포트 충돌, 권한, 실행 파일 문제를 확인하세요. 시작된 뒤에는 현재 네트워크에서 원래 접속할 수 있는 주소를 대상으로 명시적 프록시 요청을 보내세요. 운영체제마다 curl 명령 매핑이 다를 수 있으므로 Windows에서는 curl.exe를 명시적으로 사용할 수 있습니다. 아래 명령은 시스템 프록시를 변경하지 않고 지정된 로컬 HTTP 프록시 포트만 테스트합니다.

curl --proxy http://127.0.0.1:7890 --head https://example.com

HTTP 응답이 도착했다면 해당 요청이 지정된 경로를 거쳤다는 뜻이지만, 응답 상태는 대상 사이트와 함께 판단해야 합니다. 로컬 포트 연결이 거부되면 수신 상태와 포트를 확인하세요. 프록시에 연결된 뒤 시간 초과가 발생하면 DNS, 라우팅, 출구를 살펴보세요. 인증서 검증 오류가 발생하면 인증서와 시스템 시간을 확인해야 합니다. 모든 실패를 “노드가 문제”라고 단정하거나 원인을 숨기려고 인증서 검증을 끄지 마세요.

실제 설정을 단계별로 복원하기

최소 설정 테스트가 성공하면 원래 설정으로 돌아가 사용 가능한 것으로 확인된 노드 하나와 수동 그룹 하나만 먼저 검증하세요. 그다음 DNS 설정, 규칙 모음, 덮어쓰기를 추가합니다. 각 단계를 더할 때마다 같은 대상을 테스트하고 로그 차이를 기록하세요. 그러면 어느 단계부터 문제가 생기는지 찾을 수 있습니다. 명시적 프록시는 되는데 일반 브라우저에서 접속할 수 없다면 앱 프록시 설정이나 트래픽 가로채기 범위 문제일 가능성이 높습니다. 노드 매개변수를 바로 다시 작성하지 마세요.

TUN에는 가상 네트워크 어댑터, 라우팅, 권한, DNS 가로채기도 관련됩니다. 활성화한 뒤에는 도메인 요청과 IP 주소 연결을 각각 테스트하고 LAN 리소스에 계속 접근할 수 있는지 확인하세요. 다른 VPN, 가상 머신, 보안 프로그램도 라우팅을 변경할 수 있으므로 여러 네트워크 도구를 동시에 전환하지 않는 것이 좋습니다. 데스크톱 시스템 프록시와 TUN은 사용 상황이 다를 수 있습니다. 먼저 한 가지 경로를 선택해 검증한 뒤 앱 요구에 따라 함께 사용할지 결정하세요.

규칙을 검증할 때는 새 연결에서 일치한 규칙과 최종 출구를 확인하세요. 전체 스위치가 켜져 있는지만 보면 안 됩니다. 브라우저 캐시, 연결 재사용, 백그라운드 요청 때문에 페이지를 한 번 새로 고쳐도 여러 결과가 섞일 수 있으므로 필요하면 대상 앱을 종료하고 다시 테스트하세요. 화면을 공유할 때는 대상 계정, 구독 주소, 노드 인증 정보를 가리세요. 문제를 찾는 데 필요한 필드, 오류 문구, 관련 설정 부분만 남기면 됩니다.

인터넷이 끊기면 먼저 복구한 뒤 원인을 찾기

먼저 새로 켠 트래픽 가로채기 기능을 끄고, 시스템 프록시를 원래대로 돌린 다음 이전에 저장한 사용 가능한 설정을 불러오세요. 클라이언트를 종료한 뒤에도 접속할 수 없다면 시스템에 종료된 포트를 가리키는 프록시 설정이 남아 있는지 확인하세요. TUN이나 다른 도구가 추가한 경로도 해당 도구의 정상 종료 절차에 따라 복원해야 합니다. 문제를 덮어쓰려고 클라이언트를 여러 개 연속해서 설치하면 포트와 시스템 설정 충돌이 늘어날 수 있습니다.

네트워크가 복구되면 가장 최근에 변경한 항목부터 하나씩 다시 적용하세요. 구독 업데이트, 커널 변경, 규칙 수정, 시스템 네트워크 변경은 가능한 한 따로 진행해야 합니다. “연결 성공으로 표시되는데 웹페이지가 열리지 않음” 문제가 계속되면 인터넷 연결 문제 8단계 점검표에 따라 구독, 출구, 시스템 프록시, DNS를 확인하세요. 설정 흐름을 처음부터 다시 확인하려면 구독 가져오기와 연결 가이드로 돌아가세요.

설정 변경이 완료됐다고 판단하려면 파일을 불러올 수 있고, 대상 요청이 예상대로 매칭되며, 구독 업데이트 후에도 변경 사항이 유지되고, 복구 방법까지 알고 있어야 합니다. 이 네 가지를 모두 확인한 뒤 다음 항목을 수정하세요.