Clash 사용법 완벽 가이드

단계 01 / 개념 이해

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

화면과 실제 트래픽을 처리하는 프로그램 구분하기

Clash 생태계에서 클라이언트는 일반적으로 창, 트레이 메뉴, 설정 관리 기능을 갖춘 앱을 뜻합니다. 코어는 설정을 읽고 프록시 연결을 만들며, 규칙을 적용하고 DNS를 처리합니다. mihomo는 이 생태계에서 지속적으로 개발되는 코어입니다. 앱의 토글이 코어의 모든 기능을 나타내는 것은 아니며, 같은 코어 기능도 클라이언트마다 이름이 다를 수 있습니다. 안내 화면이 다르다면 똑같은 위치를 찾기보다 설정의 의미부터 확인하세요.

연결을 몇 단계로 나눠 살펴보세요. 앱이 요청을 만들고, 시스템이나 앱 설정에 따라 요청이 로컬 프록시로 전달됩니다. 코어는 현재 모드에 따라 처리 경로를 고르고, 프록시 정책이 실제 출구를 결정합니다. 구독은 설정이나 노드 정보를 제공할 뿐, 이 단계를 대신하지 않습니다. 가져오기에 성공했다면 클라이언트가 설정을 받아들였다는 뜻이고, 프록시가 켜졌다면 진입점이 설정됐다는 뜻입니다. 웹페이지가 열려야 해당 연결 경로가 대체로 정상이라고 볼 수 있습니다. 이 세 가지 상태는 서로 대신할 수 없습니다.

노드, 정책 그룹, 규칙 구분하기

노드에는 서버 주소, 프로토콜, 인증 정보가 포함되며 원격 서버에 연결하는 방법을 나타냅니다. 정책 그룹은 노드나 다른 정책을 묶어 수동 선택, 자동 검사, 장애 조치 등의 기능을 제공합니다. 규칙은 특정 연결을 어떤 정책으로 보낼지 결정합니다. 수동 그룹에서 노드를 골랐다고 해서 모든 연결이 해당 노드를 쓰는 것은 아닙니다. 그 그룹에 일치하는 트래픽에만 선택이 적용됩니다. 문제를 해결할 때는 일치한 규칙과 최종 출구를 모두 확인해야 합니다.

완전한 설정에는 보통 로컬 수신 포트, 프록시 노드, 정책 그룹, 규칙, DNS 등이 포함됩니다. 노드 목록에는 서버 정보만 들어 있을 수도 있습니다. 둘 다 링크로 받을 수 있지만 서로 바꿔 쓸 수 있다고 단정하면 안 됩니다. 클라이언트가 특정 노드 목록을 파싱할 수 있어도, 원하는 방식의 라우팅 규칙까지 자동으로 만들어 주는 것은 아닙니다. 구독 형식을 확인할 때는 제공된 내용이 완전한 Clash 설정인지, 별도로 구성해야 하는 노드 목록인지 확인하세요.

로컬 프록시와 원격 서버를 구분해서 이해하기

로컬 혼합 포트는 앱과 코어가 트래픽을 주고받는 진입점이지, 원격 서버의 포트가 아닙니다. 예시에서는 mixed-port: 7890을 자주 사용하지만 실제 값은 현재 설정과 클라이언트 설정에 따라 다릅니다. 안내에 이 숫자가 나온다고 해서 사용 중인 포트를 그대로 덮어쓰면 안 됩니다. 원격 서비스는 계정 상태, 프로토콜 지원 여부, 네트워크 연결 가능성에도 영향을 받습니다. 로컬 프로그램이 정상 실행된다고 원격 서비스까지 정상인 것은 아닙니다.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 영향을 줍니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리합니다. 둘은 규칙 모드를 대체하는 기능이 아니라 트래픽이 코어로 들어오는 서로 다른 진입점입니다. 진입점과 라우팅을 별개의 축으로 생각하세요. 먼저 요청이 코어에 들어오는지 확인하고, 그다음 어디로 전달되는지 살펴보면 진입점 문제를 규칙 오류로 오해하거나 불필요하게 DNS를 바꾸는 일을 줄일 수 있습니다.

설정하기 전에 운영체제, 클라이언트 이름, 설정 출처, 바꾸려는 네트워크 동작을 기록하세요. 예를 들어 브라우저는 프록시를 사용하고 LAN 기기는 직접 연결하도록 하는 편이 '모든 기능 켜기'보다 확인하기 쉽습니다. 프록시 소프트웨어가 익명성을 보장하는 것도 아닙니다. 원격 서비스, 대상 웹사이트, 로컬 앱은 각자 관련 데이터를 처리합니다. 신뢰할 수 있는 설정만 가져오고, 현재 위치의 법률과 네트워크 관리 규정을 준수하세요. 필요하지 않은 기기에 네트워크 진입점을 개방하지 마세요.

단계 02 / 도구 선택

클라이언트 선택: 플랫폼과 설정 호환성부터 확인

현재 기기의 사용 방식부터 확인하기

새로 설치한다면 Clash Plus부터 시작하고, 플랫폼에 맞는 설치 파일은 다운로드 페이지에서 선택하세요. 시스템 아키텍처와 지원 버전, 구독 형식, 필요한 권한을 함께 살펴보고 소프트웨어 이름만으로 결정하지 마세요. 데스크톱 클라이언트는 설정 관리와 연결 확인에 편리하고, 모바일은 운영체제의 네트워크 확장 기능이나 VPN 인터페이스에 더 많이 의존합니다. 서버나 라우터에서 장기간 실행해야 한다면 코어를 직접 배포할 수도 있지만, 서비스와 설정을 직접 관리해야 합니다.

Windows 사용자는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu를 차례로 살펴볼 수 있습니다. Clash for Windows는 개발이 중단된 보관용 선택지입니다. Clash for Windows 대체 프로그램을 찾는다면 기존 구독 출처와 사용자 지정 규칙을 먼저 보관한 뒤, 새 클라이언트가 같은 설정을 지원하는지 확인하세요. 이전 프로그램의 디렉터리 구조와 화면 설정을 그대로 가져올 수는 없는 경우가 많습니다. 마이그레이션할 때는 앱 데이터를 통째로 복사하기보다 설정 내용을 옮기는 데 집중하세요.

macOS에서는 Clash Plus, Clash Verge Rev, FlClash를 선택할 수 있습니다. ClashX Meta는 개발이 중단된 보관용 선택지입니다. Apple Silicon과 Intel용 설치 파일을 구분하고, 먼저 시스템 정보에서 칩 종류를 확인하세요. 클라이언트를 바꿀 때는 이전 앱이 로그인 시 계속 실행되는지도 확인해야 합니다. 트레이 앱 두 개가 시스템 프록시를 번갈아 바꾸는 일을 방지할 수 있습니다. 시스템 설정을 일관되게 유지하고 종료 후 복구 동작을 확인하려면 프록시 진입점을 관리하는 앱을 하나로 제한하세요.

모바일과 Linux의 차이 이해하기

Android에서는 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 살펴볼 수 있습니다. Surfboard는 Clash YAML과 다른 설정 체계를 사용하므로 모든 구독 링크를 공통 입력으로 사용할 수는 없습니다. 선택하기 전에 제공자가 안내하는 형식을 확인하세요. 시스템에 VPN 아이콘이 표시되면 로컬 네트워크 인터페이스가 설정됐다는 뜻일 수 있지만, 트래픽이 예상한 프록시 출구에 도달했다는 증거는 아닙니다. 앱의 실제 접속 결과도 확인해야 합니다.

iOS에서는 Clash Plus의 앱 스토어 페이지를 먼저 확인하고 공식 웹사이트 clashplus.io에서 제품 정보를 살펴보세요. 시스템 네트워크 확장, 백그라운드 실행 주기, 앱 샌드박스에 따라 설정 경로가 달라질 수 있으므로 데스크톱의 서비스 설치 절차를 그대로 따라 하면 안 됩니다. Linux 그래픽 데스크톱에서는 Clash Verge Rev를 우선 고려하고 FlClash도 살펴볼 수 있습니다. 배포판에 맞는 패키지 형식을 선택하고, 시스템 프록시 설정과 시스템 전체의 라우팅 처리를 구분하세요.

실제 기능을 기준으로 선택하기

설정에서 최신 프로토콜, 규칙 제공자, DNS 매개변수를 사용한다면 클라이언트에 포함된 코어가 해당 필드를 파싱할 수 있는지 확인하세요. 이름에 Clash가 들어간다고 모든 확장 문법이 똑같이 지원되는 것은 아닙니다. 가져오는 중 '지원하지 않는 필드' 오류가 발생하면 코어 문서와 현재 설정 형식을 먼저 대조하세요. 내용을 무작정 삭제하지 마세요. 매개변수를 지우면 파싱 오류는 사라질 수 있지만 기존 보안 설정이나 라우팅 동작이 바뀔 수 있습니다.

대부분의 새 사용자에게는 토글 수보다 설정을 쉽게 가져올 수 있는지, 오류 메시지가 명확한지, 시스템 프록시를 복구할 수 있는지가 중요합니다. 앱별 라우팅을 확인해야 한다면 연결 상세 정보, 규칙 일치 여부, 프로세스 식별 기능을 우선 살펴보세요. 노트북과 스마트폰은 절전 후 복귀, 네트워크 전환, 백그라운드 정책도 테스트해야 합니다. 실제 필요한 기능부터 정리한 뒤 후보 프로그램 하나를 설치해 확인하면 됩니다. 화면을 비교하려고 모든 클라이언트를 한꺼번에 설치할 필요는 없습니다.

클라이언트를 결정한 후에는 현재 사용할 수 있는 설치 파일과 내보낸 사용자 설정을 보관하고, 구독을 갱신하는 방법도 기록하세요. 마이그레이션할 때는 새 프로그램에서 설정 파싱을 확인한 다음 이전 프로그램의 트래픽 진입점을 끄고 새 프로그램을 활성화하세요. 이 순서를 따르면 연결 끊김과 포트 충돌을 줄일 수 있습니다. 패키지 종류, 플랫폼별 설치 파일, 유지 관리 상태는 다운로드 페이지의 최신 안내를 확인하고 예전 화면을 근거로 판단하지 마세요.

단계 03 / 실행 환경 준비

설치 및 권한: 코어 실행과 포트 사용 여부 확인

일반 실행을 확인한 뒤 고급 권한 설정하기

운영체제 아키텍처에 맞는 설치 파일을 다운로드하고, 실행 중인 다른 프록시 클라이언트를 종료한 뒤 시스템 안내에 따라 설치하세요. 처음 실행할 때는 TUN, LAN 접근, 자동 시작 등을 켜지 말고 화면이 열리는지, 코어가 실행되는지, 설정 화면에 접근할 수 있는지부터 확인하세요. 설치, 설정 파싱, 시스템 트래픽 처리를 각각 나눠 진행해야 문제가 생겼을 때 어느 단계에서 변화가 있었는지 알 수 있습니다. 여러 옵션을 한꺼번에 켜고 반복 시도하지 않아도 됩니다.

Windows에서는 그래픽 인터페이스와 백그라운드 서비스가 별도로 실행될 수 있습니다. TUN이나 일부 시스템 수준 작업에는 클라이언트가 제공하는 서비스 모드 또는 관리자 권한이 필요할 수 있지만, 일반 화면을 항상 최고 권한으로 실행할 필요는 없습니다. 서비스 설치에 실패하면 앱 로그와 시스템 메시지를 확인하고 보안 소프트웨어가 해당 작업을 차단했는지 살펴보세요. 출처가 불분명한 복구 스크립트를 다운로드하거나 설치를 위해 시스템 보호 기능을 전부 끄지 마세요.

macOS에서는 앱을 장기간 사용할 적절한 위치에 둔 뒤 실행하고, 출처 확인과 네트워크 관련 권한을 시스템 안내에 따라 처리하세요. 시스템 프록시는 네트워크 서비스 설정을 변경해야 하며, TUN은 클라이언트 구현에 따라 추가 권한이 필요할 수 있습니다. 앱이 실행되지 않으면 온라인에서 찾은 권한 우회 명령을 복사하기보다 앱 출처, 칩 아키텍처, 운영체제 지원 범위를 확인하세요. 권한 설정 위치는 시스템 버전에 따라 다를 수 있습니다.

모바일 권한 및 Linux 서비스 확인

Android는 처음 연결할 때 VPN 연결을 요청하는 경우가 많습니다. 현재 사용하는 클라이언트에서 온 요청인지 확인한 다음 권한을 허용하세요. 시스템 VPN 통로를 사용하는 다른 앱이 이미 있으면 네트워크를 동시에 처리하지 못할 수 있으므로 어느 앱을 유지할지 먼저 결정해야 합니다. iOS도 시스템 안내에 따라 네트워크 설정 권한을 허용하세요. 권한을 승인한 뒤 클라이언트의 실행 상태를 확인해야 합니다. 시스템 팝업이 떴다는 것만으로 구독과 출구까지 준비된 것은 아닙니다.

Linux 그래픽 앱이 열리더라도 데스크톱 프록시를 변경하거나 가상 인터페이스를 만들 수 있다는 뜻은 아닙니다. 클라이언트 안내에 따라 서비스 권한을 설정하고 설치 디렉터리 전체에 과도한 쓰기 권한을 주지 마세요. 코어를 직접 배포한다면 서비스 계정, 설정 디렉터리, 작업 디렉터리, 로그 소유자를 명확히 정하세요. 다운로드 파일을 장기 작업 디렉터리로 사용하지 마세요. 다운로드 파일을 정리하다가 참조 중인 규칙 파일과 설정까지 지울 수 있습니다.

혼합 포트 확인하기: 숫자만 반복해서 바꾸지 않기

시작 로그에 주소 사용 중 오류가 나오면 먼저 어떤 프로세스가 해당 포트를 사용하는지 확인하세요. 이전 클라이언트가 종료되지 않았거나 같은 프로그램이 여러 번 실행 중일 수도 있고, 관련 없는 서비스가 사용 중일 수도 있습니다. 원인을 확인한 다음 필요한 인스턴스만 남기거나 현재 클라이언트에 사용 가능한 포트를 지정하세요. 포트를 바꾼 뒤에는 브라우저 확장, 명령줄 환경 변수, 수동 프록시 설정도 함께 변경해야 합니다. 코어만 바꾸면 앱은 이전 진입점에 계속 접속할 수 있습니다.

# Windows PowerShell: 예시 포트의 수신 대기 정보 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux: 예시 포트의 수신 대기 정보 확인
ss -ltnp 'sport = :7890'

# macOS: 예시 포트의 수신 대기 정보 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

이 명령은 로컬 수신 대기 상태를 확인하는 데만 사용할 수 있으며, 일부 프로세스 정보는 추가 권한이 있어야 표시됩니다. 수신 대기 정보를 확인한 뒤 프로세스 이름과 클라이언트 로그를 함께 살펴보세요. 낯선 시스템 프로세스를 바로 종료하지 마세요. 수신 기록이 없더라도 설치가 손상된 것은 아닐 수 있습니다. 코어가 유효한 설정을 기다리는 중이거나 다른 포트를 사용하고 있을 수 있습니다. 설정 화면과 로그의 현재 값을 먼저 확인한 뒤 실행 환경을 변경하세요.

마지막으로 종료 후 복구를 테스트하세요. 잠시 연결이 끊겨도 괜찮은 시간에 클라이언트를 종료하고 시스템 프록시가 정상적으로 해제되는지 확인한 뒤 앱을 다시 실행합니다. 종료 후 브라우저가 접속되지 않고 시스템은 여전히 로컬 프록시 포트를 가리킨다면 진입점이 복구되지 않은 것입니다. 우선 시스템 네트워크 설정에서 남은 프록시를 끈 다음 클라이언트를 다시 시작해 종료 절차를 확인하세요. 이 테스트는 설정을 마치기 전에 진행해야 나중에 정상 종료 후 발생한 문제를 네트워크 장애로 오해하지 않습니다.

단계 04 / 유효한 설정 준비

구독 및 설정: 가져오기, 활성화, 로컬 변경 사항 보존

입력 형식을 확인한 뒤 가져오기

클라이언트의 설정 또는 구독 화면을 열고 URL 가져오기를 선택한 다음 신뢰할 수 있는 출처에서 받은 전체 링크를 붙여 넣으세요. 앞뒤 공백이나 줄바꿈, 메신저가 덧붙인 문장 부호가 포함되지 않았는지 확인한 뒤 다운로드합니다. 구독 URL에 계정 접근 정보가 포함될 수 있으므로 공개 게시판에 올리거나 신뢰할 수 없는 온라인 변환 사이트에 입력하지 마세요. 스크린샷을 공유할 때는 전체 주소를 가리세요. 특히 도메인만 가리고 뒤에 붙은 민감한 매개변수를 남기지 않도록 주의하세요.

로컬 파일을 가져올 때는 유효한 YAML 설정을 선택하고, 웹페이지를 저장한 파일이거나 시스템에서 텍스트 확장자가 추가된 파일은 아닌지 확인하세요. 완전한 설정, Base64 노드 목록, 단일 공유 링크는 구조가 서로 다르며 클라이언트가 가져올 수 있는지는 가져오기 기능에 따라 달라집니다. 형식이 헷갈린다면 구독 URL, 로컬 YAML, Base64 형식 안내를 확인하고 파일 확장자를 무작정 바꿔 가며 시도하지 마세요.

다운로드가 끝나면 설정 목록에서 해당 설정을 선택하고 활성화해야 합니다. 일부 클라이언트는 여러 구독을 저장할 수 있지만, 코어는 실제로 현재 선택된 설정이나 병합된 결과만 불러옵니다. 화면에서 현재 설정으로 표시된 항목을 확인한 다음 프록시 화면에 원하는 정책 그룹이 있는지 살펴보세요. 설정 이름이 표시된다는 것은 기록이 있다는 뜻일 뿐입니다. 코어에서 파싱 오류가 발생하면 로그에서 필드, 들여쓰기, 참조 이름을 확인해야 합니다.

YAML 구조와 정책 참조 이해하기

YAML은 공백으로 계층을 표현하므로 탭 문자를 섞어 쓰면 안 됩니다. 배열 항목은 보통 하이픈으로 시작하며 필드 이름과 값 사이에는 문법에 맞는 구분자가 필요합니다. 특수 문자가 포함된 텍스트에는 따옴표를 사용할 수 있지만 여닫는 따옴표가 쌍을 이루는지 확인하세요. 문제를 찾을 때는 로그에 표시된 위치와 앞뒤 몇 줄부터 살펴보세요. 오류 원인이 바로 윗줄에서 기호를 빠뜨린 경우가 많습니다. 노드 비밀번호와 인증 정보가 설정의 깊은 곳에 있을 수 있으니 전체 설정을 공개 게시판에 올리지 마세요.

# 최소 직접 연결 예시: 계층 구조를 설명하며 원격 프록시 노드는 포함하지 않음
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,수동 선택

이 예시는 구조를 이해하는 데 사용할 수 있지만 모든 연결이 직접 연결되므로 원격 서비스를 이용하기 위한 구독을 대신할 수는 없습니다. 규칙의 정책 이름은 설정에 정의되어 있어야 하며 대소문자와 표기가 일치해야 합니다. 설정을 수정할 때는 클라이언트에서 제공하는 덮어쓰기, 병합, 확장 기능을 이용하는 편이 좋습니다. 기능 이름은 앱마다 다를 수 있습니다. 다운로드한 설정을 직접 수정하면 다음 구독 갱신 때 변경 내용이 덮어써져 설정이 '저절로 사라진' 것처럼 보일 수 있습니다.

갱신 일정을 정하고 실패 상황에 대응하기

자동 갱신 간격은 유지 관리 설정이지 연결 속도 설정이 아닙니다. 일부 화면은 분, 다른 화면은 초 단위를 사용하므로 입력 전에 단위를 확인하세요. 화면에 분 단위라고 명시되어 있다면 1,440은 하루에 해당합니다. 이 값을 초 단위가 필요한 제공자 필드에 그대로 복사하면 안 됩니다. 너무 짧은 간격으로 서버에 계속 요청하지 마세요. 자주 갱신해도 형식 호환 문제는 해결되지 않으며 제공자의 요청 제한에 걸릴 수 있습니다.

갱신에 실패하면 네트워크 시간 초과, 인증 만료, 웹페이지 반환, 설정 파싱 오류를 구분하세요. 시간 초과라면 접속 경로를 확인하고, 인증이 만료됐다면 계정과 구독 URL을 확인하세요. 웹페이지가 반환됐다면 로그인 페이지나 오류 페이지인지 확인하고, 파싱 오류라면 형식과 코어 지원 범위를 살펴봐야 합니다. 기존 프록시가 정상일 때만 '프록시를 통해 갱신'하는 방식이 도움이 됩니다. 현재 설정이 이미 작동하지 않는다면 잠시 직접 연결로 가져오거나 제공자가 지원하는 다른 갱신 방법을 사용해야 할 수 있습니다.

갱신에 성공할 때마다 현재 설정이 계속 활성화되어 있는지 확인하고, 정책 그룹 선택도 예상대로 유지되는지 테스트하세요. 되돌리기 위해 공개하지 않을 설정 사본을 하나 보관하고 사용자 지정 규칙은 별도로 백업하세요. 더 자세한 오류 해결 절차는 구독 갱신 실패 및 자동 갱신 간격 설정을 참고하세요. 구독을 계속 삭제하고 다시 만들기보다 우선 연결을 복구한 다음 실패 원인을 정리하면 문제의 단서를 보존하기 쉽습니다.

단계 05 / 트래픽 진입점 확인

프록시 모드: 시스템 프록시, 규칙 모드, 전역 모드 구분하기

요청을 코어로 전달하는 방법부터 결정하기

설정을 가져온 후 사용할 수 있는 정책을 선택하고 시스템 프록시를 켠 다음 일반 브라우저에서 새 요청을 하나 보내세요. 연결 목록을 열어 해당 도메인과 적용된 정책이 표시되는지 확인합니다. 웹페이지 접속에 실패했는데 연결 기록도 전혀 없다면 먼저 시스템 프록시와 브라우저 자체 프록시 설정을 확인하세요. 규칙부터 바꾸면 안 됩니다. 브라우저 확장, 앱별 프록시, 시스템 설정이 서로 덮어쓸 수 있으므로 현재 요청이 어떤 진입점을 사용하는지 확인해야 합니다.

시스템 프록시는 해당 설정을 따르는 앱을 로컬 주소와 포트로 연결하지만 모든 프로그램이 이를 따르는 것은 아닙니다. 명령줄 도구, 게임, 백그라운드 서비스, 일부 스토어 앱은 자체 네트워크 스택을 사용할 수 있습니다. Windows UWP 앱은 루프백 접근 제한의 영향을 받을 수 있으므로 관련 오류를 모두 구독 문제로 돌리면 안 됩니다. 필요하다면 클라이언트의 루프백 설정이나 시스템 안내를 확인하고 실제 필요한 앱만 조정하세요. 모든 앱에 권한을 일괄 허용하지 마세요.

용도에 따라 규칙, 전역, 직접 연결 선택하기

규칙 모드는 설정의 조건에 따라 연결을 분배하므로 일상적인 라우팅에 적합합니다. 전역 모드는 일반적으로 코어에 들어온 연결을 전역 정책으로 전달합니다. 직접 연결 모드는 코어에 들어온 연결이 대상에 직접 접속하도록 합니다. 여기서 '전역'은 시스템 전체 트래픽이 이미 처리된다는 뜻이 아닙니다. 코어에 들어오지 않은 요청은 전역 모드를 선택해도 자동으로 경로가 바뀌지 않습니다. 먼저 진입점을 확인하고 다음에 모드를 선택하는 것이 이 가이드에서 가장 중요한 문제 해결 순서 중 하나입니다.

전역 모드는 짧은 비교 테스트에 적합합니다. 규칙 모드에서는 특정 대상에 접속하지 못하지만 전역 모드에서는 성공한다면 관련 규칙이나 정책을 확인해 볼 만합니다. 다만 출구에 따라 DNS나 연결 재사용 등이 달라질 수도 있으므로 특정 규칙 하나만이 원인이라고 단정하지 마세요. 테스트가 끝나면 원래 모드로 되돌리고 기존 연결을 닫거나 테스트 앱을 다시 시작해 새 설정으로 요청을 보내세요. 이전 세션이 판단을 방해하지 않도록 해야 합니다.

명시적 프록시로 비교 테스트하기

로컬 혼합 포트가 실제로 7890일 때는 아래 명령으로 프록시를 명시적으로 지정할 수 있습니다. 명령의 대상은 연결 가능 여부를 확인하는 데만 사용하는 공개 예시 사이트입니다. Windows PowerShell에서는 curl.exe를 사용하면 일부 환경에서 같은 이름의 명령 별칭과 충돌하는 문제를 피할 수 있습니다. 포트가 다르면 현재 값으로 바꾸세요. 명령이 성공해도 이번 요청 경로를 사용할 수 있다는 뜻일 뿐, 모든 앱과 대상이 정상이라고 단정할 수는 없습니다.

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

# Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

명시적 프록시로 접속되는데 브라우저는 실패한다면 브라우저 확장, 독립 프록시 설정, 캐시된 연결을 확인하세요. 두 방법 모두 실패하고 로그에 요청이 기록되면 정책 선택, 노드 상태, 대상 접속 제한을 살펴보세요. 로그에 요청이 없다면 포트와 코어 실행 상태를 확인하고 실제로 요청을 보냈는지 점검하세요. 브라우저의 일반적인 오류 화면만 보고 판단하지 마세요. 같은 오류 메시지가 DNS 확인 실패, 연결 거부, 원격 연결 종료 등 여러 원인으로 나타날 수 있습니다.

명령줄 환경 변수에 예전 프록시 진입점이 남아 있을 수도 있습니다. 문제를 해결할 때 현재 터미널에 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY가 설정되어 있는지, 앱이 해당 변수를 따르는지 확인하세요. 변수를 바꿔도 보통 새로 시작한 프로세스에만 적용되며 실행 중인 앱에는 이전 값이 남아 있을 수 있습니다. 터미널 하나에서 프록시를 사용하려고 모든 세션의 환경 변수를 바꾸지 마세요. 먼저 현재 터미널에서 확인한 다음 필요한 경우에만 영구 설정하세요.

이 장을 마치면 어떤 앱이 시스템 프록시를 사용하는지, 어떤 앱에 명시적 설정이 필요한지, 현재 모드가 어디까지 적용되는지 설명할 수 있어야 합니다. '연결됐는데 웹페이지가 열리지 않는' 문제가 계속되면 시스템 프록시, 포트 충돌, 규칙 문제 해결 체크리스트를 따라 항목별로 확인하세요. 한 번에 하나만 변경하고 변경 전후 결과를 기록해야 모드, 노드, DNS를 동시에 바꿔 비교 기준을 잃지 않습니다.

단계 06 / 연결 경로 제어

규칙 기반 라우팅: 순서대로 일치 여부와 실제 적용 결과 확인하기

조건을 작성하기 전에 규칙 순서 이해하기

규칙 목록은 보통 위에서 아래로 검사하며, 처음 조건에 맞는 규칙이 처리 정책을 결정합니다. 마지막에는 나머지 트래픽을 처리할 기본 규칙이 사용됩니다. 조건이 구체적이라고 자동으로 우선 적용되는 것은 아니며 규칙 위치도 중요합니다. 적용 범위가 넓은 조건을 앞에 두면 아래의 세부 조건은 아예 적용되지 않을 수 있습니다. 수정하기 전에 어떤 도메인은 직접 연결할지, 어떤 도메인은 특정 정책 그룹으로 보낼지, 일치하는 규칙이 없을 때 어떻게 처리할지 명확히 정리하세요.

도메인 규칙과 IP 규칙은 서로 다른 대상을 확인합니다. DOMAIN은 지정한 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사에 적용되며, IP-CIDR은 IP 주소 대역을 대상으로 하고, GEOIP는 지리 데이터베이스를 사용합니다. 도메인 접미사 규칙은 임의의 문자열 포함 조건과 다르며 해당 웹사이트의 모든 관련 도메인을 자동으로 처리하지도 않습니다. 한 페이지에서 로그인, 이미지, API 등이 서로 다른 호스트로 요청될 수 있으므로 실제 연결 기록을 바탕으로 확인해야 합니다.

이해하기 쉬운 최소 규칙부터 시작하기

아래 예시는 흔히 쓰는 규칙 순서를 보여 줍니다. 완전한 기존 설정에 추가해야 하며 PROXY는 이미 정의된 정책이나 정책 그룹이어야 합니다. 이 예시는 도메인 접미사 하나를 프록시로 보내고, 사설 네트워크 대역은 직접 연결하며, 중국 본토 IP에는 직접 연결 규칙을 적용한 뒤 나머지는 프록시로 전달합니다. 학습용 라우팅 구조이므로 모든 네트워크 환경에 그대로 적용할 수 있는 것은 아닙니다. 특히 LAN 라우팅과 서비스 제공자의 안내를 고려해 조정하세요.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolve는 이 IP 규칙과 일치시키기 위해 별도로 도메인 조회를 시작하지 않도록 하는 옵션입니다. 설정 전체의 DNS를 끄거나 대상에 IP가 절대 할당되지 않게 하는 기능은 아닙니다. 연결에 이미 사용할 수 있는 주소가 있다면 IP 규칙과 일치할 수 있습니다. 사용할지는 도메인 요청과 조회 비용을 어떻게 처리할지에 따라 결정하세요. 지리 데이터베이스도 사용할 수 있는 데이터 출처가 필요합니다. 데이터베이스가 없거나 오래되면 관련 규칙이 예상과 다르게 동작할 수 있습니다.

LAN 접근 및 서비스 검색 유지하기

라우터 관리 페이지, 프린터, 파일 서버, 사내 네트워크는 직접 연결해야 하는 경우가 많지만 사설 IP 대역 몇 개만으로 모든 문제를 해결할 수는 없습니다. 내부망에서 전용 도메인이나 분할 DNS, 다른 주소 범위를 사용할 수 있으며 서브넷 간 접근은 실제 라우팅 설정의 영향도 받습니다. 내부 도메인에 접속할 수 없다면 DNS 조회와 대상 주소에 대한 접근 가능성을 각각 확인하세요. 관련 없는 서비스까지 경로가 바뀔 수 있으므로 최상위 도메인 전체를 간단히 직접 연결 규칙에 추가하지 마세요.

규칙 제공자는 대규모 규칙 모음을 관리하는 데 유용하지만 규칙 동작 유형과 파일 형식을 구분해야 합니다. 도메인 목록, 주소 목록, 클래식 규칙 모음은 형식이 다르므로 참조할 때 콘텐츠에 맞는 유형을 지정해야 합니다. 사용 전에 출처를 신뢰할 수 있는지, 갱신 주기가 적절한지, 다운로드 실패 시 사용할 로컬 데이터가 있는지 확인하세요. 내용을 이해하지 못한 대형 규칙 모음을 무작정 추가하면 중복 조건, 지나치게 넓은 범위, 갱신에 따른 덮어쓰기로 적용 결과를 파악하기 어려워집니다.

설정 텍스트만 보지 말고 연결 상세 정보로 검증하기

규칙을 조정할 때마다 설정이 다시 로드됐는지 확인하고 대상에 새 연결을 만든 뒤 연결 상세 정보에서 도메인, 대상 주소, 일치한 규칙, 최종 정책을 살펴보세요. 일부 앱은 장시간 연결을 재사용하므로 규칙 텍스트를 바꿔도 기존 연결의 출구는 바로 바뀌지 않습니다. 필요하다면 해당 연결만 닫거나 테스트 앱을 다시 시작하세요. 모든 시스템 네트워크 설정을 초기화할 필요는 없습니다. 페이지에 이미 표시된 캐시가 아니라 새 요청을 기준으로 결과를 확인하세요.

대상이 예상과 다르게 라우팅되면 요청에 도메인 정보가 있는지 확인한 뒤 규칙 순서, 정책 이름, 구독 갱신으로 설정이 덮어써졌는지 확인하세요. 프로세스 규칙은 플랫폼 기능과 프로세스 식별 방식에도 영향을 받으므로 모든 기기에 무작정 똑같이 적용하면 안 됩니다. 새 규칙의 적용 범위를 작게 유지하고 용도를 주석으로 기록하세요. 근거가 사라진 임시 규칙은 일정 시간이 지나면 삭제하는 편이 예외 규칙을 계속 쌓는 것보다 관리하기 쉽습니다.

단계 07 / 트래픽 처리 범위 확장

TUN 및 DNS: 트래픽 처리 후 DNS 확인하기

TUN을 켜야 하는 이유부터 확인하기

시스템 프록시를 따르지 않는 앱을 코어로 전달해야 할 때 TUN을 고려하세요. TUN은 가상 네트워크 인터페이스와 라우팅 설정으로 처리 범위를 넓히지만, 특정 트래픽까지 다룰 수 있는지는 시스템 권한, 라우팅, 프로토콜 지원, 클라이언트 구현에 달려 있습니다. TUN을 모든 네트워크 문제를 해결하는 스위치로 생각하면 안 됩니다. 시스템 프록시 경로가 작동하는 것을 확인한 다음 TUN을 켜면 결과를 비교하기 쉽고 문제가 생겨도 기존 진입점으로 빠르게 되돌릴 수 있습니다.

활성화하기 전에 현재 사용하는 VPN, 컨테이너, 가상 머신, 회사 네트워크 도구를 기록하세요. 여러 도구가 동시에 라우팅이나 DNS를 변경할 수 있으므로 함께 실행할 때는 기본 라우트를 담당하는 항목과 내부망 접근을 담당하는 항목을 구분해야 합니다. 켠 뒤 내부망 연결이 끊기거나 원격 연결이 반복되면 먼저 TUN을 끄고 기존 상태로 복구한 다음 라우팅 충돌을 확인하세요. 네트워크 인터페이스 우선순위, 방화벽, DNS 서비스를 한꺼번에 변경하면 어떤 조치가 결과를 바꿨는지 파악하기 어렵습니다.

자주 사용하는 TUN 매개변수 이해하기

auto-route는 코어가 관련 라우트를 자동으로 설정하도록 하고, auto-detect-interface는 출구 인터페이스를 선택할 때 도움을 주며, dns-hijack은 조건에 맞는 DNS 요청을 가로채 처리합니다. 플랫폼 조건과 관계없이 언제나 작동하는 스위치는 아닙니다. 노트북을 유선 네트워크에서 Wi-Fi로 전환하면 출구 식별과 라우팅을 다시 설정해야 할 수 있습니다. 이때는 클라이언트 방식에 따라 다시 연결하거나 코어를 재시작하세요. 구독을 반복해서 가져올 필요는 없습니다.

# 이 옵션을 지원하는 mihomo 설정에 병합
# 해당 시스템 권한이 필요합니다. 활성화 전에 기존 설정을 보관하세요
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

이 예시는 완전한 구독 설정이 아니며 클라이언트의 TUN 관리 기능을 우회해 그대로 붙여 넣는 용도로도 적합하지 않습니다. 설정에 지정한 DNS 서버는 현재 네트워크에서 접속할 수 있어야 하고, 코어는 해당 서버 도메인을 처음 조회할 수 있어야 합니다. 예시의 가상 주소 풀은 내부 매핑용이며 원격 프록시 서버 주소가 아닙니다. 환경에서 이 주소 범위가 충돌한다면 설정 안내를 먼저 확인한 뒤 범위나 필터 조건을 조정하세요.

DNS 조회 실패와 연결 실패 구분하기

DNS는 도메인 이름과 접속 대상을 연결해 줍니다. DNS 서버를 바꾼다고 노드 인증 문제나 포트 충돌이 해결되지는 않습니다. fake-ip 모드는 요청에 매핑용 주소를 할당해 코어가 도메인과의 연결을 유지하게 하며, redir-host 모드는 일반적으로 조회한 실제 주소를 반환합니다. 두 방식은 호환성과 처리 경로가 다르므로 모든 기기에 통하는 정답은 없습니다. 일부 LAN 앱, 특수 검사 프로그램, 직접 연결 서비스에는 예외 처리가 필요할 수 있습니다.

nameserver, fallback, 관련 필터 설정은 각각 역할이 다릅니다. 대체 DNS는 단순히 '기본 서버가 고장 났을 때 한 번 조회하는 서버'가 아닙니다. 최종 결과는 선택 기준과 필터 조건에 따라 달라지므로 설정 전에 현재 코어의 처리 방식을 이해하세요. DNS 주소를 여러 개 쌓아 두면 더 안정적이라고 생각하지 마세요. 필드를 하나씩 확인하려면 mihomo DNS 설정 및 fake-ip 안내를 읽고 명확한 문제에 필요한 부분만 변경하세요.

브라우저나 앱 자체의 암호화 DNS는 일반적인 53번 포트 요청 경로를 우회할 수 있으므로 DNS 가로채기가 모든 DNS 조회를 제어하는 것은 아닙니다. 문제를 해결할 때는 앱에서 별도 DNS를 사용하는지 기록하고 시스템 DNS 경로와 비교하세요. 로그를 확인하려고 앱의 보안 기능을 장기간 모두 끄지 마세요. 통제된 테스트로 차이를 확인한 뒤 영향에 따라 DNS를 통일할지 앱 자체 정책을 유지할지 결정하세요.

활성화 후에는 세 단계로 확인하세요. 먼저 일반 웹페이지가 열리는지 확인하고, 다음으로 기존에 시스템 프록시를 따르지 않던 대상 앱이 연결 목록에 나타나는지 살펴본 뒤, LAN과 절전 후 복귀를 테스트하세요. 모바일에서는 백그라운드 정책과 배터리 사용량도 확인하세요. 관련 내용은 모바일 백그라운드 실행 및 TUN 상시 활성화 안내에서 볼 수 있습니다. TUN을 켰을 때만 문제가 생긴다면 이미 확인된 진입점으로 되돌린 뒤 라우팅과 로그를 바탕으로 해결하세요.

단계 08 / 복구 가능한 상태 유지

일상적인 유지 관리: 백업, 업데이트, 문제 해결 순서

정상 작동 상태로 되돌릴 지점 마련하기

관리 항목을 앱, 코어, 구독, 로컬 덮어쓰기 네 가지로 나눠 보세요. 앱 업데이트는 화면과 시스템 통합 방식을 바꿀 수 있고, 코어 업데이트는 지원 필드나 기본 동작을 바꿀 수 있습니다. 구독 갱신은 원격 콘텐츠를 교체하고 로컬 덮어쓰기는 개인 라우팅 설정을 보존합니다. 네 가지 항목을 한꺼번에 업데이트하지 말고 각각 기록하세요. 문제가 생겼을 때 마지막으로 바뀐 항목을 알 수 있으면 정리되지 않은 긴 로그보다 훨씬 큰 도움이 됩니다.

백업은 구독 URL만 저장하는 것으로 충분하지 않습니다. 현재 정책 선택, 사용자 지정 규칙, DNS 예외, 혼합 포트, 클라이언트의 시스템 통합 설정도 기록하세요. 내보내기 기능에 시스템 서비스, 로그인 시 자동 실행, 로컬 규칙 파일이 포함되지 않을 수 있으므로 앱 안내를 확인해 필요한 항목을 보충해야 합니다. 백업에는 접근 정보가 포함될 수 있으므로 안전한 위치에 보관하고 공개하지 마세요. 공개 클라우드 링크를 장기 설정 배포 방법으로 사용하지 마세요.

업데이트를 검증 가능한 변경 작업으로 관리하기

업데이트하기 전에 현재 설정을 저장하고 잠시 연결이 끊겨도 괜찮은 시간에 작업하세요. 업데이트 후 코어 실행, 설정 로드, 일반 브라우저 접속, 주요 앱, LAN 서비스를 확인한 뒤 이전 파일을 정리할지 결정하세요. 필드가 폐기되거나 파싱 동작이 바뀌었다면 변경 사항을 읽고 해당 설정 부분을 찾아보세요. 기능을 모두 사용하려고 새 옵션을 한꺼번에 켜지 마세요. 안정적으로 작동하는 기준 상태가 기능 목록보다 더 유용한 비교 대상입니다.

자동 시작 순서도 확인해야 합니다. 로그인할 때 앱이 실행된다고 네트워크 준비가 끝난 것은 아닙니다. 네트워크 연결 전에 구독과 규칙 제공자 갱신이 실패해도 설정이 손상됐다는 뜻은 아닐 수 있습니다. 네트워크가 복구된 뒤 다시 갱신되는지 확인하고 필요하면 클라이언트가 지원하는 지연 시작이나 재시도 옵션을 사용하세요. 노트북이 절전 모드에서 깨어난 뒤 실패한다면 출구 인터페이스, 시스템 프록시, 코어 상태를 비교하세요. 구독을 전부 삭제하는 것부터 시작하지 마세요.

진입점, 코어, 출구, 대상 순서로 문제 해결하기

첫째, 진입점을 확인합니다. 코어가 실행 중인지, 포트가 수신 대기 중인지, 앱이 실제로 해당 진입점을 사용하는지 살펴보세요. 둘째, 설정을 확인합니다. 현재 활성화된 설정이 무엇인지, 파싱 오류가 있는지, 정책 그룹 참조가 유효한지 확인하세요. 셋째, 출구를 확인합니다. 같은 정책에서 원격 서비스에 접속할 수 있는지, 인증이나 프로토콜 오류가 있는지 살펴보세요. 넷째, 대상을 확인합니다. 다른 웹사이트와 앱은 정상인지, 특정 도메인이나 네트워크에서만 문제가 발생하는지 점검하세요.

재현할 수 있는 한 번의 실패를 기준으로 로그를 수집하세요. 시간과 작업 내용을 먼저 기록한 다음 요청을 보내고 관련 로그의 앞뒤 줄을 보관합니다. 로그 수준을 잠시 높이면 도움이 되지만, 상세 로그를 장기간 유지하면 기록량이 늘고 접속 도메인이 포함될 수 있습니다. 문제 해결 후에는 일상적인 로그 수준으로 되돌리세요. 공유 전에 구독 URL, 인증 정보, 공개하고 싶지 않은 도메인을 가리세요. 앞부분의 원인을 빼고 마지막의 일반 오류 메시지만 캡처하지 마세요.

네트워크 전환 및 종료 후 남은 설정 처리하기

집 네트워크에서 회사 네트워크로 전환하면 DNS, 인증 포털, 접근 제한이 함께 바뀔 수 있습니다. 먼저 네트워크 자체에서 요구하는 로그인을 완료하고 필요하면 프록시 진입점을 잠시 끈 다음 직접 연결이 되는지 확인한 뒤 설정을 다시 활성화하세요. 회사 네트워크에서 프록시나 VPN을 제한할 수 있으므로 관련 관리 규정을 따라야 합니다. 포트를 반복해서 바꾸거나 프로세스를 숨겨 정책을 우회하지 마세요. 현재 네트워크에서 허용되는 경로가 작동해야 이후 클라이언트 테스트도 의미가 있습니다.

클라이언트를 종료한 뒤 인터넷에 연결되지 않으면 남아 있는 시스템 프록시를 먼저 확인하세요. 시스템을 재시작한 뒤에도 연결되지 않는다면 자동 시작 앱과 영구 환경 변수도 살펴봐야 합니다. 문제가 생겼을 때는 시스템 프록시를 끄거나 TUN을 비활성화하는 등 명확한 복구 방법을 마련하세요. 모든 네트워크 구성 요소를 바로 초기화하지 마세요. 일반적인 질문은 FAQ에서 더 확인할 수 있습니다. 문의할 때는 운영체제, 클라이언트, 진입 방식, 재현 절차, 비교 테스트 결과를 알려 주세요. 전체 설정을 공개할 필요는 없습니다.

단계 09 / 항목별로 확장

고급 설정 경로: 제공자, 자동 정책, 배포 범위

설정 구조를 익힌 뒤 자동화 추가하기

안정적으로 사용할 수 있다고 해서 기능을 계속 추가할 필요는 없습니다. 고급 기능은 구체적인 문제를 해결하는 데 맞춰 학습하세요. 노드가 많다면 프록시 제공자를, 규칙이 자주 바뀐다면 규칙 제공자를, 원격 기기를 상시 운영해야 한다면 서비스 관리를 살펴볼 수 있습니다. 각 단계마다 최소한으로 작동하는 설정과 별도의 테스트 목표를 유지하세요. 출처를 알 수 없는 설정을 인터넷에서 복사해 넣고 정체 모를 옵션을 무작위로 바꾸며 동작을 파악하지 마세요.

프록시 제공자는 노드 출처를 기본 설정과 분리해 갱신과 재사용을 편리하게 해 줍니다. 하지만 출처 형식, 저장 경로, 갱신 주기, 참조하는 정책 그룹을 명확히 해야 합니다. 제공자 다운로드가 성공해도 노드가 실제로 사용되고 있다는 뜻은 아닙니다. 정책 그룹에서 해당 이름을 참조해야 합니다. 상태 검사는 접속 가능한 테스트 대상이 필요하며 결과는 해당 테스트 경로에만 적용됩니다. 테스트에 성공했다고 모든 업무 요청도 성공하거나 실제 접속 속도가 빠르다고 볼 수는 없습니다.

자동 선택의 측정 범위 이해하기

수동 선택 그룹은 동작을 확인하기 가장 쉽습니다. 자동 속도 측정 그룹, 장애 조치 그룹, 부하 분산 그룹은 각각 용도가 다릅니다. 자동 선택은 테스트 조건에, 장애 조치는 가용성 판단에, 부하 분산은 연결을 어떻게 나눌지에 따라 동작합니다. 이름만 보고 모든 그룹을 겹쳐 사용하지 마세요. 세션을 유지해야 하는 서비스처럼 출구가 안정적이어야 하는 앱인지 확인한 다음 자동 전환이 추가 로그인이나 연결 끊김을 일으킬지 판단하세요.

검사 간격, 시간 초과, 허용 오차가 자동 정책에 영향을 줍니다. 간격이 너무 짧으면 네트워크 요청이 늘고 모바일 기기의 배터리가 더 빨리 소모될 수 있습니다. 너무 길면 경로 변화를 늦게 발견할 수 있습니다. 테스트 주소가 현재 네트워크에서 접속되지 않으면 그룹 전체의 결과가 왜곡됩니다. 먼저 수동 선택으로 기본 연결을 확인한 다음 자동 검사를 켜세요. 문제가 발생하면 모든 실패를 노드 품질 탓으로 돌리기보다 테스트 대상과 실제 서비스 대상을 비교하세요.

명령줄 코어를 별도 배포 작업으로 다루기

서버나 라우터에 배포하려면 실행 계정, 서비스 시작, 설정 권한, 로그 순환, 네트워크 전달을 추가로 관리해야 합니다. 데스크톱 시스템 프록시를 설정한 경험만으로 이런 작업을 대신할 수는 없습니다. 코어를 직접 실행해도 설정에 활성화된 기능만 제공되며 LAN 전체가 자동으로 프록시 네트워크가 되지는 않습니다. 우회 경로 또는 게이트웨이 방식은 기본 게이트웨이, 포워딩, 방화벽, 응답 경로까지 고려해야 하므로 장비 구성에 맞춰 설계하세요. 운영 중인 네트워크에서 시험 삼아 바꾸면 안 됩니다.

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

# 작업 디렉터리를 지정해 실행합니다. 해당 디렉터리에 설정에 필요한 리소스를 준비해야 합니다
mihomo -d ./profile

구문 검사를 통과했다는 것은 코어가 해당 설정을 받아들일 수 있다는 뜻일 뿐, 실행 환경에서 원격 서비스, DNS, 규칙 다운로드까지 사용할 수 있다는 보장은 아닙니다. 검사할 때는 가능하면 실제 실행 환경과 같은 코어와 작업 디렉터리를 사용하고 상대 경로 참조를 확인하세요. 서비스로 실행할 때는 환경 변수, 권한, 현재 디렉터리가 대화형 터미널과 다를 수 있습니다. '직접 실행하면 성공하지만 서비스로 실행하면 실패'한다면 먼저 이런 환경 차이를 비교하세요.

관리 인터페이스 및 LAN 노출 제어

관리 인터페이스는 대시보드와 자동화 제어에 사용할 수 있지만 프록시 상태를 변경할 권한도 가집니다. 실제로 필요할 때만 활성화하고, 우선 로컬 루프백 주소로 제한한 뒤 코어가 지원하는 인증을 설정하세요. 혼합 프록시 포트, 관리 인터페이스, DNS 수신 포트는 서로 다른 진입점입니다. 이 중 하나에 LAN 접근이 필요하다고 다른 포트까지 모든 인터페이스에 바인딩하지 마세요. 외부에 개방하기 전에는 호스트 방화벽으로 접근 가능한 출처도 제한해야 합니다.

다른 기기에서 프록시를 사용하려면 수신 주소, LAN 접근 설정, 인증, 방화벽 규칙을 하나씩 확인하세요. 공유 네트워크의 모든 기기를 신뢰할 수 있는 것은 아니며 포트를 공용 인터넷에 직접 노출해서도 안 됩니다. 라우터에 상시 배포한다면 기기 재시작, 저장 공간, 규칙 리소스 갱신 실패 시 동작도 고려해야 합니다. 분리된 테스트 환경에서 먼저 확인한 뒤 장기간 사용할 네트워크 진입점으로 운영하세요. 한 번의 설정 오류로 네트워크 전체에 영향을 주지 않도록 주의해야 합니다.

학습 순서는 현재 설정 이해, 규칙 독립 수정, DNS와 TUN 이해, 제공자 및 서비스 배포 순으로 진행할 수 있습니다. 각 단계에서 세 가지 질문에 답하세요. 어떤 문제를 해결하는가, 어떻게 적용 여부를 확인하는가, 어떻게 원래대로 되돌리는가? 기본 절차를 다시 확인하려면 입문 가이드를 참고하고, 도구를 바꾸려면 클라이언트 다운로드 페이지를 확인하세요. 연결의 진입점, 적용된 규칙, 최종 출구를 설명할 수 있다면 단순히 사용하는 수준을 넘어 유지 관리할 수 있습니다.