Mihomo 사용 가이드: 클라이언트 설치부터 구독·규칙 설정까지

핵심 개념: 코어, 클라이언트, 연결 경로

Mihomo는 설정을 읽고 연결을 수신해 규칙을 적용한 뒤 아웃바운드를 선택하는 네트워크 프록시 코어입니다. Clash Meta는 Mihomo의 발전 배경을 설명할 때 자주 언급되는 이름입니다. 데스크톱이나 휴대폰의 GUI 클라이언트는 설정 가져오기, 노드 선택, 권한 요청, 실행 상태 표시를 담당합니다. 화면이 열린다고 코어가 실행 중인 것은 아니며, 코어가 실행 중이어도 앱 트래픽이 프록시로 들어온다는 보장은 없습니다. 이 두 계층의 차이를 이해하는 것이 문제 해결의 출발점입니다.

먼저 네 가지를 구분하세요

클라이언트는 조작을 위한 앱이고, 코어는 네트워크 요청을 실제로 처리하는 프로그램입니다. 설정 파일은 코어의 실행 기준이며, 프록시 서버는 원격 아웃바운드입니다. 구독은 보통 노드나 전체 설정을 배포하는 데 쓰이지만 프록시 소프트웨어 자체는 아닙니다. 클라이언트를 설치해도 사용할 서버가 자동으로 생기지는 않습니다. 노드에 연결되더라도 대역폭, 출구 지역, 프로토콜이 용도에 맞는지는 별도로 확인해야 합니다.

하나의 설정 파일에는 리스닝 포트, DNS, 프록시 노드, 프록시 그룹, 규칙, 원격 규칙 공급자가 함께 들어갈 수 있습니다. 프록시 그룹은 여러 아웃바운드를 선택 가능한 대상으로 묶고, 규칙은 그 대상을 참조합니다. 화면에서 노드를 선택하는 것은 여러 계층 중 하나일 뿐입니다. 요청이 DIRECT 규칙에 먼저 일치하면 프록시 그룹에서 노드를 바꿔도 해당 요청의 경로는 바뀌지 않습니다.

요청 흐름에 따라 라우팅을 이해하기

브라우저에서 도메인에 접속하려면 먼저 IP 주소를 확인한 다음 연결을 맺어야 합니다. 요청은 시스템 프록시 설정을 통해 로컬 리스닝 포트로 들어오거나 TUN 가상 네트워크 인터페이스에서 처리될 수 있습니다. 코어에 들어온 요청은 도메인, 대상 주소 등의 조건에 따라 규칙이 아웃바운드를 결정합니다. 원격 서버에 연결할 수 있는지, 대상 웹사이트가 응답하는지는 경로의 뒷부분에서 확인할 문제입니다. 화면에 표시된 연결 상태만으로 판단해서는 안 됩니다.

시스템 프록시는 대개 해당 설정을 지원하는 앱에 프록시 진입점을 알려 주는 방식입니다. 일부 게임, 명령줄 프로그램, 자체 네트워크 설정을 사용하는 앱은 이 설정을 따르지 않습니다. TUN은 더 넓은 범위의 트래픽을 처리하지만 라우팅, DNS, 권한이 관련됩니다. 두 방식은 용도가 다르므로 TUN을 켜면 반드시 빨라진다거나 시스템 프록시가 작동하지 않으면 클라이언트를 다시 설치해야 한다고 단정할 수 없습니다.

프로토콜, 전송 방식, 설정 형식 이해하기

Shadowsocks, Trojan, VLESS, Hysteria2, TUIC, WireGuard 등의 이름은 서로 다른 프로토콜 기능을 나타냅니다. 지원 목록에 있다고 해서 모든 노드에서 사용할 수 있는 것은 아닙니다. 서버가 제공하는 매개변수와 클라이언트에서 사용하는 코어, 빌드 지원 여부를 함께 확인해야 합니다. UDP 포워딩도 진입점, 아웃바운드 프로토콜, 원격 서비스가 모두 지원해야 합니다. 웹페이지가 열린다는 사실은 해당 웹 연결이 된다는 것만 보여 줍니다.

YAML은 구조화된 텍스트 형식입니다. 같은 들여쓰기는 같은 계층을 나타내며, 콜론 뒤에는 보통 공백이 필요하고 목록 항목은 하이픈으로 시작합니다. 들여쓰기에는 탭 대신 공백을 사용하세요. 주석에는 한국어를 쓸 수 있지만 필드 구문에 전각 콜론이나 스마트 따옴표가 들어가지 않도록 주의해야 합니다. 수정 후에는 클라이언트의 설정 검사 기능을 먼저 실행한 다음 실행 중인 코어에 적용하세요.

학습을 시작할 때는 안정적인 테스트 페이지, 정상 작동이 확인된 설정 파일, 명확한 복구 방법을 준비하세요. 시스템 프록시와 TUN 중 무엇을 사용하는지, 현재 모드와 선택된 프록시 그룹도 기록해 두세요. 문제가 생기면 한 번에 하나의 변수만 바꾸세요. 용어의 뜻을 확인하려면 먼저 용어집을 살펴본 뒤 이 장의 연결 경로를 따라 어느 계층에서 문제가 발생했는지 확인하세요.

선택 및 설치: 플랫폼, 아키텍처, 권한

먼저 다운로드 센터에서 운영체제를 선택하고 CPU 아키텍처를 확인하세요. 이 사이트에서는 Clash Plus를 우선 추천합니다. 데스크톱에서는 사용 방식에 따라 Clash Verge Rev 또는 FlClash를 선택할 수도 있습니다. Windows용으로는 Clash Nyanpasu도 있습니다. 클라이언트마다 인터페이스와 설정 병합 방식이 다릅니다. 여러 프로그램을 동시에 설치하고 네트워크 트래픽 처리 기능까지 켜기보다는 하나를 선택해 기본 동작부터 확인하는 편이 관리하기 쉽습니다.

운영체제와 유지 관리 상태에 맞춰 선택하세요

macOS에서는 Clash Plus, Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. Android에서는 Clash Plus, Clash Meta for Android, FlClash 또는 Surfboard를 사용할 수 있지만 Surfboard는 설정 체계가 다르므로 Mihomo YAML을 바로 가져올 수 있다고 가정하면 안 됩니다. iOS용 Clash Plus는 App Store에서 설치하세요. 공식 사이트는 clashplus.io입니다. 클라이언트를 옮길 때는 파일 확장자만 비교하지 말고 구독에서 어떤 형식으로 설정을 제공하는지 먼저 확인하세요.

Linux 다운로드 페이지에는 Clash Verge Rev와 FlClash가 있습니다. 설치하기 전에 배포판에서 사용하는 패키지 형식을 확인하세요. Clash for Windows와 ClashX Meta는 지원이 중단된 보관용 선택지이므로 신규 사용자의 기본 선택으로는 적합하지 않습니다. Mihomo 코어 패키지는 설정과 프로세스를 직접 관리할 수 있는 사용자를 위한 것입니다. 일반적인 데스크톱 사용에는 GUI 클라이언트를 권장합니다.

환경	설치 전 확인	최초 실행 시 확인
Windows	시스템 아키텍처 및 설치 패키지 지원 범위	로컬 리스닝 포트 및 서비스 권한
macOS	Apple Silicon 또는 Intel	앱 출처, 보조 서비스 또는 네트워크 권한
Android	CPU 아키텍처 및 시스템 지원 범위	VPN 권한 및 백그라운드 실행 제한
Linux	패키지 형식, 아키텍처, 데스크톱 환경	의존성, 서비스 권한, 프록시 설정

최소 구성으로 설치하기

설치 전에 다른 프록시나 VPN 프로그램을 종료하고 자동 트래픽 처리 옵션도 끄세요. 데스크톱 설치 패키지는 시스템의 설치 절차를 따르세요. 포터블 패키지는 쓰기 권한이 있는 고정된 폴더에 풀고, 압축 파일 안에서 바로 실행하지 마세요. 처음 열면 설정, 프록시, 로그, 설정 메뉴를 찾아 두세요. 시작 프로그램 등록, LAN 공유, 복잡한 자동 업데이트 작업은 일단 켜지 않는 것이 좋습니다.

Windows에서는 일반 시스템 프록시 사용과 TUN 서비스 설치에 서로 다른 권한이 필요할 수 있습니다. 설치 프로그램이나 신뢰할 수 있는 클라이언트가 명확히 요청할 때만 권한을 허용하세요. macOS에서는 먼저 다운로드 출처를 확인한 뒤 시스템 안내에 따라 앱과 보조 서비스 권한을 처리하세요. 특정 앱의 실행 문제를 해결하려고 시스템 보안 기능 전체를 끄지 마세요. 권한을 허용한 후에도 클라이언트로 돌아가 코어가 실제로 실행 중인지 확인해야 합니다.

Android에서 네트워크 트래픽 처리를 켜면 보통 시스템 VPN 권한 요청이 표시됩니다. 허용하면 상태 표시줄에 VPN 아이콘이 나타날 수 있지만, 이것만으로 원격 노드가 작동한다고 볼 수는 없습니다. 같은 기기의 다른 VPN 서비스가 트래픽 처리 권한을 놓고 충돌할 수 있습니다. 먼저 한 서비스만 실행해 연결을 확인한 다음 배터리 최적화 제외와 백그라운드 실행 설정을 조정하세요. 권한 문제와 노드 문제를 혼동하지 않도록 합니다.

설치 후 동작 확인 및 종료

신뢰할 수 있는 설정을 가져온 다음 코어 로그를 확인하세요. 포트가 이미 사용 중이라는 오류가 나오면 이전 클라이언트나 남아 있는 프로세스가 같은 포트를 사용하는지 확인하세요. 정체를 모르는 시스템 프로세스를 함부로 종료하지 마세요. 포트를 바꾸면 그 포트를 참조하는 앱의 프록시 설정도 함께 수정해야 합니다. 로그에 구문 오류가 표시되면 설정 파일을 수정하세요. 프로그램을 계속 재설치해도 잘못된 필드가 고쳐지지는 않습니다.

마지막으로 정상 종료를 테스트하세요. 먼저 시스템 프록시나 TUN을 끄고 클라이언트를 종료한 다음 브라우저가 기존 네트워크로 계속 접속되는지 확인합니다. 종료 후 네트워크 전체에 문제가 생기면 시스템 프록시가 로컬 포트를 계속 가리키는지 살펴보세요. 이 과정까지 끝나야 설치 환경을 제어할 수 있습니다. 시스템 권한 문제는 자주 묻는 질문을 참고하세요. 기존 환경을 다른 클라이언트로 바로 교체할 필요는 없습니다.

구독 및 설정: 가져오기, 업데이트, 로컬 오버라이드

구독 URL은 설정을 배포하는 경로로, 계정 식별 정보나 접근 인증 정보가 포함될 수 있습니다. 비밀번호처럼 안전하게 보관하세요. 신뢰할 수 있는 제공자에게서만 링크를 받고, 공개 채팅이나 스크린샷, 문의 글에 전체 주소를 노출하지 마세요. 가져오기 전에 전체 Clash 설정인지, 노드 목록인지, 특정 형식의 데이터인지 확인하세요. 유형에 따라 클라이언트에서 가져오는 메뉴가 다를 수 있습니다.

가져오기부터 실제 적용까지

설정 관리 화면에서 원격 설정 추가 또는 구독 가져오기를 선택하고 전체 URL을 붙여넣어 저장하세요. 다운로드가 완료되면 설정 이름, 업데이트 시각, 파싱 메시지를 확인한 뒤 현재 설정으로 지정합니다. 일부 클라이언트는 다운로드, 선택, 적용을 각각 따로 수행합니다. 목록에 파일이 보인다고 실행 중인 코어에서 그 파일을 사용한다고 볼 수는 없습니다.

가져오기에 실패하면 먼저 어느 단계에서 오류가 발생했는지 확인하세요. 네트워크 시간 초과는 요청이 정상적으로 완료되지 않았다는 뜻입니다. 인증 실패는 링크가 만료되었을 수 있습니다. 웹페이지가 반환되면 주소가 로그인 페이지나 안내 페이지를 가리킬 수 있고, 파싱 오류는 콘텐츠 형식이 맞지 않을 가능성이 큽니다. 임의의 웹 URL을 구독 변환기에 넣지 말고, 디버깅을 위해 개인 링크를 출처가 불분명한 온라인 도구에 업로드하지 마세요.

적용한 뒤 선택 가능한 프록시 그룹이 나타나는지 확인하고, 확실한 아웃바운드를 하나 선택한 다음 테스트 페이지에 접속하세요. 노드 목록이 비어 있으면 원격 프록시 공급자를 통해 노드가 로드되는지, 해당 리소스가 다운로드되었는지 확인합니다. 기본 설정 파싱 성공과 원격 리소스 가져오기는 별개의 과정이므로 오류 메시지와 로그를 각각 살펴봐야 합니다.

원격 파일과 실행 중인 설정 구분하기

GUI 클라이언트는 원격 구독, 로컬 오버라이드, 인터페이스 설정을 합쳐 최종 설정을 만드는 경우가 많습니다. 구독 파일에 적힌 포트와 실제 실행 포트가 다르다면 인터페이스 옵션이 값을 덮어쓴 것일 수 있습니다. 문제를 확인할 때는 클라이언트가 제공하는 실행 설정이나 병합 결과를 살펴보세요. 여기에 민감한 정보가 포함될 수 있으니 주의하고, 다운로드한 파일만 보고 현재 동작을 추정하지 마세요.

계속 유지할 사용자 규칙은 클라이언트에서 지원하는 오버라이드, 병합 또는 확장 설정에 두는 것이 좋습니다. 원격으로 다운로드한 파일을 직접 수정하면 다음 업데이트에서 변경 내용이 사라질 수 있습니다. 클라이언트마다 병합 방식이 다르므로 목록을 추가하는지 전체 교체하는지 반드시 확인하세요. 먼저 결과를 쉽게 확인할 수 있는 테스트 규칙 하나를 추가해 위치와 적용 결과를 확인한 뒤 실제 규칙을 옮기세요.

# 규칙 예시: 기존 설정의 rules 목록 맨 앞에 병합
# example.com은 문서용 예시 도메인입니다
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

이 예시는 규칙 한 개만 보여 주며 노드나 전체 네트워크 설정은 포함하지 않습니다. 구독 전체를 이 내용으로 덮어쓰지 마세요. rules가 이미 있다면 같은 YAML 맵에 같은 이름의 필드를 다시 작성하지 말고 클라이언트의 병합 방식에 맞춰 항목을 추가하세요. 편집기가 저장을 완료했다는 사실만으로 규칙이 적용됐다고 판단하지 말고 연결 세부 정보에서 확인하세요.

업데이트와 백업 순서 정하기

업데이트 간격은 제공자의 권장 사항과 클라이언트 기능에 따라 정하세요. 간격을 지나치게 짧게 설정해도 노드가 더 안정적으로 작동하지 않으며, 오히려 서버의 요청 제한에 걸릴 수 있습니다. 하루에 한 번 확인하는 정도로 시작하고, 중요한 작업 전에는 직접 업데이트한 뒤 결과를 확인하세요. 노드 구독, 원격 규칙 공급자, 클라이언트 프로그램은 각각 업데이트 주기가 다르므로 하나가 성공했다고 모든 구성요소가 업데이트된 것은 아닙니다.

업데이트 전에 이전에 정상 작동한 설정을 보관하고 현재 프록시 그룹 선택도 기록하세요. 업데이트로 노드가 삭제되거나 이름이 바뀌면 기존 선택이 유효하지 않을 수 있습니다. 업데이트 후에는 설정 파싱 여부를 먼저 확인하고 자주 사용하는 웹사이트와 UDP가 필요한 앱을 테스트하세요. 문제가 생기면 먼저 이전 설정을 복원해 네트워크가 회복되는지 확인한 다음 차이를 비교하세요. DNS를 바꾸면서 프로그램까지 재설치하지 마세요.

여러 기기에서 같은 링크를 쓸 때는 서비스의 기기 수 제한과 클라이언트 형식도 확인하세요. 설정 백업에는 구독 URL뿐 아니라 로컬 오버라이드, 프록시 그룹 선택, 예약 작업도 포함될 수 있습니다. 여러 기기 간 설정 동기화 안내를 참고하세요. 동기화하기 전에 원격에서 관리할 항목과 현재 기기에만 적용할 항목을 구분해야 합니다.

프록시 모드: 규칙, 전역, 직접 연결 확인

프록시 모드는 코어에 들어온 요청이 어떤 아웃바운드를 사용할지 결정하며, 요청을 코어로 보내 주는 기능은 아닙니다. 시스템 프록시나 TUN은 진입점이고 규칙, 전역, 직접 연결은 그 다음의 처리 방식입니다. 먼저 앱이 트래픽을 전달하는지 확인한 뒤 모드를 바꿔 차이를 살펴보세요. 연결 목록에 요청이 전혀 나타나지 않는다면 모드를 바꿔도 진입점 문제는 해결되지 않습니다.

세 가지 모드의 차이

규칙 모드는 설정에 작성된 순서에 따라 요청을 처리하며, 대상별로 다른 정책을 적용할 때 적합합니다. 전역 모드는 보통 코어에 들어온 요청을 전역 프록시 그룹으로 보내므로 문제 범위를 임시로 좁힐 때 유용합니다. 직접 연결 모드는 요청을 대상에 바로 연결합니다. 직접 연결을 선택해도 클라이언트가 종료되는 것은 아닙니다. TUN과 로컬 리스너는 계속 실행될 수 있고, 모드 이름만으로 DNS 동작을 알 수는 없습니다.

처음에는 규칙 모드에서 확실한 노드를 하나 선택하고 자동 지연 테스트 그룹에 바로 맡기지 마세요. 페이지가 열리지 않으면 전역 모드로 잠시 바꾸고 전역 그룹에서 해당 노드를 선택했는지 확인할 수 있습니다. 전역 모드에서는 되지만 규칙 모드에서는 안 된다면 규칙 적용 결과와 프록시 그룹 참조를 먼저 살펴보세요. 두 모드 모두 실패하면 노드, DNS, 로컬 네트워크를 확인하세요.

모드	주요 동작	문제 해결 시 확인 사항
규칙	설정 순서에 따라 규칙 적용	일치한 규칙과 최종 아웃바운드
전역	전역 프록시 그룹 사용	전역 그룹에서 실제 선택한 항목
직접 연결	요청을 대상에 직접 연결	로컬 네트워크에 연결할 수 있는지

시스템 프록시 설정과 모드 구분하기

시스템 프록시를 켠 뒤 시스템 설정을 따르는 브라우저로 먼저 테스트하세요. 브라우저 확장 프로그램, 사용자 지정 프록시 설정, 별도 프로필이 시스템 설정을 덮어쓸 수 있습니다. 명령줄 도구는 시스템 프록시 패널이 아니라 프록시 환경 변수를 사용할 수도 있습니다. 따라서 브라우저에서 접속된다고 터미널도 프록시에 연결됐다고 볼 수는 없습니다. 클라이언트의 전체 켜기/끄기 상태만 보지 말고 앱마다 진입점을 확인하세요.

로컬 HTTP 프록시를 테스트하려면 혼합 포트가 7890인지 확인한 다음 아래 명령을 실행하세요. 포트가 다르면 실제 값으로 바꾸면 됩니다. 이 명령은 현재 요청에서만 프록시를 명시적으로 사용합니다. 다른 프로그램의 전역 환경을 설정하거나 UDP 트래픽을 처리하지는 않습니다. 대상은 문서용 예시 도메인이며 결과는 현재 네트워크와 선택한 아웃바운드에 따라 달라집니다.

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

명령 실행과 함께 연결 세부 정보를 확인하세요. 요청이 표시되고 아웃바운드도 분명하게 나온다면 진입 경로가 구성된 것입니다. 연결이 거부되면 리스닝 포트와 코어 실행 상태를 먼저 확인하세요. 프록시 진입점에는 연결되지만 원격 연결이 시간 초과되면 아웃바운드 로그를 살펴보세요. 터미널 오류를 모두 노드 장애로 단정하지 마세요. 인증서, 시스템 시간, 도메인 확인 문제도 따로 발생할 수 있습니다.

테스트 조건을 일정하게 유지하기

테스트할 때는 앱, 대상 주소, 노드를 고정하고 모드만 하나씩 바꾸면서 최종 아웃바운드를 기록하세요. 브라우저 캐시나 기존 연결 때문에 이전 경로가 계속 사용될 수 있습니다. 필요한 경우 해당 페이지를 닫거나 연결을 끊은 뒤 다시 요청하세요. 한 번의 테스트에서 노드와 DNS를 바꾸고 TUN까지 켜지 마세요. 접속이 다시 되더라도 어떤 설정이 효과가 있었는지 알 수 없습니다.

노드 지연 시간 테스트는 특정 테스트 대상에 대한 한 번의 측정일 뿐, 모든 웹사이트의 종합 속도를 나타내지 않습니다. 지연 시간이 측정돼도 대상 서비스에 접속할 수 있다는 뜻은 아니며 UDP 포워딩 성공을 증명하지도 않습니다. 대용량 다운로드, 동영상 연결, 실시간 게임은 네트워크 특성이 서로 다릅니다. 해당 앱으로 직접 검증하고 서버 제한, 출구 정책, 로컬 네트워크 변화도 고려하세요.

문제 해결을 마치면 규칙 모드로 되돌린 뒤 자주 사용하는 사이트가 예상한 프록시 그룹으로 들어가는지 확인하세요. 프린터, 라우터 관리 페이지, 개발 서버처럼 로컬 접속이 필요한 대상도 테스트 목록에 포함하세요. 종료 절차를 명확히 해 두세요. 먼저 시스템 프록시나 TUN을 끈 다음 프로그램을 종료합니다. 반복 가능한 테스트 절차는 다음 장에서 규칙을 수정할 때 기준이 됩니다. 웹페이지가 가끔 열린다는 이유만으로 설정이 올바르다고 판단해서는 안 됩니다.

규칙 기반 라우팅: 적용 순서, 프록시 그룹, 규칙 공급자

규칙 모드에서 Mihomo는 위에서 아래로 규칙을 확인하고 처음 일치한 규칙에 따라 요청을 처리합니다. 규칙이 많다고 라우팅이 더 정확해지는 것은 아닙니다. 순서와 범위가 중요합니다. 앞쪽에 범위가 넓은 도메인 규칙이 있으면 뒤에 있는 구체적인 규칙이 적용되지 않을 수 있습니다. 수정하기 전에 어떤 앱이 어떤 대상에 접속하는지, 어떤 아웃바운드를 원하는지, 무엇으로 결과를 확인할지 정하세요.

결과를 확인하기 쉬운 규칙부터 시작하기

DOMAIN은 도메인 전체가 일치하는지 확인하고, DOMAIN-SUFFIX는 도메인 접미사와 하위 도메인에 적용됩니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드로 일치 여부를 판단합니다. 키워드 규칙은 범위가 지나치게 넓어지기 쉽습니다. 처음에는 명확한 도메인이나 접미사 규칙을 사용하세요. 웹페이지 전체 URL을 도메인 필드에 넣지 마세요. 규칙에는 보통 프로토콜, 경로, 쿼리 매개변수가 포함되지 않습니다.

IP-CIDR 같은 주소 규칙은 대상 IP 대역을 기준으로 적용됩니다. GEOIP는 해당 데이터에 의존하며 대상 IP의 데이터베이스상 위치를 기준으로 하며 회사의 등록 국가를 뜻하지는 않습니다. MATCH는 나머지 요청에 적용되는 기본 규칙이므로 목록 맨 아래에 두세요. 너무 앞에 두면 뒤의 규칙은 적용되지 않습니다. IP 주소 규칙을 작성할 때 도메인 확인이 필요한지도 살펴보세요. 주소 일치를 위해 불필요한 DNS 요청이 발생할 수 있습니다.

# 학습 예시: 정확한 항목, 주소 항목, 기본 규칙의 순서
# 이 예시의 모든 요청은 직접 연결되며 원격 프록시 기능은 제공하지 않습니다
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

no-resolve는 해당 IP 주소 규칙을 위해 도메인 확인을 따로 실행하지 않도록 합니다. 설정 전체의 DNS를 끄는 옵션은 아니며 모든 LAN 트래픽이 이 IP 대역 규칙에 맞게 처리된다는 뜻도 아닙니다. 가정, 사무실, 컨테이너 네트워크의 대역은 서로 다를 수 있으므로 추가하기 전에 실제 라우팅을 확인하세요. 예시 마지막에 DIRECT를 쓴 것은 구문을 보여 주기 위한 것이므로 프록시 아웃바운드가 필요한 전체 설정에 그대로 덮어쓰면 안 됩니다.

규칙이 안정적인 프록시 대상으로 연결되도록 설정하기

규칙의 마지막 필드에는 기본 동작이나 기존 프록시 그룹 이름을 지정할 수 있습니다. 참조하는 그룹 이름은 공백과 대소문자까지 설정에 적힌 값과 정확히 일치해야 합니다. 일반적으로 규칙은 안정적인 프록시 그룹을 가리키게 하고 그룹 안에서 노드를 바꾸는 편이 여러 규칙을 특정 노드에 직접 연결하는 것보다 관리하기 쉽습니다. 구독 업데이트로 노드가 삭제되어도 안정적인 그룹 이름을 사용하면 수정할 곳이 줄어듭니다.

직접 선택하는 그룹은 아웃바운드를 확인할 때 적합하고, 자동 테스트 그룹은 정해진 후보 중 테스트 결과에 따라 선택할 때 적합합니다. 어느 한쪽이 항상 더 낫다고 볼 수는 없습니다. 자동 그룹의 테스트 주소, 간격, 후보 범위에 따라 결과가 달라집니다. 프록시 그룹이 다른 그룹을 참조할 수도 있으므로 연결 세부 정보에 표시된 그룹 이름이 실제 원격 노드와 다를 수 있습니다. 문제 해결 시 그룹 선택을 따라가며 확인하세요.

원격 규칙 공급자의 범위 이해하기

규칙 공급자는 rule-providers에서 선언한 뒤 규칙의 RULE-SET으로 참조합니다. 동작 유형과 파일 내용이 서로 맞아야 합니다. 도메인 목록, IP 주소 목록, 클래식 형식은 임의로 섞어 사용할 수 없습니다. 다운로드 실패, 경로 쓰기 권한 부족, 콘텐츠 형식 오류로 로드가 실패할 수 있습니다. 규칙 공급자 이름이 표시된다고 내부 항목까지 사용할 수 있는 것은 아닙니다.

대규모 규칙 모음은 용도별 관리에 적합하지만 추가하기 전에 출처, 업데이트 주기, 적용 범위를 확인해야 합니다. 중요한 로컬 규칙 몇 개를 유지한 상태에서 원격 규칙 모음을 하나씩 추가하고 로그와 적용 결과를 확인하세요. 범위가 겹치는 규칙 모음을 여러 개 한꺼번에 추가한 다음 문제를 찾으려 하면 앞선 규칙이 요청을 가로챘는지, 규칙 내용이 바뀌었는지, 최종 프록시 그룹 선택이 잘못됐는지 구분하기 어렵습니다.

규칙을 검증하려면 대상 페이지를 열고 연결에 표시된 도메인, 규칙, 아웃바운드를 확인하세요. 웹페이지는 이미지, 로그인, API 등 여러 도메인에 요청을 보낼 수 있습니다. 주요 도메인이 올바른 규칙에 맞더라도 모든 리소스의 경로가 같다고 볼 수는 없습니다. 일부 콘텐츠만 누락된다면 실패한 요청의 도메인을 추적하세요. 앱 전체를 장기간 전역 모드로 전환하는 것으로 해결하려고 하지 마세요.

로컬 규칙을 수정할 때는 필드 이름을 반복하는 대신 대상과 이유를 짧은 주석으로 남기세요. 설정을 업데이트할 때마다 사용자 규칙이 예상한 위치에 있는지 확인합니다. DNS 관련 문제는 DNS 설정 절에서 이어서 살펴보세요. 코어에 도메인이 표시되지 않는다면 도메인 규칙을 더 추가하는 것만으로는 해결되지 않을 수 있습니다. 먼저 요청 진입점과 DNS 확인 경로를 점검하세요.

TUN 트래픽 처리: 라우팅, DNS, UDP의 범위

TUN은 가상 네트워크 인터페이스로 트래픽을 받아 코어에 전달하며 시스템 프록시를 따르지 않는 앱에 적합합니다. 트래픽 처리 방식만 바꿀 뿐 노드, 규칙, 원격 서버 기능을 대체하지는 않습니다. 켜기 전에 시스템 프록시에서 정상 작동하는 설정을 확인하고 현재 DNS, 다른 VPN, 가상 네트워크 인터페이스 상태를 기록하세요. 이를 기준으로 삼아야 새로 발생한 문제를 트래픽 처리 계층으로 좁힐 수 있습니다.

필요한 서비스를 설치한 뒤 기능을 켜세요

데스크톱 클라이언트는 인터페이스 생성과 라우팅 변경에 필요한 권한을 서비스 모드나 보조 프로세스로 얻을 수 있습니다. 구체적인 메뉴는 클라이언트마다 다릅니다. 먼저 화면 안내에 따라 서비스를 설치하고 상태가 정상인지 확인한 뒤 TUN을 켜세요. Android는 보통 시스템 VPN 권한으로 트래픽을 처리합니다. 모든 클라이언트의 권한 방식이 같다고 가정하지 마세요. 스위치를 누를 수 있다는 이유만으로 실제 인터페이스가 만들어졌다고 볼 수도 없습니다.

처음 켤 때는 기본 네트워크 스택 설정을 유지하고 엄격한 라우팅, 복잡한 제외 목록, 여러 DNS 업스트림을 한꺼번에 추가하지 마세요. 일반 웹페이지를 먼저 확인한 뒤 시스템 프록시로 처리할 수 없었던 앱을 테스트하세요. 코어 로그에 권한 부족이나 인터페이스 생성 실패가 표시되면 서비스와 시스템 권한부터 해결해야 합니다. 이때 노드를 바꿔도 가상 인터페이스 문제는 해결되지 않습니다.

# TUN 설정 예시: 이미 작동하는 설정에 병합해야 합니다
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  dns-hijack:
    - any:53

이 예시는 일반적인 필드를 보여 주며 모든 시스템에서 동작한다고 보장하지 않습니다. 클라이언트 인터페이스가 필드 값을 덮어쓸 수도 있으므로 적용 후 실제 실행 설정을 확인하세요. auto-route는 관련 경로를 자동 설정하고, auto-detect-interface는 아웃바운드 인터페이스 선택을 지원합니다. 네트워크 카드가 여러 개이거나 가상 머신, 특수 전화 접속 환경에서는 추가 확인이 필요할 수 있습니다. 네트워크 스택의 지원 여부와 동작은 플랫폼에 따라 다릅니다.

자동 라우팅과 엄격한 라우팅 이해하기

자동 라우팅은 조건에 맞는 요청을 TUN으로 전달하지만 기기의 모든 연결이 반드시 처리된다는 뜻은 아닙니다. 라우팅 우선순위, 제외 항목, 앱의 인터페이스 지정, 다른 VPN이 결과에 영향을 줄 수 있습니다. 엄격한 라우팅은 처리 범위를 제한하며 운영체제에 따라 라우팅이나 제한 방식이 달라집니다. 속도를 높이는 옵션이 아니며 모든 문제를 해결하기 위해 기본으로 켜야 하는 기능도 아닙니다.

엄격한 라우팅을 켜기 전에 LAN 접속, 시스템 인터넷 연결 확인, 회사 네트워크에 필요한 연결을 테스트하세요. 프린터에 연결되지 않거나 사내 서비스에 접속할 수 없다면 최근 추가한 라우팅 옵션을 먼저 끄고 문제가 사라지는지 확인한 다음 실제 네트워크 대역에 맞춰 예외를 설정하세요. 경험만 믿고 많은 IP 대역을 한꺼번에 제외하면 원래 처리하려던 트래픽까지 우회될 수 있습니다.

DNS와 UDP를 각각 검증하기

dns-hijack는 조건에 맞는 기존 DNS 요청을 코어의 DNS 처리 경로로 보냅니다. 예시는 포트 53 요청을 대상으로 하며 앱 자체의 암호화 DNS를 자동으로 복호화하지는 않습니다. 브라우저의 보안 DNS나 앱 내장 DNS는 다른 경로를 사용할 수 있습니다. 켠 뒤 도메인 접속에 문제가 생기면 TUN 스위치만 보지 말고 DNS 진입점과 연결 진입점을 따로 점검하세요.

UDP는 실제로 필요한 앱으로 검증하세요. 노드 설정에서 UDP를 허용하더라도 서버와 중간 네트워크가 필요한 전송을 모두 지원한다는 뜻은 아닙니다. 게임에 접속할 수 없다면 연결이 코어에 들어오는지, 규칙에서 필요한 기능을 지원하는 아웃바운드를 선택했는지, 원격에서 데이터가 돌아오는지 확인하세요. 웹페이지 접속이나 지연 시간 테스트로 이런 검증을 대신할 수 없으며 실시간 서비스의 안정성도 보장되지 않습니다.

절전 모드에서 복귀하거나 Wi-Fi 네트워크를 바꾸거나 유선 네트워크 카드를 연결하면 아웃바운드 인터페이스와 기본 경로가 달라질 수 있습니다. 네트워크를 바꾼 뒤에만 실패한다면 먼저 트래픽 처리를 재시작하거나 클라이언트 방식에 따라 인터페이스를 다시 만들고 로그를 비교하세요. 자주 사용하는 네트워크에서 TUN을 안정적으로 켜고 끌 수 있는지 확인한 뒤 시작 시 자동 실행을 고려하세요. 라우터와 서버 배포에는 포워딩, 방화벽, 응답 경로도 관련되므로 별도 작업으로 다뤄야 합니다. 데스크톱 예시를 그대로 적용하지 마세요.

유지 관리: 업데이트, 로그, 문제 발생 시 복구

안정적인 사용을 위해서는 환경을 자주 새로 구성하기보다 변경 내용을 추적할 수 있어야 합니다. 정상 작동하는 설정, 필요한 로컬 오버라이드, 현재 트래픽 처리 방식을 기록해 두세요. 클라이언트, 코어, 구독, 규칙 공급자, 지리 데이터는 서로 다른 업데이트 대상이며 각기 다른 메뉴에서 관리할 수 있습니다. 업데이트 버튼 하나가 성공했다고 모든 구성요소가 바뀌거나 설정 동작이 그대로라고 볼 수는 없습니다.

순서에 맞춰 업데이트하기

클라이언트를 업데이트하기 전에 변경 사항을 읽고 운영체제 호환성과 설정 마이그레이션 안내를 확인하세요. 설정을 내보내거나 백업한 다음 네트워크 트래픽 처리를 정상적으로 종료하고 설치를 진행합니다. 업데이트 후에는 기존 설정이 로드되는지, 리스닝 포트가 유지되는지 확인한 뒤 시스템 프록시와 TUN을 테스트하세요. 클라이언트에 코어 별도 업데이트 기능이 있다면 프로그램과 코어를 같은 테스트에서 동시에 바꾸지 마세요.

구독을 업데이트한 뒤 노드와 그룹 이름의 변경을 확인하고, 규칙 공급자를 업데이트한 뒤 주요 대상에 어떤 규칙이 적용되는지 확인하세요. 원격 리소스 다운로드가 성공해도 내용이 예상과 다를 수 있고 경로 권한 문제로 이전 데이터가 계속 사용될 수도 있습니다. 로그와 업데이트 시각을 함께 확인하세요. 중요한 작업 전에 여러 구성요소를 한꺼번에 업그레이드하지 않는 편이 좋습니다. 동시 업데이트보다 결과를 확인하고 복구할 시간을 확보하는 것이 실용적입니다.

진입점, DNS 확인, 규칙, 아웃바운드 순서로 점검하기

먼저 일반 네트워크에서 접속할 수 있어야 하는 대상에 연결되는지 확인한 다음 코어 프로세스와 로컬 리스너를 확인하세요. 이후 실패한 요청이 연결 목록에 나타나는지 살펴봅니다. 기록이 전혀 없다면 앱 프록시 설정이나 TUN을 확인하고, 기록이 있다면 도메인 확인, 규칙 적용, 선택된 아웃바운드를 점검하세요. 마지막으로 원격 핸드셰이크와 대상 서비스 응답을 확인합니다. 이 순서로 살펴보면 시스템 프록시 설정이 남아 있는 문제를 서버 장애로 오인하지 않을 수 있습니다.

로그에 연결 거부가 표시되면 보통 대상 포트에서 연결을 받아들이지 않은 것입니다. 시간 초과는 제한 시간 내에 작업이 완료되지 않았다는 뜻이고, 이름 확인 실패는 도메인 처리 단계의 문제를 가리킵니다. 정확한 원인은 오류에 나온 주소, 포트, 단계와 함께 판단해야 합니다. 인증서 오류는 시스템 시간이나 서버 이름과 관련될 수도 있습니다. 마지막 오류 한 줄만 복사하지 말고 같은 시간대의 앞뒤 기록도 남기세요.

문제 해결 중에는 로그 상세 수준을 잠시 높이고 작업이 끝나면 평소 수준으로 되돌려 저장 공간과 개인정보 노출을 줄이세요. 로그를 공유하기 전에 구독 URL, 인증 정보, 제어 인터페이스 자격 증명, 개인을 식별할 수 있는 내용을 삭제하세요. 스크린샷에도 전체 노드 주소나 계정 정보가 보일 수 있습니다. 문제를 설명할 때는 오류 유형, 발생 시각, 필요한 네트워크 단계만 남기는 것이 좋습니다.

증상	먼저 확인	지금은 하지 않기
종료 후 웹페이지가 열리지 않음	시스템 프록시가 여전히 로컬 포트를 가리키는지	모든 DNS를 바로 변경하기
전역 모드에서는 되지만 규칙 모드에서는 실패	적용된 규칙과 프록시 그룹 선택	클라이언트를 반복해서 재설치하기
TUN을 켠 뒤 문제가 발생함	권한, 인터페이스, 라우팅 변경	구독과 규칙을 동시에 교체하기
일부 도메인에만 접속할 수 없음	DNS 응답과 실패한 리소스의 도메인	네트워크 전체를 계속 전역 모드로 사용하기

변경의 영향을 되돌려 확인하기

업데이트 후 문제가 생기면 이전 설정을 복원하고 필요하다면 이전 트래픽 처리 설정도 되돌리세요. 네트워크가 복구되면 차이를 하나씩 비교합니다. 복원 후에도 문제가 계속되면 로컬 네트워크, 서버 또는 다른 외부 요인일 수 있습니다. 되돌리기는 최종 해결책이 아니라 문제가 이번 변경과 관련 있는지 확인하는 방법입니다. 설정 파일의 텍스트 차이를 비교하면 기억에 의존해 필드를 찾는 것보다 정확합니다.

휴대폰의 백그라운드 연결 끊김은 운영체제의 앱 종료, 네트워크 전환, 원격 시간 초과를 구분해야 합니다. 앱으로 돌아오자마자 연결이 복구되는 경우에 백그라운드 제한과 배터리 최적화를 살펴보는 것이 좋습니다. 데스크톱이 절전 모드에서 깨어난 뒤 문제가 생기면 인터페이스, DNS, 라우팅 복구를 확인하세요. 테스트할 때 기기 상태와 발생 시점을 기록하고 간헐적인 문제를 모두 같은 설정 탓으로 돌리지 마세요.

도움을 요청할 때는 플랫폼, 클라이언트 이름, 트래픽 처리 방식, 실패한 대상의 유형, 최근 변경 사항, 이미 해 본 테스트를 알려 주세요. 인터넷이 안 된다는 말만으로는 원인을 찾기 어렵습니다. 연결됐지만 웹페이지가 열리지 않을 때 확인할 목록에 따라 정보를 정리하고 자주 묻는 질문에서 관련 항목을 찾아보세요. 재현 가능한 최소 사례가 개인 설정 파일 전체보다 문제를 논의하기에 적합합니다.

DNS 및 고급 설정: 이름 확인 경로, 제어 인터페이스, 배포

앞의 장을 마친 뒤 DNS와 자동화를 별도 주제로 학습하세요. DNS는 도메인의 IP 주소를 찾는 기능에 그치지 않고 규칙에서 확인할 수 있는 정보, 연결 대상, 네트워크 경로에도 영향을 줍니다. 설정을 바꾸기 전에 시스템 DNS, 브라우저 보안 DNS, 클라이언트 DNS, TUN DNS 하이재킹 설정을 기록하세요. 요청을 누가 받아 누구에게 질의하는지 흐름을 정리하면 여러 DNS 계층이 서로 우회하는 상황을 피할 수 있습니다.

Fake-IP와 업스트림 DNS의 역할

fake-ip 모드는 앱에 매핑 주소를 돌려주고 코어가 이를 이용해 도메인과 이후 연결을 연결합니다. 실제 대상이 존재하지 않는다는 뜻도, 원격 서버의 주소라는 뜻도 아닙니다. redir-host는 실제 DNS 확인 결과를 앱에 전달합니다. 두 방식은 호환성과 규칙에서 사용할 수 있는 정보가 다르므로 특정 모드를 모든 기기의 정답으로 여기지 말고 앱과 트래픽 처리 방식에 맞춰 검증하세요.

아래는 기존 설정에 병합할 DNS 예시입니다. 루프백 리스너는 로컬 수신 범위를 제한합니다. TUN이나 클라이언트가 자체 DNS 연결 방식을 사용한다면 필요한 설정을 유지하고 무리하게 덮어쓰지 마세요. 예시의 업스트림 DNS는 현재 네트워크에서 연결할 수 있어야 합니다. 먼저 DNS 요청이 정상적으로 완료되는지 확인한 뒤 라우팅과 대체 정책을 살펴보세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

nameserver는 일반 DNS 업스트림 목록입니다. 주소를 여러 개 입력한다고 순서대로 하나씩 전환된다고 단정할 수 없습니다. 도메인 형식의 암호화 DNS를 사용한다면 해당 업스트림 도메인을 확인할 초기 DNS 경로도 고려해야 합니다. 노드 서버 주소가 도메인인 경우에도 연결 전에 먼저 이름을 확인해야 합니다. 노드 연결을 위해 필요한 DNS 요청이 아직 연결되지 않은 노드에 의존하도록 설정하면 안 됩니다.

fallback과 fallback-filter는 대체 DNS와 결과 선택 조건을 설정하는 항목이지, 요청이 실패할 때마다 다른 주소로 자동 전환하는 기능은 아닙니다. 여러 업스트림을 무작정 추가하지 말고 실제 DNS 요구사항에 맞춰 구성하세요. 일부 LAN 도메인이나 특정 앱은 매핑 주소와 호환되지 않을 수 있습니다. fake-ip-filter 사용을 검토할 수 있지만, 먼저 DNS 모드가 문제의 원인인지 확인한 뒤 범위를 명확히 지정해 예외를 추가하세요.

모드를 바꾼 뒤에도 앱이 이전 주소를 캐시하거나 브라우저가 기존 연결을 유지할 수 있습니다. 새로 요청을 만들어 시스템과 클라이언트에서 제공하는 방법으로 관련 캐시를 처리하세요. 이전 상태를 새 설정의 결과로 오해하지 않도록 합니다. 매개변수 간 관계는 nameserver, fallback, DNS 하이재킹 안내에서 자세히 확인하세요. 새로운 DNS 경로는 한 번에 하나씩 추가하세요.

제어 인터페이스와 LAN 접근

외부 제어 인터페이스에서는 상태 조회와 관리 작업을 할 수 있으므로 기본적으로 로컬에서만 접근하도록 제한하세요. 원격 관리를 고려하기 전에 접근 인증 정보를 설정해야 합니다. 제어 포트를 인터넷에 직접 노출하지 마세요. 다른 기기에서 로컬 프록시를 사용하도록 허용할 때도 리스닝 주소, 인증, 시스템 방화벽을 확인하세요. LAN 접근은 스위치 하나만 켜면 되는 문제가 아니며 실제로 어떤 출처에서 연결할 수 있는지까지 고려해야 합니다.

설정, 로그, 백업에는 민감한 필드가 포함될 수 있습니다. 비공개 저장소도 적절한 접근 제어가 필요합니다. 자동 동기화를 설정하기 전에 공유하면 안 되는 기기 설정을 제외해 서로 다른 기기의 포트, 라우팅, 권한 설정이 섞이지 않게 하세요. 자동화 작업은 실패를 알리고 이전에 정상 작동한 상태를 보존해야 합니다. 잘못된 웹페이지를 다운로드했을 때 사용 중인 설정을 그대로 덮어써서는 안 됩니다.

용도에 맞는 다음 학습 경로

데스크톱 사용자는 프록시 그룹과 규칙 공급자 관리로, 모바일 사용자는 네트워크 전환과 백그라운드 안정성 확인으로 학습을 이어갈 수 있습니다. 서버나 라우터 사용자는 서비스 관리, 포워딩, 방화벽을 추가로 다루세요. 서버와 라우터에서는 응답 경로와 트래픽 처리 범위도 확인해야 합니다. 데스크톱 설정을 복사하는 것만으로 배포가 끝났다고 볼 수 없습니다. 코어 명령줄을 사용하기 전에 현재 프로그램의 도움말을 확인하고 설정 검사를 통과했는지 확인하세요.

고급 기능에는 모두 확인 기준이 있어야 합니다. 연결 세부 정보에서 규칙을 설명할 수 있고, DNS 확인 경로를 파악할 수 있으며, TUN을 안정적으로 켜고 끌 수 있고, 업데이트 후 이전 설정을 복원할 수 있어야 합니다. 이 조건을 충족한 뒤 자동 경로 선택이나 원격 관리를 추가하세요. 기본 절차를 다시 확인하려면 빠른 시작 가이드로, 클라이언트를 바꾸려면 다운로드 센터로 돌아가 실제 작업과 학습 단계를 맞추세요.