Clash YAML 설정 파일 가이드: 포트, DNS, 프록시 그룹 및 오버라이드

설정 구조와 YAML 문법

Clash 설정 파일은 코어가 요청을 어떻게 수신하고, 도메인을 확인하고, 출구를 선택하는지를 정의합니다. 클라이언트 화면의 모든 환경설정을 담는 파일은 아닙니다. 창 위치, 메뉴 막대 아이콘, 로그인 시 실행 여부 등은 보통 GUI 클라이언트가 별도로 저장합니다. 설정을 살펴보기 전에 현재 실행 중인 코어 종류와 클라이언트가 실제로 불러온 설정을 확인하세요. 파일명이 config.yaml이라고 해서 반드시 적용 중인 파일인 것은 아닙니다. 구독 설정, 로컬 설정, 실행 중 생성된 파일이 동시에 존재할 수 있습니다.

맵, 목록과 들여쓰기

YAML 맵은 키와 값으로 구성하고, 목록 항목은 하이픈으로 시작합니다. 최상위의 dns는 맵이고, proxies, proxy-groups, rules는 보통 목록입니다. 하위 필드는 상위 필드보다 더 들여써야 합니다. 탭 대신 공백 두 칸을 일관되게 사용하는 것을 권장합니다. 같은 계층의 필드는 나란히 정렬해야 합니다. 파서가 특정 줄을 가리켜도 실제 원인은 앞줄에 있을 수 있습니다. 따옴표가 닫히지 않았거나 목록 항목 앞의 하이픈이 빠진 경우가 대표적입니다.

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

dns:
  enable: true
  nameserver:
    - https://dns.alidns.com/dns-query

proxies: []

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

rules:
  - MATCH,출구 선택

이 예시는 직접 연결 출구만 포함하며 연결 가능한 원격 프록시 노드는 없습니다. YAML 계층 구조와 프록시 그룹 참조, 규칙의 최종 처리 관계를 확인하는 용도이며 서비스 제공업체의 노드 설정을 대체하지 않습니다. 각 절의 예시를 그대로 이어 붙여 하나의 파일로 만들지 마세요. 같은 최상위 필드는 한곳에 합쳐야 합니다. 특히 dns나 rules를 두 번 작성한 뒤 코어가 자동으로 병합할 것이라고 기대해서는 안 됩니다.

문자열, 불리언과 특수 문자

콜론 뒤에 공백이 있는 값, 해시 기호가 포함된 값, 자료형이 모호할 수 있는 값은 따옴표로 감싸는 것이 좋습니다. 일반 문자열에 해시 기호를 쓰면 주석 시작으로 처리되어 뒤쪽 내용이 비밀번호나 이름으로 읽히지 않을 수 있습니다. 불리언은 true 또는 false, 포트는 정수로 작성합니다. 노드 이름, 프록시 그룹 이름, 규칙 대상은 모두 문자열이므로 참조할 때 철자를 완전히 일치시켜야 합니다. 한국어 이름도 사용할 수 있지만 이름 앞뒤의 공백 역시 문자열의 일부가 될 수 있습니다.

큰따옴표를 사용할 때는 백슬래시 이스케이프에 유의하세요. 이스케이프가 필요 없는 일반 문자열에는 작은따옴표를 사용할 수 있습니다. 편집기가 따옴표를 곡선형 따옴표로 자동 교체하면 파일은 파싱되더라도 예상과 다른 문자열이 만들어질 수 있습니다. 참조 오류를 점검할 때는 화면에 비슷하게 보이는 이름만 보지 말고 원문을 비교하세요. 노드나 프록시 그룹에 같은 이름을 사용하지 말고, 사용자 지정 객체 이름으로 DIRECT, REJECT 같은 내장 출구 이름을 사용하지 마세요.

설정 출처와 검증 방법

구독 링크가 반환하는 내용이 완전한 YAML이라고 단정할 수 없습니다. 인코딩된 노드 목록을 반환하거나, 서버 측 변환이 필요하거나, 요청 방식에 따라 형식이 달라지는 링크도 있습니다. 가져오기에 실패하면 먼저 클라이언트에서 설정 유형을 확인한 다음 파싱 로그를 살펴보세요. 로그인 화면, 오류 페이지, 만료 안내가 YAML 확장자로 저장되어도 유효한 설정은 아닙니다. 구독 주소에는 접근 자격 증명이 포함될 수 있으므로 공개 게시판이나 스크린샷에 노출하지 마세요.

기기에 독립형 mihomo 명령줄 프로그램이 설치되어 있다면 터미널에서 다음 문법 검사를 실행할 수 있습니다. GUI 클라이언트에 내장된 코어는 셸 검색 경로에 없을 수 있으므로, 명령을 찾을 수 없다는 오류만으로 설정이 손상되었다고 판단하지 마세요. 검사에는 클라이언트와 비슷한 코어 및 동일한 리소스 디렉터리를 사용해야 합니다. 외부 규칙 파일을 참조하는 설정은 해당 파일도 존재해야 합니다. 검사를 통과해도 설정을 불러올 수 있다는 뜻일 뿐, 원격 노드에 연결되거나 트래픽 분리가 예상대로 작동한다는 보장은 없습니다.

mihomo -t -f ./config.yaml

정상적으로 연결되는 원본 설정을 보관하고, 관련 필드 한 묶음씩 수정하면서 예상한 변화를 기록하는 것이 좋습니다. 그러면 문제가 생겼을 때 문법 오류, 클라이언트 오버라이드, 네트워크 연결 실패, 규칙 매칭 이상을 구분하기 쉽습니다. 서로 관련 없는 온라인 설정 예시를 한꺼번에 추가하면 오류 원인이 뒤섞이고, 나중에 되돌릴 때 비교 기준도 사라집니다.

수신 포트와 접근 범위

포트 필드는 로컬 앱이 프록시 요청을 코어에 전달하는 진입점을 정합니다. 원격 노드 포트나 제어 API 포트와는 다릅니다. 브라우저가 로컬 혼합 포트에 연결되면 코어가 규칙에 따라 원격 노드나 직접 연결 출구를 선택합니다. 원격 노드의 서버 포트는 해당 노드 항목에 지정합니다. 이 두 계층을 혼동하면 시스템 프록시가 원격 서버를 가리키게 하거나, 원격 노드 주소를 루프백 주소로 잘못 바꾸는 일이 생깁니다.

HTTP, SOCKS와 혼합 포트

필드	처리하는 요청	사용 범위
`port`	CONNECT 요청을 포함한 HTTP 프록시	시스템 HTTP 및 HTTPS 프록시에서 사용 가능
`socks-port`	SOCKS 프록시	앱이 해당 프록시 프로토콜을 지원해야 함
`mixed-port`	HTTP 및 SOCKS 프록시	두 프로토콜이 하나의 수신 포트를 공유
`external-controller`	코어 관리 API	웹 트래픽 프록시 진입점이 아님

일반적인 데스크톱 환경에서는 혼합 포트 하나만 설정해도 됩니다. 예시는 7890을 사용하지만 모든 클라이언트가 같은 값을 사용하는 것은 아닙니다. 화면에 표시되는 값, 실행 중인 설정, 시스템 프록시 설정이 서로 일치해야 합니다. 독립된 수신 포트를 여러 개 사용한다면 포트 번호를 각각 다르게 지정해 같은 주소에서 충돌하지 않도록 하세요. 필요 없는 진입점을 끄는 편이 모든 포트 필드를 늘어놓는 것보다 이해하기 쉽고, 실제로 앱이 사용하는 포트도 확인하기 좋습니다.

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule

루프백 주소와 LAN 공유

127.0.0.1은 현재 기기의 IPv4 루프백 주소입니다. 휴대폰에 이 주소를 입력하면 휴대폰 자신에 연결되며 Mac에 연결되는 것이 아닙니다. Mac의 프록시를 LAN 기기와 공유하려면 LAN 연결을 명시적으로 허용하고 적절한 수신 주소를 설정한 뒤, 다른 기기에서 Mac의 실제 LAN 주소를 입력해야 합니다. 수신을 허용한 뒤에는 방화벽, 네트워크 격리, 접근 인증도 고려해야 합니다. 스위치 하나만 켜고 접근 범위를 무시해서는 안 됩니다.

allow-lan은 LAN 요청을 허용할지 제어하고, bind-address는 수신 주소를 제한합니다. 실제 접근 가능 여부는 필드 조합, 코어 동작, 시스템 방화벽에 따라 달라집니다. 데스크톱에서 혼자 사용할 때는 루프백 연결을 유지하는 것이 좋습니다. 공유할 때는 신뢰할 수 있는 네트워크로 범위를 제한하고, 라우터에서 로컬 프록시 포트를 인터넷에 직접 노출하지 마세요. 공용 Wi-Fi의 다른 기기는 같은 서브넷에 있다는 이유만으로 신뢰할 수 있는 것이 아닙니다.

macOS 시스템 프록시 필드

macOS의 웹 프록시와 보안 웹 프록시는 보통 로컬 HTTP 진입점을 사용합니다. 보안 웹 프록시라는 이름이 로컬 진입점에서 TLS를 별도로 활성화해야 한다는 뜻은 아닙니다. HTTPS 웹사이트는 일반적으로 HTTP CONNECT로 터널을 만듭니다. 클라이언트가 혼합 포트를 사용한다면 웹 프록시, 보안 웹 프록시, SOCKS 프록시가 같은 루프백 주소와 포트를 가리킬 수 있습니다. 포트를 각각 따로 사용하는 경우에는 각 항목을 알맞은 값으로 설정해야 하며, 예시 숫자를 그대로 복사하면 안 됩니다.

다음 명령으로 Wi-Fi라는 네트워크 서비스의 현재 설정을 확인할 수 있습니다. 기기마다 서비스 이름이 다를 수 있으므로 먼저 목록 명령으로 확인하세요. 네트워크 서비스가 여러 개라면 실제 연결에 사용 중인 서비스를 점검해야 합니다. 외장 어댑터, 유선 네트워크, 서비스 이름 변경으로 인해 확인 대상과 실제 출구가 달라질 수 있습니다. 명령 출력의 주소가 올바르더라도 클라이언트가 실제로 수신 중이라는 뜻은 아니므로 로컬 프로세스도 확인하세요.

networksetup -listallnetworkservices
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi
lsof -nP -iTCP:7890 -sTCP:LISTEN

포트가 사용 중이면 먼저 수신 중인 프로세스를 확인하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 프록시 클라이언트 두 개가 동시에 실행되면 포트를 두고 충돌하거나 시스템 프록시 설정을 번갈아 변경할 수 있습니다. 하나를 종료한 뒤에도 시스템 설정이 남아 있지 않은지 확인해야 합니다. 포트를 바꿨다면 셸 환경 변수, 편집기 프록시 설정, 앱에 직접 입력한 프록시 주소도 함께 업데이트하세요. 그렇지 않으면 브라우저는 정상화되어도 일부 앱은 이전 주소로 계속 연결할 수 있습니다.

모드와 트래픽 진입 경로

모드는 요청이 코어에 들어온 뒤 출구를 어떻게 선택할지 결정하고, 시스템 프록시와 TUN은 요청이 코어에 들어오는 경로를 정합니다. 서로 다른 두 문제입니다. 규칙 모드를 켜도 모든 앱의 트래픽이 자동으로 처리되지는 않으며, TUN을 켜도 모든 트래픽이 원격 프록시를 거쳐야 하는 것은 아닙니다. 연결 동작을 설명할 때는 먼저 앱이 어떤 진입 경로를 사용하는지 확인하고, 현재 코어 모드와 해당 연결의 매칭 결과를 차례로 살펴보세요.

규칙, 전역 및 직접 연결 모드

mode: rule은 규칙 목록 순서에 따라 출구를 선택하고, mode: global은 전역 정책을 사용하며, mode: direct는 직접 연결합니다. 연결 품질이나 네트워크 권한 수준을 나타내는 값이 아닙니다. 전역 모드는 문제가 규칙과 관련 있는지 잠시 비교할 때 유용하지만, 모든 문제를 해결하는 스위치로 사용해서는 안 됩니다. 선택한 원격 노드 자체에 연결할 수 없다면 전역 모드로 바꿔도 대개 나아지지 않습니다.

mode: rule
log-level: info
ipv6: false

GUI 클라이언트에서는 보통 화면에서 모드를 바꿀 수 있습니다. 이 설정이 제어 API를 통해 실행 중인 코어에 적용되더라도 원본 YAML에 다시 저장되지 않을 수 있습니다. 설정을 다시 불러온 뒤 모드가 유지되는지는 클라이언트의 저장 방식에 따라 다릅니다. 문제를 점검할 때는 파일과 실시간 화면을 모두 확인하세요. 편집기의 mode 값만 보고 현재 모드를 단정해서는 안 됩니다. 클라이언트 로그, 연결 화면, 생성된 설정을 확인하는 편이 더 직접적입니다.

시스템 프록시와 터미널 환경 변수

시스템 프록시는 해당 설정을 따르는 앱에 주로 영향을 줍니다. 많은 명령줄 프로그램은 자체 프록시 로직을 사용하며 기본적으로 macOS 네트워크 설정을 읽지 않습니다. 현재 셸에만 환경 변수를 임시로 설정해 비교 테스트할 수 있습니다. 새 터미널 창은 다른 창에서 나중에 추가한 변수를 자동으로 물려받지 않습니다. 변수 이름과 대소문자 지원 여부는 도구마다 다르므로 문제가 생기면 시스템 프록시를 반복해서 바꾸기보다 해당 도구의 문서를 확인하세요.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890

curl -I https://example.com

unset http_proxy https_proxy all_proxy

여기서 socks5h는 이 표기를 지원하는 도구가 대상 도메인을 프록시 측에서 확인하도록 합니다. 도메인을 로컬에서 먼저 확인한 뒤 주소를 보내는 방식과 다릅니다. 환경 변수는 해당 변수를 읽는 프로그램에만 적용되며 운영체제 전체의 네트워크 경로를 바꾸지는 않습니다. 일부 도구는 명령줄 인수나 설정 파일을 함께 제공하며, 이 설정이 환경 변수보다 우선할 수 있습니다. 무엇이 적용되는지 모호해지지 않도록 검증할 때는 중복 설정을 최대한 줄이세요.

TUN 설정과 권한 범위

TUN은 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 수신하며, 보통 클라이언트에 보조 서비스를 설치하거나 관련 권한을 부여해야 합니다. 다음은 mihomo에서 자주 사용하는 필드 조합이며 모든 GUI 클라이언트가 같은 방식으로 설정을 받는 것은 아닙니다. 일부 클라이언트는 TUN 필드를 자체적으로 관리하고 인터페이스를 자동 선택하거나 제외 경로를 생성합니다. 해당 클라이언트가 지원하는 설정 화면을 우선 사용하세요. 전체 활성화 절차는 TUN 모드 가이드에서 확인할 수 있습니다.

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

auto-route는 코어가 관련 라우팅을 설정하도록 하고, auto-detect-interface는 출구 인터페이스를 자동으로 찾습니다. Wi-Fi 전환, 도킹 스테이션 연결, 다른 VPN 실행으로 출구 인터페이스와 라우팅이 바뀔 수 있습니다. 연결이 끊기면 노드를 바로 원인으로 지목하지 말고 인터페이스와 라우팅 상태를 확인하세요. 기업 VPN, 가상 머신, 다른 네트워크 확장 기능도 경로를 바꿀 수 있으므로 함께 사용할 때는 하나씩 켜며 확인해야 합니다.

DNS 가로채기 규칙에도 한계가 있습니다. 위 설정은 일반 DNS 포트 트래픽을 대상으로 하며 앱에 내장된 암호화 DNS까지 모두 자동으로 처리한다는 뜻은 아닙니다. TUN을 켠 뒤 일부 도메인만 문제가 생기면 DNS 모드, 앱 자체 설정, 라우팅 제외 항목을 함께 점검하세요. 클라이언트를 종료하기 전에는 클라이언트가 트래픽 가로채기를 정상적으로 해제하도록 해야 합니다. 프로세스를 강제 종료하면 네트워크가 일시적으로 작동하지 않을 수 있습니다.

문제 비교는 정해진 순서로 진행하세요. 추가 VPN을 끄고 시스템 프록시만 테스트한 다음, 진입점이 작동하는 것을 확인하고 TUN을 켭니다. 마지막으로 다른 네트워크 도구를 다시 활성화하세요. 매번 조건 하나만 바꾸고 브라우저, 터미널, 대상 앱의 차이를 기록합니다. Windows 앱 루프백은 별도 플랫폼 기능으로 macOS TUN과 같은 뜻이 아닙니다. 자세한 내용은 Windows 앱 루프백 안내를 참고하세요.

DNS 필드와 도메인 확인 경로

DNS 설정은 세 가지를 확인해야 합니다. 앱의 조회가 코어로 들어오는지, 코어가 어떤 리졸버를 사용하는지, 조회 결과가 이후 연결에 어떻게 반영되는지입니다. 공용 DNS 주소 하나를 적는다고 모든 앱이 그 주소를 사용하는 것은 아닙니다. 시스템 프록시 환경에서 앱은 먼저 시스템 리졸버를 호출할 수 있습니다. HTTP CONNECT나 원격 DNS를 사용하는 SOCKS 요청은 도메인 이름을 그대로 전달할 수도 있습니다. TUN, 앱 내장 암호화 DNS, 로컬 캐시도 관찰되는 경로를 바꿉니다.

기본 리졸버와 부트스트랩 DNS

dns.enable은 코어의 DNS 모듈을 활성화하고, nameserver는 일반 업스트림 리졸버를 지정합니다. 암호화 DNS 주소에 도메인 이름을 사용한다면 해당 이름을 먼저 확인해야 합니다. default-nameserver는 이러한 초기 확인에 사용할 수 있으며 명확한 IP 주소를 지정하는 것이 적합합니다. 모든 리졸버를 서로 의존하는 도메인 이름으로 설정한 뒤, 아직 연결되지 않은 프록시 경로로 최초 연결이 이뤄지기를 기대하지 마세요.

dns:
  enable: true
  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
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

예시는 필드 간 관계를 보여줄 뿐, 특정 공용 리졸버가 모든 네트워크에 적합하다는 뜻은 아닙니다. 업스트림을 선택할 때는 현재 네트워크에서 직접 연결할 수 있는지, 조직 내부 도메인에 전용 리졸버가 필요한지, 원격 노드가 있는 네트워크에서 어떤 DNS가 필요한지 고려하세요. proxy-server-nameserver는 프록시 서버 도메인을 확인하는 필드입니다. 노드 주소 확인과 일반 웹사이트 확인을 분리해 시작 단계의 순환 의존 위험을 줄일 수 있습니다.

fake-ip와 실제 주소 모드

fake-ip 모드는 조건에 맞는 도메인에 합성 주소를 반환합니다. 코어는 매핑 정보를 이용해 원래 도메인을 복원한 다음 연결하고 규칙을 판정합니다. 예시의 네트워크 대역은 벤치마크용 주소 공간이지 원격 프록시 서버 주소가 아닙니다. 앱에 이런 주소가 표시되어도 반드시 DNS 오류는 아닙니다. 하지만 합성 주소를 받은 요청이 코어를 우회하면 연결에 실패할 수 있으므로 DNS 진입 경로와 트래픽 진입 경로가 일치해야 합니다.

실제 주소로 응답하는 모드는 기존 DNS 동작과 더 비슷하지만 앱 캐시, 공유 IP, 연결 방식에 따라 도메인과 연결의 연관성이 달라질 수 있습니다. 어느 한쪽이 무조건 더 낫다고 볼 수는 없습니다. LAN 검색, 게임, 기기 관리, 주소를 직접 검증하는 일부 앱에서는 fake-ip 제외가 필요할 수 있습니다. 필터 항목을 추가하기 전에 실제 원인이 주소 호환성인지, 원격 노드나 대상 서비스의 연결 실패인지 확인하세요.

도메인별 리졸버 지정

nameserver-policy를 사용하면 특정 도메인에 리졸버를 지정할 수 있어 회사 내부 도메인을 내부 DNS로 보내기에 적합합니다. 아래에서는 구조 설명을 위해 예시 도메인과 사설 주소를 사용했으므로 실제로 사용할 때는 조직에서 제공한 값으로 바꿔야 합니다. 내부 DNS에 기업 VPN을 통해서만 접근할 수 있다면 해당 주소까지 조회가 전달되도록 라우팅도 설정해야 합니다. 내부 도메인을 공용 리졸버로 보내면 보통 올바른 결과를 얻지 못하며 불필요한 조회 정보가 노출될 수도 있습니다.

dns:
  nameserver-policy:
    "+.corp.example.com":
      - 192.168.10.1

이 내용은 기존 dns 맵에 합쳐야 하며, 같은 이름의 최상위 필드를 두 번째로 추가해서는 안 됩니다. 규칙에 따라 DNS 출구를 선택하는 고급 설정을 도입하기 전에 기본 DNS 확인 경로가 정상적으로 작동하는지 확인하세요. 일부 DNS 라우팅 옵션은 조회 요청에도 규칙 판정을 적용합니다. 규칙 판정 자체에 DNS가 필요하다면 리졸버 수를 계속 늘리기보다 코어 문서를 참고해 의존 관계를 해결해야 합니다.

DNS 문제 확인 순서

먼저 클라이언트 로그에 해당 조회가 나타나는지 확인한 다음 응답 주소와 연결에서 최종 선택된 출구를 살펴보세요. 일반적인 dig 테스트만으로 앱 내장 암호화 DNS의 동작을 입증할 수는 없습니다. 브라우저에서 웹페이지가 열려도 터미널이 같은 DNS 경로를 사용한다는 뜻은 아닙니다. 설정을 바꾼 뒤에도 브라우저, 시스템, 코어가 각자 캐시를 유지할 수 있습니다. 기존 연결을 닫고 새 요청을 보내세요. 필요한 경우 클라이언트에서 안내하는 방법으로 캐시를 비우세요.

IPv6도 계층별로 살펴봐야 합니다. 최상위 스위치, DNS가 IPv6 주소를 반환하는지 여부, 운영체제에 사용할 수 있는 IPv6 경로가 있는지는 서로 다른 조건입니다. 특정 필드를 끄는 것만으로 모든 IPv6 문제를 설명할 수는 없습니다. 연결이 느리거나 첫 요청이 지연되면 DNS 조회 시간, 연결 설정 시간, 선택된 출구를 비교하고 네트워크 속도 저하를 단계별로 점검하는 방법을 참고하세요. 모든 대기 시간을 DNS 문제로 단정하지 마세요.

프록시 노드 필드와 원격 제공업체

프록시 노드는 특정 원격 연결 방식을 정의하며, 핵심은 프로토콜 종류, 서버 주소, 서버 포트, 인증 매개변수입니다. 프록시 그룹은 노드를 선택하고 규칙은 프록시 그룹을 선택하므로 서로 대체할 수 없습니다. 서비스 제공업체가 제공한 노드 필드를 기준으로 설정하고 이름만 보고 프로토콜을 추측하지 마세요. 이름에 특정 프로토콜이 표시되어도 단순한 라벨일 뿐이며, 코어가 실제로 사용하는 프로토콜은 type 필드에 지정됩니다.

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

name은 프록시 그룹에서 참조하는 이름이고, server는 서버 도메인이나 IP 주소이며, port는 원격 서비스의 수신 포트입니다. 인증 방식은 프로토콜마다 다릅니다. 비밀번호를 사용하거나 사용자 식별자를 사용하고, TLS와 전송 매개변수를 함께 요구하는 경우도 있습니다. 필드 이름이 비슷하다고 다른 프로토콜에서 그대로 가져다 쓸 수 있는 것은 아닙니다. 아래 Shadowsocks 예시는 구조만 설명하며 도메인과 비밀번호는 교육용 가짜 값이므로 원격 연결에 사용할 수 없습니다.

proxies:
  - name: "예시 출구"
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

암호화 방식, 비밀번호, 서버 포트는 서버 측 설정과 일치해야 합니다. 포트에 흔히 사용하는 웹 포트가 적혀 있어도 해당 노드가 HTTPS 서비스라는 뜻은 아니며 일반 브라우저에서 바로 접속할 수 있다는 뜻도 아닙니다. udp: true는 해당 기능을 설정에서 허용한다는 의미일 뿐입니다. 실제 동작 여부는 프로토콜 구현, 서버 지원, 상위 네트워크, 앱의 요청 경로에 따라 달라집니다. UDP가 작동하지 않으면 이 필드만 반복해서 바꾸지 말고 전체 연결 경로를 확인하세요.

TLS, 서버 이름과 전송 매개변수

TLS를 사용하는 프로토콜에서는 연결 주소와 인증서 검증에 사용하는 이름이 서로 다를 수 있습니다. server는 연결할 주소를 지정하며, 일부 프로토콜의 servername 같은 필드는 서버 이름을 전달하고 검증하는 데 사용됩니다. 구체적인 이름은 프로토콜 설정 형식에 따라 다릅니다. WebSocket 경로, 요청 헤더, gRPC 서비스 이름도 서버 설정과 일치해야 합니다. 이런 매개변수를 빠뜨리면 TCP 포트에 연결할 수 있어도 상위 계층 핸드셰이크는 실패할 수 있습니다.

인증서 오류가 나면 먼저 시스템 시간, 서버 이름, 인증서 체인, 서버 배포 상태를 확인하세요. 인증서 검증을 건너뛰면 보안 경계가 바뀌므로 일반적인 문제 해결 방법으로 사용해서는 안 됩니다. 용도를 모르는 상태에서 지문, 전송 최적화, 연결 재사용 필드를 임의로 추가하지 마세요. 다른 프로토콜에서 유효한 필드라도 현재 프로토콜이 지원한다는 보장은 없습니다. 파서가 알 수 없거나 무관한 필드를 받아들였다고 해서 예상한 대로 적용되는 것도 아닙니다.

원격 노드 모음과 상태 확인

proxy-providers를 사용하면 노드 출처를 기본 설정과 분리할 수 있어 노드 목록을 주기적으로 갱신하기에 적합합니다. 제공업체 파일은 노드 제공자 형식에 맞아야 합니다. 규칙과 DNS 설정까지 포함한 구독을 같은 입력 형식이라고 보고 그대로 사용할 수는 없습니다. 아래는 원격 출처 설정 예시이며 링크는 설명용입니다. 실제 설정에는 신뢰할 수 있는 출처를 사용하고 접근 자격 증명을 비공개 정보로 취급하세요. 공개 저장소에 올리지 마세요.

proxy-providers:
  remote-pool:
    type: http
    url: "https://example.com/proxies.yaml"
    path: ./providers/remote-pool.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

interval은 업데이트 간격이고 상태 확인 간격은 사용 가능성 검사 주기를 제어합니다. 서로 다른 역할을 합니다. 경로는 코어 작업 디렉터리를 기준으로 해석하며, GUI 클라이언트는 별도 데이터 디렉터리를 사용할 수 있습니다. 업데이트에 실패하면 원격 응답 오류, 형식 불일치, 로컬 디렉터리 쓰기 권한 문제를 구분하세요. 기존 캐시를 계속 사용할 수 있는지도 로그를 확인해야 합니다. 백업 없이 캐시를 바로 삭제해 아직 작동하던 노드 목록까지 지우지 마세요.

노드 이름과 참조 안정성

구독을 업데이트하면 노드 이름이 바뀔 수 있습니다. 수동 프록시 그룹에서 예전 이름을 하나씩 참조하고 있다면 업데이트 후 참조가 끊길 수 있습니다. 노드 이름을 대량으로 복사하는 것보다 제공업체의 use로 목록을 가져오는 편이 보통 관리하기 쉽습니다. 단, 필터 표현식도 이름 규칙에 맞춰 조정해야 합니다. 여러 출처를 합칠 때는 이름이 겹치지 않도록 하세요. 중복 이름은 표시 문제에 그치지 않고 프록시 선택, 로그 확인, 오버라이드 위치를 불분명하게 만들 수 있습니다.

노드 목록이 표시된다고 해서 사용 가능 여부까지 검증된 것은 아닙니다. 도메인 확인, 서버 연결, 프로토콜 핸드셰이크, 대상 접근 순서로 점검하세요. 노드 하나만 실패하면 같은 프록시 그룹의 다른 노드와 비교해 보세요. 모든 노드가 실패한다면 로컬 네트워크, 진입점, 시스템 시간, 설정 출처를 확인하세요. 속도 측정 결과도 모든 웹사이트, 프로토콜, 시간대에서의 실제 성능을 보장하지 않습니다.

클라이언트를 고를 때는 먼저 macOS 다운로드 페이지에서 Clash Plus를 살펴본 다음 필요한 기능에 따라 Clash Verge Rev와 FlClash를 비교할 수 있습니다. 화면 구성이 비슷해도 코어 필드 지원 범위가 완전히 같지는 않습니다. GUI 클라이언트와 코어의 역할 분담을 알아보려면 Clash 오픈 소스 생태계와 mihomo의 관계를 읽고 설정을 어느 계층에서 관리할지 결정하세요.

프록시 그룹 필드와 상태 확인

프록시 그룹은 노드를 묶어 규칙에서 참조할 출구 이름을 만듭니다. 노드가 자주 바뀌는 경우 규칙에서 개별 노드를 직접 지정하기보다 그룹을 대상으로 지정하면 노드를 교체해도 규칙 전체를 다시 쓸 필요가 없습니다. 그룹이 다른 그룹을 참조해 수동 선택과 자동 선택을 계층화할 수도 있습니다. 다만 참조에 순환이 없어야 하고, 그룹 이름은 고유해야 하며, 참조 대상은 모두 최종 실행 설정에 존재해야 합니다. 원본 구독에만 있고 오버라이드에서 삭제된 노드도 문제를 일으킬 수 있습니다.

수동 선택 그룹과 중첩 구조

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

  - name: "자동 선택"
    type: url-test
    use:
      - remote-pool
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

예시의 remote-pool은 앞 절에서 정의한 제공업체에 해당합니다. proxies에는 노드나 그룹 이름을 직접 나열하고, use는 제공업체의 노드 목록을 가져옵니다. select를 사용하면 실제 출구는 사용자가 현재 선택한 항목에 따라 달라집니다. 목록에 있는 노드에 연결 문제가 생겨도 자동으로 다른 노드를 고르지 않습니다. 사용자가 자동 선택 기능이 있는 하위 그룹을 선택한 경우는 예외입니다. 목록 순서가 현재 선택 상태를 의미하지도 않습니다.

중첩 구조를 활용하면 지역, 용도, 선택 방식을 나눌 수 있지만 계층이 너무 많으면 읽기 어려워집니다. 연결 화면에 규칙 대상이 표시되어도 그룹에서 현재 선택된 항목을 따라 최종 노드를 확인해야 합니다. 문제를 찾을 때는 알려진 노드를 직접 참조하는 간단한 선택 그룹을 만들어 노드 자체가 작동하는지 먼저 검증한 뒤 자동 그룹과 복잡한 중첩을 다시 적용하세요. 이렇게 하면 정책 로직 문제와 원격 연결 문제를 분리할 수 있습니다.

자동 선택, 장애 전환과 부하 분산

유형	주요 동작	적합한 용도
`select`	수동 선택 유지	출구를 직접 제어해야 할 때
`url-test`	측정 결과에 따라 노드 선택	사용 가능한 후보 중 자동 선택
`fallback`	후보 순서에 따라 사용 가능한 노드 선택	출구를 우선 고정하고 실패 시 전환
`load-balance`	선택한 정책에 따라 연결 분배	여러 출구로 요청 분산

url-test 결과는 지정된 테스트 주소에 접속한 성능을 나타냅니다. 다운로드 속도나 모든 대상 서비스의 종합 점수는 아닙니다. tolerance는 작은 차이로 잦은 전환이 발생하지 않도록 하는 값이며 단위는 밀리초입니다. 지연 시간이 고정된다는 보장은 아닙니다. 후보 노드 품질이 비슷하다면 매번 가장 낮은 측정값을 좇기보다 어느 정도 차이를 허용하는 편이 출구를 안정적으로 유지하는 데 유리할 수 있습니다.

fallback은 후보 순서에 따라 우선순위를 정합니다. 앞쪽 노드가 사용 가능하면 그 노드를 사용하며, 측정값이 항상 가장 낮은 노드를 선택하는 방식은 아닙니다. load-balance는 설정한 분배 정책에 따라 연결을 처리합니다. 하나의 연결을 여러 회선으로 나눠 대역폭을 합산하지 않습니다. 로그인 상태, 지역 인식, 세션 일관성이 중요한 앱에서는 여러 출구를 사용할 때 생길 수 있는 영향을 고려하세요. 이름에 부하 분산이 있다고 해서 무조건 활성화하지 마세요.

테스트 주소, 간격과 지연 검사

테스트 주소는 안정적이고 가벼운 응답을 제공하며 확인하려는 연결 상태를 잘 나타내야 합니다. 어떤 노드가 테스트 사이트에는 접근할 수 없지만 실제 대상에는 연결할 수 있다면 자동 정책이 그 노드를 현재 테스트 조건에 부적합하다고 판단할 수 있습니다. 반대로 테스트에 성공해도 모든 서비스를 이용할 수 있다는 뜻은 아닙니다. 테스트 주소의 한계를 이해하고 인터넷 전체의 상태를 나타내는 값으로 여기지 마세요. 오판이 의심되면 실제 대상 요청과 로그를 비교하세요.

interval을 줄이면 탐지 빈도와 요청 횟수, 기기 자원 사용량이 늘어날 뿐 노드 대역폭이 직접 높아지지는 않습니다. 제공업체 상태 확인과 프록시 그룹 테스트를 모두 사용하면 중복 검사가 발생할 수도 있습니다. 일부 그룹은 사용되지 않을 때 검사를 줄이는 지연 검사 기능을 지원하므로 그룹으로 전환한 직후에는 상태가 갱신될 때까지 기다려야 할 수 있습니다. 모든 간격을 아주 짧게 맞추기보다 사용 패턴에 따라 설정하세요.

필터 표현식과 선택 상태

filter나 제외 표현식으로 제공업체 노드를 거를 때는 먼저 이름에 예상한 문자열이 실제로 포함되어 있는지 확인하세요. 정규식에서 괄호, 세로줄, 특수 문자는 각각 의미가 있으므로 일반적인 설명을 그대로 필터 조건으로 사용하면 안 됩니다. 구독에서 이름이 바뀌면 그룹이 비어 있을 수 있습니다. 필터를 수정한 뒤에는 그룹 제목만 남아 있는지 보지 말고 펼친 노드 목록을 확인하세요. 후보 목록이 비어 있는 것은 자동 그룹 이상을 찾는 중요한 단서입니다.

클라이언트나 설정에서 선택 상태 저장을 사용하면 설정을 다시 불러온 뒤에도 이전 수동 선택이 복원될 수 있습니다. 이름이 바뀌면 복원에 실패할 수도 있습니다. YAML 목록 순서를 테스트할 때는 현재 실제 선택을 먼저 확인하세요. 첫 번째 항목이 항상 적용된다고 생각하면 안 됩니다. 세 가지 자동 정책의 작동 방식과 용도는 url-test, fallback, load-balance 비교에서 확인한 뒤 기존 그룹을 조정할지 판단하세요.

규칙 문법과 적용 순서

규칙 목록은 순서대로 처리되는 결정 과정입니다. 코어는 앞에서부터 확인하고 먼저 일치한 규칙의 출구를 사용하므로 같은 규칙이라도 순서가 달라지면 결과가 달라질 수 있습니다. 규칙을 작성할 때는 범위가 명확한 예외를 먼저 두고, 더 넓은 범위의 규칙을 뒤에 배치한 다음 마지막에 최종 처리 규칙을 추가하세요. 목록 맨 앞에 MATCH를 놓고 뒤의 도메인 규칙도 적용되기를 기대하지 마세요. 제한되지 않은 요청을 최종 규칙이 이미 처리합니다.

도메인, 접미사와 키워드 규칙

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,출구 선택
  - DOMAIN-KEYWORD,example,출구 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,출구 선택

DOMAIN은 도메인 전체가 일치하는지 확인하므로 단일 호스트 예외에 적합합니다. DOMAIN-SUFFIX는 해당 도메인과 하위 도메인 범위를 모두 매칭합니다. DOMAIN-KEYWORD는 문자열 포함 여부를 기준으로 하므로 범위가 넓고 관련 없는 서비스와 일치할 가능성도 큽니다. 규칙의 도메인에는 https://, 경로, 쿼리 매개변수를 붙이지 마세요. 전체 웹 주소를 처리하는 곳이 아닙니다. 특정 호스트를 구분해야 한다면 범위가 분명한 규칙을 우선 사용하세요.

각 규칙의 마지막 대상은 실제로 존재하는 노드, 프록시 그룹, 내장 출구여야 합니다. 한국어 쉼표는 영문 쉼표를 대신할 수 없으며 이름에 공백이 더 들어가면 참조를 확인하기 어려워집니다. 대상이 없다는 오류가 나면 규칙만 확인하지 말고 앞 단계의 노드 병합이나 그룹 오버라이드로 이름이 바뀌었는지도 점검하세요. 자주 갱신되는 노드 목록에서는 개별 노드보다 이름이 안정적인 프록시 그룹을 대상으로 지정하는 편이 관리하기 쉽습니다.

IP 규칙과 DNS 확인에 미치는 영향

IP-CIDR과 IP-CIDR6은 IP 대역을 기준으로 판단합니다. 요청에 도메인만 포함되어 있다면 일부 IP 규칙은 먼저 도메인을 확인해야 할 수 있습니다. no-resolve를 추가하면 규칙 매칭을 위해 조회를 새로 시작하지 않도록 할 수 있습니다. 그렇다고 모든 IP 요청을 무시하는 것은 아닙니다. 연결에 대상 IP가 이미 포함되어 있으면 해당 주소로 계속 매칭될 수 있습니다. 이 옵션은 DNS 확인 동작을 제어하며 직접 연결이나 프록시 여부를 정하지 않습니다.

사설 네트워크 대역 규칙은 LAN 접근을 보호하는 데 적합하지만 실제 네트워크에는 다른 주소 대역과 특수 라우팅도 있을 수 있습니다. 한 번의 조회에서 특정 주소를 발견했다고 넓은 공인 IP 대역 전체를 직접 연결로 지정하지 마세요. 대규모 서비스는 IP를 공유할 수 있고 조회 결과도 네트워크에 따라 달라집니다. 도메인으로 명확하게 표현할 수 있는 정책은 한 번의 IP 조회 결과를 따라가는 것보다 안정적입니다. IP 기준 분리가 필요하다면 대역 범위와 업데이트 출처를 확인하세요.

원격 규칙 집합과 선언 방식

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

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

해당 규칙 파일은 다음 구조를 사용합니다. 여기서 behavior: domain은 페이로드가 도메인 매칭 항목이라는 뜻이지, 완전한 규칙 문장 목록이라는 뜻은 아닙니다. 제공업체가 classical을 사용하면 페이로드 형식과 사용할 수 있는 규칙 유형이 달라집니다. 규칙 제공자 선언, 파일 형식, 실제 내용은 서로 일치해야 합니다. 확장자가 같다고 내부 구조까지 같다는 뜻은 아니며 다운로드 실패 응답으로 받은 웹페이지도 규칙 집합으로 불러올 수 없습니다.

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

규칙 집합에는 매칭 항목만 저장합니다. 실제 출구는 기본 설정의 RULE-SET 규칙에서 결정합니다. 규칙 집합을 정상적으로 불러와도 앞선 규칙이 이미 일치하면 내부 도메인이 예상한 출구를 사용하지 않을 수 있습니다. 규칙 집합을 업데이트한 뒤에는 연결 화면에 표시되는 실제 규칙 유형과 대상을 확인하세요. 특정 도메인 하나를 해결하려고 원격 규칙 전체를 맨 앞으로 옮기면 먼저 적용해야 하는 LAN 규칙이나 업무 예외가 달라질 수 있습니다.

연결 재사용과 검증 방법

규칙을 바꾸면 보통 새로 만들어지는 연결에 적용됩니다. 기존 장기 연결, 브라우저 연결 풀, 앱 세션은 이전 경로를 계속 사용할 수 있습니다. 확인할 때는 관련 연결을 닫고 명확한 대상에 새로 요청한 뒤 일치한 규칙, 프록시 그룹, 최종 노드를 함께 살펴보세요. 웹페이지 하나가 여러 도메인에 요청을 보낼 수 있습니다. 기본 문서, 이미지, 로그인, API 요청이 서로 다른 경로를 사용할 수도 있으므로 페이지가 열리는지만으로 모든 하위 요청의 정책이 올바른지 판단할 수 없습니다.

모든 진입 경로에서 도메인 정보를 확인할 수 있는 것은 아닙니다. 앱이 IP에 직접 연결하거나 자체 DNS 확인을 사용하거나 기존 연결을 재사용하면 규칙에 보이는 정보가 달라질 수 있습니다. 적절한 경우 스니핑 기능으로 도메인 정보를 보완할 수는 있지만 완전한 URL을 파악하는 기능은 아니며 모든 암호화 연결에서 정보를 복원한다고 보장할 수도 없습니다. 연결 기록에 실제로 표시되는 메타데이터를 바탕으로 점검하세요. 코어가 브라우저 주소창의 전체 내용을 확인한다고 가정하지 마세요.

설정 오버라이드, 병합과 검증 절차

오버라이드를 사용하면 구독 업데이트를 유지하면서 로컬 포트, DNS, 규칙, 프록시 선택을 관리할 수 있습니다. 중요한 것은 YAML을 하나 더 작성했는지가 아니라 클라이언트가 여러 출처를 어떻게 최종 설정으로 병합하는지입니다. 원본 구독, 로컬 오버라이드, 클라이언트 환경설정, 실행 중 API 변경은 서로 다른 계층에 있을 수 있습니다. 어떤 계층이 최종적으로 필드 값을 결정하는지는 모든 클라이언트에서 같지 않습니다. 현재 클라이언트의 병합 설명과 실제 생성 결과를 기준으로 확인하세요.

스칼라, 맵과 목록의 차이

스칼라 필드는 보통 뒤에 설정한 값이 앞선 값을 덮어씁니다. 예를 들어 혼합 포트 값이 다른 값으로 바뀝니다. 맵은 깊은 병합을 하거나 전체를 교체할 수 있고, 목록은 교체하거나 앞뒤에 추가하거나 전용 스크립트로 처리할 수 있습니다. 한 클라이언트의 병합 방식이 다른 클라이언트에서도 같다고 가정하지 마세요. 특히 규칙 목록을 교체하면 원래 규칙이 사라지고 뒤에 추가하면 MATCH 뒤에 배치되어 실제로 매칭되지 않을 수 있습니다.

필드 형태	일반적인 처리 방식	확인할 항목
스칼라, 예: `mixed-port`	새 값으로 덮어쓰기	화면 설정이 다시 값을 바꾸는지
맵, 예: `dns`	깊은 병합 또는 전체 교체	기존 하위 필드가 유지되는지
목록, 예: `rules`	교체, 앞에 추가 또는 뒤에 추가	최종 처리 규칙과 사용자 지정 규칙의 순서
객체 목록, 예: `proxy-groups`	도구의 처리 방식에 따름	이름 기준으로 매칭하는지, 이름이 중복되는지

구독 내용과 로컬 변경 사항 분리

노드 자격 증명과 원격 노드 목록은 신뢰할 수 있는 구독을 따라 업데이트하고, 수신 포트, LAN 권한, 로컬 DNS 예외는 로컬에 저장하는 것이 적합합니다. 일회성으로 다운로드한 캐시 파일을 직접 수정한 뒤 다음 업데이트에서도 변경 내용이 유지되기를 기대하지 마세요. 현재 기기의 네트워크 인터페이스 이름, 절대 경로, 로컬 수신 주소를 모든 기기에 동기화하지도 마세요. 운영체제와 클라이언트마다 데이터 디렉터리, 권한, 지원 필드가 다릅니다.

# 로컬 필드 예시; 병합 방식은 클라이언트 설명을 따르세요
mixed-port: 7890
allow-lan: false
log-level: info

profile:
  store-selected: true

이 예시는 유지하려는 로컬 필드만 보여줄 뿐, 규칙 병합 방식을 정의하지 않습니다. profile.store-selected는 프록시 그룹 선택을 저장하는 설정이며 클라이언트가 구독 파일을 저장하는 기능과는 다릅니다. 클라이언트에 같은 설정이 있다면 화면에서 생성한 값과 오버라이드 중 어느 쪽이 우선하는지 확인하세요. 같은 필드를 여러 곳에서 관리하면 편집기 값과 화면에 표시되는 값이 달라질 수 있어 이후 문제를 찾기 어려워집니다.

최종 설정 확인과 최소 변경

수정하기 전에 현재 정상 작동하는 설정을 내보내거나 백업하고, 사용 중인 클라이언트, 코어 종류, 주요 스위치를 기록하세요. 수정한 뒤에는 최종 실행 설정을 열어 대상 필드가 있는지, 다른 계층에 덮어쓰이지 않았는지, 참조된 그룹 이름이 여전히 존재하는지 확인합니다. 원본 구독은 그대로인데 실행 설정이 달라지는 것은 정상적인 생성 과정입니다. 원본 파일을 수정했는데 실행 설정이 바뀌지 않았다면 잘못된 파일을 편집했거나 설정을 다시 생성하지 않았을 수 있습니다.

검증은 네 단계로 나눌 수 있습니다. 먼저 YAML 문법과 코어 로드를 확인하고, 다음으로 로컬 포트가 수신 중인지 살펴봅니다. 이어서 명확한 프록시 요청 하나를 테스트하고 마지막으로 규칙과 최종 출구를 확인하세요. 단계마다 필요한 증거가 다릅니다. 문법 검사를 통과해도 노드에 연결된다는 뜻은 아닙니다. 노드에 연결되어도 시스템 프록시가 설정되었다는 뜻은 아니며, 브라우저가 작동해도 터미널이 프록시를 거친다는 뜻은 아닙니다. 각 단계를 차례로 확인해야 잘못된 설정 영역에서 계속 시도하는 일을 막을 수 있습니다.

mihomo -t -f ./config.yaml
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl --proxy http://127.0.0.1:7890 -I https://example.com

명령줄 테스트 결과는 클라이언트의 실제 환경과 비교해야 합니다. 독립형 코어는 작업 디렉터리, 규칙 캐시, 권한이 다를 수 있으므로 독립 테스트에 성공했다는 이유만으로 클라이언트 설정 생성 문제를 제외할 수 없습니다. 설정을 다시 불러온 뒤 로그에서 파싱 실패, 객체 누락, 수신 실패를 확인하고 가장 먼저 나타난 명확한 오류부터 해결하세요. 이후 발생하는 연결 실패는 앞선 로드 오류의 결과일 수 있으므로 각각 별개의 네트워크 문제로 다루지 않는 것이 좋습니다.

롤백, 공유와 자주 묻는 질문

수정 후 연결이 끊기면 먼저 이전에 사용 가능했던 설정으로 복구하고 새로 추가한 오버라이드를 끈 뒤 차이를 하나씩 다시 적용하세요. 원본 구독을 보관하고 임시 테스트 파일로 유일한 사본을 덮어쓰지 마세요. 여러 기기에서 동기화할 때는 공통으로 사용할 내용만 공유하고 로컬 경로, 네트워크 인터페이스, 기기별 규칙은 해당 기기에 남겨두세요. 구독 주소와 노드 비밀번호는 접근을 제한해 보관해야 합니다. 자세한 방법은 여러 기기 간 설정 동기화 안내를 참고하세요.

YAML을 수정했는데 클라이언트가 이전 포트를 계속 사용하는 이유는 무엇인가요?

현재 선택된 설정을 수정했는지 먼저 확인한 다음 클라이언트의 포트 설정, 오버라이드 파일, 최종 실행 설정을 살펴보세요. 화면 환경설정의 우선순위가 더 높다면 해당 설정 화면에서 값을 통일해야 합니다. 다시 불러온 뒤 수신 프로세스를 확인하고 시스템 프록시와 앱에 직접 입력한 프록시 주소도 업데이트하세요.

구독을 업데이트한 뒤 사용자 지정 규칙이 사라지는 이유는 무엇인가요?

구독 캐시를 직접 수정하면 다음 업데이트 때 덮어써지는 경우가 많습니다. 클라이언트가 지원하는 지속형 오버라이드 기능을 사용하고 규칙을 앞에 추가하는지, 뒤에 추가하는지, 전체 교체하는지 확인하세요. 사용자 지정 규칙이 일치하려면 관련 범위가 넓은 규칙과 MATCH보다 앞에 있어야 합니다.

하나의 설정 파일을 모든 Clash 클라이언트에서 그대로 사용할 수 있나요?

이름만으로 호환성을 판단할 수는 없습니다. 노드 프로토콜, DNS 필드, TUN 매개변수, 병합 방식이 다를 수 있습니다. 먼저 코어의 지원 범위를 확인한 뒤 공통 설정은 유지하고 기기 및 클라이언트 전용 설정은 분리하세요. 처음 설정한다면 빠른 시작 가이드로 돌아가 설정을 가져온 다음 고급 설정을 단계별로 추가하세요.

설정 관리의 목표는 모든 필드의 출처를 명확히 하고, 모든 규칙의 순서를 설명할 수 있으며, 변경할 때마다 되돌릴 기준을 남기는 것입니다. 문제가 생기면 먼저 범위를 좁힌 뒤 세부 항목을 추가하세요. 다시 설치하거나 클라이언트를 비교하려면 다운로드 페이지를 이용하세요. 설정 가져오기, 모드 선택, 연결 확인을 순서대로 진행하려면 빠른 시작 가이드로 돌아가세요. 가이드의 모든 필드를 한꺼번에 활성화해야 한다고 생각할 필요는 없습니다.