Mihomo 설정 가이드

1. 핵심 개념과 클라이언트 선택

코어, 인터페이스, 서비스 제공처

Mihomo는 설정을 해석하고 규칙을 적용해 외부 연결을 만드는 프록시 코어입니다. Clash Meta는 Mihomo 생태계에서 널리 쓰이는 이전 명칭입니다. 클라이언트는 그래픽 인터페이스와 설정 관리, 시스템 연동 기능을 제공합니다. 인터페이스에서 시스템 프록시나 프록시 그룹을 선택하면 코어의 작동 상태나 관련 시스템 설정이 바뀝니다. 따라서 화면에 실행 중이라고 표시되는 것만으로는 프로세스가 작동한다는 점만 확인할 수 있을 뿐, 구독이 유효하거나 외부 연결이 가능하고 모든 앱이 프록시를 사용한다고 단정할 수 없습니다.

전체 연결 흐름은 앱, 트래픽 진입점, 규칙, 프록시 그룹, 외부 연결로 이루어집니다. 앱은 시스템 프록시나 TUN을 통해 요청을 코어에 전달합니다. 코어는 모드에 따라 규칙을 적용할지 결정하고, 일치하는 규칙에 따라 연결을 직접 연결하거나 차단하거나 특정 프록시 그룹으로 보냅니다. 프록시 그룹은 실제 외부 연결을 선택합니다. 구독은 보통 외부 연결 설정과 일부 규칙을 제공하지만, 클라이언트 자체가 네트워크 서비스인 것은 아닙니다. 클라이언트를 다운로드하고 설치한 뒤에도 유효한 설정을 제공하는 출처를 준비하거나 관련 서비스를 직접 배포하고 관리해야 합니다.

플랫폼에 맞는 설치 경로 선택

처음 선택할 때는 Clash Plus를 고려하고, 사용하는 플랫폼과 방식에 따라 다른 클라이언트와 비교해 보세요. Windows에서는 Clash Verge Rev, FlClash, Clash Nyanpasu도 선택할 수 있습니다. macOS에서는 Clash Verge Rev와 FlClash를 비교해 볼 수 있고, Android에서는 Clash Meta for Android, FlClash 또는 Surfboard를 고려할 수 있습니다. Surfboard의 설정 형식은 Mihomo와 완전히 같지 않으므로 둘 다 프록시 도구라는 이유만으로 같은 YAML 파일을 가져오면 안 됩니다. 플랫폼별 설치 경로는 다운로드 센터에서 확인하세요.

지원 상태와 기능 범위

Clash for Windows와 ClashX Meta는 더 이상 유지 관리되지 않습니다. 이전 환경을 확인하거나 기존 설정을 마이그레이션할 때는 활용할 수 있지만, 오래된 가이드에 나온다는 이유만으로 계속 사용하는 것은 권장하지 않습니다. Linux 데스크톱 사용자는 Clash Verge Rev와 FlClash를 먼저 비교해 보세요. 서버와 라우터에서는 Mihomo 코어를 직접 실행하는 방법도 고려할 수 있습니다. 이 방식은 프로세스, 설정 디렉터리, 수신 주소와 라우팅을 직접 관리해야 하며, 그래픽 클라이언트가 자동으로 처리하는 시스템 연동 기능은 제공하지 않습니다.

iOS에서 Clash Plus를 사용하려면 공식 웹사이트 clashplus.io에서 앱 정보를 확인한 뒤 App Store 페이지에서 설치할 수 있습니다. 이름이 같은 클라이언트라도 플랫폼에 따라 인터페이스와 시스템 기능이 다를 수 있습니다. 설정을 익힐 때는 버튼 위치를 똑같이 찾기보다 각 설정의 역할을 파악하는 것이 좋습니다.

이 단계에서는 다음 세 가지 질문에 답할 수 있어야 합니다. 어떤 클라이언트가 실행 중인지, 실제 연결을 처리하는 코어나 네트워크 구성 요소가 무엇인지, 설정을 누가 제공하고 업데이트하는지 확인하세요. 클라이언트를 비교할 때는 화면이 비슷한지보다 구독 호환성, 규칙 적용 방식, 로그 확인 가능 여부와 설정 백업 기능을 살펴보세요. ‘특정 프로토콜 지원’이라는 설명이 있어도 현재 플랫폼과 구현 방식이 구독에 사용된 세부 매개변수까지 지원하는지 확인해야 합니다. 프로토콜 이름이 같다고 모든 확장 필드를 서로 바꿔 쓸 수 있는 것은 아닙니다.

2. 설치, 권한과 초기 환경

설치 전 아키텍처와 기존 설정 확인

먼저 시스템 정보에서 기기의 아키텍처를 확인한 뒤 설치 패키지를 선택하세요. Windows 기기는 대부분 x64지만 ARM 기기도 있습니다. macOS는 Apple Silicon과 Intel을 구분해야 하고, Linux는 아키텍처뿐 아니라 배포판에서 사용하는 패키지 형식도 확인해야 합니다. 파일 크기만으로 호환성을 추측하지 마세요. 설치 프로그램이 실행된다고 해서 함께 제공되는 코어도 현재 시스템에서 작동한다는 뜻은 아닙니다. 실행 직후 종료된다면 구독을 수정하기 전에 아키텍처와 시스템 요구 사항을 확인하고 앱 로그를 살펴보세요.

기기에 다른 프록시 클라이언트가 설치되어 있다면 먼저 종료하고 시스템 프록시가 이전 포트를 가리키고 있지 않은지 확인하세요. 창을 닫아도 백그라운드 프로세스가 종료되지 않을 수 있습니다. 트레이 아이콘, 메뉴 막대 아이콘, 시스템 서비스가 계속 실행 중일 수 있습니다. 처음 연결을 확인할 때는 트래픽을 처리하는 클라이언트를 하나만 사용하세요. 여러 프로그램이 시스템 프록시를 번갈아 변경하거나 TUN 장치 두 개가 기본 경로를 두고 충돌하는 상황을 막을 수 있습니다. 기존 설정은 백업하되 상태를 모르는 채 동시에 활성화하지 마세요.

데스크톱 플랫폼의 권한 설정 순서

Windows에서는 일반 권한으로 설치하고 실행해 기본 화면이 열리는지 확인하세요. 서비스 설치나 관리자 권한이 필요한 네트워크 기능을 활성화할 때만 클라이언트 안내에 따라 권한을 허용하면 됩니다. 시스템 프록시를 사용하기 위해 앱 전체를 계속 관리자 권한으로 실행할 필요는 보통 없습니다. TUN이나 서비스 모드에는 권한이 높은 보조 구성 요소가 필요할 수 있습니다. 포트가 사용 중이라는 메시지가 나오면 어떤 프로세스가 해당 포트를 수신하는지 확인하세요. 한쪽의 포트를 변경한 뒤에는 시스템 프록시 대상도 함께 업데이트해야 합니다. YAML만 수정하고 시스템 진입점은 그대로 두면 안 됩니다.

macOS에서 처음 실행할 때는 시스템 안내에 따라 앱 출처와 권한 요청의 목적을 확인하세요. 클라이언트에 따라 보조 서비스를 설치하거나 네트워크 확장을 사용할 수 있으며, 절차는 앱마다 다릅니다. 키체인 팝업과 네트워크 확장 권한은 서로 다른 기능입니다. 전자는 민감한 정보를 저장하는 데 사용될 수 있고, 후자는 시스템 네트워크 트래픽을 처리할 권한을 부여합니다. 대화상자가 나타나면 요청한 앱과 권한을 먼저 확인하고 모든 안내를 무조건 허용하지 마세요. 자세한 내용은 macOS 권한 및 키체인 안내를 참조하세요.

Linux 그래픽 클라이언트가 시스템 프록시를 설정할 수 있는지는 데스크톱 환경과 앱 구현에 따라 다릅니다. 명령줄 프로그램도 데스크톱 프록시 설정을 읽는다고 보장할 수 없습니다. 설치 후에는 코어 프로세스가 실행 중인지, 설정을 정상적으로 불러왔는지, 로컬 포트가 수신 중인지 확인한 뒤 프록시를 지원하는 앱으로 테스트하세요. 코어를 직접 실행한다면 설정 디렉터리에 적절한 읽기·쓰기 권한을 부여하세요. 편의를 위해 디렉터리 전체를 모든 사용자에게 쓰기 허용하지 마세요. 서비스 계정, 작업 디렉터리와 상대 경로가 서로 맞지 않으면 직접 실행할 때는 정상인데 백그라운드 실행은 실패하는 경우가 많습니다.

모바일 기기와 최소 실행 설정

Android에서 처음 VPN 연결을 설정하면 시스템 권한 요청이 표시됩니다. 이는 트래픽 진입점 사용을 허가한다는 뜻이지, 원격 연결이 정상이라는 뜻은 아닙니다. 일반적으로 시스템에서 VPN 연결 하나만 활성화할 수 있으므로 회사 VPN이나 다른 네트워크 도구와 충돌할 수 있습니다. 절전 정책으로 클라이언트가 백그라운드에서 중지될 수도 있습니다. 실제 연결 끊김이 확인된 경우에만 관련 제한을 조정하세요. iOS도 앱 안내에 따라 VPN 설정을 허용한 뒤 클라이언트로 돌아와 설정 불러오기 오류가 있는지 확인하세요.

# 로컬 연결 예제이며 프록시 외부 연결은 포함하지 않음
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

위 예제는 기본 매개변수를 이해하기 위한 것으로, 프록시 서비스를 제공하는 완전한 설정이 아닙니다. mixed-port는 HTTP 및 SOCKS 요청을 받습니다. allow-lan: false는 LAN 접근을 제한하려는 설정이며, 실제 노출 여부는 수신 주소와 방화벽 설정도 함께 확인해야 합니다. 우선 로컬에서만 사용하고 LAN 공유는 활성화하지 마세요. 설치가 완료되었다고 판단하려면 인터페이스와 코어, 로컬 진입점이 모두 정상이어야 하며, 클라이언트를 종료한 뒤 원래 네트워크 상태로 복구되어야 합니다.

3. 구독 가져오기와 설정 관리

구독 주소와 실제 설정 구분

구독 링크는 설정을 가져오는 경로이고, 다운로드된 내용이 코어에서 실제로 해석하는 설정입니다. 링크에서 완전한 YAML 파일, 프록시 연결 정보만 포함된 목록, 다른 클라이언트용 형식이 반환될 수 있습니다. 가져오기 전에 제공자가 현재 클라이언트와 코어를 명시적으로 지원하는지 확인하세요. 브라우저에서 링크가 열린다는 것은 응답을 받았다는 뜻일 뿐, 유효한 설정을 받았다는 뜻은 아닙니다. 로그인 페이지, 잔액 안내, 접근 제한 페이지도 정상적인 웹페이지 형태로 반환될 수 있습니다.

클라이언트에서 설정 또는 구독 관리 메뉴를 찾아 원격 설정을 추가하고, 출처를 알아볼 수 있는 이름을 지정한 뒤 주소를 붙여 넣고 다운로드하세요. 완료 후에는 업데이트 시간과 파싱 결과, 프록시 그룹이 생성되었는지 확인한 다음 현재 설정으로 지정하세요. 클라이언트에 따라 ‘다운로드 성공’과 ‘사용 설정 완료’가 별도 동작일 수 있습니다. 파일을 저장했더라도 코어가 해당 설정으로 전환된 것은 아닙니다. 현재 설정 이름과 시작 로그를 함께 확인해 활성화되지 않은 파일을 계속 수정하는 일을 피하세요.

설정 출처별 역할 나누기

원격 구독은 보통 제공자가 관리하므로 다운로드 캐시를 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 장기간 유지할 규칙, DNS 또는 진입점 설정은 클라이언트의 덮어쓰기, 병합 또는 확장 기능을 사용하세요. 기능 이름과 적용 순서는 클라이언트마다 다릅니다. 해당 기능이 필드를 통째로 교체하는지, 원래 목록의 앞이나 뒤에 추가하는지 먼저 확인하세요. 규칙 목록에서는 MATCH 뒤에 추가한 규칙이 문법상 올바르더라도 실행되지 않을 수 있습니다.

설정을 출처 계층, 개인 덮어쓰기 계층, 실행 상태의 세 부분으로 나누면 문제를 파악하기 쉽습니다. 출처 계층에서는 구독에서 무엇을 다운로드했는지 확인하고, 덮어쓰기 계층에서는 로컬에서 무엇을 추가하거나 교체했는지 살펴봅니다. 실행 상태에서는 코어에 최종적으로 어떤 설정이 전달됐는지 확인합니다. 인터페이스의 값이 YAML과 다르면 구독 원문만 보지 말고 최종 설정이나 로그를 확인하세요. 일부 클라이언트는 시작 시 포트와 제어 인터페이스 등의 필드를 삽입하므로 실행 설정이 원격 원본 파일과 다르더라도 반드시 오류는 아닙니다.

# 일부 예제: 자주 사용하는 최상위 필드 두 가지
mode: rule
log-level: info

# 규칙에서 참조하는 PROXY는 전체 설정에 정의되어 있어야 함
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

가져오기 및 업데이트 실패 해결

파싱 오류가 발생하면 오류 메시지에 표시된 필드명과 줄 번호를 먼저 기록하세요. YAML은 공백으로 계층을 표현하므로 들여쓰기에 탭을 섞으면 안 됩니다. 목록 앞의 하이픈, 콜론 뒤의 공백, 문자열의 특수 문자도 파싱에 영향을 줍니다. 오류 줄은 파서가 문제를 발견한 위치일 뿐, 실제 원인은 앞 줄의 따옴표 누락이나 잘못된 계층일 수 있습니다. 파일 전체를 다시 정리해 처음부터 단서를 잃기보다 오류 주변을 나누어 확인하세요.

다운로드에 실패하면 도메인 확인 실패, 연결 시간 초과, 인증서 오류, 권한 만료, 응답 내용 불일치를 구분하세요. 구독 요청은 클라이언트 자체나 코어에서 처리할 수 있어 브라우저와 같은 네트워크 경로를 사용한다고 보장할 수 없습니다. 제공자가 특정 요청 식별자를 요구하는 경우에만 User-Agent를 변경하세요. 임의로 값을 바꾸는 것은 일반적인 해결 방법이 아닙니다. 자세한 확인 절차는 구독 파싱 실패 자가 진단을, 처음 가져오는 방법은 구독 가져오기 절차를 참조하세요.

업데이트 전에 최근 정상적으로 작동한 설정을 백업하고, 업데이트 후 프록시 그룹 참조가 여전히 유효한지 확인하세요. 제공자가 외부 연결 이름을 바꾸면 기존에 고정 선택한 구성원이 더 이상 유효하지 않을 수 있습니다. 클라이언트가 이전 선택을 보존했다면 프록시 그룹에서 다시 확인하세요. 새로고침이 성공했다는 이유만으로 업데이트가 완료됐다고 판단하지 말고 실제 연결과 적용된 규칙을 확인하세요. 자주 바뀌는 구독에서는 개인 규칙이 쉽게 바뀌는 외부 연결 이름보다 안정적인 프록시 그룹 이름을 참조하도록 설정하는 편이 좋습니다.

4. 프록시 모드와 프록시 그룹

진입점과 외부 연결 결정 구분

시스템 프록시, TUN, Rule은 서로 다른 계층의 옵션입니다. 앞의 두 가지는 앱 트래픽이 코어에 들어오는 방식을 결정하고, Rule은 들어온 뒤 트래픽을 어떻게 분기할지 결정합니다. 따라서 ‘Global로 바꿨는데도 일부 앱이 프록시를 사용하지 않는다’는 상황은 모순이 아닙니다. 해당 앱이 시스템 프록시를 사용하지 않고 다른 진입점에도 연결되지 않았을 수 있습니다. 문제를 확인할 때는 먼저 연결 패널에서 해당 요청을 찾으세요. 연결이 전혀 보이지 않으면 진입점을 확인해야 하며, 외부 연결이나 규칙 순서를 계속 바꿀 필요는 없습니다.

일반적인 사용에서는 Rule 모드부터 시작하면 됩니다. Global은 짧은 시간 동안 문제를 비교 진단할 때 적합하지만, 구독 만료나 진입점 충돌, DNS 오류를 자동으로 해결하지는 않습니다. Direct도 클라이언트 종료와 같은 의미가 아닙니다. 진입점 처리와 코어의 DNS 해석은 계속 유지될 수 있습니다. 프록시 환경 전체가 원인인지 확인하려면 클라이언트를 종료하고 시스템 설정을 복원해야 합니다. Direct로만 전환해서는 TUN 라우팅이나 클라이언트 DNS가 계속 작동하는 상황을 배제할 수 없습니다.

프록시 그룹 참조 구조 이해

프록시 그룹은 규칙과 실제 외부 연결 사이에 위치하는 중간 계층입니다. select는 구성원을 직접 선택하고, url-test는 검사 결과에 따라 구성원을 선택합니다. fallback은 순서대로 사용 가능한 구성원을 찾고, load-balance는 설정된 분배 방식에 따라 연결을 나눕니다. 자동 선택 그룹의 검사 결과는 검사 주소와 방식에 대한 결과일 뿐, 특정 웹사이트가 반드시 접속 가능하다는 뜻은 아닙니다. 화면에 표시된 값을 모든 상황의 품질 지표로 간주하지 마세요.

# 이 그룹을 기존 전체 설정의 proxy-groups 목록에 추가
# 직접 연결 옵션만 포함한 구조 예제이며 프록시 외부 연결은 추가하지 않음
proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,수동 선택

예제에서는 규칙이 그룹 이름을 참조하고, 그룹은 내장 DIRECT를 참조합니다. 실제 구독에서는 정의된 외부 연결 이름을 구성원으로 추가하거나 다른 프록시 그룹을 참조할 수 있지만, 서로 참조해 순환이 생기지 않도록 해야 합니다. 이름은 대소문자, 공백, 기호까지 정확히 일치해야 합니다. 그룹 이름을 변경할 때는 rules의 참조와 다른 그룹의 구성원도 함께 수정하세요. 화면에 표시되는 이름만 바꾸면 대상이 없어져 설정을 불러오지 못할 수 있습니다.

요청 하나로 선택 결과 확인

프록시 그룹을 전환하면 새 연결에는 보통 새 선택이 적용되지만, 이미 맺어진 장시간 연결은 기존 외부 연결을 계속 사용할 수 있습니다. 브라우저 연결 풀, 다운로드 작업, 메신저 연결이 유지될 수 있습니다. 확인할 때는 관련 페이지나 작업을 종료한 다음 새 요청을 보내고 연결 패널에서 규칙, 프록시 체인과 외부 연결을 확인하세요. 필요한 경우 해당 업무의 연결만 종료하면 됩니다. 다른 작업에 영향을 줄 수 있으므로 매번 모든 연결을 초기화할 필요는 없습니다.

인터페이스에는 전체 프록시 그룹과 구독에서 사용자 지정한 프록시 그룹이 함께 표시될 수 있습니다. Rule 모드에서는 화면 맨 위에 보이는 그룹이 아니라, 규칙이 참조하는 대상이 실제로 적용됩니다. 외부 연결을 바꿨는데도 동작에 변화가 없다면 클라이언트가 선택을 저장하지 않았다고 단정하지 말고 연결 기록의 프록시 체인을 따라가며 확인하세요. 이름이 같은 다른 출처의 설정으로 바꾼 경우에는 그룹 구성원도 달라졌는지 확인해야 합니다.

이 단계를 마치기 전에 조건을 통제해 한 번 비교 테스트하세요. 진입점은 그대로 둔 채 같은 웹사이트에 Rule과 Global을 각각 적용하고 결과를 기록합니다. Global은 되지만 Rule이 안 되면 규칙 적용 결과와 그룹 선택을 확인하세요. 둘 다 안 되면 먼저 외부 연결이나 이름 해석을 확인해야 합니다. 이는 장기간 사용할 설정을 권장하는 것이 아니라 문제 범위를 전체 연결 경로에서 특정 단계로 좁히기 위한 방법입니다. 용어는 프록시 그룹 안내에서 확인하세요.

5. 규칙 분기와 적용 순서

먼저 일치한 규칙이 연결을 결정

Mihomo의 일반 규칙은 위에서 아래 순서로 평가하며, 먼저 일치하는 규칙의 대상이 적용됩니다. 따라서 우선순위는 규칙 유형의 이름보다 위치에 따라 결정됩니다. 정확한 도메인 규칙도 앞에 있는 더 넓은 규칙보다 우선하지 않습니다. 마지막의 MATCH는 기본 경로 역할을 합니다. 규칙을 작성할 때는 구체적인 예외를 먼저 두고 범위가 넓은 분류를 뒤에 배치한 다음 기본 외부 연결을 마지막에 추가하세요. 연결 패널에서 실제로 적용된 규칙을 확인하세요.

DOMAIN은 도메인 전체와 일치하고, DOMAIN-SUFFIX는 도메인 및 하위 도메인과 일치합니다. DOMAIN-KEYWORD는 키워드로 비교하므로 범위가 더 넓고 의도치 않게 일치할 수 있습니다. IP 규칙은 대상 주소에 적용되고, 프로세스 규칙은 플랫폼 지원 및 프로세스 식별 조건에 따라 작동합니다. 웹사이트의 IP 주소 하나를 알고 있다고 해당 주소를 영구적인 단일 IP 규칙으로 추가하지 마세요. 콘텐츠 전송, 주소 변경, 공유 호스팅 때문에 범위가 부족하거나 다른 서비스에 영향을 줄 수 있습니다.

# 일부 규칙 예제이며 PROXY는 기존 프록시 그룹이어야 함
rules:
  - DOMAIN,router.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

여기서 example.com은 문법 설명을 위한 예시 도메인이므로 실제 서비스에 맞게 바꿔야 합니다. no-resolve는 이 IP 규칙을 적용하기 위해 도메인을 새로 해석하지 않는다는 뜻이지, 모든 DNS 요청을 끈다는 의미는 아닙니다. 연결에 대상 주소가 이미 있다면 해당 주소를 기준으로 규칙이 적용될 수 있습니다. GEOSITE와 GEOIP는 로컬 데이터 파일을 사용하므로 분류 이름이 실제로 존재해야 합니다. 설정을 성공적으로 불러왔다는 사실은 문법과 데이터가 유효하다는 뜻일 뿐, 분류 내용이 현재 업무에 정확히 맞는다는 뜻은 아닙니다.

내장 분류에서 규칙 세트로 확장

직접 작성한 규칙 목록이 길어지면 rule-providers를 사용해 규칙 데이터와 기본 설정을 분리할 수 있습니다. 제공자에는 출처, 저장 위치, 업데이트 주기와 콘텐츠 형식을 지정하고, rules에서 RULE-SET으로 참조합니다. domain, ipcidr, classical은 지원하는 콘텐츠 형식이 서로 다르므로 확장자만 바꿔서 서로 대체할 수 없습니다. 규칙 세트 파일의 항목에는 보통 최종 정책이 포함되지 않습니다. 적용 정책은 해당 파일을 참조하는 rules 행에서 지정합니다.

# 로컬 규칙 세트 예제: 상대 경로는 코어 작업 디렉터리를 기준으로 함
rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,PROXY

# rules/local-domains.yaml로 저장
payload:
  - '+.example.com'

로컬 파일을 사용하면 원격 다운로드까지 함께 확인하지 않고도 형식과 규칙 적용을 먼저 검증할 수 있습니다. 정상 작동을 확인한 뒤 원격 출처를 고려하고, 관리 방식과 적용 범위를 확인하세요. 원격 규칙 세트를 업데이트하지 못해도 이전 캐시가 계속 적용될 수 있으며 캐시가 없다면 불러오지 못할 수 있습니다. 기본 설정 업데이트와 규칙 세트 업데이트는 별도로 확인해야 하므로 로그도 각각 살펴보세요. 용도가 겹치는 규칙 세트를 여러 개 무작정 추가하면 실제 결과를 결정한 세트를 파악하기 어렵습니다.

근거를 바탕으로 분기 오류 확인

요청이 코어에 들어왔는지 확인하고, 대상 도메인과 주소, 적용 규칙, 대상 그룹 선택 순서로 살펴보세요. 연결 정보에 IP만 표시된다면 앱이 직접 주소를 해석하는지, DNS가 코어를 우회하는지, 도메인 스니핑 조건이 충족되는지 확인해야 합니다. 스니핑으로 도메인 정보를 보완할 수는 있지만 모든 프로토콜에서 원래 호스트명을 알아낼 수 있는 것은 아닙니다. 규칙이 적용되지 않는 모든 문제를 스니핑 활성화로 해결할 수는 없습니다. 규칙을 추가하기 전에 코어가 실제로 어떤 정보를 확인할 수 있는지 파악하세요.

일부 웹사이트는 로그인, 정적 리소스, API, 미디어 도메인에 각각 접속합니다. 첫 화면 도메인에만 규칙을 추가하면 페이지 일부만 정상화될 수 있습니다. 명확한 작업을 한 번 수행하면서 실패한 연결을 확인한 뒤 필요한 범위만 추가하세요. 범위가 지나치게 넓은 키워드 때문에 무관한 트래픽까지 처리되지 않도록 주의하세요. 규칙 유형과 순서는 사용자 지정 규칙과 우선순위를, 분류를 조합하는 방법은 GEOSITE 및 규칙 세트 분기 설정을 참조하세요.

6. DNS, Fake-IP와 TUN

DNS 해석과 연결은 서로 연관된 별도 경로

DNS는 도메인을 주소로 변환하고 프록시는 그 뒤의 연결을 전달하지만, 두 경로가 반드시 같지는 않습니다. 브라우저는 암호화 DNS를 사용할 수 있고, 시스템은 이전 결과를 캐시할 수 있으며, 앱에 자체 해석기가 내장되어 있을 수도 있습니다. 따라서 웹사이트에 접속할 수 없다고 바로 외부 연결 문제로 볼 수는 없습니다. 먼저 주소가 반환되는지 확인하고, 다음으로 연결이 코어에 들어오는지, 마지막으로 어떤 외부 연결을 사용하는지 확인하세요. 네트워크를 비교할 때는 클라이언트 설정을 동일하게 유지해야 네트워크와 설정이 동시에 바뀌어 원인을 찾기 어려워지는 일을 막을 수 있습니다.

Fake-IP는 도메인에 가상 주소를 할당하고 매핑 정보를 관리합니다. 이후 트래픽이 코어에 도달하면 원래 도메인과 연결할 수 있습니다. 이 주소는 웹사이트의 실제 주소가 아니므로 가상 주소만으로 지리적 위치를 판단할 수 없습니다. redir-host는 해석된 실제 주소를 반환하므로 실제 주소가 필요한 특정 환경에 적합하지만, 규칙 판정이 도메인 매핑과 해석 결과에 더 의존할 수 있습니다. 모든 앱에 통하는 한 가지 방식이 있는 것은 아니므로 LAN, 게임, 기업 내부망의 요구에 맞춰 확인해야 합니다.

# DNS 일부 예제이며 로컬에서만 수신
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - 'localhost'
  nameserver:
    - https://1.1.1.1/dns-query

위 예제는 로컬 DNS 수신 포트만 생성하며 시스템이 해당 포트로 DNS 요청을 보내도록 자동 설정하지는 않습니다. 시스템 DNS, TUN 가로채기 또는 클라이언트 연동 기능을 별도로 연결해야 합니다. 예제에 지정된 업스트림도 실제 네트워크에서 연결할 수 있어야 합니다. 암호화 프로토콜이라는 이유만으로 연결 가능성이 보장되지는 않습니다. fake-ip-filter는 특정 도메인에 가상 주소를 반환하지 않도록 설정하는 기능입니다. 호환성 문제가 확인된 도메인에만 예외를 추가하세요. 범위를 넓히면 기존 트래픽 분기 방식이 바뀌고 문제를 찾기도 어려워질 수 있습니다.

TUN 사용 조건과 제한

TUN은 가상 네트워크 인터페이스를 통해 IP 트래픽을 받아 시스템 프록시를 따르지 않는 프로그램에 사용할 수 있습니다. 활성화하기 전에 권한, 드라이버 또는 보조 서비스가 준비되었는지 확인하고 다른 VPN이 실행 중인지 살펴보세요. auto-route는 관련 라우팅 설정을 구성하고, auto-detect-interface는 외부 연결에 사용할 인터페이스를 감지합니다. 다중 네트워크 카드, 핫스팟과 기업 네트워크에서는 실제 결과를 다시 확인해야 합니다. TUN은 권한이나 외부 연결 프로토콜 제한, 방화벽을 우회하는 만능 기능이 아닙니다.

# TUN 일부 예제이며 플랫폼 및 DNS 설정과 함께 사용해야 함
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns-hijack에서 일반 DNS 포트를 지정해도 앱이 자체적으로 만든 암호화 DNS 연결까지 모두 처리할 수는 없습니다. 시스템 프록시와 TUN을 반드시 동시에 사용할 필요는 없습니다. 클라이언트의 권장 방식에 따라 선택해 진입점이 겹치는 바람에 연결 흐름을 파악하기 어려워지지 않도록 하세요. 활성화한 뒤 일반 웹페이지, 대상 앱, LAN 서비스를 차례로 테스트하세요. 프린터, 공유 폴더나 기업 내부망에 문제가 생기면 전체 트래픽을 직접 연결로 바꾸기보다 라우팅 제외나 도메인 예외가 필요한지 확인하세요.

DNS 누수와 내부망 충돌 확인

DNS 누수 여부는 의도한 해석 경로를 기준으로 판단해야 합니다. 어떤 요청을 어떤 해석기가 처리해야 하는지, 요청이 그 경로를 우회했는지 확인하세요. 테스트 웹페이지에 특정 해석기 이름이 표시되더라도 단서일 뿐, 모든 요청이 프록시를 통과했거나 우회했다는 증거는 아닙니다. 시스템 DNS, 클라이언트 로그, 브라우저의 보안 DNS 설정과 필요한 경우 네트워크 패킷 캡처를 함께 확인해 요청이 실제로 어디로 향하는지 파악하세요. 테스트할 때 IPv4와 IPv6도 구분해야 합니다. 한 주소 체계만 확인하고 결론을 내리지 마세요.

기업 내부망에서 전용 DNS를 사용한다면 공용 DNS로 내부 도메인을 해석하지 못할 수 있습니다. 내부 도메인 접미사별 해석 정책을 설정하고 해당 DNS 주소에 올바른 인터페이스로 연결할 수 있는지 확인하세요. 순환이 발생하면 프록시 연결에 DNS 해석이 필요하고 프록시 서버의 도메인도 같은 미확립 해석 경로에 의존할 수 있습니다. 프록시 서버 주소를 별도 경로로 해석할 수 있도록 설정해야 합니다. Fake-IP의 적용 범위는 Fake-IP와 redir-host의 차이에서 자세히 확인하세요.

7. 유지 관리와 문제 해결

복구 가능한 설정 기준선 만들기

안정적으로 사용하기 시작하면 클라이언트 설정, 개인 덮어쓰기와 규칙 파일을 포함해 백업하세요. 구독 링크만으로는 완전한 백업이 되지 않습니다. 원격 내용이 바뀔 수 있고, 로컬의 프록시 그룹 선택과 추가 규칙이 구독에 포함되지 않을 수 있습니다. 공개해도 되는 규칙과 계정 인증 정보가 포함된 설정은 분리해 백업하고, 민감한 정보는 접근을 통제할 수 있는 위치에 보관하세요. 현재 사용하는 진입점, DNS 모드, 특수 라우팅을 기록해 두면 화면 캡처만 저장하는 것보다 환경을 복구하기 쉽습니다.

업데이트는 클라이언트, 코어, 구독과 규칙 데이터로 나눠 진행하세요. 클라이언트 업데이트는 인터페이스와 시스템 연동을 바꿀 수 있고, 코어 업데이트는 지원하는 필드에 영향을 줄 수 있습니다. 구독 업데이트는 주로 외부 연결과 설정 내용을 변경합니다. 한 번에 한 항목만 업데이트하고 기본 기능을 확인하면 문제가 발생했을 때 되돌릴 대상을 정확히 알 수 있습니다. 업무 중 문제가 생겼을 때 모든 구성 요소를 한꺼번에 업데이트한 뒤 ‘업데이트 후 안 된다’는 이유만으로 복구하지 마세요. 호환성 문제와 서비스 변경을 구분하기 어렵습니다.

연결 순서에 따라 인터넷 연결 문제 진단

먼저 영향을 받는 범위를 확인하세요. 모든 앱인지, 특정 프로그램인지, 특정 웹사이트의 일부 기능인지 구분합니다. 클라이언트를 거치지 않을 때 네트워크가 정상인지도 확인하세요. 기본 네트워크도 연결되지 않으면 Wi-Fi, 모바일 네트워크, 인증 포털 또는 시스템 네트워크 상태부터 확인해야 합니다. 클라이언트가 실행 중이라면 코어가 정상적으로 시작됐는지, 현재 설정이 올바른지, 포트가 수신 중인지 살펴보세요. 대상 요청이 연결 목록에 없다면 외부 연결을 바꾸기보다 시스템 프록시, 앱 프록시 설정 또는 TUN을 먼저 확인하세요.

요청이 코어에 들어온 뒤에는 DNS 해석 결과, 적용 규칙과 최종 외부 연결을 확인하세요. 같은 외부 연결로 여러 사이트에 접속할 수 없다면 서비스 상태, 인증 정보와 원격 연결 가능 여부를 살펴보세요. 한 사이트만 실패하면 규칙, 사이트에서 사용하는 도메인과 프로토콜 차이를 확인해야 합니다. HTTP 오류 응답을 받았다는 것은 애플리케이션 계층의 결과를 받았다는 뜻이므로 네트워크 전체가 끊긴 것으로 볼 수 없습니다. 인증서 오류가 발생해도 검증 기능을 끄지 말고 시스템 시간, 대상 도메인과 중간 장비부터 확인하세요.

# 로컬 HTTP 프록시 진입점 확인: 포트는 실제 설정과 일치해야 함
curl -I --proxy http://127.0.0.1:7890 https://example.com

# SOCKS 진입점을 확인하고 도메인 해석은 프록시에서 수행
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

이 명령은 지정한 진입점과 웹사이트만 확인하며 모든 프로그램의 트래픽이 프록시로 전달된다는 뜻은 아닙니다. PowerShell에서 명령 별칭이 다르면 curl.exe를 사용하세요. socks5h와 일반 SOCKS 주소 형식은 도메인을 해석하는 위치가 다르므로 비교할 때 사용한 형식을 기록해야 합니다. 두 명령의 성공 여부만 비교하지 말고 로그에서 적용된 규칙도 확인하세요. 한쪽은 직접 연결되고 다른 쪽은 프록시를 사용했다면 같은 조건의 테스트가 아닙니다.

로그, 캐시와 종료 후 복구

일상적으로는 info와 같은 적절한 로그 수준을 사용하고, 문제를 확인할 때만 자세한 로그를 활성화하세요. 로그를 장시간 쌓기보다 실패한 작업의 시간, 대상과 오류 내용을 기록하는 편이 효과적입니다. 공유하기 전에 구독 주소, 인증 정보, 내부 호스트명과 업무 정보가 드러날 수 있는 요청 경로를 삭제하세요. 자세한 로그는 리소스를 더 사용하고 민감한 연결 정보를 기록할 수도 있으므로 문제를 파악한 뒤에는 로그 수준을 원래대로 되돌리세요.

DNS나 모드를 변경한 뒤에도 기존 캐시와 장시간 연결 때문에 결과가 바로 달라지지 않을 수 있습니다. 관련 연결을 먼저 종료하고 필요한 경우 시스템이나 앱 캐시를 새로 고치세요. 클라이언트 디렉터리 전체를 바로 삭제할 필요는 없습니다. 클라이언트를 종료한 뒤에도 접속할 수 없다면 시스템 프록시가 종료된 로컬 포트를 가리키는지, TUN 라우팅이 복구됐는지, DNS가 연결할 수 없는 주소를 가리키는지 확인하세요. 빠른 점검은 시스템 프록시 설정과 연결 확인을 참조하세요.

8. 고급 설정과 검증 과정

모듈화한 뒤 자동화 추가

고급 설정은 모든 기능을 켜는 것이 아니라 설정 각 부분의 입력, 출력과 실패 동작을 설명할 수 있는 상태를 말합니다. 안정적인 설정을 갖춘 뒤 개인 규칙을 구독에서 분리하고, 긴 규칙 목록을 별도의 제공자 파일로 정리한 다음 외부 연결 제공자와 자동 선택 정책을 고려해 보세요. 모듈을 나눌 때마다 경로와 이름 참조, 적용 순서를 확인해야 합니다. 모듈화의 목적은 수정 범위를 줄이는 것이지 간단한 설정을 여러 계층의 참조가 얽혀 추적하기 어려운 구조로 만드는 것이 아닙니다.

proxy-providers와 rule-providers는 서로 다른 문제를 해결합니다. 전자는 프록시 외부 연결 목록을 제공하고, 후자는 규칙에 사용할 조건 목록을 제공합니다. 보통 각각 프록시 그룹과 rules에서 참조합니다. 완전한 클라이언트 구독을 검토 없이 외부 연결 제공자 파일로 사용하지 마세요. proxies가 포함되어 있어도 인터페이스에 필요한 다른 섹션이 함께 있을 수 있으므로 실제 파싱 방식을 확인해야 합니다. 출처가 분명하지 않은 원격 파일은 자동 업데이트에 연결하기 전에 먼저 로컬에서 구조를 살펴보세요.

프록시 정책 테스트 매트릭스 만들기

자주 쓰는 웹사이트 하나만 여는 것이 아니라 서로 다른 유형을 테스트해야 합니다. 로컬 게이트웨이, LAN 서비스, 직접 연결이 필요한 사이트, 프록시가 필요한 사이트와 대상 업무 앱을 준비하고 예상 진입점, 규칙과 외부 연결을 각각 기록하세요. IPv6를 사용하는 경우 주소 체계 선택도 확인해야 하며, UDP를 사용하는 경우 진입점과 원격 프로토콜이 모두 지원되는지 점검하세요. 웹페이지가 열린다는 것은 TCP 연결 하나가 정상이라는 뜻일 뿐, 음성 통화, 게임이나 UDP 기반 기능까지 정상이라는 의미는 아닙니다.

같은 페이지를 다시 열기, 음성 연결을 새로 설정하기, 동일한 내부 서비스를 방문하기처럼 반복 가능한 동작으로 테스트하세요. 매개변수를 바꾸기 전에 예상 결과를 적어 두면 ‘더 빨라진 것 같다’거나 ‘가끔 된다’는 느낌만으로 설정이 정상이라고 판단하는 일을 막을 수 있습니다. 자동 선택 그룹은 검사 실패 후의 동작, 구성원 변경 후의 참조와 네트워크 전환 후 복구도 확인하세요. 화면에 정상적으로 표시되는지뿐 아니라 자동화 방식이 실제 요구에 맞는지 검증해야 합니다.

명령줄 코어와 제어 인터페이스

그래픽 인터페이스 없이 코어를 실행하려면 작업 디렉터리와 설정 파일 경로부터 이해해야 합니다. 상대 경로는 보통 작업 디렉터리를 기준으로 하며 규칙 파일, 캐시와 데이터 파일도 영향을 받을 수 있습니다. 설정 파일만 서버에 복사하고 로컬 제공자 파일을 빠뜨리는 것은 흔한 마이그레이션 실패 원인입니다. 먼저 포그라운드에서 설정과 로그를 확인한 뒤 서비스로 실행하세요. 서비스 계정과 로그인 계정은 권한이 다를 수 있으므로 디렉터리 읽기·쓰기와 네트워크 접근을 각각 확인해야 합니다.

# mihomo가 설치된 환경에서 설정 확인
mihomo -t -d ./mihomo-work -f ./mihomo-work/config.yaml

# 검사가 통과하면 포그라운드에서 실행
mihomo -d ./mihomo-work -f ./mihomo-work/config.yaml

설정 검사는 문법과 일부 참조 오류를 찾을 수 있지만, 구독 주소와 DNS 업스트림, 모든 외부 연결이 실제 실행 중에 연결된다는 점까지 보장하지는 않습니다. 포그라운드 테스트를 마친 뒤 같은 매개변수를 사용하는 시스템의 서비스 설정에 적용하세요. 외부 제어 인터페이스를 활성화한다면 수신 범위를 제한하고 접근 보호를 설정해야 합니다. 원격 패널 사용이 편리하다는 이유로 공용 네트워크에 그대로 노출하지 마세요. 제어 인터페이스는 실행 상태를 변경할 수 있으므로 일반적인 읽기 전용 웹페이지와 위험 수준이 다릅니다.

문제 해결 결과를 변경 기록으로 남기기

변경할 때마다 이유, 관련 필드, 검증 대상과 롤백 방법을 기록하세요. 복잡한 설정은 진입점이 명확하고 프록시 그룹이 적으며 규칙 경로를 파악하기 쉬운 최소 실행 기준선을 보관하는 것이 좋습니다. 문제가 생기면 새로운 기능을 하나씩 제거해 기준선과 비교하세요. 출처를 알 수 없는 설정을 인터넷에서 계속 가져와 덧붙이지 마세요. 설정 형식이 궁금하면 구독 및 설정 형식을 확인하고, 처음부터 다시 살펴보려면 빠른 시작 가이드로 돌아가세요.

이 가이드의 최종 목표는 모든 필드를 외우는 것이 아니라 앱 진입점, 도메인 해석, 규칙 적용, 프록시 그룹 선택과 실제 외부 연결을 따라가며 하나의 연결을 설명할 수 있는 것입니다. 다음에는 별도 규칙 세트, 도메인별 DNS 해석기 지정, 서버 프로세스 관리처럼 현재 업무에 필요한 기능만 익히세요. 설정을 읽기 쉽게 유지하고 결과를 검증하며 변경 사항을 되돌릴 수 있도록 관리하는 것이 매개변수를 계속 늘리는 것보다 장기적인 유지 관리에 유리합니다.