01 핵심 개념: 연결은 어떤 과정을 거칠까
클라이언트, 코어, 프록시 서비스는 서로 다릅니다
Clash 생태계에서 클라이언트는 보통 구독 관리, 모드 전환, 연결 확인을 위한 창과 메뉴가 있는 앱을 가리킵니다. 코어는 네트워크 트래픽을 전달하고 규칙을 매칭하는 프로그램이며, Mihomo는 이 생태계에서 흔히 쓰이는 코어입니다. 화면이 열렸다는 것은 앱이 실행됐다는 뜻일 뿐, 코어가 설정을 불러왔거나 네트워크 요청이 프록시로 전달되고 있다는 의미는 아닙니다. 문제를 해결할 때 이 과정을 나눠 확인하면 반복해서 재설치하는 것보다 효과적입니다.
프록시 서비스는 원격 연결에 필요한 주소, 프로토콜, 인증 정보를 제공하고, 구독은 이러한 설정을 배포하는 방식입니다. 클라이언트를 설치한다고 사용할 수 있는 서비스가 자동으로 생기지는 않습니다. 사용 권한이 있는 서비스 제공처에서 호환되는 설정을 받아 현지 법률, 서비스 약관, 이용 중인 네트워크의 관리 정책을 준수하세요. 구독 링크에 접속 인증 정보가 포함될 수 있으므로 공개 게시판에 올리거나 출처가 불분명한 변환 사이트에 입력하지 마세요.
요청이 들어오는 경로부터 출구까지 이해하기
요청은 보통 네 단계를 거칩니다. 앱이 요청을 보내고, 시스템 프록시나 가상 네트워크 인터페이스가 요청을 코어에 전달합니다. 규칙에 따라 정책이 결정되고, 정책에 따라 직접 연결하거나 원격 프록시를 사용합니다. 시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정이며, 실제로 따를지는 앱에 달려 있습니다. TUN은 더 많은 네트워크 트래픽을 가져올 수 있는 가상 네트워크 인터페이스지만, 라우팅, 권한, 제외 설정의 영향을 받습니다. TUN을 켠다고 모든 프로그램이 예상대로 동작하는 것은 아닙니다.
노드는 개별 원격 연결 설정이고, 프록시 그룹은 노드나 다른 정책을 관리하는 묶음입니다. 규칙에 적힌 PROXY는 대개 프록시 그룹 이름이며 모든 설정에 기본으로 포함되는 키워드가 아닙니다. DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. 규칙이 특정 이름을 가리킨다면 설정에 해당 이름이 있는지 확인한 뒤, 그 그룹에서 어떤 항목이 최종 선택됐는지 확인하세요.
| 계층 | 확인할 내용 | 주요 확인 위치 |
|---|---|---|
| 요청 유입 | 앱이 요청을 코어에 전달하는지 | 시스템 프록시, TUN, 앱 프록시 |
| 규칙 판단 | 요청에 어떤 규칙이 적용됐는지 | 연결 상세 정보, 규칙 화면 |
| 출구 정책 | 정책 그룹이 최종적으로 어떤 출구를 선택했는지 | 프록시 그룹, 연결 경로 |
| 원격 연결 | 서버, 인증, 프로토콜을 사용할 수 있는지 | 로그, 서비스 제공처의 상태 안내 |
DNS와 포트가 결과에 영향을 주는 이유
DNS는 도메인 이름을 IP 주소로 변환하는 체계입니다. 클라이언트는 시스템 DNS를 이용하거나 코어의 DNS 기능을 사용할 수 있습니다. 어느 단계에서 이름을 해석하는지에 따라 도메인 규칙의 적용 여부, IP 규칙의 매칭 결과, 요청이 해석을 기다리는 시간이 달라집니다. 연결에 실패했다고 곧바로 노드 문제라고 단정하지 마세요. 도메인 해석 실패, 해석된 IP에 연결할 수 없는 문제, 프록시 핸드셰이크 실패는 각각 다른 원인입니다.
포트는 로컬 서비스에 접속하는 번호입니다. 혼합 포트는 보통 HTTP 프록시와 SOCKS 프록시 요청을 모두 받지만, 클라이언트마다 기본값이 다릅니다. 이 문서의 예시는 7897을 사용합니다. 실제 설정에서는 클라이언트에 표시된 값을 기준으로 삼으세요. 포트 번호가 일치해도 트래픽이 코어에 전달된다는 보장은 없습니다. 수신 주소와 앱 설정을 확인하고, 해당 포트를 다른 프로그램이 사용 중인지도 점검해야 합니다.
02 클라이언트 선택: 플랫폼과 관리 방식부터 확인
사용 중인 기기에 맞는 GUI 클라이언트부터 선택하세요
처음 사용한다면 Clash Plus를 우선 살펴보고, 플랫폼과 사용 습관에 따라 다른 클라이언트와 비교해 보세요. 화면 모양만 보고 고르거나, 튜토리얼 화면과 똑같이 보이도록 오래된 프로그램을 설치하지 마세요. 운영체제 지원 여부, 프로세서 아키텍처 호환성, 구독 형식 지원 여부, 필요한 시스템 프록시·로그·TUN 관리 기능을 확인하는 것이 중요합니다. 설치 파일은 Clash 다운로드 페이지에서 확인할 수 있습니다.
Windows에서는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu를 차례로 살펴볼 수 있습니다. macOS에서는 Clash Plus, Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. Linux GUI 클라이언트로는 Clash Verge Rev와 FlClash가 있습니다. 클라이언트가 비슷한 코어 기능을 제공하더라도 서비스 설치 방식, 오버라이드 기능, 권한 관리는 서로 다를 수 있습니다. 따라서 이 문서에서는 특정 버튼 위치를 모든 클라이언트의 공통 기준으로 삼지 않고 기능 이름을 사용해 설명합니다.
모바일 기기와 데스크톱의 차이
Android에서는 필요에 따라 Clash Plus, Clash Meta for Android, FlClash, Surfboard 중에서 선택할 수 있습니다. Surfboard의 설정 체계는 Clash YAML과 완전히 같지 않으므로 모든 Clash 설정을 그대로 가져와 각 항목이 대응한다고 기대해서는 안 됩니다. 먼저 서비스 제공처에서 지원하는 구독 형식을 확인한 다음 클라이언트를 선택하세요. 모바일 운영체제는 대개 VPN 인터페이스로 트래픽을 가져옵니다. 앱을 처음 연결할 때 표시되는 시스템 권한 요청은 트래픽을 가져오는 과정의 일부입니다.
iOS에서는 다운로드 페이지를 통해 Clash Plus의 App Store 페이지로 이동하거나 공식 사이트 clashplus.io를 확인할 수 있습니다. 모바일의 백그라운드 제한과 앱별 트래픽 처리 방식은 데스크톱의 시스템 프록시 설정과 다릅니다. 여러 기기에서 설정을 익힐 때는 메뉴 이름을 그대로 따라 하기보다 규칙의 원리와 설정 간 관계를 적용하세요. 구독을 함께 사용하더라도 각 기기에서 실행 매개변수까지 모두 똑같이 쓸 수 있다는 뜻은 아닙니다.
| 사용 목적 | 선택할 때 확인할 사항 | 다음 단계 |
|---|---|---|
| 처음 사용 | 구독 가져오기와 시스템 프록시 설정이 쉬운지 | 먼저 규칙 모드로 연결 |
| 사용자 지정 규칙 관리 | 영구 오버라이드, 규칙 삽입 또는 병합 기능을 제공하는지 | 오버라이드 적용 순서 기록 |
| 더 많은 앱의 트래픽 처리 | TUN 지원, 서비스 권한, 시스템 호환성 | 이 문서의 TUN 섹션 읽기 |
| 서버 또는 라우터 | 코어 아키텍처, 실행 방식, 관리 기능 | 서비스와 접근 제어를 별도로 설계 |
클라이언트와 코어를 별도로 보관해 사용
Clash for Windows와 ClashX Meta는 유지 관리가 중단됐으며, 다운로드 페이지에서는 보관용 옵션으로 안내합니다. 기존 설정은 마이그레이션할 때 참고할 수 있지만 새 환경에는 지속적으로 관리되는 솔루션을 우선 선택하는 편이 좋습니다. 이전할 때는 구독 출처, 규칙의 목적, 프록시 그룹 선택을 보존하고 새 클라이언트의 데이터 디렉터리를 통째로 덮어쓰지 마세요. 이전 버전의 데이터베이스, 캐시, 서비스 등록 정보는 새 클라이언트와 호환되지 않을 수 있습니다.
Mihomo 코어 패키지는 설정, 프로세스, 권한을 직접 관리할 수 있는 사용자를 대상으로 합니다. 완전한 GUI가 포함된 설치 프로그램과는 다르며, 모든 시스템 연동을 자동으로 처리하지도 않습니다. 브라우저에서 규칙에 따라 네트워크를 사용하는 것이 목적이라면 GUI 클라이언트로 기본 과정을 먼저 설정하는 편이 간편합니다. 기존 환경을 이전하려면 Clash for Windows 지원 종료 후 대안과 마이그레이션 방법도 참고해 포트와 프록시 설정을 하나씩 확인하세요.
이 단계에서는 여러 클라이언트를 동시에 설치해 비교 실행할 필요가 없습니다. 주력 클라이언트 하나를 선택하고 다른 도구는 종료해 시스템 프록시, 라우팅, DNS를 동시에 변경하지 않도록 하세요. 네트워크 경로를 하나로 정리해야 이후 검증 결과를 제대로 해석할 수 있습니다.
03 설치 확인: 시스템 아키텍처, 권한, 로컬 포트
다운로드 전에 운영체제와 프로세서 아키텍처 확인
먼저 시스템 정보를 열어 운영체제, 프로세서 아키텍처, 사용 가능한 저장 공간을 확인하세요. Windows 설치 파일은 보통 x64용이며, macOS는 Intel과 Apple Silicon을 구분해야 합니다. Linux는 배포판에 따라 패키지 형식도 확인해야 합니다. 이름에 ARM이 들어간다고 모든 ARM 기기에서 같은 파일을 사용할 수 있는 것은 아닙니다. 다운로드 페이지에 표시된 아키텍처와 클라이언트 요구 사항을 따르고, 확장자를 바꾸거나 강제로 압축을 풀어 플랫폼 호환성 문제를 해결하려 하지 마세요.
설치 전에 이전 프록시 클라이언트와 네트워크 트래픽을 처리할 수 있는 다른 도구를 종료하세요. 이전 앱의 시작 프로그램 설정이나 상주 서비스가 활성화돼 있다면 창만 닫아도 백그라운드 프로세스가 남을 수 있으므로 트레이 메뉴에서 완전히 종료해야 합니다. 이전 환경의 혼합 포트와 구독 출처를 기록해 두면 마이그레이션 후 확인하기 쉽습니다. 새 클라이언트에서 연결을 완료하고 검증하기 전에는 기존 설정을 삭제하지 마세요.
플랫폼에 맞춰 처음 실행하기
Windows에서는 설치 프로그램을 실행한 뒤 일반 앱으로 먼저 시작하세요. 서비스 설치나 TUN 권한이 필요할 때만 클라이언트 안내에 따라 권한을 높이세요. 앱 전체를 항상 관리자 권한으로 실행하는 것을 일반적인 해결책으로 삼지 마세요. macOS에서는 앱을 응용 프로그램 폴더에 넣고 시스템에서 승인하는 방식으로 실행하세요. 보안 경고가 나오면 출처와 경고 내용을 먼저 확인하고, 출처를 알 수 없는 터미널 명령을 따라 시스템 보호를 일괄 해제하지 마세요.
Linux에서는 배포판에 맞는 패키지 관리 방식으로 설치하고, 의존성 오류가 해결됐는지 확인하세요. GUI가 열리면 코어 상태와 로그 메뉴가 작동하는지 확인합니다. 데스크톱 환경에 따라 시스템 프록시 설정 방식이 다를 수 있습니다. 프록시 설정이 자동으로 적용되지 않았다고 해서 코어가 실행되지 않는 것은 아닙니다. 앱 시작 실패, 코어 시작 실패, 시스템 연동 실패를 구분한 다음 해당 단계에 맞게 해결하세요.
정상적인 첫 실행 기준 만들기
처음 실행한 뒤 설정에서 혼합 포트, 수신 주소, LAN 연결 허용 여부를 확인하세요. 현재 컴퓨터에서만 사용할 경우 보통 로컬 접근 범위만 허용하면 됩니다. 이 문서에서는 127.0.0.1:7897을 예시 주소로 사용합니다. 실제 포트가 다르면 이후 앱 설정과 명령에 해당 값을 사용하세요. 설정을 저장한 뒤 클라이언트에서 수신 실패나 포트 충돌이 발생하지 않았는지 확인합니다.
# Windows PowerShell: 예시 포트의 수신 상태 확인
Get-NetTCPConnection -LocalPort 7897 -State Listen
# macOS / 일반적인 Linux 환경: 예시 포트 확인
lsof -nP -iTCP:7897 -sTCP:LISTEN이 명령은 운영체제에 맞춰 문제를 확인할 때 사용하는 도구이며 모든 플랫폼에서 실행할 필요는 없습니다. 수신 상태가 표시되지 않으면 먼저 코어가 실행됐는지, 설정을 불러왔는지, 실제 포트가 이 값인지 확인하세요. 프로세스가 표시되면 프로세스 이름도 확인하세요. 포트가 사용 중이라는 이유만으로 정상이라고 판단할 수는 없습니다. 명령을 찾을 수 없다는 메시지가 나오면 시스템 기본 리소스 모니터나 클라이언트 로그로 확인하면 됩니다. 한 번 확인하려고 별도 도구를 설치할 필요는 없습니다.
설치 단계에서 TUN, 시작 시 연결, 모든 자동 업데이트 옵션을 바로 켤 필요는 없습니다. 먼저 클라이언트가 정상적으로 시작되고 로그를 읽을 수 있으며 포트 충돌이 없는지 확인한 다음 구독 섹션으로 넘어가세요. 문제가 발생하면 오류 원문과 재현 단계를 남겨 두세요. 단순히 ‘열리지 않음’이라고 기록하는 것보다 해결에 도움이 됩니다. 이 단계의 목표는 검증하지 않은 기능을 쌓는 것이 아니라, 재현 가능한 최소 로컬 환경을 갖추는 것입니다.
04 구독 가져오기: 링크에서 실제 실행 설정까지
호환되는 설정을 받은 뒤 업데이트하세요
구독은 업데이트 가능한 설정 출처로, 원격 링크나 로컬 YAML 파일 형태로 제공됩니다. 먼저 서비스 제공처에 어떤 클라이언트나 코어에서 사용할 수 있는지 확인하세요. 그런 다음 클라이언트의 구독, 설정 또는 Profiles 화면에서 원격 설정 추가를 선택합니다. 알아보기 쉬운 이름을 입력하고 링크 전체를 붙여 넣은 뒤 저장하고 업데이트하세요. 링크 끝부분의 매개변수를 빠뜨리지 말고, 웹페이지에 보이는 제목을 실제 구독 주소로 착각하지 마세요.
업데이트가 완료되면 해당 설정을 선택해 활성화해야 하는 경우가 많습니다. 다운로드 완료와 설정 적용은 별개의 작업입니다. 구독 목록의 업데이트 시간이 바뀌었다고 실행 중인 코어가 전환된 것은 아닙니다. 현재 설정 이름과 코어 로그, 프록시 그룹이 표시되는지 확인하세요. 이전 그룹 이름이 계속 보이면 활성화 상태부터 점검합니다. 일부 클라이언트는 여러 구독을 함께 관리할 수 있지만, 실제 실행 설정이 어떻게 병합되는지는 클라이언트별 설정 방식을 확인해야 합니다.
구독 파일, 오버라이드, 실행 결과 구분하기
구독 원문은 서비스 제공처가 전달한 데이터이고, 오버라이드는 클라이언트가 불러올 때 내용을 추가하거나 수정하는 설정입니다. 실행 설정은 코어가 최종적으로 받는 결과입니다. 다운로드된 캐시를 직접 수정하면 다음 업데이트에서 덮어써질 수 있습니다. 장기간 유지할 규칙, 포트, DNS 설정은 클라이언트에서 제공하는 영구 오버라이드 기능에 두고, 구독 전·후 중 언제 적용되는지 또는 항목별로 병합되는지 확인하세요.
모든 원격 설정에 완전한 규칙이 포함되는 것은 아닙니다. 노드만 제공하고 클라이언트 템플릿으로 프록시 그룹과 규칙을 보완해야 하는 설정도 있고, DNS, 규칙 제공자, 완성된 정책이 이미 포함된 설정도 있습니다. 가져온 뒤 먼저 구조를 확인하고 튜토리얼에 맞추려고 기존 설정을 바로 삭제하지 마세요. 특히 프록시 그룹 이름은 규칙에서 참조될 수 있으므로 그룹 이름만 바꾸고 규칙은 수정하지 않으면 코어에서 설정을 거부하거나 일부 정책이 작동하지 않을 수 있습니다.
# 구조 예시: 설정 항목을 익히기 위한 예시이며 프록시 서비스 설정이 아닙니다
mixed-port: 7897
allow-lan: false
mode: rule
proxies: []
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,PROXY위 YAML은 설정 간 관계를 보여 주지만 원격 노드가 없어 모든 요청이 직접 연결됩니다. 항목을 읽고 확인하는 데는 사용할 수 있지만 프록시 서비스를 검증하는 용도는 아닙니다. 실제 구독의 서버 주소, 비밀번호, 프로토콜, 인증서 매개변수는 사용 권한이 있는 출처에서 받아야 합니다. 교육용 예시를 조합해 만들지 마세요. YAML은 공백으로 들여쓰며 같은 계층에서는 들여쓰기 수준을 통일해야 합니다. 탭 문자, 전각 콜론, 짝이 맞지 않는 따옴표는 파싱 오류를 일으킬 수 있습니다.
오류 유형에 따라 업데이트 문제 해결하기
네트워크 시간 초과가 표시되면 현재 네트워크에서 구독 서비스에 접속할 수 있는지 확인하고, 기존 프록시를 통해 업데이트해야 하는지도 점검하세요. 인증 실패가 나오면 링크 만료 여부와 서비스 이용 상태를 확인합니다. 설정 대신 웹페이지 내용이 반환되면 로그인 페이지, 오류 페이지 또는 리디렉션 페이지가 열린 것일 수 있으니 서비스 제공처에 올바른 주소를 문의하세요. 다운로드는 성공했지만 파싱에 실패하면 노드를 계속 바꾸기보다 필드 호환성과 오류가 발생한 행을 확인하세요.
로컬 파일 가져오기는 이전이나 오프라인 백업에 유용하지만 보통 서비스 제공처의 업데이트를 자동으로 반영하지 않습니다. 원격 구독은 서비스 유효 기간과 업데이트 주기에 맞춰 사용하고 지나치게 자주 수동 새로 고침을 하지 마세요. 업데이트 전에 복구 가능한 로컬 설정을 보관하고, 업데이트 후에는 프록시 그룹, 규칙, 연결이 정상인지 확인합니다. 로그나 화면을 공유할 때는 구독 링크, 서버 인증 정보, 개인 접속 기록을 가리세요. 이름만 가렸다고 안전한 것은 아닙니다.
05 프록시 모드: 트래픽 진입과 라우팅 판단을 따로 설정
규칙, 전역, 직접 연결 모드의 차이
프록시 모드는 코어에 들어온 요청이 어떤 출구를 사용할지 결정하며, 모든 앱이 요청을 코어에 전달하도록 보장하지는 않습니다. 규칙 모드는 설정된 규칙을 차례로 적용하므로 일상적인 트래픽 분기에 적합합니다. 전역 모드는 코어에 들어온 요청을 전역 정책으로 보내 문제 범위를 잠시 좁힐 때 유용합니다. 직접 연결 모드는 코어에 들어온 요청을 대상에 바로 연결하므로 비교 테스트에 적합합니다. 전역 모드로 바꿔도 시스템 프록시를 거치지 않던 앱이 갑자기 트래픽을 전달하는 것은 아닙니다.
전역 모드가 특정 노드를 의미하는 것도 아닙니다. 전환한 뒤 전역 정책이 현재 어떤 그룹이나 출구를 가리키는지 확인하세요. 규칙 모드에서는 각 규칙이 참조하는 정책 그룹의 선택 상태를 확인해야 합니다. 그룹에 DIRECT가 포함됐다면 해당 항목을 선택했을 때 직접 연결됩니다. 화면에 규칙 모드라고 표시돼도 마찬가지입니다. 요청의 실제 동작을 확인하려면 연결 경로와 규칙 매칭 결과를 봐야 하며 홈 화면의 모드 이름만 확인해서는 안 됩니다.
| 설정 | 해결하는 문제 | 단독으로 보장하지 않는 결과 |
|---|---|---|
| 시스템 프록시 | 시스템 프록시 설정을 따르는 앱에 프록시 연결 경로 제공 | 모든 앱과 모든 UDP 요청의 트래픽 처리 |
| 규칙 모드 | 도메인, 주소 등의 조건에 따라 정책 선택 | 규칙과 관계없이 모든 앱의 요청이 자동으로 코어에 전달되는 것 |
| 전역 모드 | 코어에 들어온 요청을 전역 정책으로 전달 | 선택한 원격 서비스의 정상 작동 |
| TUN 모드 | 가상 네트워크 인터페이스를 통해 더 많은 트래픽 처리 | 모든 규칙과 DNS 설정의 정확성 |
설명 가능한 첫 연결 검증하기
먼저 규칙 모드를 활성화하고 프록시 그룹에서 사용할 권한이 있는 출구를 선택한 다음 시스템 프록시를 켜세요. 확인할 웹페이지를 열면서 연결 화면을 확인합니다. 새 연결이 표시되지 않으면 브라우저에 별도 프록시 설정이 있는지, 확장 프로그램이 설정을 덮어쓰는지, 요청이 캐시된 것은 아닌지 먼저 확인하세요. 페이지를 다시 열어 새 요청을 보낼 수 있지만, 브라우저의 기존 연결을 모드 전환 후 결과로 착각하지 마세요.
연결이 표시되면 상세 정보를 펼쳐 대상 도메인, 적용된 규칙, 최종 정책을 확인하세요. 웹페이지가 열리는 것은 결과 중 하나일 뿐입니다. 직접 연결이 성공했을 수도 있고 프록시가 적용됐을 수도 있습니다. 설정에서 직접 연결로 지정한 테스트 도메인과 프록시로 지정한 대상을 비교해 예상한 경로를 확인하세요. 웹페이지 하나의 성공 여부로 전체 네트워크 환경을 판단하거나 외부 페이지에 표시된 지역을 유일한 근거로 삼지 마세요.
시스템 프록시를 따르지 않는 앱에 진입 경로를 직접 설정하기
일부 명령줄 도구는 데스크톱의 시스템 프록시 설정을 자동으로 읽지 않습니다. 이런 경우 도구 자체의 프록시 설정을 사용하거나 단일 명령에 로컬 진입 주소를 지정하세요. 아래 요청은 혼합 포트를 예시로 사용합니다. 실제 포트가 다르면 해당 숫자를 바꾸세요. 이 방법은 HTTP 프록시 진입을 확인하는 용도이며 UDP나 TUN도 정상이라고 판단할 근거는 아닙니다. 요청 결과는 대상 사이트, 현재 네트워크, 선택한 정책의 영향도 받습니다.
curl --proxy http://127.0.0.1:7897 --head https://example.com명령에서 로컬 포트에 연결할 수 없다고 나오면 설치 섹션으로 돌아가 수신 상태를 확인하세요. 프록시에는 연결됐지만 원격 핸드셰이크가 실패한다면 출구, 인증, 네트워크 제한을 확인해야 합니다. 일시적으로 전역 테스트를 할 때는 원래 모드와 프록시 그룹 선택을 기록하고, 테스트가 끝나면 규칙 모드로 되돌리세요. 모드 전환은 보통 새 연결에만 적용되므로 기존 장기 연결은 이전 경로를 계속 사용할 수 있습니다. 필요하면 해당 연결을 종료한 뒤 요청을 다시 보내 확인하세요.
이 단계에서는 세 가지를 순서대로 확인하는 습관을 들이세요. 먼저 요청이 코어에 들어왔는지, 다음으로 어떤 규칙이 적용됐는지, 마지막으로 출구가 작동하는지 확인합니다. 요청이 아예 들어오지 않았다면 규칙을 바꿔도 해결되지 않습니다. 규칙은 제대로 적용됐지만 핸드셰이크에 실패했다면 규칙을 계속 수정하는 것은 변수만 늘립니다. 더 짧은 작업 순서가 필요하다면 입문 가이드로 돌아가 기본 과정을 따라 해 보세요.
06 규칙 분기: 첫 규칙 매칭부터 영구 오버라이드까지
위에서 아래로 확인하고, 처음 일치하는 규칙에서 멈춥니다
규칙 목록은 모든 조건을 계산한 뒤 결과를 종합하는 방식이 아닙니다. 일반적으로 코어는 위에서 아래로 규칙을 확인하며, 처음 일치한 규칙이 정책을 결정하고 나머지 규칙은 해당 요청에 적용되지 않습니다. 더 구체적이거나 우선 적용해야 할 예외를 더 넓은 규칙보다 위에 두세요. MATCH는 기본 규칙이므로 보통 마지막에 둡니다. 앞에 배치하면 뒤의 규칙으로 요청을 처리할 수 없습니다.
DOMAIN은 도메인 전체 이름과 일치하고, DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. 각각 적용 범위가 다르므로 몇 글자를 줄이려고 서로 바꿔 쓰면 안 됩니다. 특히 키워드 규칙은 예상보다 넓은 범위에 적용될 수 있습니다. 특정 호스트만 처리하려면 전체 도메인 규칙이 확인과 관리에 더 유리합니다.
# 기존 설정에 PROXY라는 프록시 그룹이 있다고 가정합니다
rules:
- DOMAIN,docs.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,PROXY
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,PROXY이 순서에서는 docs.example.com을 전체 도메인 규칙에 따라 먼저 직접 연결하고, 나머지 접미사 일치 도메인은 프록시 그룹으로 보냅니다. 사설 주소 규칙은 지정한 주소 대역을 처리합니다. no-resolve는 이 주소 규칙 때문에 도메인 해석을 새로 요청하지 않는다는 뜻이며, 요청에 대상 IP가 이미 있으면 매칭할 수 있습니다. 전체 설정에서 DNS를 끈다는 뜻이 아니며 모든 주소 규칙에 이 옵션을 무조건 추가해야 하는 것도 아닙니다.
주소 규칙과 규칙 세트의 적용 범위
IP-CIDR은 IPv4 주소 대역에 사용하고, IPv6 대역에는 보통 IP-CIDR6을 사용합니다. GEOIP는 IP 주소 데이터베이스를 기준으로 판단하며 IP의 위치가 회사 소재지나 방문자의 지역과 반드시 일치하지는 않습니다. 데이터베이스도 바뀔 수 있습니다. 도메인 해석이 필요한지, 이미 확인된 주소를 사용하는지에 따라 결과가 달라질 수 있으므로 주소 규칙을 도메인 규칙보다 앞에 배치할 때는 DNS 동작과 매칭 로그를 특히 주의해서 확인하세요.
RULE-SET은 설정에 선언된 규칙 제공자를 참조하며, 규칙 종류별로 관리할 때 유용합니다. 규칙 목록에 원격 링크를 직접 넣어 사용하는 약칭은 아닙니다. 제공자 이름, 출처, 형식, 동작 유형이 서로 맞아야 합니다. 일반 도메인 목록과 클래식 규칙 목록은 작성 방식이 다릅니다. 잘못 섞으면 로드에 실패하거나 규칙이 적용되지 않을 수 있습니다. 처음에는 로컬 규칙 몇 개를 익힌 다음 외부 규칙 세트를 추가하세요.
다운로드 캐시뿐 아니라 실행 결과도 수정하기
규칙을 추가하기 전에 클라이언트가 앞쪽 규칙 삽입, 뒤쪽 규칙 삽입, 전체 오버라이드 중 어떤 방식을 제공하는지 확인하세요. 기존 MATCH 뒤에 사용자 지정 규칙을 추가하면 문법이 올바르더라도 적용되지 않을 수 있습니다. 저장 후에는 편집창의 내용만 보지 말고 최종 실행 규칙을 확인하세요. 프록시 그룹 이름에 공백, 문장 부호, 영문 외 문자가 포함돼 있으면 축약하지 말고 그대로 참조해야 합니다. 대상 이름이 설정에 없다면 참조 관계부터 바로잡으세요.
매번 확인하기 쉬운 규칙 하나만 추가하고 설정을 다시 불러온 뒤 새 연결을 만들어 상세 정보에서 새 규칙이 적용됐는지 확인하세요. 이전 연결이 남아 있다면 해당 연결을 종료하거나 요청을 보낸 앱을 다시 시작합니다. 그래도 일치하지 않으면 도메인과 IP 중 무엇이 표시되는지, 앞에 더 넓은 규칙이 있는지, 앱이 코어를 우회하는지, 오버라이드가 실제 실행 설정에 들어갔는지 확인하세요. 한 번에 전체 규칙을 추가해 원인을 파악하기 어려워지는 대신 이렇게 하나씩 문제를 좁힐 수 있습니다.
07 TUN 모드: 트래픽 처리 범위 확장과 DNS 연동
TUN이 필요한 경우
브라우저는 규칙에 따라 연결되지만 특정 앱이 시스템 프록시를 따르지 않는다면 먼저 해당 앱에서 HTTP 또는 SOCKS 프록시를 별도로 설정할 수 있는지 확인하세요. 적절한 설정 방법이 없고 더 많은 네트워크 요청을 처리해야 한다면 TUN을 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 코어로 전달합니다. 시스템 프록시 설정보다 시스템 계층에 미치는 영향이 크므로 기본 연결이 정상인 상태에서 활성화해야 합니다.
활성화하기 전에 시스템 프록시 상태, 현재 DNS, 다른 VPN 도구의 상태를 기록하고 종료 후 복구할 방법도 확인하세요. 기본 경로를 차지할 수 있는 다른 트래픽 처리 도구는 끄고, 클라이언트의 안내에 따라 서비스를 설치하거나 권한을 승인합니다. 여러 가상 네트워크 인터페이스를 동시에 활성화한 상태에서 어느 쪽에 문제가 생겼는지 판단하려 하지 마세요. 모바일 VPN 인터페이스와 데스크톱 TUN의 설정 메뉴는 다르므로 데스크톱 YAML을 휴대전화의 전체 설정에 그대로 적용하지 마세요.
인터페이스, 라우팅, DNS를 함께 이해하기
TUN이 트래픽을 받아들인다고 해서 DNS 경로까지 자동으로 올바른 것은 아닙니다. 앱은 시스템 DNS, 암호화된 DNS, 자체 해석기를 사용해 주소를 얻을 수 있고, 코어가 일부 DNS 요청을 처리할 수도 있습니다. 도메인 정보가 예상한 경로로 들어오지 않으면 시스템 프록시 모드와 도메인 규칙의 동작이 달라질 수 있습니다. ‘주소를 직접 입력하면 되지만 도메인으로는 안 되는’ 문제가 발생하면 모든 출구를 바꾸거나 규칙을 수정하기 전에 DNS부터 확인하세요.
# Mihomo 필드 예시. 입력이 필요한지는 클라이언트의 TUN 관리 방식에 따라 다릅니다
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53이 설정은 자동 라우팅, 출구 인터페이스 감지, DNS 처리 필드를 보여 주는 예시이며 단독으로 실행할 수 있는 완전한 설정은 아닙니다. GUI 클라이언트에서 해당 필드를 자동으로 만들 수 있으므로 가능하면 설정 화면에서 관리하고 중복 오버라이드를 피하세요. any:53은 모든 종류의 암호화 DNS를 자동으로 처리한다는 의미가 아닙니다. 앱이 HTTPS로 보내는 DNS 요청은 기존 53번 포트 질의와 같지 않습니다. 실제 동작은 DNS 설정과 라우팅 범위에도 좌우됩니다.
Fake-IP와 실제 주소 해석 이해하기
Fake-IP는 도메인에 내부 매핑 주소를 할당한 뒤 코어가 해당 주소와 도메인을 연결하는 방식입니다. 대상 서버가 실제로 그 주소로 옮겨지는 것은 아닙니다. 이 방식을 사용하면 시스템 도구에 표시되는 주소가 웹사이트의 실제 공인 IP와 다를 수 있으므로 한 번의 조회 결과만으로 잘못된 가로채기라고 판단하지 마세요. 실제 주소나 특수한 검색 방식을 이용하는 앱은 특정 도메인을 제외해야 할 수 있습니다. 제외 범위를 최대한 좁게 설정하고 DNS 기능 전체를 끄지 마세요.
DNS 동작 방식을 바꾼 뒤에도 시스템이나 앱의 캐시에 이전 결과가 남을 수 있습니다. 관련 연결을 종료하고 새로 조회한 뒤 로그를 확인하세요. 필요한 경우 운영체제 문서에 따라 DNS 캐시를 비웁니다. LAN 프린터, 공유 폴더, 기기 검색에 문제가 생기면 사설 네트워크 대역의 라우팅, LAN 도메인 해석, 제외 규칙을 확인하세요. LAN 문제를 모두 노드 오류로 볼 수는 없습니다. DNS 문제를 해결하려고 수신 범위를 전체에 개방해서도 안 됩니다.
검증할 때는 브라우저, 대상 앱, LAN 리소스를 각각 테스트하고 연결 화면에서 코어에 트래픽이 들어오는지 확인하세요. 앱 하나만 실패하면 해당 앱의 프로토콜과 프록시 지원을 점검합니다. 모든 앱이 실패하면 먼저 트래픽을 가져오는 경로를 확인하세요. 클라이언트를 종료한 뒤 시스템 네트워크가 정상으로 돌아오는지도 살펴봐야 합니다. 이런 비교를 마친 뒤에 자동 시작과 자동 트래픽 처리를 켜세요. 웹페이지 하나가 잠시 열렸다고 설정이 안정적이라고 판단해서는 안 됩니다.
08 일상적인 관리: 업데이트, 백업, 단계별 문제 해결
세 종류의 업데이트를 따로 관리하기
클라이언트, 코어, 구독 업데이트는 각각 다른 내용을 바꿉니다. 클라이언트 업데이트는 화면과 시스템 연동에 영향을 주고, 코어 업데이트는 프로토콜, 규칙, DNS 동작을 바꿀 수 있으며, 구독 업데이트는 주로 서비스 제공처가 전달하는 노드와 규칙에 영향을 줍니다. 세 가지를 한꺼번에 업데이트한 뒤 검증하면 변화의 원인을 찾기 어렵습니다. 필요에 따라 하나씩 진행하고, 작업 전후의 모드, 설정 이름, 주요 스위치를 기록하세요.
업데이트 전에 복원 가능한 설정을 저장하고 현재 사용 방식과 관련된 변경 사항을 확인하세요. 구독에 포함된 필드가 더 최신 코어를 요구할 수 있고, 오래된 클라이언트는 새 코어 기능을 제대로 관리하지 못할 수 있습니다. 호환성 오류가 발생하면 먼저 클라이언트와 코어의 조합을 확인한 다음 롤백을 고려하세요. 출처를 알 수 없는 파일을 여러 곳에서 받아 섞지 마세요. 백업을 복원할 때도 내부 데이터를 전부 덮어쓰지 말고 클라이언트가 인식하는 설정 형식인지 확인해야 합니다.
백업에 포함할 항목
쓸모 있는 백업에는 구독 출처, 영구 오버라이드, 사용자 지정 규칙, 프록시 그룹 선택, 포트, TUN, DNS의 주요 설정이 포함돼야 합니다. 구독 캐시는 임시 복구 자료일 뿐 구독 출처와 사용자 지정 내용을 대신할 수 없습니다. 화면 캡처는 설정을 기억하는 데는 편리하지만 긴 규칙을 복구하기에는 적합하지 않습니다. 설정을 텍스트로 내보내고 간단한 작업 설명을 덧붙이면 앱 디렉터리만 저장하는 것보다 이전하기 쉽습니다.
백업에는 서비스에 접근할 수 있는 인증 정보가 포함될 수 있으므로 접근 제어가 가능한 위치에 보관하고 기기 간 전송 시 공개 공유를 피하세요. 컴퓨터와 휴대전화에서 같은 구독 링크를 쓸 수 있더라도 포트, 인터페이스, 캐시 경로, TUN 매개변수까지 동일하게 사용할 수 있는 것은 아닙니다. 여러 기기를 동기화할 때는 먼저 ‘서비스와 규칙의 목적’을 맞춘 다음 시스템 계층 설정을 기기별로 구성하세요. 자세한 방법은 컴퓨터와 휴대전화에서 같은 구독을 사용하는 동기화 방법을 참고하세요.
| 확인된 증상 | 먼저 확인할 계층 | 다음에 확인할 근거 |
|---|---|---|
| 앱 요청이 연결 화면에 표시되지 않음 | 시스템 프록시, 앱 프록시 또는 TUN 진입 경로 | 새 요청이 코어에 들어왔는지 |
| 연결은 표시되지만 출구가 잘못됨 | 규칙 순서와 프록시 그룹 선택 | 매칭된 규칙과 최종 연결 경로 |
| 도메인 해석 실패 | DNS 출처, 접근성, 트래픽 처리 방식 | 해석 오류와 해당 도메인 |
| 프록시 핸드셰이크 실패 | 원격 연결, 인증, 프로토콜 호환성 | 오류 원문과 발생 시간 |
한 번에 하나의 변수만 바꿔 문제 해결하기
먼저 프록시를 거치지 않을 때 기본 네트워크를 사용할 수 있는지 확인하세요. 다음으로 코어가 실행 중인지, 포트가 수신 중인지 확인한 뒤 대상 요청에 적용된 규칙을 살피고 마지막으로 원격 연결을 점검합니다. 단계마다 확인 결과를 기록하세요. 전역 모드로 잠시 전환하는 것은 규칙의 영향을 비교하기 위한 것이지 모든 문제에 통용되는 해결책이 아닙니다. TUN을 잠시 끄는 것도 트래픽 처리 문제를 구분하기 위한 방법이지 TUN을 계속 꺼 둬야 한다는 의미는 아닙니다. 점검을 마치면 원래 설정을 복구하고 다시 확인하세요.
로그 수준은 현재 문제를 해결하는 데 필요한 정도로 설정하세요. 자세한 정보가 필요하면 잠시 로그 수준을 높여 한 번 재현한 뒤 관련 부분만 저장하고 평소 설정으로 되돌리세요. 접속 기록이 장기간 대량으로 쌓이지 않도록 합니다. 다른 사람에게 도움을 요청할 때는 운영체제, 클라이언트, 현재 모드, 트래픽 처리 방식, 전체 오류 현상을 설명하고 필요한 로그만 민감 정보를 가려서 제공하세요. 구독 전체를 업로드하거나 관련 없는 방문 기록까지 함께 보내지 마세요.
지연 시간 테스트는 참고 자료일 뿐 실제 사용 경험을 보장하지 않습니다. 테스트 주소, 핸드셰이크 과정, 대상 사이트, 필요한 대역폭에 따라 결과가 달라집니다. 테스트 결과는 정상인데 실제 앱이 느리다면 테스트 버튼만 반복해서 누르지 말고 앱의 대상 연결을 확인하세요. 테스트 결과의 의미는 url-test 지연 시간과 실제 사용 경험의 차이에서 확인할 수 있습니다. 단일 수치로 전체 출구 품질을 판단하지 마세요.
09 고급 설정: 프록시 그룹, 규칙 세트, 복구 가능한 설정
정책 구조를 정리한 뒤 자동화 추가하기
기본 연결이 안정된 뒤 고급 설정의 목표는 설정을 길게 만드는 것이 아니라 선택, 업데이트, 롤백을 명확하게 하는 것입니다. 일상적인 사용, 특정 서비스, 직접 연결 예외의 정책 범위를 먼저 정한 다음 자동 선택을 고려하세요. 이름이 명확하고 계층이 단순한 프록시 그룹은 서로 여러 번 참조하는 그룹보다 설명하기 쉽습니다. 그룹을 만들기 전에 어떤 문제를 해결할지, 문제가 생기면 어느 출구로 되돌릴지 기록하세요.
select 프록시 그룹은 사용자가 직접 선택하며 출구를 고정해야 하는 경우에 적합합니다. url-test는 지정한 주소의 테스트 결과로 후보를 선택하고, fallback은 후보 순서와 사용 가능 여부에 따라 전환합니다. 그룹마다 선택 방식이 다르므로 모두 ‘가장 빠른 항목을 자동으로 선택한다’고 이해하면 안 됩니다. 테스트 요청에도 네트워크 비용이 드니 필요한 주기로 설정하고 화면을 자주 바꾸려고 테스트를 반복하지 마세요.
# 설정 조각: proxies에 같은 이름의 노드가 먼저 있어야 합니다
proxy-groups:
- name: 일상 선택
type: select
proxies:
- 자동 선택
- DIRECT
- name: 자동 선택
type: url-test
proxies:
- 출구 A
- 출구 B
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50여기서 ‘출구 A’와 ‘출구 B’는 예시 참조 이름입니다. 사용하기 전에 실제 설정에 존재하는 노드 이름으로 바꿔야 합니다. 테스트 주소도 현재 환경에서 접속할 수 있고 지속적인 확인에 적합한 대상으로 선택하세요. interval은 확인 간격이고 tolerance는 작은 변동으로 자주 전환되는 일을 줄이는 데 쓰입니다. 이 매개변수가 속도를 보장하지는 않습니다. 세션을 안정적으로 유지해야 하는 앱에서는 출구 전환이 로그인과 장기 연결에 미치는 영향도 고려하세요.
규칙 세트를 독립적인 의존 항목으로 관리하기
규칙 제공자를 추가할 때 출처, 동작 유형, 업데이트 방식, 참조 위치를 기록하세요. 원격 규칙이 바뀌면 실제 트래픽 분기도 달라질 수 있으므로 ‘설정 파일이 바뀌지 않았다’고 해서 동작까지 항상 같은 것은 아닙니다. 중요한 사용자 지정 예외는 앞쪽 규칙으로 유지하고 규칙 세트가 계속 업데이트되는지도 정기적으로 확인하세요. 다운로드에 실패하면 제공자 상태를 먼저 살펴보세요. 프록시 그룹이 정상이라고 모든 외부 의존 항목이 로드됐다고 판단하지 마세요.
DNS 확장 기능과 스니핑 기능을 추가하기 전에는 해결할 문제가 분명한지 확인하세요. 스니핑은 일부 프로토콜 트래픽에서 도메인 등의 정보를 추출하는 기능이며, 프로토콜과 암호화 방식에 따라 한계가 있습니다. 모든 연결에서 도메인을 복원할 수 있는 것은 아닙니다. 현재 규칙이 제대로 작동한다면 기능 목록을 채우려고 모든 옵션을 켤 필요는 없습니다. 기능을 하나 추가할 때마다 어떤 요청을 처리하는지, 어떤 제약이 생기는지, 끈 뒤 어떻게 이전 동작으로 복구하는지 기록하세요.
재현 가능한 설정 변경 절차 만들기
변경은 네 단계로 진행하는 것이 좋습니다. 현재 작동하는 설정을 복사하고, 작은 변경 하나를 적용한 뒤, 문법과 실행 결과를 확인하고, 결론을 기록한 다음 변경을 유지하세요. Mihomo 코어를 별도로 사용하고 터미널에서 해당 프로그램을 찾을 수 있다면 아래 명령으로 설정을 검사할 수 있습니다. GUI 클라이언트 사용자는 먼저 클라이언트에 내장된 설정 검사 기능을 이용해도 됩니다. 문법 검사를 통과했다는 것은 설정을 불러올 수 있다는 뜻일 뿐, 규칙과 출구가 실제로 동작하는지는 연결로 확인해야 합니다.
mihomo -t -f config.yaml고급 설정은 도메인 하나에 직접 연결 예외 추가, 서비스 종류별 정책 생성, 규칙 세트 업데이트 확인, 복구 가능한 백업 설계 순서로 연습할 수 있습니다. 각 단계가 끝나면 실행 규칙과 연결 경로가 예상대로인지 확인하세요. 출구를 선택할 때는 지연 시간, 요금 배수, 지역, 프로토콜 비교 방법을 참고할 수 있지만, 한 번의 테스트로 장기적인 사용 경험을 판단하지 마세요.