Clash YAML 설정 가이드

1. YAML 구조와 설정 적용 과정

Clash 설정 파일은 위에서 아래로 실행되는 스크립트가 아니라 계층형 데이터의 모음입니다. 최상위 필드에서 수신 방식, 프록시 출처, 프록시 그룹, 규칙을 선언하면 코어가 파일 전체를 읽어 필요한 객체를 구성합니다. 이 차이를 이해하는 것이 중요합니다. 규칙을 파일 맨 아래에 적었다고 해서 그 규칙이 마지막에 생성되는 것은 아닙니다. 실제 매칭 순서는 rules 목록 안의 순서에 따라 결정됩니다. 파일 이름은 달라도 되고 확장자가 .yml일 수도 있지만, 클라이언트에서 현재 선택한 설정이 실제로 로드됩니다.

맵, 목록, 문자열 구분하기

콜론은 필드 이름과 값을 구분하며, 일반적으로 콜론 뒤에는 공백을 둡니다. 하이픈은 목록 항목을 나타냅니다. 들여쓰기는 계층 관계를 표시하므로 탭 대신 공백 두 칸을 일관되게 사용하는 것이 좋습니다. 아래의 proxies는 프록시 그룹의 후보 목록이지 최상위 프록시 노드 목록이 아닙니다. 이름은 같아도 서로 다른 계층에 있습니다. 파싱 오류가 나면 해당 줄의 글자만 확인하지 말고 앞뒤 줄의 들여쓰기부터 살펴보세요.

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

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

rules:
  - MATCH,출구 선택

구조를 이해하기 위한 직결 설정 예제입니다. 혼합 프록시 포트를 열지만 모든 연결은 최종적으로 직접 연결되며 원격 프록시 기능은 포함하지 않습니다. 복잡한 규칙을 처음부터 가져오는 것보다 이 설정으로 코어가 파일을 읽는지 확인하는 편이 문법 오류를 찾기 쉽습니다. 목록의 DIRECT는 내장 아웃바운드이므로 별도로 선언할 필요가 없습니다. 프록시 그룹 이름은 규칙에서 참조하는 이름과 정확히 일치해야 합니다. 공백, 문장 부호, 대소문자가 다르면 참조에 실패할 수 있습니다.

구독 원문과 실행 설정 구분하기

Clash Plus, Clash Verge Rev 같은 클라이언트에서 원격 구독은 설정의 출처일 뿐인 경우가 많습니다. 클라이언트가 포트 설정, TUN 스위치, 전역 확장, 현재 구독에 적용되는 덮어쓰기 설정을 추가해 코어에서 실행할 파일을 생성할 수도 있습니다. 따라서 임시 생성 파일을 직접 수정해도 설정이 유지되지 않을 수 있습니다. 구독을 바꾸거나 설정을 저장하거나 클라이언트를 재시작하면 파일이 다시 생성될 수 있습니다. 지금 수정하는 파일이 구독 복사본인지, 지속적으로 적용되는 덮어쓰기 설정인지, 단순히 확인용으로 생성된 실행 결과인지 먼저 확인하세요.

일반 YAML 파일은 문법 검사를 통과해도 mihomo가 요구하는 필드 형식에 맞지 않을 수 있습니다. 예를 들어 proxy-groups를 문자열로 작성하면 일반 YAML 파서는 받아들일 수 있지만 코어가 요구하는 형식은 목록입니다. 반대로 문법과 구조가 올바르더라도 노드 연결이 보장되지는 않습니다. 도메인, 인증 정보, 원격 서비스도 별도로 확인해야 합니다. 문제 해결 시 '파일을 읽음', '시작에 성공함', '연결을 수립함'을 각각 구분하면 관계없는 필드를 반복해서 수정하는 일을 줄일 수 있습니다.

저장 전 확인할 세 가지

첫째, 편집기가 한글 그룹 이름을 깨뜨리지 않도록 UTF-8로 저장하세요. 둘째, 콜론 뒤 공백, 샵 기호 또는 특수 문장 부호가 포함된 문자열은 따옴표로 감싸세요. 주석은 따옴표 바깥의 샵 기호부터 시작하며 값에 포함되지 않습니다. 셋째, 같은 계층의 맵에 동일한 키를 중복해서 쓰지 마세요. 파서에 따라 중복 키를 오류로 처리하거나 마지막 항목만 남길 수 있습니다. 이런 동작을 설정 병합 방법으로 사용해서는 안 됩니다.

수정하기 전에 작동하는 설정을 따로 보관하고 테스트용 설정에 복사해 작업하세요. mihomo 실행 파일을 별도로 사용한다면 mihomo -t -f config.yaml로 설정을 검사할 수 있습니다. 클라이언트와 동일한 코어를 사용하고 상대 경로가 어느 디렉터리를 기준으로 하는지도 확인하세요. 테스트를 통과한 뒤에도 설정을 다시 불러오고 로그에서 현재 설정이 적용됐는지 확인해야 합니다. 구독 응답에 문제가 있다면 구독 파싱 실패 자가 점검 목록도 참고하세요.

2. 공통 필드: 수신 포트와 실행 모드

공통 필드는 코어가 로컬 연결을 받는 방식과 연결이 들어온 뒤 규칙에 따라 아웃바운드를 선택할지 결정합니다. Windows 시스템 프록시 설정을 대신하지는 않습니다. 코어가 포트를 수신한다는 것은 애플리케이션이 해당 포트에 연결할 수 있다는 뜻일 뿐입니다. 요청이 실제로 전달되려면 클라이언트의 시스템 프록시 스위치, 애플리케이션 자체 프록시 설정 또는 TUN 가로채기가 필요합니다. 브라우저에서 변화가 없다면 노드 프로토콜을 바로 바꾸지 말고 먼저 트래픽 유입 경로를 확인하세요.

port, socks-port, mixed-port

설정을 '빠짐없이' 갖추려고 프록시 포트 세 가지를 모두 켤 필요는 없습니다. 일반적인 데스크톱 환경에서는 혼합 포트 하나면 충분합니다. 포트 번호는 유효 범위 안에 있고 다른 프로세스가 사용하지 않으며 애플리케이션에 입력한 값과 일치하면 변경할 수 있습니다. 여기서 예시로 든 7897은 설명을 위한 값이며 모든 클라이언트의 기본값은 아닙니다. 포트를 바꿨다면 이전 포트를 직접 입력해 둔 브라우저 확장 프로그램, 명령줄 도구, 다운로드 프로그램도 함께 수정하세요.

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

이 설정은 로컬 애플리케이션만 접속하는 기본 구성에 적합합니다. allow-lan: false는 LAN 기기의 접속을 허용하지 않는다는 뜻입니다. 루프백 주소를 명시하면 로컬 전용이라는 점도 분명해집니다. 휴대폰에서 PC의 프록시를 사용하려면 관련 제한을 변경하고 PC의 LAN 주소를 사용한 뒤 신뢰할 수 있는 네트워크 범위에서 Windows 방화벽을 설정하세요. 문제를 확인하려고 방화벽 전체를 끄거나 로컬 프록시 포트를 공용 인터넷에 노출하지 마세요.

규칙 모드와 프록시 그룹은 별개 설정

mode: rule은 연결을 규칙에 차례로 대조합니다. global은 전역 아웃바운드 선택을 사용하고 direct는 연결을 직접 보냅니다. 전역 모드로 바꿔도 기존 규칙 내용은 수정되지 않으며 현재 라우팅 방식만 달라집니다. 규칙 모드에서 규칙이 선택 그룹을 가리키고 그 그룹이 다시 직결을 가리킬 수도 있으므로 '규칙 모드'라고 해서 요청이 반드시 원격 프록시를 거치는 것은 아닙니다. 실제로 적용된 규칙과 최종 아웃바운드 경로를 확인하세요.

클라이언트 화면의 모드 버튼이 실행 중 설정 파일의 값을 덮어쓰거나 설정을 다시 생성할 때 파일에 반영할 수 있습니다. 재시작할 때마다 다른 모드로 돌아간다면 구독을 반복해서 수정하지 말고 클라이언트의 저장 설정을 확인하세요. 문제를 진단할 때 log-level을 잠시 debug로 높이고 작업이 끝나면 info로 되돌릴 수 있습니다. 디버그 로그에는 도메인과 연결 정보가 기록될 수 있으므로 공유 전에 구독 주소, 인증 정보, 개인 접속 기록을 삭제하세요.

최상위 IPv6와 제어 인터페이스

최상위 ipv6는 코어의 IPv6 관련 지원을 제어합니다. 뒤에서 설명하는 DNS 섹션의 같은 이름 필드와는 계층이 다릅니다. 이 값을 끈다고 Windows 네트워크 어댑터의 IPv6까지 꺼지는 것은 아니며 모든 애플리케이션이 가로채졌다는 뜻도 아닙니다. 네트워크에서 IPv6가 필요하다면 유입 경로, 라우팅, DNS 조회, 노드 지원을 함께 확인하세요. 경로 불일치를 단일 비활성화 스위치로 덮어서는 안 됩니다.

external-controller는 관리 인터페이스이며 브라우저가 사용하는 HTTP 프록시 포트가 아닙니다. 주소와 인증 정보는 보통 클라이언트에서 관리하므로 구독에서 임의로 변경하지 않는 것이 좋습니다. 연결 패널은 표시되지 않지만 프록시는 계속 작동한다면 관리 인터페이스 연결 문제와 프록시 수신 문제를 구분해야 합니다. PowerShell에서 Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue를 실행해 포트 사용 상태를 확인하고 프로세스 정보와 대조하세요. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요.

3. 프록시 노드와 구독 제공자

노드 정의는 원격 프록시 서버에 연결하는 방법을 지정합니다. 최상위 proxies는 일반적으로 노드 목록이며 각 항목에 이름, 프로토콜 유형, 서버 주소, 포트, 프로토콜별 인증 정보가 들어갑니다. 이름은 프록시 그룹에서 참조하는 로컬 식별자이지 서버 주소가 아닙니다. 노드 이름을 바꾸면 화면에서 알아보기 쉬워질 수 있지만 해당 노드를 직접 참조하는 그룹도 함께 수정해야 합니다. 구독을 갱신할 때 이름이 다시 생성된다면 제공자나 안정적인 그룹 구조를 활용하는 편이 좋습니다.

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

server에는 도메인이나 IP 주소를 넣고 port에는 서버에서 실제로 수신하는 포트를 입력합니다. 공유 링크에 포함된 숫자라면 무엇이든 포트로 쓸 수 있는 것은 아닙니다. 프로토콜마다 인증 방식이 다릅니다. Shadowsocks는 보통 암호화 방식과 비밀번호를 사용하고 Trojan은 비밀번호와 TLS를 사용하며 VLESS에는 별도의 ID와 전송 설정이 있습니다. type만 바꾼다고 노드 프로토콜이 변환되지는 않습니다. 서버에서도 그에 맞는 서비스를 제공해야 합니다.

proxies:
  - name: "로컬 SOCKS 연결"
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

proxy-groups:
  - name: "출구 선택"
    type: select
    proxies:
      - "로컬 SOCKS 연결"
      - DIRECT

이 예제는 실제 SOCKS5 필드를 사용하지만 로컬에서 포트 1080으로 SOCKS 서비스를 실행 중일 때만 트래픽을 전달할 수 있습니다. 원격 노드를 제공하지 않으며 mihomo 자체의 혼합 포트를 가리키면 순환 연결이 생길 수 있습니다. 예제에서 로컬 주소를 사용한 이유는 가상의 인증 정보를 만들지 않고 데이터 구조를 설명하기 위해서입니다. 실제 노드 값은 서비스 제공자에게 받아 항목별로 확인하세요. 웹 예제의 인증 정보를 그대로 사용하지 마세요.

udp: true는 해당 노드가 UDP 트래픽을 처리하도록 허용한다는 뜻이지, 원래 UDP를 지원하지 않는 서비스에 기능을 추가하는 설정은 아닙니다. 프로토콜 구현, 서버 설정, 중간 네트워크, 트래픽 유입 방식이 모두 결과에 영향을 줍니다. 웹 페이지는 정상인데 음성 통화나 게임에 문제가 있다면 애플리케이션이 사용하는 전송 방식을 먼저 확인한 다음 노드가 이를 처리할 수 있는지 살펴보세요. 웹 페이지가 열린다는 이유만으로 전체 연결 경로가 정상이라고 판단해서는 안 됩니다.

proxy-providers는 프록시 모음의 출처

노드 목록을 별도로 갱신하려면 proxy-providers를 사용할 수 있습니다. 제공자 콘텐츠는 일반적으로 proxies 목록을 포함하는 프록시 모음이며 임의의 전체 설정 주소와 같은 형식으로 취급해서는 안 됩니다. HTTP 제공자는 원격 콘텐츠를 가져오고 파일 제공자는 로컬 파일을 읽습니다. 제공자 자체가 프록시 그룹은 아니므로 그룹에서 use로 참조해야 합니다. 아래 예제는 관계를 설명하기 위해 로컬 파일을 사용합니다. 경로는 코어가 읽을 수 있는 설정 디렉터리 안에 있어야 합니다.

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

proxy-groups:
  - name: "구독 출구"
    type: select
    use:
      - local-pool
    proxies:
      - DIRECT

해당하는 local-pool.yaml에는 노드 목록이 들어가야 하며 proxy-providers를 한 번 더 감싸서는 안 됩니다. 상대 경로는 일반적으로 실행 디렉터리나 코어의 작업 디렉터리를 기준으로 하므로 편집기에서 현재 열어 둔 폴더가 기준이라고 단정할 수 없습니다. 파일을 찾지 못하면 클라이언트에 표시된 설정 디렉터리와 코어 로그를 확인하세요. 파일을 시스템 디렉터리에 함부로 옮기거나 경로 제한을 피하려고 디스크 전체에 대한 접근 권한을 넓히지 마세요.

연결 실패는 단계별로 확인

먼저 서버 도메인이 조회되는지 확인하고 대상 포트에 연결할 수 있는지 점검한 다음 인증, TLS 이름, 전송 설정을 확인하세요. TLS 인증서 검증에 사용하는 이름이 연결 주소와 다를 수 있으므로 서버 요구 사항에 맞춰 입력해야 합니다. 인증서 오류가 나면 인증서 검증을 건너뛰는 것을 상시 해결책으로 삼지 말고 시스템 시간, 인증서 체인, 이름부터 확인하세요. 연결 시간 초과와 인증 거부는 서로 다른 단계에서 발생합니다. 포트를 계속 바꿔 보기보다 로그의 오류 유형을 확인하는 편이 더 유용합니다.

구독 주소에는 접속 정보가 포함되는 경우가 많으므로 스크린샷, 로그, 공개된 문의 글에 전체 링크가 노출되지 않도록 하세요. 클라이언트를 바꾸기 전에 구독 출처를 보관하고 클라이언트 페이지에서 플랫폼에 맞는 앱을 선택하세요. 이 사이트에서는 Clash Plus를 우선 추천하며 Clash Verge Rev 등 다른 선택지도 제공합니다. GUI 클라이언트마다 확장 필드를 처리하는 방식이 다르므로 이전할 때 코어의 지원 범위를 확인하고 mihomo와 원본 코어의 차이도 참고하세요.

4. 프록시 그룹: 선택, 속도 측정, 대체 경로

프록시 그룹은 규칙과 개별 노드 사이에서 출구를 결정합니다. 규칙이 그룹을 지정하면 그룹에서 노드를 선택하며, 그룹이 다른 그룹을 참조해 계층형 아웃바운드 구조를 만들 수도 있습니다. 이 구조를 사용하면 노드 목록을 갱신할 때 모든 도메인 규칙을 함께 수정하지 않아도 됩니다. 그룹 이름은 짧고 안정적으로 정하고 '업무 출구', '미디어 출구'처럼 용도를 나타내세요. 이름 자체가 특별한 동작을 일으키는 것은 아니며 실제 선택 방식은 type과 관련 필드가 결정합니다.

명시적으로 선택하려면 select

select는 수동 선택 그룹으로, 사용자가 클라이언트 화면에서 후보를 선택합니다. 노드, 다른 그룹, DIRECT 같은 내장 아웃바운드를 후보로 둘 수 있습니다. 처음 불러올 때 어떤 후보가 선택되는지는 클라이언트가 이전 선택을 저장하는지에 따라 달라지므로 목록의 첫 항목만 보고 현재 출구를 판단하지 마세요. 설정을 수정한 뒤에는 프록시 화면에서 실제 선택 상태를 확인해야 합니다. 특히 그룹에서 직결, 오래된 노드, 삭제된 후보를 선택한 적이 있다면 꼭 점검하세요.

proxy-groups:
  - name: "자동 대체"
    type: fallback
    proxies:
      - "로컬 SOCKS 연결"
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: "출구 선택"
    type: select
    proxies:
      - "로컬 SOCKS 연결"
      - "자동 대체"
      - DIRECT

이 조각은 이전 절에서 정의한 로컬 노드를 참조하므로 전체 설정을 단독으로 대체할 수 없습니다. fallback은 후보 순서에 따라 사용 가능한 출구를 선택합니다. 예제에서는 대체 동작을 설명하기 위해 직결을 마지막에 넣었습니다. 원격 프록시가 끊겼을 때 접속을 중단해야 하는 업무라면 DIRECT를 대체 그룹에 넣지 마세요. 후보가 사용 가능하다는 것과 원하는 개인정보 보호 수준을 유지한다는 것은 별개의 문제입니다. 대체에 성공해도 기존과 같은 네트워크 경로를 사용한다는 뜻은 아닙니다.

url-test와 fallback은 선택 기준이 다릅니다

url-test는 탐지 결과를 바탕으로 후보를 선택하며 일반적으로 응답이 빠른 출구를 자동 선택할 때 사용합니다. fallback은 후보 순서와 사용 가능 여부를 더 중요하게 봅니다. interval의 단위는 초이며 탐지 주기를 나타냅니다. 개별 연결의 시간 초과 값이 아닙니다. tolerance는 작은 차이 때문에 선택이 자주 바뀌는 현상을 줄이는 데 쓸 수 있지만 서비스 지연을 보장하는 값은 아닙니다. 그룹 내 후보를 바꾸면 새 연결에는 적용되지만 기존 연결은 바로 이전되지 않을 수 있습니다.

속도 측정 주소는 예상한 응답을 안정적으로 반환하는 HTTPS 주소여야 합니다. 예제의 주소는 탐지 대상일 뿐 사이트가 외부 리소스로 사용하는 주소가 아닙니다. 탐지 대상에 접속할 수 있다고 모든 웹사이트에 접속할 수 있는 것은 아니며, 반대로 탐지 주소가 차단되면 정상 노드도 비정상으로 표시될 수 있습니다. 한 번의 탐지 결과로 요금제 대역폭을 판단하지 말고 측정 시간을 다운로드 속도로 간주하지도 마세요. 문제를 확인할 때는 같은 주소에 직접 접속해 보고 로그에서 테스트가 어떤 노드를 거쳤는지 비교하세요.

그룹 참조는 한 방향으로 유지

그룹이 다른 그룹을 참조할 수는 있지만 순환 구조를 만들면 안 됩니다. 예를 들어 '출구 선택'이 '자동 선택'을 참조하고 '자동 선택'이 다시 '출구 선택'을 참조해도 더 똑똑한 결정을 내리는 것이 아니라 잘못된 종속 관계가 생길 뿐입니다. 제공자는 use로 추가하고 직접 지정하는 노드는 proxies로 추가할 수 있으며 필요에 따라 둘을 함께 사용할 수 있습니다. 후보 목록이 갑자기 비었다면 필터 조건이 너무 엄격한지, 제공자가 정상적으로 갱신됐는지, 덮어쓰기 설정에서 그룹 이름이 바뀌었는지 확인하세요.

로드 밸런싱은 단일 다운로드 연결을 여러 회선으로 나눠 속도를 합산하는 기능이 아닙니다. 분배 방식에 따라 같은 서비스의 여러 연결이 서로 다른 출구를 사용할 수 있으며 로그인 확인이나 세션 오류가 발생할 수 있습니다. 업무 로그인, 결제, 접속 출발지 주소가 고정되어야 하는 서비스에는 출구 하나를 명시적으로 선택하는 편이 낫습니다. 일반적인 데스크톱 설정이라면 이름만 비슷한 그룹을 많이 쌓기보다 수동 그룹 하나와 명확한 계층 몇 개를 유지하는 것이 관리와 연결 경로 확인에 유리합니다.

5. 규칙 문법과 위에서 아래로 매칭

규칙 모드에서 mihomo는 일반적으로 rules 목록을 위에서 아래로 확인해 처음 일치하는 항목의 아웃바운드를 사용합니다. 따라서 규칙 내용뿐 아니라 위치도 중요합니다. 범위가 넓은 직결 규칙을 앞에 두면 뒤에 있는 세부 도메인 규칙이 적용되지 않을 수 있습니다. 사용자 지정 규칙을 만들기 전에 도메인, 대상 IP, 프로세스 또는 다른 속성 중 무엇을 기준으로 매칭할지 정하고 그에 맞는 규칙 유형을 선택하세요. 비슷해 보이는 문구를 그대로 복사하는 것만으로는 충분하지 않습니다.

도메인 규칙에는 전체 URL을 넣지 않습니다

DOMAIN은 도메인 하나와 정확히 일치시킬 때, DOMAIN-SUFFIX는 도메인과 하위 도메인에 적용할 때 사용합니다. DOMAIN-KEYWORD는 키워드로 매칭하며 보통 적용 범위가 더 넓습니다. 필드에 https://, 경로, 쿼리 매개변수를 넣지 않습니다. 일반 도메인 규칙으로 웹 주소의 경로를 구분할 수는 없습니다. 한 웹사이트도 로그인, 이미지, API에 서로 다른 도메인을 사용할 수 있으므로 주소 표시줄의 기본 도메인만 처리하지 말고 실제 연결을 확인하세요.

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,출구 선택
  - 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,출구 선택

예제에 사용된 도메인은 문서용 예약 도메인이며 실제 서비스와 관련이 없습니다. '출구 선택' 그룹은 프록시 그룹에 정의되어 있어야 합니다. 마지막의 MATCH는 앞선 규칙에 매칭되지 않은 연결을 처리하는 기본 규칙이므로 대개 맨 끝에 둡니다. 그 앞의 사설 주소 규칙은 LAN 직결을 설명하기 위한 것입니다. 실제 네트워크에 맞춰 검토하세요. 일부 기업 네트워크에서는 특정 터널을 통해 사설망에 접속해야 하므로 사설 주소를 모두 로컬에서 바로 연결할 수 있다고 봐서는 안 됩니다.

no-resolve의 한계 이해하기

IP 유형 규칙은 대상 주소가 먼저 확인되어야 적용될 수 있습니다. 요청에 도메인이 포함되어 있다면 DNS 조회가 이후 매칭 경로에 영향을 줄 수도 있습니다. no-resolve를 추가하면 해당 규칙과 매칭하기 위해 도메인 조회를 새로 시작하지 않습니다. 대상 IP를 이미 알고 있는 연결은 계속 매칭될 수 있습니다. 이 옵션은 '이 연결에서 DNS를 절대 사용하지 않음'을 뜻하지 않으며 도메인을 자동으로 특정 주소에 연결하지도 않습니다. 도메인별로 안정적으로 분기하려면 보통 도메인 규칙을 먼저 작성하고 필요한 IP 규칙을 보완용으로 추가하세요.

프로세스 규칙은 Windows 애플리케이션별로 트래픽을 분리하는 데 유용하지만 코어가 연결에 해당하는 프로세스를 인식해야 합니다. 트래픽 유입 방식, 권한, 시스템 환경에 따라 인식 결과가 달라질 수 있습니다. 브라우저는 여러 하위 프로세스를 사용하고 애플리케이션 업데이트로 실행 파일 경로가 바뀔 수도 있으므로 규칙을 만들기 전에 연결 세부 정보에서 실제 프로세스를 확인하세요. 프로세스 규칙 매칭을 방화벽 수준의 격리로 간주해서는 안 됩니다. 엄격한 네트워크 제한이 필요하다면 운영체제의 제어 기능도 사용하세요.

규칙 제공자는 형식과 동작을 모두 확인

rule-providers는 재사용할 규칙 모음을 구성하는 기능이며 프록시 제공자와는 콘텐츠 유형이 다릅니다. behavior는 모음 안의 항목을 해석하는 방식을 나타내며 일반적으로 domain, ipcidr, classical이 사용됩니다. format은 파일 형식을 설명합니다. 두 필드는 각각 '어떤 규칙이 들어 있는지'와 '파일이 어떤 형식으로 저장됐는지'를 나타내며 서로 대체할 수 없습니다. 아래에서는 관계를 확인할 수 있도록 로컬 클래식 규칙 모음을 사용합니다.

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

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,출구 선택

# ./rules/local-domains.yaml 파일 내용:
# payload:
#   - DOMAIN-SUFFIX,example.com
#   - DOMAIN,intranet.example.org

규칙 모음의 항목에는 아웃바운드가 포함되지 않습니다. 참조하는 위치의 RULE-SET에서 대상이 이미 지정되기 때문입니다. 규칙 세트를 불러오지 못한다면 전체 규칙 목록을 삭제하기 전에 경로, 응답 내용, 파일 형식부터 확인하세요. 원격 주소가 로그인 페이지나 오류 메시지를 반환한다면 HTTP 요청에 성공했더라도 유효한 규칙 파일이 아닙니다. 갱신 주기는 다시 가져오는 간격만 제어할 뿐 원격 파일이 항상 파싱 가능하다고 보장하지 않습니다.

규칙을 확인할 때는 먼저 클라이언트 연결 화면에서 대상 도메인, 매칭된 규칙, 최종 아웃바운드를 확인한 뒤 순서를 바꾸세요. 기존 연결은 이전 경로를 계속 사용할 수 있습니다. 테스트 전에 해당 애플리케이션 연결을 끊거나 다시 열어 볼 수 있지만 새로고침 한 번으로 모든 연결이 새로 만들어지는 것은 아닙니다. 자세한 방법은 연결 확인 절차를 참고하세요. 구독이 주기적으로 갱신된다면 사용자 지정 규칙을 지속적으로 적용되는 덮어쓰기 설정에 넣으세요. 설정 병합에 대한 자세한 내용은 설정 덮어쓰기와 병합을 참고하세요.

6. DNS: 조회 경로와 fake-ip

DNS 설정은 도메인에서 IP 주소를 얻는 방법과 조회 요청이 전송되는 경로를 정합니다. 프록시 노드 선택과 관련은 있지만 같은 설정은 아닙니다. 브라우저에서 프록시를 통해 웹사이트에 접속할 수 있다고 해서 시스템의 모든 DNS 요청이 코어를 거치는 것은 아닙니다. 반대로 코어에서 DNS 기능을 켰다고 Windows나 애플리케이션이 조회 요청을 코어로 전달하는 것도 아닙니다. Clash DNS 누수를 확인하려면 필드 하나만 보고 판단하지 말고 요청의 출처, DNS 서버, 네트워크 출구를 먼저 확인하세요.

수신 주소가 시스템 DNS 가로채기를 뜻하지는 않습니다

dns.enable은 코어의 DNS 기능을 켜고 listen은 로컬 수신 주소를 지정합니다. 시스템 서비스와의 충돌을 피하기 위해 아래에서는 루프백 주소와 일반적이지 않은 포트를 사용합니다. 이 설정만 추가해도 TUN DNS 가로채기나 명시적인 전달 설정이 없다면 Windows에서 기본적으로 네트워크 어댑터의 DNS를 계속 사용할 수 있습니다. 포트가 포함된 주소를 IP만 입력할 수 있는 네트워크 어댑터 설정에 넣지 마세요. 유입 방식마다 주소 형식 요구 사항이 다릅니다.

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:
    - 1.1.1.1
  nameserver:
    - https://dns.cloudflare.com/dns-query

이 예제는 DNS 구조를 설명하기 위한 것으로 모든 네트워크에 적합한 상위 DNS를 의미하지 않습니다. default-nameserver는 DNS 상위 서버의 도메인을 조회할 때 발생할 수 있는 'DNS 서버에 접속하려면 먼저 그 서버의 주소를 조회해야 하는' 의존성을 줄이는 데 사용합니다. nameserver는 일반 조회에 사용할 상위 서버입니다. 암호화 DNS는 조회 전송 방식을 바꿀 수 있지만 아웃바운드 경로를 자동으로 변경하거나 로컬 네트워크에서 상위 서버에 접속할 수 없는 문제를 해결하지는 않습니다.

fake-ip 사용 시 연결 트래픽이 코어를 거쳐야 합니다

fake-ip는 도메인에 가상 주소를 할당하고 코어에 주소와 도메인의 대응 정보를 저장합니다. 이후 연결이 코어에 들어오면 이 정보를 바탕으로 처리합니다. 예제의 주소 대역은 이러한 매핑에 사용하는 값이며 웹사이트의 실제 공인 IP 주소가 아닙니다. 애플리케이션이 가상 주소를 받은 뒤 코어를 거치지 않고 직접 연결하면 접속에 실패할 수 있으므로 DNS 유입 경로와 트래픽 유입 경로를 함께 설정해야 합니다. 가상 주소가 보인다고 DNS 오류인 것은 아닙니다. 이후 연결이 같은 mihomo 인스턴스를 거치는지가 중요합니다.

fake-ip-filter를 사용하면 일부 도메인에는 가상 주소를 사용하지 않을 수 있습니다. 로컬 기기 검색이나 호환되지 않는 서비스에 흔히 사용하지만 모든 이상 동작을 필터 목록에 넣어서는 안 됩니다. 애플리케이션에서 실제 IP가 필요한지, 자체 DNS를 사용하는지, LAN 도메인을 어떤 DNS 서버가 응답해야 하는지 먼저 확인하세요. redir-host는 다른 방식으로 처리하며 매칭과 조회에 별도의 한계가 있습니다. 모드를 바꾼 뒤에는 기존 DNS 캐시가 남을 수 있으므로 이전 조회 결과로 새 설정을 판단하지 마세요.

도메인별 상위 DNS와 프록시 노드 조회

nameserver-policy를 사용하면 도메인에 따라 DNS 상위 서버를 선택할 수 있어 사내 도메인을 내부 DNS로 조회할 때 유용합니다. 프록시 서버 자체의 도메인 조회는 proxy-server-nameserver로 따로 지정해 일반 서비스 조회와 서로 의존하지 않도록 할 수 있습니다. respect-rules를 켜서 DNS 상위 서버로 가는 연결도 라우팅 규칙을 따르게 한다면 프록시 노드의 도메인을 어떻게 조회할지 먼저 정하세요. 그렇지 않으면 '조회하려면 프록시가 필요하고 프록시를 연결하려면 조회가 필요한' 순환이 생길 수 있습니다.

DNS 필드의 우선순위가 실제 동작에 영향을 주므로 처음부터 여러 대체 서버, 도메인별 정책, 복잡한 규칙을 한꺼번에 추가하지 않는 것이 좋습니다. 먼저 설명 가능한 조회 경로 하나를 만든 뒤 필요한 예외를 더하세요. 브라우저의 보안 DNS, 다른 VPN의 DNS 설정, 기업 보안 프로그램, 라우터의 전달 기능 때문에 테스트 요청이 예상한 경로를 거치지 않을 수도 있습니다. 대체 DNS 서버를 많이 등록한다고 항상 좋은 것은 아니며 각 서버의 연결 가능 여부와 적용 범위를 확인해야 합니다.

설정을 바꾼 뒤 필요하면 ipconfig /flushdns를 실행해 Windows DNS 캐시를 비우고 별도 캐시를 사용하는 애플리케이션도 다시 시작하세요. 시스템 캐시만 지워도 브라우저, 코어, 원격 DNS 서버의 캐시까지 반드시 지워지는 것은 아닙니다. LAN 프린터나 사내 도메인에 접속할 수 없다면 전체 분기 기능을 끄기 전에 올바른 내부 DNS를 복원하세요. 새 설정이 정상적으로 작동하는지 확인한 뒤 지속 설정으로 저장하고 로컬 조회가 필요한 도메인을 기록해 두면 나중에 관리하기 쉽습니다.

7. TUN, 시스템 프록시, Windows 라우팅

시스템 프록시와 TUN은 대표적인 트래픽 유입 방식입니다. 시스템 프록시는 Windows 프록시 설정을 따르는 애플리케이션에서 사용하며 브라우저 연결을 먼저 확인할 때 적합합니다. TUN은 가상 네트워크 장치와 라우팅을 통해 더 많은 트래픽을 처리하므로 시스템 프록시를 사용하지 않는 애플리케이션에 유용합니다. TUN을 켜도 노드 인증 정보가 바뀌거나 UDP 지원이 자동으로 추가되지는 않습니다. TUN을 연결하기 전에 작동하는 노드와 기본 규칙으로 아웃바운드를 확인하세요. 유입 경로와 원격 연결 문제를 동시에 진단하지 않도록 하는 것이 좋습니다.

설정 필드와 클라이언트 권한이 함께 결과를 결정

Windows에서 가상 네트워크 어댑터를 만들고 라우팅을 변경하거나 서비스를 설치할 때 권한이 필요할 수 있습니다. 클라이언트 서비스 모드, 관리자 권한 실행, 코어 설정은 각각 담당하는 역할이 다릅니다. YAML 스위치 하나만으로 모든 시스템 작업이 끝나는 것은 아닙니다. 클라이언트에서 제공하는 서비스 설치와 TUN 설정 기능을 우선 사용하세요. 화면에서 이 필드를 관리한다면 다음 설정 생성 시 구독을 직접 수정한 내용이 덮어쓰일 수 있습니다. 문제를 해결할 때 화면에 표시된 상태와 실제 실행 설정이 일치하는지 먼저 확인하세요.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

이 예제는 mihomo의 TUN 필드를 사용합니다. auto-route는 자동 라우팅을 요청하고 auto-detect-interface는 아웃바운드 인터페이스를 식별하며 dns-hijack은 코어 DNS가 처리할 요청을 지정합니다. 유효한 dns 설정과 함께 사용해야 합니다. 기존 DNS 포트를 가로채도 암호화 DNS를 모두 처리하는 것은 아닙니다. 애플리케이션이 HTTPS로 직접 조회하면 트래픽 형태가 달라지므로 동작을 별도로 확인해야 합니다.

네트워크 스택은 범용 성능 스위치가 아닙니다

stack은 코어가 지원하는 네트워크 스택 방식을 선택합니다. 호환성은 운영체제, 코어 구현, 애플리케이션에 따라 달라집니다. mixed는 여러 방식을 조합한 옵션이지 모든 기기에서 다른 방식보다 우수하다는 뜻은 아닙니다. 특정 애플리케이션에서 문제가 생기면 기준 설정을 보존하고 항목을 하나씩 비교하세요. 네트워크 스택, MTU, DNS, 노드를 한꺼번에 바꾸지 마세요. 한 번에 조건 하나만 바꿔야 무엇이 문제를 해결했는지 알 수 있습니다.

MTU는 네트워크 패킷 크기에 영향을 줍니다. 일부 경로에서는 패킷 분할이나 터널 캡슐화가 문제가 될 수 있지만 모든 지연의 원인은 아닙니다. 특정 사이트나 전송 방식, 큰 패킷에서만 문제가 나타나는지 먼저 살펴본 다음 조정을 고려하세요. 온라인에서 본 고정값을 성급히 적용하면 정상적인 연결의 원인을 더 파악하기 어려워질 수 있습니다. 시스템 프록시는 정상인데 TUN에서만 문제가 생긴다면 구독을 바로 바꾸기보다 라우팅, 유입 경로, DNS, 네트워크 스택을 중점적으로 확인하세요.

다중 네트워크 어댑터와 다른 VPN 점검 순서

PC가 유선, 무선, 가상 머신 네트워크 또는 회사 VPN에 동시에 연결되어 있으면 기본 경로와 DNS가 서로 다른 인터페이스에서 설정될 수 있습니다. 자동으로 아웃바운드 인터페이스를 감지해도 복잡한 네트워크 구성에서는 원하는 결과가 나오지 않을 수 있습니다. Get-NetRoute -AddressFamily IPv4로 라우팅을 확인하고 Get-NetIPConfiguration으로 인터페이스 설정을 점검할 수 있습니다. 현재 상태를 먼저 기록한 뒤 허용된 환경에서 충돌하는 프로그램을 하나씩 비활성화하세요. 정체를 알 수 없는 가상 네트워크 어댑터를 바로 삭제하지 마세요.

시스템 프록시와 TUN을 함께 켜도 반드시 이중 프록시가 되는 것은 아니지만 트래픽 유입 경로를 판단하기는 더 복잡해집니다. 문제를 확인할 때는 한 가지 방식만 남기고 애플리케이션의 추가 프록시 확장도 꺼서 테스트 조건을 명확히 하세요. 회사 기기는 관리자 정책의 제한을 받을 수 있으므로 네트워크 관리 규정을 따르세요. 서비스를 삭제하거나 시스템 보안 정책을 바꿔 제한을 강제로 우회하지 마세요. 상시 사용할 때는 클라이언트 자동 시작과 서비스 모드를 켤지 결정하면 됩니다.

클라이언트를 종료하기 전에 TUN과 시스템 프록시를 끄고 시스템 네트워크가 복구됐는지 확인하는 것이 좋습니다. 비정상 종료 후 웹페이지가 열리지 않으면 Windows 프록시 설정이 중지된 로컬 포트를 가리키는지 확인한 다음 남아 있는 라우팅과 다른 VPN의 상태를 점검하세요. 바로 전체 네트워크를 초기화하지 마세요. 빈 화면이나 서비스 시작 오류가 발생하면 Windows 클라이언트 시작 문제 해결을 참고하세요. 연결 경로 확인은 가이드의 연결 확인 절에서 이어서 진행할 수 있습니다.

8. 덮어쓰기, 병합, 되돌릴 수 있는 수정 절차

구독은 원격에서 관리되는 경우가 많으므로 가져온 콘텐츠를 직접 수정하면 업데이트 후 변경 사항이 사라질 수 있습니다. 덮어쓰기 설정을 사용하면 원격 노드 업데이트는 유지하면서 로컬 규칙과 설정도 보존할 수 있습니다. 다만 '덮어쓰기'는 mihomo 코어가 공통으로 정한 편집기 기능이 아니라 클라이언트가 설정 파일을 생성할 때 사용하는 처리 방식입니다. Clash Plus, Clash Verge Rev 등 클라이언트마다 메뉴 위치, 문법, 적용 순서가 다르므로 각 클라이언트의 안내를 확인하세요.

스칼라, 맵, 목록은 각각 다른 방식으로 병합

포트나 모드 같은 스칼라 값은 일반적으로 나중에 설정한 값이 앞선 값을 대체합니다. DNS 같은 맵은 하위 필드별로 합쳐질 수도 있고 통째로 교체될 수도 있습니다. 규칙과 프록시 그룹 같은 목록은 교체, 추가, 앞에 삽입 중 한 방식으로 처리될 수 있습니다. 클라이언트가 동작을 명시하지 않았다면 '이 항목을 모든 규칙의 맨 앞에 넣어 준다'고 가정하지 마세요. 아래는 원하는 최종 규칙의 예시일 뿐 모든 클라이언트에서 사용할 수 있는 덮어쓰기 명령이 아닙니다.

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

구독에 이미 규칙 목록이 있는데 위 예제로 목록 전체를 교체하면 구독의 나머지 규칙이 사라집니다. 끝에 추가하더라도 기존 목록에 MATCH가 있으면 새 규칙이 매칭되지 않을 수 있습니다. 클라이언트에서 지원하는 규칙 앞에 삽입 기능을 사용하거나 스크립트에서 삽입 위치를 명시한 뒤 생성된 결과를 확인하세요. 그룹 하나를 변경할 때도 기존 그룹을 수정하는지, 같은 이름의 그룹을 실수로 추가하는지 점검해야 합니다.

생성 순서를 먼저 파악한 뒤 적용 위치 결정

설정을 생성할 때 원격 구독, 구독별 확장, 전역 확장, 그래픽 인터페이스 설정, 실행 중 선택 항목이 차례로 적용될 수 있습니다. 실제 순서는 클라이언트마다 다르므로 특정 클라이언트의 방식을 전체 생태계의 공통 규칙으로 볼 수는 없습니다. 덮어쓰기 설정을 저장했는데 적용되지 않는다면 최종 실행 파일에 해당 필드가 있는지 먼저 확인하세요. 없다면 덮어쓰기가 적용되지 않았거나 뒤 단계에서 교체됐을 가능성이 큽니다. 필드는 있는데 동작이 다르면 참조 관계, 규칙 위치, 트래픽 유입 경로를 점검하세요.

전역 덮어쓰기는 로컬 수신 제한처럼 모든 구독에서 공통으로 사용할 설정에 적합합니다. 구독별 덮어쓰기는 특정 제공자나 그룹 이름에 의존하는 규칙에 적합합니다. 한 구독에만 존재하는 그룹 이름을 전역 규칙에 넣으면 다른 구독으로 바꿨을 때 대상 그룹을 찾지 못할 수 있습니다. 이전할 때는 이전 클라이언트 전용 구문 분석 스크립트와 코어의 YAML 설정을 분리하세요. 스크립트 파일 전체를 설정에 붙여 넣으면 안 됩니다. 관련 내용은 Clash for Windows 이전 노트를 참고하세요.

저장, 테스트, 적용, 검증의 네 단계

저장 단계에서는 현재 작동하는 설정의 출처와 덮어쓰기 내용을 먼저 백업하세요. 백업에 구독 인증 정보가 포함되어 있다면 안전하게 보관해야 합니다. 테스트 단계에서는 YAML 문법, 노드 참조, 규칙 대상이 올바른지 확인합니다. 독립 코어로 테스트할 수 있다면 조각이 아니라 최종 설정을 검사하세요. 적용 단계에서는 클라이언트가 이전 설정으로 되돌아가지 않았는지 확인하고 로그에서 파싱 오류나 제공자 오류를 살펴봅니다. 검증 단계에서는 변경 대상에 새 연결을 만들어 규칙 매칭과 최종 출구가 예상과 일치하는지 확인하세요.

# 해당 코어가 설치된 터미널에서 지정한 파일 테스트
mihomo -t -f config.yaml

# PowerShell: 예제 프록시 포트의 수신 상태 확인
Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue

# Windows 시스템 DNS 캐시 비우기
ipconfig /flushdns

각 명령은 서로 다른 항목을 확인합니다. 설정 테스트는 원격 인증을 검증하지 않고 포트가 수신 중이어도 대상 웹사이트에 접속할 수 있다고 보장하지 않습니다. DNS 캐시를 비워도 잘못된 규칙은 수정되지 않습니다. 세 명령을 만능 해결 절차처럼 사용하지 마세요. 명령을 찾을 수 없다면 출처를 알 수 없는 도구를 다운로드하지 말고 실행 파일 경로나 터미널 환경부터 확인하세요. 클라이언트에 설정 검사 기능이 내장되어 있다면 독립 코어와 클라이언트 코어의 버전 차이를 피하기 위해 해당 기능을 우선 사용해도 됩니다.

업데이트 후에는 시작 여부뿐 아니라 의존 항목도 다시 확인

구독 업데이트로 노드 이름이 바뀌거나 노드가 삭제되거나 그룹 규칙이 조정될 수 있습니다. 클라이언트 업데이트로 확장 처리 방식이 달라질 수도 있습니다. 업데이트가 끝나면 로컬 규칙에서 참조하는 그룹이 여전히 있는지, 규칙 제공자가 정상적으로 로드됐는지, TUN과 DNS가 예상대로 유지되는지 확인하세요. 시작에 성공했다는 것은 설정이 받아들여졌다는 뜻일 뿐 업무 규칙이 여전히 원래 목표대로 동작한다는 보장은 아닙니다. 중요한 애플리케이션에서 새 연결을 테스트하고 자주 사용하는 내부망 리소스와 일반 웹페이지에도 계획한 대로 접속되는지 확인하세요.

필드 용어를 더 알아보려면 용어 가이드를 참고하세요. 구독을 아직 가져오지 않았다면 구독 가져오기 절차로 돌아가면 됩니다. 고급 기능을 한 번에 모두 설정할 필요는 없습니다. 설정을 관리할 때 중요한 것은 각 필드의 용도가 분명하고 예외 규칙을 설명할 수 있으며 업데이트 후 되돌릴 방법이 있는 것입니다. 검증 가능한 짧은 로컬 덮어쓰기 설정이 구독 전체를 계속 복사하는 방식보다 안정적으로 관리하기 쉽습니다.