Clash 사용법 가이드:
설치·규칙 분기·유지 관리

1. 핵심 개념: 클라이언트, 코어, 설정

인터페이스와 실행 계층 구분하기

Clash 생태계의 클라이언트는 일반적으로 그래픽 인터페이스와 프록시 코어로 구성됩니다. 인터페이스에서는 구독을 가져오고, 프록시 그룹을 확인하고, 설정을 변경하며 시스템 권한을 요청합니다. 코어는 로컬 포트를 열고 연결 정보를 분석해 규칙과 대조한 뒤 외부 연결을 만듭니다. 인터페이스가 실행된다고 코어가 정상 작동하는 것은 아니며, 코어가 실행 중이어도 시스템 트래픽이 프록시로 전달된다는 보장은 없습니다. 문제를 해결할 때 두 계층을 따로 확인하는 편이 반복해서 재설치하는 것보다 효과적입니다.

mihomo는 Clash 생태계에서 널리 쓰이는 코어입니다. 클라이언트마다 포함된 코어가 다를 수 있고, 수정 가능한 설정 항목에도 제한이 있을 수 있습니다. 동일한 설정을 여러 플랫폼에서 사용할 수 있는지는 파일 확장자가 아니라 프로토콜, 규칙 유형, 코어 기능과 플랫폼 지원 여부에 따라 달라집니다. 다른 기기로 옮길 때는 구독과 프록시 그룹 구성을 우선 재사용하고 포트, 파일 경로, 네트워크 인터페이스 이름처럼 기기에 따라 달라지는 항목을 확인하세요. 기존 로컬 설정을 전부 덮어쓰지는 마세요.

연결은 어떤 과정을 거칠까요?

전체 흐름은 네 단계로 볼 수 있습니다. 앱이 요청을 보내고, 트래픽이 로컬 프록시 입구로 들어오며, 코어가 모드와 규칙에 따라 출구를 선택한 뒤, 직접 연결하거나 원격 프록시를 거쳐 목적지에 접속합니다. 시스템 프록시와 TUN은 주로 두 번째 단계, 규칙과 프록시 그룹은 세 번째 단계, 노드 프로토콜은 네 번째 단계에 관여합니다. 웹페이지 오류는 어느 단계에서든 발생할 수 있으므로 노드 변경만으로 문제를 해결할 수는 없습니다. 트래픽이 들어오는 경로와 DNS 조회 과정도 함께 확인해야 합니다.

설정 파일은 이 과정들의 관계를 정의합니다. proxies는 개별 프록시를 정의하고, proxy-groups는 프록시를 선택하거나 자동으로 테스트할 수 있는 그룹으로 구성하며, rules는 순서에 따라 연결을 특정 정책으로 전달합니다. 구독에는 전체 설정이 포함될 수도 있고 노드 정보만 들어 있을 수도 있습니다. 노드 정보만 있다면 클라이언트에서 템플릿을 사용해 프록시 그룹과 규칙을 보완해야 합니다. 구독을 가져올 수 있다고 해서 규칙 분기 설정까지 완성된 것은 아닙니다.

노드는 원격 서비스에 연결하기 위한 정보이고, 프록시 그룹은 노드를 구성하는 방식입니다. 둘을 혼동하지 마세요. Proxy라는 프록시 그룹에서 특정 노드를 선택하거나 다른 프록시 그룹을 지정할 수 있습니다. 직접 연결 정책인 DIRECT는 원격 프록시를 거치지 않고 목적지에 연결한다는 뜻입니다. 그룹 이름은 보통 설정 작성자가 정하므로 정해진 한국어 이름은 없습니다. 아래 예시에서는 참조 관계를 설명하기 위해 Proxy를 사용하며, 실제로 수정할 때는 자신의 설정에 맞춰야 합니다.

로컬 포트와 DNS의 역할

로컬 수신 포트는 앱에서 코어로 들어가는 입구입니다. 혼합 포트는 하나의 포트에서 일반적인 HTTP 프록시와 SOCKS 프록시 연결을 모두 받을 수 있지만, 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다. DNS는 도메인 이름을 IP 주소로 변환하며 도메인 규칙을 제때 판별할 수 있는지에도 영향을 줍니다. 브라우저가 자체 암호화 DNS를 사용하고 시스템은 다른 DNS 서버를 사용한다면 동일한 목적지도 서로 다른 경로를 이용할 수 있습니다. 로그에 표시된 도메인과 실제 연결 주소를 함께 살펴보세요.

시작하기 전에 클라이언트와 네트워크 서비스를 구분해야 합니다. 클라이언트를 설치해도 사용할 수 있는 원격 프록시가 자동으로 생기지는 않습니다. 연결하려면 직접 보유하고 사용 권한이 있는 설정이 필요합니다. 구독 URL에는 접근 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관하세요. 스크린샷, 로그, 문의 내용에도 정보가 노출될 수 있습니다. 공유하기 전에 전체 URL, 계정 식별 정보와 노드 인증 정보를 삭제하고 문제 해결에 필요한 항목과 오류만 남기세요.

이 장의 목표는 용어를 전부 외우는 것이 아니라 다음 세 가지 질문에 답할 수 있게 되는 것입니다. 현재 어떤 클라이언트와 코어를 사용하는가? 설정은 어디에서 불러오는가? 앱은 어떤 입구를 통해 코어에 연결되는가? 이 내용을 기록해 두면 시스템 프록시가 적용되지 않거나 규칙이 일치하지 않거나 구독 업데이트가 실패했을 때 여러 설정을 한꺼번에 바꾸지 않고 올바른 점검 방법을 선택할 수 있습니다.

2. 클라이언트 선택: 플랫폼과 사용 목적부터 확인

꾸준히 관리되는 클라이언트를 일상용으로 선택하세요

클라이언트를 고를 때는 외관보다 기기의 운영체제와 프로세서 아키텍처, 사용 목적을 먼저 확인하세요. 처음 사용하는 경우 Clash Plus를 살펴보고 클라이언트 다운로드 페이지에서 운영체제에 맞는 설치 항목을 선택할 수 있습니다. 설정 편집, 연결 확인, 특정 코어 기능을 자주 사용한다면 다른 클라이언트와 비교해 보세요. 오래된 사용 설명서의 스크린샷만 보고 결정하지 마세요. 메뉴가 비슷해 보여도 현재 운영체제 지원 여부와 권한 절차는 다를 수 있습니다.

데스크톱에서는 트레이 상주, 시스템 프록시, 시작 프로그램 등록, 설정 오버라이드, TUN 등을 자주 사용합니다. 모바일에서는 시스템 VPN 권한, 백그라운드 실행, 절전 모드 이후 연결 복구가 중요합니다. 실제로 필요한 기능 두세 가지를 먼저 정한 다음 해당 클라이언트의 설명을 확인하세요. 사용하지 않을 고급 옵션은 선택 기준에서 제외해도 됩니다. 기능이 많다고 처음 설정하기 쉬운 것은 아니며 다른 네트워크 프로그램과의 호환성도 보장되지 않습니다.

아키텍처, 설정 호환성, 기존 클라이언트

프로세서 아키텍처와 운영체제 이름은 별개의 기준입니다. macOS의 Apple Silicon과 Intel 설치 파일은 파일명에 Mac이 포함됐다는 이유만으로 같은 것으로 볼 수 없습니다. Android의 ARM64와 ARM 패키지도 기기 사양에 맞춰 선택해야 합니다. Windows 기기에 ARM 프로세서가 탑재된 경우에는 앱에 명시된 지원 방식을 확인하세요. 모든 데스크톱 설치 파일이 네이티브로 지원된다고 볼 수는 없습니다. 다운로드 페이지에 없는 아키텍처의 설치 파일 주소를 임의로 추측하지 마세요.

Clash for Windows와 ClashX Meta는 유지 관리가 중단된 기존 클라이언트입니다. 예전 사용 설명서를 이해하거나 기존 환경을 이전할 때 참고할 수 있지만, 보관된 설치 파일을 계속 업데이트되는 기본 선택지로 삼는 것은 적절하지 않습니다. Clash for Windows 대체 프로그램을 찾을 때는 새 클라이언트에서 기존 설정을 읽을 수 있는지, 오버라이드 설정을 어떻게 보존하는지, 종료할 때 시스템 프록시를 복구하는지 확인하세요. 이전을 마친 뒤 기존 프로그램을 제거해 두 클라이언트가 같은 포트를 동시에 사용하지 않도록 하세요.

파일을 가져올 수 있다고 해서 그 안의 모든 기능이 클라이언트에서 작동하는 것은 아닙니다. 구독에 포함된 프로토콜, 규칙 제공자, 스크립트나 특정 코어 전용 항목이 대상 앱에서 지원되지 않을 수 있습니다. Surfboard 같은 앱도 명시적으로 지원하는 설정 형식을 사용해야 합니다. 가져오기 오류가 발생하면 항목 이름과 줄 번호부터 확인하세요. 호환되지 않는 설정을 반복해서 제출하지 마세요. 필요하다면 설정 제공자에게 해당 클라이언트용 형식을 요청하고, 인증 정보가 불분명한 변환 서비스에 맡기지 마세요.

이전을 위한 최소 정보 기록

클라이언트를 바꾸기 전에 현재 구독 이름, 모드, 프록시 그룹 선택과 수동 프록시에 의존하는 앱을 기록하세요. 직접 추가한 규칙이 구독 파일에 들어 있는지, 클라이언트의 오버라이드 기능으로 관리되는지도 구분해 저장합니다. 원격 구독 파일은 업데이트하면서 덮어쓸 수 있으므로 올바른 위치에 저장된 로컬 변경 사항만 쉽게 이전할 수 있습니다. 기록은 로컬에 보관하고 전체 구독 URL을 공개 메모나 스크린샷에 남기지 마세요.

iOS용 Clash Plus는 다운로드 페이지를 통해 App Store에서 설치할 수 있으며, 제품 공식 웹사이트는 clashplus.io입니다. 모바일 운영체제는 일반적으로 VPN 구성으로 트래픽을 처리하므로 데스크톱의 시스템 프록시 스위치와 일대일로 대응하지 않습니다. 여러 플랫폼을 다루는 설명서를 볼 때는 기능의 목적을 기준으로 이해하세요. 모바일에서 데스크톱 전용 혼합 포트 메뉴를 찾거나, 데스크톱에서 모바일의 백그라운드 권한 설정을 그대로 따라 할 필요는 없습니다.

이 단계에서는 주로 사용할 클라이언트 하나와 대체 방법 하나만 정하면 됩니다. 프록시 클라이언트를 여러 개 동시에 설치해 백그라운드에서 실행하지 않는 것이 좋습니다. 주 클라이언트로 다음 장의 설치와 구독 가져오기를 진행하고 네트워크를 정상적으로 복구할 수 있는지 확인한 다음 다른 인터페이스의 차이를 살펴보세요. 기기 지원 여부, 설정 호환성, 필수 기능, 로그 확인 및 종료 방법을 기준으로 선택 이유를 설명할 수 있어야 합니다. 이름이나 인터페이스 색상만으로 결정하지 마세요.

3. 설치 확인: 복구할 수 있는 실행 환경 만들기

설치 전에 충돌 요인부터 확인

설치 전에 다른 프록시 클라이언트와 게임 가속기, 시스템 네트워크를 변경할 수 있는 프로그램을 종료하세요. 수동 프록시, 회사 VPN, 특수 DNS가 사용 중인지도 기록해 둡니다. 창만 닫지 말고 백그라운드 프로세스까지 종료해야 합니다. 여러 프로그램이 동시에 라우팅과 프록시 설정을 변경하면 각 프로그램의 인터페이스에는 문제가 없어 보여도 실제 트래픽은 다른 입구로 전달될 수 있습니다. 기존 네트워크 설정을 스크린샷으로 남겨 두면 테스트 후 원래 환경으로 복구하기 쉽습니다.

다운로드 페이지에서 운영체제와 아키텍처에 맞는 패키지를 선택하고 클라이언트의 설치 안내를 확인하세요. 설치 버전, 포터블 버전, 압축 파일은 저장 위치가 서로 다를 수 있으며, 포터블로 실행해도 모든 데이터가 프로그램 폴더에 저장되는 것은 아닙니다. 처음 실행하기 전에 설정 디렉터리에 쓰기 권한이 있는지 확인하세요. 읽기 전용 경로나 제한이 엄격한 시스템 폴더는 피하는 것이 좋습니다. 서비스 설치가 필요하다면 네트워크 권한을 제공하는 기능이지 원격 프록시 인증 정보를 제공하는 기능은 아니라는 점을 알아 두세요.

플랫폼에 필요한 권한 설정

Windows에서 처음 실행할 때는 기본 창과 시스템 트레이 메뉴가 모두 열리는지 확인한 다음 코어 실행 여부를 살펴보세요. 방화벽 안내가 표시되면 실제 사용 범위에 맞춰 처리하고 편의를 위해 모든 네트워크 접근을 허용하지 마세요. 기기 안에서만 사용할 경우 LAN 수신을 활성화할 필요가 없습니다. TUN에 필요한 서비스나 관리자 권한은 기본 연결에 성공한 뒤 설정할 수 있습니다. 그러면 처음부터 문제가 생겼을 때 설치 오류와 고급 트래픽 처리 문제를 구분하기 쉽습니다.

macOS에서는 앱 안내에 따라 처음 실행하고 시스템 권한을 설정하세요. 네트워크 확장, 보조 서비스, 키체인 권한을 요청하면 설치 중인 앱에서 보낸 안내인지 먼저 확인하세요. 출처를 알 수 없는 요청을 무턱대고 승인하지 마세요. “손상됨” 메시지가 표시되거나 확장 기능을 활성화할 수 없다면 다운로드 출처, 운영체제 호환성과 시스템 설정의 차단 정보를 확인하세요. 운영체제 보안 기능 전체를 끄지는 마세요. 자세한 권한 설정 방법은 macOS 설치 및 권한 문제 해결을 참고하세요.

Android와 iOS는 처음 연결할 때 시스템 VPN 권한을 요청하는 경우가 많습니다. 기기에 다른 VPN이 설치되어 있다면 새 연결이 기존 VPN을 대체하거나 일시 중지하는지 확인하세요. Android에서 화면을 오래 잠근 뒤 연결이 끊기면 배터리 최적화와 백그라운드 실행 제한을 살펴보세요. 처음부터 모든 권한을 허용할 필요는 없습니다. Linux에서는 패키지 형식이 배포판에 맞는지 확인하고 클라이언트 안내에 따라 데스크톱 의존성과 서비스를 설치하세요. 그래픽 인터페이스가 열린다고 권한 서비스까지 정상 작동하는 것은 아닙니다.

자동 시작 전에 로컬 입구 확인

설정에서 실제 수신 주소와 포트를 찾아 기록하세요. 사용 설명서에 나오는 포트는 예시일 뿐이며 다른 프로세스에서 이미 사용 중이거나 클라이언트가 변경했을 수 있습니다. 포트 충돌이 발생하면 코어 실행에 실패하거나 로그에 주소가 이미 사용 중이라는 메시지가 표시됩니다. 이때는 먼저 기존 클라이언트를 종료하고 충돌 원인을 확인하세요. 포트를 무작정 여러 번 바꾸지 마세요. 브라우저, 터미널 또는 시스템 프록시가 계속 이전 포트를 참조할 수 있습니다.

# Windows PowerShell: 예시 포트의 수신 상태 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux: 예시 포트를 수신하는 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

위 명령은 진단용이며 프록시를 자동으로 시작하지 않습니다. 아무 결과도 나오지 않는 것은 아직 포트가 열리지 않았기 때문일 수 있습니다. 명령어가 없다고 표시되면 관련 도구가 설치되지 않은 것일 수 있습니다. 프로세스가 발견되면 먼저 어떤 프로그램인지 확인한 후 종료 여부를 결정하세요. 정체를 알 수 없는 시스템 서비스를 바로 종료하지 마세요. 수신 주소가 로컬 루프백 주소라면 다른 기기에서 연결할 수 없는 것이 정상적인 기본 보안 경계입니다. “네트워크 문제 해결”을 위해 외부에 포트를 함부로 개방하지 마세요.

마지막으로 복구 테스트를 진행하세요. 복잡한 설정을 가져오기 전에 클라이언트가 정상적으로 종료되는지 확인하고, 종료 후 기존 직접 연결이 되는지 살펴봅니다. 다시 실행해 코어 로그와 수신 포트가 일치하는지도 확인하세요. 간단해 보이지만 시스템 프록시 설정이 남아 있거나 권한 서비스에 문제가 있거나 포트가 충돌하는 상황을 미리 찾을 수 있습니다. 이 기본 환경을 유지한 채 다음 장에서는 구독만 추가하세요. DNS, TUN, LAN 공유를 동시에 변경하지 마세요.

4. 구독 가져오기: 다운로드·파싱·활성화 구분

가져오기 방법을 선택하고 콘텐츠 유형 확인

구독은 클라이언트가 설정을 주기적으로 가져오는 방법입니다. 보통 “설정”, “구독” 또는 “Profiles” 메뉴에서 이용할 수 있습니다. 제공업체에서 전체 URL을 복사한 다음 URL 가져오기를 선택하고 알아보기 쉬운 이름을 지정해 다운로드하세요. URL의 쿼리 매개변수는 인증에 쓰일 수 있습니다. 복사 과정에서 끝부분이 빠지거나 공백과 줄바꿈이 포함되면 요청이 실패할 수 있습니다. 구독 URL을 검색엔진이나 공개 온라인 검사 페이지에 입력하지 마세요.

완성된 YAML 설정 파일이 있다면 로컬 파일 가져오기를 사용할 수 있습니다. 받은 자료가 설정 내용인지, 웹 로그인 페이지나 안내문 또는 압축 파일이 아닌지 먼저 확인하세요. 구독 요청이 성공해도 실제 응답은 계정 로그인 페이지일 수 있습니다. 다운로드 성공 여부와 설정 파싱 성공 여부는 별도로 확인해야 합니다. 형식 오류가 표시되면 파일 첫 부분과 오류 줄 주변의 구조를 살펴보세요. 내용을 공유하기 전에는 반드시 인증 정보를 삭제해야 합니다. 문제 해결을 위해 전체 설정을 노출해서는 안 됩니다.

YAML은 들여쓰기로 계층을 나타내며 일반적으로 탭 대신 공백을 사용합니다. 콜론 뒤에는 올바른 구분 기호가 필요하고 목록 항목은 같은 수준의 들여쓰기를 유지해야 합니다. 편집할 때 기존 인코딩과 구조를 보존하고 한글 문장 부호를 문법 기호로 사용하지 마세요. 특수 문자가 포함된 문자열은 YAML 규칙에 따라 따옴표로 감쌀 수 있지만 모든 항목을 일괄적으로 따옴표로 묶지는 마세요. 오류가 표시된 줄은 파서가 문제를 발견한 위치일 뿐입니다. 실제로 들여쓰기나 따옴표가 빠진 곳은 바로 윗줄일 수 있습니다.

가져온 다음 활성 설정 선택

설정이 목록에 표시되는 것은 클라이언트에 저장되었다는 뜻일 뿐입니다. “활성화”, “사용” 또는 해당 설정의 활성 표시를 선택하고 코어가 다시 불러올 때까지 기다린 다음 프록시 페이지에서 그룹을 확인하세요. 이전 그룹 이름이 계속 보인다면 다운로드만 완료하고 설정을 전환하지 않았을 가능성이 큽니다. 설정을 바로 삭제하고 다시 만들기보다는 활성 설정 이름, 업데이트 시간, 로딩 오류를 확인하세요. 설정이 여러 개라면 이름에 용도를 적어 실수로 다른 항목을 선택하지 않도록 하세요.

완성된 설정에는 대개 노드와 프록시 그룹이 포함됩니다. 먼저 주요 그룹을 펼쳐 선택 가능한 출구가 있는지 확인한 다음 사용 권한이 있는 노드를 선택해 테스트하세요. 노드 이름이 표시된다고 서비스가 정상이라는 뜻은 아닙니다. 인증 정보 만료, 원격 서버 연결 불가, 프로토콜 비호환 문제는 연결을 시도할 때 나타날 수 있습니다. 지연 시간 테스트 실패가 모든 네트워크 오류를 의미하지도 않습니다. 테스트 주소와 방식이 실제 서비스 접속과 다를 수 있습니다.

구독 업데이트와 클라이언트 업데이트는 서로 다른 작업입니다. 전자는 노드, 규칙 또는 프록시 그룹 구성을 변경하고 후자는 프로그램과 코어 기능을 변경합니다. 원격 업데이트가 직접 편집한 파일을 덮어쓸 수 있으므로 지속적으로 사용할 규칙은 클라이언트의 오버라이드, 병합 또는 로컬 확장 기능에 저장하세요. 병합 순서를 먼저 확인한 뒤 소규모로 테스트하세요. 어떤 기능은 배열 전체를 교체하고 어떤 기능은 앞이나 뒤에 항목을 추가합니다. 이름이 비슷해도 동작 방식은 다를 수 있습니다.

업데이트 오류 유형 구분하기

업데이트가 실패하면 요청이 완료되지 않았는지, 서버가 접근을 거부했는지, 응답 내용을 파싱할 수 없는지부터 구분하세요. 요청 시간이 초과되면 현재 네트워크와 DNS 조회를 확인하고 업데이트에 프록시가 필요한지 살펴봅니다. 접근이 거부되면 URL이 완전한지, 계정 상태에 문제가 없는지, 제공업체 안내가 있는지 확인하세요. 파싱에 실패하면 응답 내용과 코어 지원 범위를 확인합니다. 모든 오류를 노드 문제로만 돌리지 마세요. 구독 다운로드는 다른 네트워크 경로를 사용할 수 있습니다.

처음 구독을 가져올 때 프록시를 통해야만 다운로드할 수 있다면 제공업체가 허용하는 로컬 설정 가져오기 방법으로 기본 연결을 먼저 만든 다음 업데이트 경로를 테스트하세요. 일회성 다운로드 문제를 해결하려고 데이터 처리 방식이 불분명한 변환 사이트에 구독을 맡기지 마세요. 구독 제공자와 규칙 제공자가 외부 파일을 별도로 다운로드할 수도 있습니다. 기본 설정이 성공적으로 로드된 뒤에도 해당 리소스가 준비되었는지 확인하세요. 처음 시작하거나 오프라인 상태에서 복구할 때 특히 중요합니다.

이 장을 마치면 설정 목록에서 현재 활성 항목을 찾고, 프록시 페이지에서 주요 그룹을 확인하며, 업데이트 오류가 다운로드와 파싱 중 어느 단계에서 발생했는지 설명할 수 있어야 합니다. 마지막으로 정상 작동한 설정을 로컬에 저장하고 사용자 지정 변경 위치도 기록하세요. 다음 장에서는 기존 그룹으로 모드를 검증하고 규칙을 바로 확장하지 않습니다. 그래야 접속 결과가 바뀌었을 때 모드 전환 때문인지 구독 내용 업데이트 때문인지 구분할 수 있습니다.

5. 프록시 모드: 트래픽 입구와 출구를 따로 확인

규칙·글로벌·직접 연결 모드의 역할

프록시 모드는 코어로 들어온 연결이 어떤 출구를 사용할지 결정합니다. 규칙 모드는 설정의 규칙을 순서대로 확인하므로 일상적으로 목적지별 트래픽을 나누는 데 적합합니다. 글로벌 모드는 코어가 받은 연결을 글로벌 정책에 따라 처리하고 직접 연결 모드는 목적지에 바로 접속합니다. 세 모드 모두 트래픽이 코어에 들어온 상태여야 작동합니다. 시스템 프록시, 수동 프록시 또는 TUN에서 처리하지 않는 앱은 글로벌 모드로 바꿔도 자동으로 경로가 변경되지 않습니다.

처음에는 규칙 모드를 선택하고 주요 프록시 그룹에서 사용할 수 있는 노드를 선택했는지 확인하세요. 그런 다음 프록시를 이용해야 하는 목적지 하나와 정상적으로 직접 연결되어야 하는 목적지 하나를 열어 테스트합니다. 웹사이트 하나만 확인하고 전체 네트워크가 정상이라고 잘못 판단하지 않기 위해서입니다. 문제가 있다면 잠시 글로벌 모드로 전환해 비교하세요. 글로벌 모드는 되지만 규칙 모드에서 실패한다면 클라이언트를 재설치하기보다 규칙 일치 여부와 프록시 그룹 참조를 먼저 확인하세요.

글로벌 모드라고 해서 모든 기기의 트래픽이 프록시를 통과하거나 DNS 요청이 같은 출구를 사용하는 것은 아닙니다. 코어가 이미 받은 연결에 적용할 정책만 바꿉니다. 일부 클라이언트에서는 글로벌 선택이 평소 사용하는 Proxy 그룹과 별개이므로 모드를 전환한 뒤 글로벌 정책이 어느 출구를 가리키는지 확인해야 합니다. 테스트를 마치면 원래 모드로 되돌리고 실제 네트워크 사용에 맞는지 다시 점검하세요. 임시 테스트 설정을 잊은 채 계속 사용하는 일을 방지할 수 있습니다.

시스템 프록시는 모드가 아니라 트래픽 입구

시스템 프록시 스위치는 운영체제가 앱에 제공하는 프록시 정보를 변경합니다. 브라우저는 보통 이 설정을 따르지만 게임, 일부 업데이트 프로그램, 터미널 도구와 자체 네트워크 기능을 사용하는 앱은 따르지 않을 수 있습니다. 특정 프로그램이 직접 연결된다고 해서 규칙이 잘못된 것은 아닙니다. 로컬 프록시 포트에 아예 연결하지 않았을 수 있습니다. 연결 목록에서 해당 프로세스와 목적지를 먼저 찾아보세요. 기록이 없다면 입구를 확인해야 합니다. 해당 연결에 영향을 줄 수 없는 규칙을 계속 변경하지 마세요.

로컬 HTTP 프록시를 따로 테스트할 때는 아래 명령을 사용할 수 있습니다. 포트는 예시이므로 클라이언트에서 실제로 수신 중인 혼합 포트나 HTTP 프록시 포트로 바꾸세요. 명령에서 입구를 직접 지정하므로 터미널이 시스템 프록시를 읽는지 여부에 영향을 받지 않습니다. 테스트 성공은 해당 요청이 이 입구를 통해 처리되었다는 뜻일 뿐입니다. 브라우저와 다른 프로토콜, 모든 목적지가 동일한 경로를 사용한다는 증거는 아닙니다.

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

연결 기록으로 판단 확인

요청을 관찰할 때는 출발 앱, 대상 도메인 또는 주소, 일치한 규칙, 프록시 그룹, 최종 노드를 차례로 기록하세요. 요청이 DIRECT로 연결되었다면 설정에 맞는지 먼저 확인하고, 규칙과 정책이 올바른데도 실패한다면 노드 연결과 DNS를 점검합니다. 연결 목록에서 짧은 연결은 합쳐지거나 빠르게 사라질 수 있으므로 로그를 먼저 열고 다시 시도하세요. 트레이 아이콘 색상이나 전체 설정 스위치만으로 실제 출구를 판단하지 마세요. 표시 상태는 서비스가 실행 중이라는 뜻에 그칠 수 있습니다.

모드를 전환해도 이미 연결된 장시간 연결이 즉시 다른 경로로 이동하지는 않을 수 있습니다. 브라우저의 연결 재사용, 채팅 앱의 상시 연결, 동영상 스트리밍은 기존 경로를 계속 사용할 수 있습니다. 비교 테스트에서는 새 요청을 만들고 필요하다면 해당 앱을 종료한 뒤 다시 실행하세요. 클라이언트에 연결 종료 기능이 있더라도 현재 전송 중인 작업이 중단될 수 있습니다. 모드를 빠르게 반복 전환하면서 기존 연결 하나만 관찰하면 서로 모순된 결과가 나올 수 있습니다.

이 장에서 권장하는 점검 순서는 다음과 같습니다. 코어가 포트를 수신하는지, 앱 트래픽이 코어에 들어오는지, 모드가 무엇인지, 어떤 출구를 사용하는지 확인하세요. 직접 연결 모드는 프로그램 종료를 대신하지 않으며 시스템 프록시 입구가 계속 남아 있을 수 있습니다. 테스트가 끝나면 클라이언트의 절차에 따라 트래픽 처리를 중지하고 시스템 설정이 복구되었는지 확인하세요. “연결됨”으로 표시되는데 웹페이지가 열리지 않는다면 구독·포트·시스템 프록시 문제 해결 체크리스트를 참고하세요.

6. 규칙 분기: 순서·프록시 그룹·로컬 오버라이드

설명할 수 있는 규칙부터 시작

규칙은 일반적으로 위에서 아래로 확인되며 일치하면 해당 정책으로 전달됩니다. 따라서 규칙의 순서와 내용은 모두 중요합니다. 구체적인 예외는 포괄적인 규칙보다 앞에 두고 기본 처리 규칙은 맨 끝에 배치하세요. 규칙을 추가해도 위치를 확인하지 않으면 적용되지 않을 수 있습니다. MATCH를 앞에 두면 뒤에 있는 규칙은 예상한 분기 처리를 할 수 없습니다. 처음부터 큰 규칙 모음을 가져오기보다 몇 가지 규칙의 적용 범위를 이해해 두면 문제가 생겼을 때 원인을 파악하기 쉽습니다.

DOMAIN은 지정된 도메인과 일치하고 DOMAIN-SUFFIX는 해당 도메인과 하위 도메인을 모두 포함합니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드로 판단합니다. 키워드 규칙은 적용 범위가 넓어 관련 없는 서비스까지 같은 정책에 포함할 수 있습니다. IP-CIDR은 IP 주소 대역을 대상으로 하며 GEOIP는 지리 데이터베이스에 의존합니다. 판별 결과가 서비스의 실제 운영 지역과 반드시 일치하지는 않습니다. 도메인 규칙과 IP 규칙은 서로 다른 정보를 사용하므로 실제 연결 기록을 기준으로 선택하세요.

# 기존 설정에 병합하세요. Proxy는 이미 존재하는 프록시 그룹이어야 합니다.
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-SUFFIX,google.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

이 예시는 규칙 블록만 보여 주며 원격 노드는 포함하지 않으므로 단독으로 프록시를 연결할 수 없습니다. no-resolve는 도메인 연결과 일치시키기 위해 이 주소 규칙이 별도로 DNS 조회를 시작하지 않는다는 뜻입니다. 전체 DNS를 비활성화하는 설정은 아닙니다. LAN 직접 연결은 실제 네트워크 대역과 TUN 경로를 함께 확인해야 합니다. 사설 대역 하나를 추가해도 모든 내부 네트워크가 포함되는 것은 아닙니다. 기업 환경에서는 별도 주소 대역을 사용할 수 있으므로 실제 네트워크 설계를 기준으로 확인하세요.

규칙과 노드를 분리하는 프록시 그룹

규칙이 프록시 그룹을 가리키도록 하면 규칙을 수정하지 않고도 노드를 전환할 수 있습니다. 선택형 그룹에서는 사용자가 출구를 정하고, 자동 테스트 그룹은 설정된 테스트 결과에 따라 노드를 선택하며, 장애 조치 그룹은 순서대로 사용할 수 있는 항목을 찾습니다. 각 그룹은 서로 다른 문제를 해결합니다. 지연 시간이 짧다고 다운로드 속도가 빠른 것은 아니며, 테스트 대상에 연결된다고 실제 서비스 도메인에도 접속할 수 있는 것은 아닙니다. 용도에 맞는 그룹 유형을 선택하고 모든 그룹을 같은 유형으로 바꾸지 마세요.

그룹 이름을 바꾸면 규칙, 다른 프록시 그룹, 오버라이드에서 참조하는 이름도 함께 확인해야 합니다. 이름이 맞지 않으면 로딩에 실패하거나 예상했던 참조가 작동하지 않을 수 있습니다. 정상 작동하는 설정을 복사해 둔 뒤 하나의 그룹에서 구성원과 선택 방식을 먼저 테스트하고 수정 범위를 넓히세요. 그룹 사이에 순환 참조가 생기지 않도록 주의하세요. 클라이언트에 순환 의존성 오류가 표시되면 참조 경로를 하나씩 따라가며 확인하고, 오류 메시지에 언급된 임의의 노드를 삭제해 문제를 피하지 마세요.

업데이트에 안전한 사용자 지정 방식

장기적으로 유지할 사용자 지정 설정은 클라이언트가 지원하는 오버라이드 또는 병합 기능을 우선 사용하세요. 새 규칙이 구독 규칙 앞에 들어가는지 뒤에 들어가는지 확인한 다음 쉽게 검증할 수 있는 규칙 하나를 추가합니다. 병합 기능이 rules 배열 전체를 교체하면 기존 규칙 분기가 모두 사라질 수 있습니다. 끝에만 추가한다면 MATCH 뒤에 새 규칙이 놓일 수도 있습니다. 편집기에 넣은 일부 내용만 보지 말고 저장 전에 실제 병합 결과를 확인하는 편이 안전합니다.

규칙 제공자를 사용하면 대량의 규칙을 별도 리소스로 관리하고 RULE-SET으로 참조할 수 있습니다. 사용 전에는 제공자 형식, 동작 유형, 업데이트 방식을 확인해야 합니다. 도메인 목록과 전체 규칙 목록은 임의로 서로 바꿔 쓸 수 없습니다. 리소스 다운로드에 실패해도 기본 설정은 로드될 수 있지만 트래픽 분기 결과가 달라질 수 있습니다. 개별 규칙이 정확한지 확인하기 전에 로그에서 리소스 상태와 캐시를 확인해 제공자가 아직 준비되지 않은 문제가 아닌지 살펴보세요.

문제 해결 시에는 특정 목적지 하나를 정한 뒤 도메인이 표시되는지 확인하고 일치한 규칙과 최종 정책을 살펴보세요. IP 주소만 표시된다면 앱이 주소로 직접 연결하는지, DNS 캐시 또는 트래픽 처리 방식이 영향을 주는지 확인해야 합니다. 규칙은 정상인데 서비스에 문제가 있다면 다른 도메인, 콘텐츠 전송 주소 또는 로그인 인터페이스가 추가로 필요할 수 있습니다. 앱 하나를 해결하려고 모든 트래픽을 글로벌 모드로 바꾸지 마세요. 먼저 예외 범위를 좁히고 변경 이유를 기록하세요.

이 장을 마치면 특정 요청이 현재 규칙과 일치한 이유와 프록시 그룹 전환이 어떤 대상에 영향을 주는지 설명할 수 있어야 합니다. 규칙을 수정하기 전후의 차이를 저장하고 다시 불러온 뒤 새 연결로 확인하세요. 예상과 다르게 작동하면 다음 계층을 점검하기 전에 이 변경 하나를 되돌리세요. 작은 단위로 변경하면 구독 업데이트, DNS 변경, 규칙 테스트가 하나의 문제로 뒤섞이지 않습니다.

7. TUN 모드: 처리 범위·권한·DNS

TUN이 필요한 경우

TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 코어로 전달합니다. 시스템 프록시를 따르지 않는 앱을 처리할 때 유용하며 더 많은 네트워크 트래픽을 통합해 처리하는 데도 사용됩니다. 시스템 프록시와의 핵심 차이는 처리 위치에 있으며 “더 빠르다”거나 “더 고급이다”라는 뜻이 아닙니다. 실제 처리 범위는 라우팅 제외, 앱 우회 설정, 프로토콜 지원, 플랫폼 제한에 따라 달라집니다. TUN을 켠다고 모든 패킷이 같은 원격 출구를 사용한다는 뜻은 아닙니다.

시작하기 전에 구독이 정상인지, 규칙이 적절한지, 일반적인 프록시 입구가 작동하는지 확인해야 합니다. 현재 설정을 저장하고 다른 VPN을 종료한 다음 원격 근무 환경, 가상 머신, 컨테이너 네트워크에서 특수 경로를 사용하는지 점검하세요. 원격 연결로 기기를 관리 중이라면 기본 경로를 함부로 바꾸지 마세요. 관리 연결이 끊길 수 있으므로 로컬 제어 방법이나 복구 수단을 미리 준비해야 합니다. TUN 문제 해결은 기본 프록시가 정상 작동하는 상태에서 진행해야 하며 사용할 수 없는 구독을 대신할 수는 없습니다.

하나씩 활성화하고 변경을 겹치지 않기

클라이언트 안내에 따라 권한 서비스를 설치하거나 시스템 권한을 허용한 뒤 가상 인터페이스, 라우팅, 코어 로그를 확인하세요. 일부 클라이언트는 시스템 프록시를 자동으로 함께 설정하고, 다른 클라이언트는 두 방식을 동시에 사용할 수 있습니다. 실제 동작은 클라이언트 설명을 따르세요. 효과를 비교하려면 한 가지 트래픽 처리 경로만 사용해 테스트하고 대상 앱의 연결 기록이 나타나는지 확인한 다음 다른 입구를 함께 사용할지 결정하세요. 네트워크 관련 옵션을 무작정 모두 켜지 마세요.

# mihomo 설정 조각입니다. 기존 설정 및 클라이언트 관리 방식과 조정해야 합니다.
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

예시의 자동 라우팅은 트래픽 처리 경로를 추가하고, 인터페이스 자동 감지는 출구 네트워크 인터페이스를 찾으며, DNS 하이재킹 항목은 지정된 DNS 트래픽을 받습니다. 실제 지원되는 항목과 동작은 코어와 운영체제에 따라 다릅니다. 클라이언트에 TUN 설정 화면이 있다면 해당 화면을 우선 사용해 관리하세요. 인터페이스 설정과 파일 설정이 서로 덮어쓰는 일을 방지할 수 있습니다. 이 조각만 복사해도 완전한 DNS 서비스를 구성할 수는 없으며 모든 플랫폼이 같은 네트워크 스택을 사용하는 것도 아닙니다.

DNS가 도메인의 규칙 분기에 미치는 영향

DNS는 TUN 환경에서 중요한 요소입니다. Fake-IP 모드는 도메인을 가상 주소에 연결해 이후 연결에서 코어가 원래 도메인을 식별하도록 합니다. 일반적인 실제 IP 조회는 목적지 주소를 그대로 반환합니다. 두 방식의 호환 범위는 서로 다르므로 웹페이지가 한 번 빨리 열렸다는 이유만으로 우열을 판단할 수 없습니다. 실제 주소를 사용하는 기기 검색, 내부 서비스, 일부 앱에는 예외가 필요할 수 있습니다. 설정을 바꾸기 전에 문제가 DNS 모드 때문인지, 규칙이나 라우팅 때문인지 확인하세요.

fake-ip-filter에는 가상 주소 대신 실제 IP를 반환할 도메인을 지정합니다. 하지만 일반적인 프록시 우회 목록은 아닙니다. 실제 주소를 반환한 뒤에도 연결은 계속 규칙 판단을 받습니다. 필터 목록에 도메인을 추가한다고 자동으로 직접 연결되는 것은 아닙니다. 서비스에 직접 연결해야 한다면 규칙과 라우팅도 확인하세요. 주소 매핑 과정을 자세히 알아보려면 Fake-IP 모드와 가상 주소 풀을 읽고 필요한 범위에 한해 예외를 설정하세요.

DNS 하이재킹을 사용해도 모든 DNS 조회 방식을 가로채는 것은 아닙니다. 앱 내 암호화 DNS는 일반 HTTPS나 다른 연결을 통해 요청을 보낼 수 있으므로 53번 포트만 처리하는지 확인해서 앱의 DNS 요청도 코어에 들어왔다고 판단할 수는 없습니다. 도메인 규칙이 예상과 다르게 작동하면 브라우저의 보안 DNS, 앱 내 DNS 조회, 시스템 캐시를 확인하세요. 시스템 DNS, 코어 DNS, 브라우저 설정을 동시에 바꾸지 마세요. 한 번에 하나씩 변경하고 연결을 새로 만들어 테스트해야 합니다.

네트워크 전환 상황도 테스트해야 합니다. 유선에서 무선으로 바꾸거나 Wi-Fi에서 모바일 네트워크로 전환하거나 절전 모드에서 깨어날 때 출구 인터페이스가 달라질 수 있습니다. 일반 프록시는 작동하지만 TUN이 실패한다면 기본 인터페이스, 남은 라우팅 설정, 권한 서비스, DNS 처리를 확인한 뒤 클라이언트를 재시작할지 결정하세요. 자세한 비교는 TUN과 시스템 프록시의 트래픽 처리 범위 비교를 참고하세요. 이 장의 목표는 트래픽을 정상적으로 처리하면서 내부 네트워크를 사용할 수 있고 TUN을 끈 뒤 원래 네트워크로 복구되는 것입니다.

8. 유지 관리: 업데이트·속도 테스트·오류 기록

설정 업데이트와 프로그램 업데이트 구분하기

안정적으로 사용하기 시작하면 변경 항목을 통제하는 것이 중요합니다. 구독 업데이트, 클라이언트 업데이트, 코어 전환, 운영체제 업데이트를 한 번에 진행하지 마세요. 현재 활성 설정, 모드, 프록시 그룹 선택을 기록하고 한 가지 업데이트를 마칠 때마다 다시 테스트한 뒤 다음 작업을 진행하세요. 이렇게 하면 문제가 생겼을 때 어떤 변경이 원인인지 파악하기 쉽습니다. “어제는 됐는데 오늘은 안 된다”는 기록만으로는 원격 서비스와 로컬 환경 중 어디가 바뀌었는지 구분하기 어렵습니다.

구독을 업데이트하기 전에 로컬 사용자 지정 규칙이 덮어쓰기 되지 않는 위치에 저장되어 있는지 확인하고 정상 설정을 하나 보관하세요. 업데이트 후 프록시 그룹 이름과 구성원, 주요 규칙이 바뀌었는지 살펴보세요. 선택해 둔 노드가 이미 삭제되었을 수 있습니다. 클라이언트를 업데이트할 때는 기능 및 호환성 안내를 읽고 설정 경로, 권한 서비스, 코어 매개변수가 달라지는지 확인하세요. 이전 프로세스와 새 프로그램을 동시에 실행하면 인터페이스와 실제 수신 프로세스가 서로 다른 설치본에 속할 수 있습니다.

속도 테스트로 알 수 있는 범위

Clash 노드 속도 테스트는 보통 지정된 테스트 주소에 요청을 보내 응답 상태를 확인합니다. 지속적인 다운로드 속도나 모든 웹사이트의 사용 경험을 나타내지는 않습니다. 테스트 실패 원인은 테스트 대상 자체, DNS 조회 경로, 요청 시간 초과 설정일 수 있습니다. 노드를 비교할 때는 같은 조건에서 비슷한 시간대에 동일한 대상을 테스트하고 실제 서비스에서도 확인하세요. 테스트를 지나치게 자주 새로 고치면 요청만 늘고 일시적인 변동을 지속적인 품질 차이로 오해할 수 있습니다.

자동 테스트 프록시 그룹도 테스트 대상과 간격의 영향을 받습니다. 간격이 너무 짧으면 선택이 자주 바뀔 수 있으며 이미 연결된 장시간 연결은 매번 즉시 이동하지 않습니다. 특정 서비스에서 안정적인 출구가 필요하면 작동하는 노드를 수동으로 고정하는 편이 좋을 수 있습니다. 접속 가능성을 우선한다면 적절한 장애 조치 설정을 사용하세요. 지연 시간 숫자 하나만 보고 영상, 회의, 대용량 파일 전송에 적합한 노드라고 판단하지 마세요. 사용 사례마다 중요한 지표가 다릅니다.

연결 흐름에 따라 문제 해결 기록 남기기

문제가 발생하면 먼저 프록시를 사용하지 않는 기본 네트워크가 정상인지 확인한 뒤 구독 유효성, 코어 수신 상태, 시스템 입구, 규칙 일치, DNS를 차례로 확인하세요. 안정적으로 재현할 수 있는 목적지 하나와 구체적인 발생 시간을 기록하고 여러 앱을 동시에 테스트해 결과를 뒤섞지 마세요. 먼저 일반 로그 수준을 사용하고 추가 확인이 필요할 때만 잠시 상세 로그를 활성화하세요. 문제 해결이 끝나면 상세 로그를 끄세요. 로그가 계속 쌓이거나 불필요한 접속 기록이 남는 것을 방지할 수 있습니다.

연결 거부와 연결 시간 초과는 의미가 다릅니다. 연결 거부는 로컬 포트가 수신 중이지 않거나 원격 서비스가 거부했거나 방화벽에서 차단했을 수 있습니다. 시간 초과는 패킷 손실, 라우팅 문제, 목적지 연결 불가, DNS 응답 대기와 관련될 수 있습니다. 오류 문구는 단서일 뿐 최종 원인은 아닙니다. 발생한 위치와 함께 판단하세요. 로컬 입구에서 거부되었다면 원격 노드를 바꿔도 해결되지 않습니다. 규칙이 일치한 뒤 원격 연결이 실패했다면 시스템 프록시를 반복해서 켜고 꺼도 인증 문제는 해결되지 않습니다.

문제 해결을 위해 자료를 정리할 때는 클라이언트와 운영체제 이름, 사용 모드, 재현 절차, 목적지 유형, 개인정보를 가린 오류를 남기세요. 구독 URL, 노드 주소에 포함된 계정 매개변수와 비밀번호, 개인을 식별할 수 있는 정보는 삭제해야 합니다. 로그에는 접속한 도메인이 포함될 수 있고 스크린샷의 QR 코드에도 인증 정보가 들어 있을 수 있습니다. 전체 구독 정보를 이미 공개했다면 게시물을 삭제하는 것만으로는 복사된 정보의 위험을 없앨 수 없으므로 서비스 제공업체에서 해당 접근 정보를 재설정하세요.

사용하지 않는 설정과 오래된 규칙, 테스트용 시스템 프록시를 주기적으로 정리하세요. 백업에는 정상 작동하는 설정과 로컬 변경 사항 설명을 보관하면 됩니다. 클라이언트를 종료한 뒤 시스템 네트워크가 복구되는지 확인하고 절전 모드에서 깨어나거나 재부팅한 다음에도 활성 설정이 올바른지 점검하세요. 비슷한 문제가 생기면 자신의 변경 기록을 먼저 확인한 뒤 이 사이트의 사용 설명서와 문제 해결 게시물을 참고하세요. 자주 유지 관리하는 것이 목적이 아닙니다. 간단한 기록만으로도 명확한 복구 절차를 마련할 수 있습니다.

9. 고급 설정: 작동하는 설정에서 이해할 수 있는 설정으로

실험용 복사본과 관찰 방법부터 준비

앞의 8개 장을 마쳤다면 더 많은 매개변수를 무작정 추가하기보다 현재 동작을 설명할 수 있어야 합니다. 정상 작동하는 설정을 실험용으로 복사하고 변경할 때마다 목적, 예상 결과, 복구 방법을 기록하세요. 테스트에서는 한 번에 변수 하나만 바꾸고 동일한 목적지에 새 연결을 만든 뒤 일치한 규칙과 최종 출구를 확인합니다. 변경 전후의 차이를 설명할 수 있어야 해당 매개변수를 이해한 것입니다. 우연히 한 번 연결에 성공한 것으로 충분하지 않습니다.

첫 번째 단계에서는 설정 구조를 정리합니다. 원격 구독 내용, 로컬 규칙, 프록시 그룹 기본 설정, 기기 설정을 따로 관리하세요. 어떤 항목을 클라이언트에서 생성하는지, 원격 설정에서 가져오는지, 오버라이드에서 추가하는지 확인합니다. 최종 설정이 어떻게 병합되는지 모른다면 복잡한 스크립트를 추가하기 전에 클라이언트의 병합 순서를 알아보세요. 설정이 커질수록 파일 길이를 줄이는 것보다 출처를 명확히 구분하는 일이 중요합니다.

의존 순서에 따라 DNS와 제공자 학습

두 번째 단계에서는 DNS를 자세히 살펴볼 수 있습니다. 기본 DNS, 프록시 서버 도메인 조회, 목적지 도메인 조회가 각각 어느 단계에 필요한지 먼저 이해한 뒤 nameserver, fallback, 필터링 조건을 알아보세요. 여러 암호화 DNS 주소를 단순히 추가한다고 더 안정적인 것은 아닙니다. DNS 서버 자체의 도메인을 조회하기 위한 별도 경로가 필요할 수 있고, 접속 경로가 아직 연결되지 않은 프록시에 의존할 수도 있습니다. 의존성 순환으로 설정이 완성된 것처럼 보여도 시작 단계에서 계속 대기할 수 있습니다.

세부 항목은 DNS nameserver·fallback·하이재킹 설정 안내에서 하나씩 확인하세요. fallback의 용도와 판단 방식은 설정 및 코어 구현에 따라 다르므로 기본 DNS가 실패한 뒤에만 사용하는 예비 목록이라고 단정하지 마세요. 반복해서 테스트할 수 있는 도메인을 정한 다음 DNS 응답, 규칙 일치, 연결 상태를 함께 관찰하세요. 반환 주소만 보고 결론을 내리지 마세요.

세 번째 단계에서 프록시 제공자와 규칙 제공자를 추가할 수 있습니다. 자주 업데이트되는 리소스를 기본 설정에서 분리할 수 있지만 다운로드, 캐시, 시작 의존성이 늘어납니다. 리소스 출처와 형식, 저장 경로, 업데이트 간격을 각각 확인하고 처음 다운로드가 실패했을 때 사용할 캐시가 있는지도 살펴보세요. 기기마다 경로 권한이 다릅니다. 데스크톱에서 쓸 수 있는 상대 경로가 모바일이나 서비스 환경에서도 작동한다고 볼 수 없으며 클라이언트에서 다시 관리해야 할 수 있습니다.

서버·라우터·제어 인터페이스의 사용 범위

네 번째 단계에서 서버나 라우터에 Mihomo 코어를 설치하는 방법을 살펴볼 수 있습니다. 이런 환경에는 권한, 서비스 시작, 시스템 복구를 대신 관리하는 데스크톱 인터페이스가 없습니다. 설정 경로, 실행 사용자, 로그, 라우팅을 직접 관리해야 합니다. 먼저 로컬에서 지정한 프록시가 작동하는지 확인한 뒤 LAN 입구와 방화벽 범위를 설계하세요. 기본 게이트웨이를 바로 교체하지 마세요. 라우터에는 프로세서 아키텍처, 메모리, 시스템 구성 요소도 중요하므로 압축 파일 이름만으로 호환성을 판단할 수 없습니다.

제어 인터페이스는 상태 확인이나 코어 관리에 사용하는 기능이지 일반 프록시 입구가 아닙니다. 원격 접근이 필요하다면 수신 범위를 제한하고 인증을 설정한 다음 방화벽과 보호된 관리 경로도 함께 사용하세요. 제어 인터페이스를 공개 네트워크에 직접 개방하지 마세요. 공개 설정 저장소에 인증 정보를 보관해서도 안 됩니다. LAN 프록시 공유도 이용자와 접근 범위를 명확히 해야 합니다. LAN 연결 허용은 입구 설정일 뿐 완전한 접근 제어를 자동으로 제공하지 않습니다.

회사 내부망, 앱별 규칙, 이중 네트워크 출구, IPv6를 설정해야 한다면 예상 경로를 먼저 정리하세요. 어떤 트래픽이 코어에 들어오는지, 어떤 트래픽은 직접 연결해야 하는지, DNS는 어디에서 처리하는지, 프록시 연결이 끊기면 어떤 상태여야 하는지 기록합니다. IPv6는 주소, DNS, 라우팅을 모두 고려해야 하므로 설정 항목 하나를 켰다고 완벽하게 지원된다고 볼 수 없습니다. 회사 네트워크 정책이나 관리 대상 기기와 관련된 설정은 먼저 허가를 받으세요. 프록시 설정으로 기존 접근 제한을 우회하지 마세요.

최종적으로 각 프록시 그룹의 용도가 명확하고 예외 규칙마다 이유가 있으며 백그라운드 서비스를 끄는 방법과 업데이트 오류 복구 방법을 아는 설정을 구성해야 합니다. 처음 연결하는 방법은 빠른 시작 안내에서, 기기를 변경할 때는 클라이언트 다운로드 페이지에서 다시 확인할 수 있습니다. 이해하지 못한 설정 조각을 계속 복사하는 것보다 필요한 규칙만 명확히 정하고 안정적인 절차를 따르면 관리가 쉬워지고 네트워크 문제가 어느 계층에서 발생했는지도 더 잘 파악할 수 있습니다.