Clash 사용 설명서: 구독, 트래픽 분할과 TUN 설정

핵심 개념: 먼저 커널, 클라이언트와 설정 파일을 구분하기

Clash는 하나의 설치 파일이 아닙니다

일상적으로 말하는 “Clash”는 프록시 커널, 그래픽 클라이언트 또는 Clash 설정 형식을 사용하는 도구 전체를 가리킬 수 있습니다. 커널은 설정을 읽고 프록시 연결을 만들며 규칙을 매칭하고 트래픽을 전달합니다. 그래픽 클라이언트는 설정, 로그, 프록시 그룹, 시스템 프록시와 업데이트 기능을 클릭 가능한 화면으로 정리합니다. mihomo는 현재 Clash 생태계에서 널리 사용되는 계승 커널이며, 많은 최신 클라이언트가 이를 통해 다양한 프로토콜, 규칙 유형, TUN과 DNS 기능을 제공합니다. 이 관계를 이해하는 것이 중요합니다. 같은 구독이라도 클라이언트에 따라 버튼 위치는 다를 수 있지만, 커널이 처리하는 프록시 노드, 프록시 그룹과 규칙 로직은 대체로 비슷합니다.

설정 파일은 일반적으로 YAML 형식을 사용합니다. 포트, 프록시 노드, 프록시 그룹, 규칙, DNS와 TUN 설정을 포함할 수 있습니다. 구독은 원격 설정 소스입니다. 클라이언트가 구독 링크를 저장하고 필요할 때 서비스 제공자가 생성한 설정을 내려받은 다음 커널에 전달해 로드합니다. 구독 링크 자체는 “연결 버튼”이 아니며 노드 이름도 최종 출구를 의미하지 않습니다. 요청은 먼저 규칙 매칭을 거친 뒤 규칙이 지정한 프록시 그룹에서 특정 노드나 DIRECT를 선택합니다. 따라서 문제를 점검할 때는 원격 구독 다운로드, 커널의 설정 해석, 규칙에 따른 사용 가능한 정책으로의 트래픽 전달이라는 세 단계를 구분해야 합니다.

하나의 요청이 Clash를 거치는 과정

브라우저로 웹페이지에 접속하는 경우를 예로 들어 보겠습니다. 브라우저는 먼저 요청을 시스템 네트워크 스택에 전달합니다. 시스템 프록시가 켜져 있으면 이를 지원하는 앱이 HTTP 또는 SOCKS 요청을 클라이언트의 수신 포트로 보냅니다. TUN이 활성화되어 있다면 더 많은 IP 트래픽이 가상 네트워크 인터페이스로 먼저 들어갑니다. 커널은 대상 도메인이나 주소를 확인한 뒤 규칙 목록의 위에서부터 매칭하고, 일치하는 규칙에 지정된 정책으로 요청을 전달합니다. 정책은 특정 노드일 수도 있고, 수동 선택, 자동 지연 시간 측정, 장애 조치, DIRECT 또는 거부일 수도 있습니다. 마지막으로 노드가 해당 프로토콜을 사용해 원격 서버와 연결하고, 응답 데이터는 같은 경로를 따라 앱으로 돌아갑니다.

이 흐름을 이해하면 흔한 현상을 설명할 수 있습니다. 브라우저는 정상인데 특정 게임만 연결되지 않는다면 해당 앱이 시스템 프록시를 사용하지 않아 TUN이 필요할 수 있습니다. 모든 웹사이트가 열리지 않지만 구독 업데이트는 성공한다면 설정은 내려받았고 문제는 노드, 정책 또는 로컬 트래픽 연결 단계에 있을 가능성이 큽니다. 특정 도메인만 이상하다면 규칙, DNS 또는 대상 서비스 자체의 제한일 가능성이 높습니다. 문제를 해결할 때는 클라이언트를 반복해서 삭제하기보다 “구독 가져오기, 설정 해석, 트래픽 연결, 규칙 매칭, 노드 연결, DNS 조회” 중 어느 계층에서 문제가 발생했는지 먼저 확인해야 합니다.

클라이언트 선택: 플랫폼, 커널과 사용 환경을 기준으로 판단하기

현재도 유지 관리되는 그래픽 클라이언트를 우선 선택하세요

클라이언트를 고를 때는 먼저 운영체제를 확인하고, 그다음 유지 관리 상태, 커널 종류와 필요한 기능을 살펴보세요. 이 사이트의 다운로드 목록에서는 Windows, macOS, Android와 iOS를 지원하는 Clash Plus를 우선 추천합니다. 여러 플랫폼에서 비슷한 방식으로 사용하려는 경우에 적합합니다. Windows와 macOS에서는 Clash Verge Rev, FlClash도 선택할 수 있으며, Windows에는 Clash Nyanpasu도 있습니다. Android에서는 Clash Meta for Android, FlClash 또는 Surfboard를 사용할 수 있습니다. Linux 데스크톱 환경에서는 Clash Verge Rev 또는 FlClash가 적합합니다. Clash for Windows와 ClashX Meta는 유지 관리가 중단되었으므로 기존 설정 이전에만 활용하고 새로 설치할 때의 기본 선택으로 삼지 않는 것이 좋습니다.

“화면이 익숙해 보인다”는 유일한 기준이 아닙니다. TUN, 프로세스 규칙, 규칙 집합 또는 최신 설정 필드가 필요하다면 클라이언트의 커널이 해당 기능을 인식할 수 있는지 확인해야 합니다. mihomo 커널을 사용하는 클라이언트는 현재 설정 생태계에 더 잘 맞는 경우가 많지만, 같은 mihomo 클라이언트라도 권한 요청, 설정 저장 위치, 트레이 메뉴와 시스템 프록시 구현은 다를 수 있습니다. 구독 서비스가 특정 필드에 의존한다면 서비스 안내를 우선 따르세요. 필드를 인식하지 못할 때는 전체 설정을 바로 삭제하거나 수정하지 말고 먼저 커널 호환성을 확인해야 합니다.

데스크톱, 모바일과 서버는 사용 방식이 다릅니다

데스크톱 클라이언트는 보통 시스템 프록시와 TUN을 함께 제공합니다. 시스템 프록시는 설정이 간단해 브라우저, 메신저와 시스템 프록시를 따르는 소프트웨어에 적합합니다. TUN은 더 넓은 범위의 트래픽을 다루므로 시스템 프록시를 읽지 않는 앱에 유용합니다. Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 연결하며, 활성화하면 VPN 상태 표시가 나타납니다. 다른 VPN 앱이 동시에 실행 중이면 같은 인터페이스를 함께 사용할 수 없는 경우가 많습니다. iOS도 시스템 네트워크 확장 기능에 의존하므로 설정 위치와 백그라운드 동작이 시스템 정책의 영향을 받습니다. 모바일에서는 배터리 최적화, 백그라운드 제한과 앱별 프록시도 함께 확인해야 합니다.

서버, 소프트 라우터와 컨테이너 환경에서는 mihomo 커널을 직접 실행하는 방식이 더 적합합니다. 이런 환경에서는 그래픽 화면을 위해 데스크톱 의존성을 추가할 필요가 없으며, 보통 설정 파일, 명령줄 인자와 외부 제어 인터페이스로 관리합니다. 다만 커널 패키지는 바로 사용할 수 있는 데스크톱 클라이언트가 아닙니다. 설정 경로, 실행 사용자, 서비스 관리, 로그 순환과 방화벽 규칙을 직접 준비해야 합니다. 개인 컴퓨터에서 웹을 탐색하는 목적이라면 그래픽 클라이언트를 우선 선택하세요. 게이트웨이 전달, 별도 라우터 또는 자동화 배포가 명확히 필요할 때만 순수 커널 방식으로 넘어가는 것이 좋습니다.

시스템 아키텍처와 설치 파일 유형 확인

Windows의 일반적인 데스크톱 기기는 x64를 사용하며, ARM 프로세서가 탑재된 기기만 ARM64가 필요합니다. macOS에서는 “이 Mac에 관하여”에서 칩 종류를 확인할 수 있습니다. Apple 칩은 arm64, Intel 프로세서는 x64에 해당합니다. Android 설치 파일은 arm64, arm 또는 범용 패키지로 나뉠 수 있습니다. 최근 주류 스마트폰은 대부분 arm64를 사용하지만 구형 기기와 일부 에뮬레이터는 실제 아키텍처에 맞춰 선택해야 합니다. Linux에서는 아키텍처뿐 아니라 deb, rpm과 압축 패키지도 구분해야 합니다. Debian과 Ubuntu는 deb, Fedora 계열은 rpm을 주로 사용하며, 순수 커널 압축 패키지는 직접 배포해야 합니다.

전체 클라이언트 목록, 플랫폼별 다운로드 경로와 유지 관리 상태는 다운로드 페이지에서 확인할 수 있습니다. 기존 클라이언트에 중요한 설정이 남아 있다면 이전하기 전에 설정을 내보내거나 구독 주소, 정책 선택과 사용자 지정 규칙을 기록하세요. 새 클라이언트를 설치하기 전에 기존 클라이언트를 종료하고, 클라이언트의 데이터베이스와 설정 디렉터리는 보통 서로 덮어쓸 수 없다는 점을 기억하세요. 가장 안전한 방법은 구독을 다시 가져온 뒤 사용자 지정 내용을 항목별로 복원하는 것입니다.

설치 및 초기 설정: 복구 가능한 기본 환경 만들기

설치 전에 충돌 상태부터 정리하세요

클라이언트를 설치하기 전에 실행 중인 프록시, VPN과 이전 Clash 클라이언트를 종료하고 시스템 프록시에 잔여 설정이 없는지 확인하세요. Windows에서는 시스템 네트워크 설정에서 수동 프록시가 켜져 있는지 확인할 수 있습니다. macOS에서는 현재 네트워크 서비스의 프록시 설정에서 HTTP, HTTPS와 SOCKS 항목을 확인하세요. 잔여 프록시는 흔한 오판을 일으킵니다. 새 클라이언트는 아직 실행되지 않았는데 브라우저가 이미 존재하지 않는 로컬 포트로 요청을 보내 모든 웹페이지가 열리지 않을 수 있습니다. 이때 문제는 설치 파일이 아니라 이전 프로그램을 종료한 뒤 시스템 프록시가 복원되지 않은 데 있습니다.

데스크톱 설치가 끝나면 클라이언트를 먼저 실행하되 고급 기능을 한꺼번에 활성화하지 마세요. 화면이 정상적으로 표시되고 커널이 시작되며 로그에 반복적인 오류가 없는지 확인한 뒤 구독을 가져오세요. TUN을 처음 실행할 때 Windows에서는 관리자 권한을 요청하거나 가상 네트워크 구성 요소를 설치할 수 있습니다. macOS에서는 네트워크 확장 허용이나 시스템 자격 증명 입력을 요구할 수 있습니다. 권한은 해당 기능을 실제로 활성화할 때만 부여하면 됩니다. 권한을 거부해도 시스템 프록시는 대체로 사용할 수 있지만 TUN은 가상 인터페이스를 만들 수 없습니다.

먼저 설정 디렉터리와 자동 시작 정책을 확인하세요

그래픽 클라이언트는 보통 설정, 구독 색인, 커널 파일과 로그를 사용자 디렉터리에 저장합니다. 프로그램 디렉터리와 설정 디렉터리를 혼동하지 마세요. 앱을 제거해도 사용자 설정이 삭제되지 않을 수 있고, 덮어써서 설치해도 설정이 초기화되지 않을 수 있습니다. 문제가 발생하면 먼저 클라이언트가 제공하는 초기화, 설정 전환 또는 캐시 삭제 기능을 사용하세요. 설정 데이터베이스가 손상되었다는 점을 확인한 경우에만 백업 후 설정 디렉터리 삭제를 고려해야 합니다. 사용자 디렉터리를 임의로 정리하면 구독 주소, 스크립트, 사용자 지정 규칙과 정책 선택을 함께 잃을 수 있습니다.

“부팅 시 시작”과 “시작할 때 시스템 프록시 활성화”는 서로 다른 옵션입니다. 전자는 클라이언트 실행만 담당하고, 후자는 운영체제의 프록시 설정을 변경합니다. 이동이 잦은 업무용 기기에서는 클라이언트 자동 시작을 켤 수 있지만, 몇 차례 재부팅 동작을 확인한 뒤 네트워크 자동 연결 여부를 결정하는 것이 좋습니다. 웹 인증이 필요한 공용 네트워크에 자주 접속한다면 자동 프록시 활성화로 인증 페이지가 열리지 않을 수 있습니다. 이 경우 시스템 프록시를 잠시 중지해 인증을 완료한 뒤 연결을 복구하세요. TUN 자동 시작도 기본 설정이 안정된 뒤 활성화해 부팅 시 권한이나 DNS 오류가 전체 네트워크에 영향을 주지 않도록 해야 합니다.

포트 설정은 역할을 명확하게 유지하세요

Clash 설정에서 흔히 사용하는 포트는 HTTP 포트, SOCKS 포트와 혼합 포트입니다. 혼합 포트는 하나의 수신 포트에서 HTTP와 SOCKS 요청을 모두 받을 수 있어 대부분의 개인 기기에 적합합니다. 다른 프로그램이 사용하지 않는 포트라면 충분하며 “속도”를 이유로 자주 변경할 필요는 없습니다. LAN 연결을 허용하면 같은 네트워크의 다른 기기가 수신 포트에 접근할 수 있으므로 공유가 꼭 필요할 때만 활성화하고, 수신 주소와 접근 제어 및 시스템 방화벽으로 허용 범위를 제한하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090

위의 기본 설정 조각은 혼합 포트를 활성화하고 로컬 기기만 허용하며 규칙 모드를 사용하고 제어 인터페이스를 로컬로 제한하는 예입니다. 클라이언트에 따라 화면에서 이 필드를 생성할 수 있으므로 직접 편집하기 전에 저장 시 파일을 덮어쓰는지 확인하세요. 제어 인터페이스는 그래픽 화면과 커널이 통신하는 용도이므로 신뢰할 수 없는 네트워크에 직접 노출해서는 안 됩니다. 로그 수준은 일상적으로 info를 선택하면 충분합니다. debug는 진단 정보가 많아져 짧은 문제 해결에 적합하지만, 장기간 켜 두면 로그가 커지고 중요한 정보를 확인하기 어려워집니다.

최소한의 연결 고리로 설치를 확인하세요

기본 확인은 정해진 순서로 진행합니다. 먼저 커널 상태가 실행 중인지 확인하고, 사용할 수 있는 설정을 가져온 다음 프록시 그룹에서 노드를 선택합니다. 이어서 시스템 프록시를 켜고 브라우저로 일반 웹페이지에 접속하세요. 실패하면 먼저 클라이언트의 연결 기록과 로그를 확인합니다. 연결 기록이 전혀 없으면 트래픽이 클라이언트에 들어오지 않은 것입니다. 기록은 있지만 DIRECT로 표시되면 규칙이 DIRECT에 매칭된 것입니다. 프록시 기록은 있으나 핸드셰이크에 실패하면 노드 연결이나 네트워크 환경에 문제가 있을 수 있습니다. 이 최소 흐름이 완료된 뒤 TUN, DNS 가로채기, 스크립트나 복잡한 규칙을 활성화하면 문제 해결이 훨씬 쉬워집니다.

구독 가져오기와 업데이트: 원격 설정의 전체 주기 관리

구독 링크, 설정 파일과 노드 링크의 차이

구독 링크는 일반적으로 서비스 서버가 생성한 설정을 반환하며, 여러 노드, 프록시 그룹, 규칙과 DNS 설정을 포함할 수 있습니다. 단일 노드 링크는 하나의 프록시 노드만 설명하므로 완전한 트래픽 분할 구조를 자동으로 제공하지 않습니다. 로컬 YAML 파일은 특정 시점에 저장된 정적 설정이며 원격 변경을 자동으로 반영하지 않습니다. 가져오기 전에 내용의 유형을 확인하세요. 클라이언트에서 URL 입력을 요구한다면 HTTPS로 시작하는 구독 주소를 입력하고, 파일로 가져온다면 완전한 YAML 파일을 선택해야 합니다. 단일 노드 링크만 있다면 클라이언트가 클립보드 파싱을 지원하는지 확인하거나 기존 설정에 직접 추가해야 합니다.

구독 주소는 설정에 접근할 수 있는 인증 정보와 같으므로 스크린샷, 포럼 또는 공개 저장소에 게시해서는 안 됩니다. 클라이언트는 보통 주소를 로컬 설정 데이터베이스에 저장합니다. 여러 기기에서 동기화할 때는 각 기기에 구독을 따로 가져오거나 서비스 제공자가 제공하는 중앙 관리 방식을 우선 사용하세요. 구독 주소가 포함된 설정 파일을 공개 동기화 디렉터리에 넣지 마세요. 예시 주소는 테스트 도메인을 사용해야 합니다. 예:

https://example.invalid/api/profile/clash?token=xxxx

올바른 가져오기 절차

클라이언트에서 “구독”, “설정” 또는 “Profiles” 페이지를 열고 URL로 새 설정을 만드세요. 링크를 붙여 넣은 뒤 알아보기 쉬운 이름을 지정합니다. 설정 변경 빈도에 따라 업데이트 간격을 정할 수 있지만, 일반적인 사용에서는 몇 분마다 새로 고칠 필요가 없습니다. 저장한 뒤 한 번 수동으로 업데이트하여 클라이언트에 설정 이름, 업데이트 시간 또는 프록시 그룹이 표시되는지 확인하세요. 단순히 “추가됨” 상태만 표시되는지 확인해서는 안 됩니다. 그런 다음 해당 설정으로 전환해 커널을 다시 로드합니다. 일부 클라이언트는 “구독 다운로드”와 “설정 활성화”를 별도 동작으로 나눕니다. 업데이트만 하고 전환하지 않으면 현재 실행 중인 설정은 여전히 이전 버전일 수 있습니다.

가져오기가 끝났다고 해서 이전 설정을 바로 삭제하지 마세요. 먼저 주요 프록시 그룹이 존재하는지, 규칙 모드를 선택할 수 있는지, 자주 사용하는 노드가 표시되는지 확인한 뒤 연결을 테스트하세요. 새 설정이 안정적으로 작동하는 것을 확인한 후에도 단기간 사용할 복구용 이전 설정을 보관하는 것이 좋습니다. 여러 설정을 함께 보관한다면 “일상 구독”, “로컬 규칙 테스트”처럼 명확한 이름을 사용하고 모두 config나 default로 지정하지 마세요. 설정을 바꾸면 프록시 그룹과 규칙도 변경되며, 클라이언트가 이전 정책 선택을 새 설정에 매핑하지 못할 수 있으므로 전환 후 출구 그룹을 다시 확인해야 합니다.

업데이트 실패는 계층별로 점검하세요

구독 업데이트에 실패하면 먼저 오류 유형을 확인하세요. 시간 초과는 클라이언트가 구독 서버에 접근하지 못한다는 뜻일 수 있습니다. 인증서나 시스템 시간이 잘못되면 HTTPS 연결에 영향을 줍니다. 인증되지 않았다는 응답은 주소가 만료되었거나 접근 조건이 바뀌었음을 의미할 수 있습니다. 다운로드는 성공했지만 해석에 실패한다면 반환된 내용이 유효한 설정이 아닐 가능성이 큽니다. 웹 오류 페이지, 인코딩 문제 또는 현재 커널이 인식하지 못하는 필드가 원인일 수 있습니다. 접근 가능한 브라우저 환경에서 구독 주소를 열어 내용을 받을 수 있는지 확인하되, 반환 내용을 공개하지 마세요. 브라우저에서는 접근되는데 클라이언트에서 실패한다면 구독 업데이트가 프록시, DIRECT 또는 현재 프록시를 사용하도록 설정되었는지 확인하세요.

“프록시를 통해 구독 업데이트”에는 흔한 순환 문제가 있습니다. 현재 설정의 모든 노드가 작동하지 않는데 구독 업데이트도 현재 프록시를 거쳐야 하면 새 설정을 가져올 수 없습니다. 이때는 일시적으로 DIRECT 업데이트로 전환하거나 작동하는 예비 설정을 사용해 업데이트하세요. 반대로 현재 네트워크에서 구독 서버에 직접 접근할 수 없다면 사용 가능한 프록시를 통해 업데이트해야 합니다. 클라이언트마다 업데이트 경로의 이름이 다르므로 구독 설정, 전체 설정 또는 네트워크 설정에서 찾아야 하며 같은 주소를 반복해서 다시 추가해서는 안 됩니다.

자동 업데이트에는 복구 여지를 남겨 두세요

시작 시 자동 업데이트는 설정이 안정적이고 기기 네트워크가 신뢰할 수 있는 환경에 적합하지만, 유일한 관리 방식으로 사용해서는 안 됩니다. 원격 설정 생성이 일시적으로 실패하면 자동 업데이트가 정상 설정을 오류 내용으로 바꿀 수 있습니다. 최근에 정상 작동한 설정을 보관하고 적절한 업데이트 간격을 설정하며, 중요한 이동이나 네트워크 전환 전에 수동으로 업데이트하고 테스트하는 것이 안전합니다. 직접 관리하는 로컬 오버라이드 규칙이 있다면 구독 업데이트가 수정 내용을 덮어쓰지 않는지 확인하세요. 클라이언트가 오버라이드, 병합 또는 스크립트를 지원한다면 사용자 지정 내용을 매번 교체되는 구독 파일이 아닌 별도의 계층에 두어야 합니다.

프록시 모드: 규칙, 글로벌과 DIRECT 선택하기

규칙 모드를 일상 사용의 기본값으로 선택하세요

규칙 모드는 요청 대상을 하나씩 확인하고 도메인, IP, 프로세스 또는 규칙 집합에 따라 트래픽을 서로 다른 정책으로 전달합니다. 일반적인 설정에서는 로컬 네트워크와 프록시가 필요 없는 대상은 DIRECT로 보내고, 특정 대상은 프록시 그룹에 전달하며, 매칭되지 않은 요청은 마지막 기본 규칙으로 처리합니다. 장점은 “가장 빠른 노드를 자동 선택”하는 것이 아니라 트래픽 유형마다 서로 다른 경로를 사용하게 하는 데 있습니다. 실제 노드는 매칭된 프록시 그룹이 결정합니다. 대부분의 일상적인 환경에서는 규칙 모드를 유지하는 것이 좋습니다. 접근 범위, LAN 서비스와 앱별 연결 요구를 균형 있게 처리할 수 있기 때문입니다.

규칙 모드에서 “일부 웹사이트는 정상이고 일부는 이상하다”는 현상이 나타나도 바로 글로벌 모드로 바꾸지 마세요. 먼저 연결 기록에서 대상 요청을 찾아 매칭된 규칙과 정책을 확인하세요. 대상이 잘못 DIRECT로 분류되었다면 더 정확한 도메인 규칙을 추가하고, 잘못된 프록시 그룹으로 전달되었다면 규칙의 대상이나 프록시 그룹 선택을 조정해야 합니다. 도메인이 전혀 보이지 않고 IP만 표시된다면 DNS 모드, 스니핑 또는 앱이 주소에 직접 연결하는지 확인하세요. 글로벌 모드는 진단 도구로 사용할 수 있습니다. 글로벌 모드에서 복구된다면 노드 자체는 대체로 정상이고 문제는 규칙이나 DNS에 집중되어 있을 가능성이 큽니다. 글로벌 모드에서도 실패한다면 노드와 트래픽 연결을 먼저 확인하세요.

글로벌 모드는 “성능 향상 모드”가 아닙니다

글로벌 모드는 일반적인 분할 규칙을 적용하지 않고 커널에 들어온 모든 트래픽을 하나의 글로벌 프록시 그룹으로 전달합니다. 노드를 짧게 확인하거나, 아직 규칙에 포함되지 않은 대상에 임시로 접근하거나, 모든 트래픽이 같은 경로를 사용해야 할 때 적합합니다. 글로벌 모드라고 해서 시스템 프록시를 따르지 않는 앱이 자동으로 Clash에 들어오는 것은 아니며 운영체제 권한을 우회하지도 않습니다. 규칙 모드에서 어떤 프로그램의 연결 기록이 전혀 없다면 글로벌 모드로 전환해도 대개 해결되지 않습니다. 이 경우 시스템 프록시, 앱의 프록시 설정 또는 TUN을 확인해야 합니다.

글로벌 모드를 장기간 사용하면 로컬 서비스, 프린터, LAN 기기와 원래 DIRECT로 처리해야 하는 업무까지 프록시를 거칠 수 있습니다. 일부 설정은 LAN 주소를 특별히 처리하지만 모든 클라이언트가 같은 방식으로 동작한다고 가정해서는 안 됩니다. 라우터 관리 페이지, LAN 저장소 또는 개발 환경에 접근할 때 연결 경로가 불필요하게 우회된다면 규칙 모드로 돌아가 로컬 네트워크 대역을 DIRECT로 유지하세요. 글로벌 모드에서 사용하는 출구는 “GLOBAL” 프록시 그룹의 현재 선택에 따라 결정되며 목록의 첫 번째 노드를 자동으로 사용한다는 뜻이 아닙니다.

DIRECT 모드는 복구와 원인 파악에 사용하세요

DIRECT 모드는 커널에 들어온 트래픽을 프록시 노드로 보내지 않습니다. 네트워크 인증, 구독의 DIRECT 업데이트, 대상이 로컬 네트워크에서 접근 가능한지 확인하거나 일반 네트워크를 임시로 복구할 때 유용합니다. 이는 “클라이언트 종료”와 완전히 같지 않습니다. 클라이언트는 시스템 프록시나 TUN 연결을 유지한 채 전달 동작만 DIRECT로 바꿀 수 있습니다. 시스템 프록시 잔여 설정을 점검할 때는 DIRECT 모드와 연결 기능을 완전히 끈 상태를 모두 테스트하세요. DIRECT 모드는 되지만 클라이언트를 종료하면 되지 않는다면 시스템 DNS, 프록시 설정 또는 네트워크 인터페이스 상태가 아직 복구되지 않았을 수 있습니다.

모드 전환 후 확인 방법

모드를 전환한 뒤에는 새 요청을 다시 보내야 하며, 이미 연결된 요청만 보고 판단해서는 안 됩니다. 브라우저는 기존 연결을 재사용할 수 있고 앱도 DNS 캐시를 보관할 수 있으므로 새 시크릿 창을 열거나 대상을 다시 로드하고 앱을 잠시 재시작해 보세요. 그런 다음 연결 목록에서 새 요청에 적용된 모드와 정책을 확인합니다. 클라이언트가 연결 정리를 지원한다면 전환 후 기존 연결을 닫아도 되지만 커널을 자주 재시작할 필요는 없습니다. “모드, 매칭 규칙, 프록시 그룹, 실제 노드, 오류 메시지”를 기록하면 단순히 “열림/안 열림”만 적는 것보다 차이를 훨씬 쉽게 찾을 수 있습니다.

모드를 선택할 때는 “프록시 모드”와 “트래픽 연결 방식”을 구분해야 합니다. 규칙, 글로벌, DIRECT는 커널에 들어온 뒤의 처리 방식을 결정하고, 시스템 프록시와 TUN은 어떤 트래픽이 커널에 들어올 수 있는지를 결정합니다. 두 축은 서로 독립적입니다. 규칙 모드와 TUN을 함께 사용하면 더 많은 앱을 처리할 수 있지만, 글로벌 모드와 시스템 프록시를 함께 사용해도 시스템 프록시를 따르는 소프트웨어만 적용됩니다. 이 점을 이해하면 모순처럼 보이던 많은 현상이 명확해집니다.

규칙 분할: 매칭 순서부터 프록시 그룹 설계까지

규칙은 위에서 아래로 매칭되며 처음 일치한 규칙에서 멈춥니다

Clash의 규칙 목록에는 명확한 순서가 있습니다. 요청은 첫 번째 규칙부터 확인하며, 일치하면 해당 규칙이 지정한 정책을 바로 사용하고 아래 규칙은 더 이상 검사하지 않습니다. 따라서 범위가 정확한 규칙은 보통 앞에 두고, 범위가 넓은 규칙 집합과 마지막 기본 규칙은 뒤에 둡니다. 광범위한 도메인 접미사나 IP 대역을 너무 앞에 배치하면 뒤의 정밀한 규칙은 절대 적용되지 않습니다. 규칙을 점검할 때는 설정에 해당 규칙이 있는지만 확인하지 말고 더 넓은 규칙보다 앞에 있는지 뒤에 있는지도 확인해야 합니다.

자주 사용하는 규칙 유형에는 정확한 도메인, 도메인 접미사, 도메인 키워드, IP 대역, 소스 주소, 대상 포트, 프로세스 이름과 규칙 집합 참조가 있습니다. 도메인 규칙은 커널이 대상 도메인을 확인할 수 있어야 합니다. 요청이 IP로만 표시되면 도메인 규칙이 매칭되지 않을 수 있습니다. IP 규칙에서는 조회 결과와 IPv4, IPv6 차이도 고려해야 합니다. 데스크톱 플랫폼에서는 프로세스 규칙이 유용하지만 시스템 권한과 클라이언트 구현의 영향을 받으므로 핵심 트래픽 분할을 전부 프로세스 식별에 의존해서는 안 됩니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - DOMAIN-KEYWORD,media,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DST-PORT,22,Direct-or-Proxy
  - MATCH,Final

예시에서는 정확한 도메인을 먼저 DIRECT로 보내고, example.org와 그 하위 도메인은 Proxy로, 이름에 media가 포함된 도메인은 Media로 보냅니다. 로컬 네트워크 대역은 DIRECT로 처리하고 대상 포트가 22인 요청은 별도 정책에 전달하며 나머지는 Final이 처리합니다. 정책 이름은 proxy-groups의 이름과 대소문자와 공백까지 완전히 같아야 합니다. no-resolve는 일부 IP 규칙이 매칭을 위해 추가 도메인 조회를 실행하지 않도록 하는 옵션이지만, 적용 여부는 규칙 유형과 설정 목적을 함께 고려해야 합니다.

프록시 그룹으로 규칙과 실제 노드를 분리하세요

규칙은 특정 노드 이름을 직접 지정하기보다 의미가 분명한 프록시 그룹을 가리키는 것이 좋습니다. 예를 들어 규칙은 “Media”, “Work” 또는 “Final”을 가리키고, 프록시 그룹 안에서 실제 노드를 선택하도록 구성합니다. 이렇게 하면 구독 업데이트로 노드가 추가되거나 삭제되어도 규칙을 전부 다시 작성할 필요가 없습니다. 수동 선택 그룹은 사용자가 출구를 직접 결정할 때 적합합니다. 자동 테스트 그룹은 테스트 주소에 주기적으로 접속해 응답에 따라 노드를 선택하고, 장애 조치 그룹은 순서대로 사용 가능한 노드를 시도합니다. 부하 분산 그룹은 설정된 알고리즘에 따라 연결을 나눕니다. 그룹마다 해결하는 문제가 다르므로 이름만 보고 동작을 추측해서는 안 됩니다.

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

url-test는 지정된 테스트 주소에 한 번 요청했을 때의 결과를 측정할 뿐이며, 동영상 대역폭, 장시간 연결 안정성 또는 모든 대상에서의 실제 사용 경험을 의미하지 않습니다. 테스트 주소는 장기간 접근 가능하고 응답 본문이 작으며 실제 사용 경로를 어느 정도 대표해야 합니다. 간격이 너무 짧으면 불필요한 요청이 늘고, 너무 길면 노드 변화를 제때 발견하지 못합니다. tolerance는 지연 시간이 비슷할 때 잦은 전환을 줄여 여러 노드 사이를 반복해서 오가는 현상을 완화합니다. 자동 그룹은 일반적인 접속에 적합하고, 중요한 세션이나 고정 출구가 필요한 업무에는 수동 선택 그룹이 더 적합합니다.

규칙 집합과 원격 제공자

규칙이 많을 때는 rule-providers를 사용해 범주별 규칙을 별도 파일로 나누고 주 설정에서 참조할 수 있습니다. 규칙 집합을 따로 업데이트할 수 있고 재사용도 쉽습니다. 다만 원격 규칙도 다운로드 실패, 형식 비호환과 업데이트에 따른 동작 변경 위험이 있습니다. 규칙 제공자에 적절한 업데이트 간격과 로컬 캐시 경로를 설정하고, 처음 활성화한 뒤 로그에서 다운로드 성공 여부를 확인하세요. 규칙 집합 유형, 동작 유형과 파일 형식이 서로 맞아야 합니다. domain, ipcidr과 classical은 내용 구조가 달라 혼용하면 해석 오류가 발생하거나 규칙이 예상대로 작동하지 않을 수 있습니다.

규칙을 수정할 때는 “최소 범위 수정”을 원칙으로 삼으세요. 먼저 문제가 명확한 도메인에 정확한 규칙 하나를 추가하고 매칭 결과를 확인한 뒤 도메인 접미사나 규칙 집합으로 범위를 넓힐지 결정합니다. 하위 도메인 하나에 문제가 있다고 최상위 도메인 전체를 같은 정책으로 보내거나 최종 MATCH를 앞에 배치해서는 안 됩니다. 클라이언트가 오버라이드나 규칙 병합을 지원한다면 로컬 규칙을 지속적인 오버라이드 계층에 넣어 구독 업데이트 후 사라지지 않게 하세요. DNS와 규칙이 서로 영향을 주는 방식은 Clash DNS 설정 자세히 알아보기에서 이어서 확인할 수 있습니다.

TUN과 DNS: 더 많은 트래픽을 연결하고 일관된 조회 유지하기

TUN은 트래픽 진입 경로 문제를 해결합니다

시스템 프록시는 앱이 운영체제의 프록시 설정을 직접 읽어야 작동합니다. 브라우저와 대부분의 데스크톱 앱은 지원하지만 게임, 명령줄 도구, 일부 스토어 앱과 사용자 지정 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 완전히 무시할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 통해 더 많은 IP 트래픽을 커널로 보냅니다. 따라서 더 넓은 범위의 앱을 처리할 수 있습니다. TUN은 새로운 프록시 모드가 아닙니다. 트래픽이 TUN으로 들어온 뒤에도 규칙, 글로벌 또는 DIRECT 모드로 처리되며 실제 출구는 여전히 프록시 그룹이 결정합니다.

TUN을 처음 활성화할 때 클라이언트는 관리자 권한, 네트워크 확장 권한 또는 VPN 권한을 요구할 수 있습니다. Windows에서는 다른 가상 네트워크 어댑터, 기업 보안 소프트웨어와 기존 VPN도 확인해야 합니다. macOS에서는 네트워크 확장이 시스템에서 허용되었는지 확인하세요. Android와 iOS에서는 TUN이 보통 시스템 VPN으로 표시되므로 같은 인터페이스를 사용하는 다른 앱과 충돌할 수 있습니다. 활성화 직후 모든 네트워크가 끊기면 먼저 TUN을 꺼서 기본 연결을 복구한 뒤 인터페이스 생성, 라우팅 입력과 DNS 수신 오류를 로그에서 확인해야 합니다. 계속 노드만 바꾸는 것은 올바른 해결 방법이 아닙니다.

주요 TUN 매개변수의 역할

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

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

auto-route는 커널이 필요한 라우팅을 자동으로 입력하게 하고, auto-detect-interface는 현재 외부 연결 네트워크 인터페이스를 식별합니다. 유선, 무선과 모바일 핫스팟 사이를 전환하는 기기에 적합합니다. stack은 TUN이 사용할 네트워크 스택 구현을 결정하며 mixed가 일반적인 선택입니다. 특정 플랫폼에서 호환 문제가 발생하면 클라이언트 문서에 따라 system, gvisor 또는 mixed를 테스트하되 한 번에 하나의 매개변수만 바꾸세요. dns-hijack는 조건에 맞는 DNS 요청을 커널로 보내 앱이 Clash DNS를 우회하는 상황을 줄입니다.

예시의 주소는 필드 구조를 설명하기 위한 것일 뿐입니다. 실제 DNS 서버는 현재 네트워크에서의 접근성, 개인정보 보호 요구와 설정 출처를 함께 고려해 선택해야 합니다. nameserver와 fallback을 무작정 많이 추가하지 마세요. 서버가 많다고 반드시 안정적인 것은 아니며 조회 경로와 문제 해결 결과가 오히려 복잡해질 수 있습니다. 구독에서 이미 DNS 구간을 제공한다면 먼저 기존 로직을 이해한 뒤 수정하세요. 클라이언트의 그래픽 스위치로 TUN 설정을 생성할 때도 구독 파일과 전체 설정에 서로 충돌하는 DNS 매개변수를 중복해서 작성하지 않도록 주의해야 합니다.

fake-ip와 redir-host의 차이

fake-ip 모드는 도메인에 대해 예약 주소 대역의 매핑 주소를 반환하고, 커널은 매핑 관계를 통해 원래 도메인을 보존합니다. 그 결과 도메인 규칙을 더 이른 단계에서 매칭할 수 있습니다. 일반적으로 트래픽 분할 능력이 좋지만 일부 LAN 서비스, 특수 앱 또는 실제 조회 결과에 의존하는 프로그램은 fake-ip-filter에 추가해야 할 수 있습니다. redir-host는 전통적인 조회 흐름에 더 가깝습니다. 실제 IP를 반환한 뒤 조회 결과를 바탕으로 전달하므로 호환 방식은 직관적이지만 도메인 정보 보존과 매칭 경로는 다릅니다. 선택할 때는 클라이언트 기본값과 실제 호환성을 기준으로 판단하고 특정 이름을 선호한다는 이유로 자주 전환할 필요는 없습니다.

“웹페이지는 열리는데 특정 LAN 기기를 찾지 못한다”거나 “앱 로그인은 실패하지만 브라우저는 정상이다”라는 현상이 나타나면 DNS 로그, fake-ip 필터 항목과 로컬 도메인을 확인해 보세요. 필터는 모든 도메인을 제외하기보다 특정 로컬 도메인 접미사처럼 가능한 한 정밀하게 설정해야 합니다. 수정 후에는 앱 자체의 DNS 캐시를 지우거나 연결을 다시 만들어야 이전 조회 결과가 계속 사용되지 않습니다. 시스템에서 다른 암호화 DNS, 브라우저 보안 DNS 또는 기업용 DNS 클라이언트가 실행 중이라면 Clash의 조회 경로를 우회하는지도 확인해야 합니다.

TUN 충돌 원인 찾기

TUN을 켠 뒤 네트워크가 완전히 끊기면 먼저 가상 인터페이스가 정상적으로 만들어졌는지, 기본 라우팅이 입력되었는지, 현재 물리 인터페이스를 올바르게 인식했는지 확인하세요. 일부 앱만 이상하다면 해당 앱의 요청이 연결 목록에 들어오는지, TUN 라우팅에서 제외되었는지 확인합니다. LAN 접근에 문제가 있으면 사설 네트워크 대역 규칙과 라우팅 제외 항목을 살펴보세요. 절전 모드에서 깨어난 뒤 작동하지 않는다면 네트워크 인터페이스가 바뀌었지만 라우팅이 갱신되지 않았을 수 있습니다. 먼저 TUN을 껐다가 다시 켜서 복구되는지 확인한 뒤 인터페이스 자동 감지와 클라이언트 업데이트를 검토하세요.

컨테이너, 가상 머신, 게임 플랫폼 가속 도구 또는 기업 VPN을 동시에 실행하면 라우팅 테이블이 복잡해집니다. 문제를 해결할 때는 먼저 라우팅을 변경하는 다른 프로그램을 잠시 종료하고 Clash TUN만 실행했을 때 정상인지 확인하세요. 그다음 하나씩 다시 실행해 충돌이 어느 단계에서 발생하는지 관찰합니다. 업무 환경에서 기업 VPN 사용이 강제된다면 라우팅을 임의로 덮어쓰지 말고 시스템 프록시를 사용하거나 네트워크 관리 정책을 따라야 합니다. TUN의 목적은 연결 범위를 넓히는 것이지 관리되는 네트워크 정책을 강제로 바꾸는 것이 아닙니다.

일상 유지 관리와 문제 해결: 안정적인 점검 순서 만들기

유지 관리의 핵심은 설정, 커널과 시스템 상태입니다

Clash 클라이언트가 안정적으로 실행되고 있다면 설정을 자주 지우거나 노드를 바꿀 필요가 없습니다. 일상적인 관리는 구독 필요 시 업데이트, 클라이언트와 커널의 유지 관리 상태 확인, 로그 용량 정기 점검, 복구 가능한 설정 출처 보존이라는 네 가지로 정리할 수 있습니다. 구독 업데이트 후에는 자주 사용하는 프록시 그룹만 간단히 확인하면 됩니다. 클라이언트를 업데이트하기 전에는 현재 설정 위치와 주요 스위치를 기록하고, 업데이트 후에는 커널 실행, 시스템 프록시와 TUN 상태를 먼저 확인하세요. 덮어써서 설치해도 구독이 보통 바뀌지는 않지만, 사용자 지정 규칙과 로컬 설정은 별도로 백업해야 합니다.

로그는 문제를 찾기 위한 것이며 장기간 debug 수준으로 유지할 필요는 없습니다. 정상 실행 시에는 info를 사용하면 설정 로드, 수신 포트, 구독 업데이트와 연결 오류를 확인할 수 있습니다. 문제가 생기면 한 번 재현한 뒤 해당 시점 전후의 로그를 읽으세요. 마지막 줄을 계속 보는 것보다 첫 번째로 명확한 오류를 찾는 것이 효과적입니다. 이후 오류는 앞선 실패의 연쇄 결과일 수 있기 때문입니다. 로그를 공유하기 전에는 구독 주소, 노드 인증 정보와 개인 경로를 삭제하고 오류 유형, 관련 필드와 필요한 맥락만 남기세요.

문제 범위로 장애 위치 판단하기

모든 앱이 인터넷에 연결되지 않으면 먼저 DIRECT 모드로 전환하고 TUN을 끈 뒤 일반 네트워크가 작동하는지 확인하세요. 이어서 커널 상태와 포트 사용 여부를 확인합니다. 시스템 프록시를 따르는 앱만 정상이고 다른 앱이 이상하다면 TUN이나 앱 자체의 프록시 설정을 점검해야 합니다. 웹사이트 하나만 이상하다면 매칭 규칙, DNS 결과와 대상 서비스 상태를 확인하세요. 특정 노드 하나만 문제라면 같은 프록시 그룹의 다른 노드로 비교합니다. 구독은 업데이트되지 않지만 기존 연결이 작동한다면 문제를 구독 주소와 업데이트 경로로 한정하고 클라이언트 전체를 초기화하지 마세요.

지연 시간 테스트는 테스트 주소에 대한 짧은 요청 결과만 보여 줍니다. 지연 시간이 낮은 노드도 대역폭, 패킷 손실, 혼잡 또는 대상 경로에 따라 동영상이나 대용량 파일에서 성능이 떨어질 수 있습니다. 반대로 지연 시간이 조금 높은 노드가 더 안정적일 수도 있습니다. 실제 사용 경험은 연결 성공률, 지속 전송, 대상 서비스 응답과 일정 기간의 안정성을 함께 봐야 합니다. 지연 시간 수치를 해석하는 원리와 주의점은 Clash 지연 시간 테스트 수치 읽는 법에서 확인할 수 있습니다.

포트, 시간과 캐시는 놓치기 쉬운 기본 항목입니다

포트가 이미 사용 중이면 커널이 수신할 수 없으며 로그에 address already in use와 같은 메시지가 나타나는 경우가 많습니다. 먼저 이전 클라이언트와 중복 커널 프로세스를 종료한 뒤 포트가 해제되었는지 확인하세요. 시스템 시간이 크게 어긋나면 HTTPS 인증서 검증과 일부 프로토콜 핸드셰이크가 실패할 수 있으므로 신뢰할 수 있는 시간 동기화를 활성화해야 합니다. DNS와 연결 캐시는 변경 사항이 즉시 반영되지 않게 만들 수 있습니다. 규칙을 바꾼 뒤에도 기존 연결은 이전 정책을 계속 사용할 수 있고, DNS를 수정한 뒤에도 앱이 이전 결과를 보관할 수 있습니다. 테스트할 때는 연결을 새로 만들고 필요하면 대상 앱만 다시 시작하세요. 매번 기기 전체를 재부팅할 필요는 없습니다.

시스템 프록시를 끄지 못할 때는 운영체제 네트워크 설정에서 직접 복구할 수 있습니다. Windows에서는 자동 구성 스크립트와 수동 프록시가 동시에 남아 있는지도 확인해야 합니다. macOS에서는 현재 네트워크 서비스의 프록시 항목을 확인하세요. 클라이언트가 비정상 종료되면 TUN 라우팅은 보통 정리되지만, 드물게 가상 인터페이스나 라우팅 상태가 잠시 남을 수 있습니다. 클라이언트를 다시 실행한 뒤 정상적으로 한 번 종료하는 방법이 드라이버를 바로 삭제하는 것보다 안전한 경우가 많습니다. 모바일에서는 시스템 VPN 설정에서 연결을 끊은 다음 클라이언트에 다시 권한을 부여할 수 있습니다.

재현 가능한 문제 해결 기록 만들기

효과적인 문제 해결 기록에는 최소한 운영체제, 클라이언트 이름, 사용한 연결 방식, 프록시 모드, 문제가 발생한 시간, 대상 앱, 매칭된 정책과 주요 로그가 포함되어야 합니다. “작동하지 않는다”는 설명만으로는 구독, 규칙, DNS와 노드 문제를 구분할 수 없습니다. “규칙 모드에서 브라우저 요청이 DIRECT에 매칭되고, 글로벌 모드에서 Proxy에 매칭된 뒤 복구됨”이라고 기록하면 바로 규칙 계층을 가리킬 수 있습니다. 각 테스트에서는 한 번에 하나의 변수만 바꾸고 변경 전후 결과를 기록하세요. 복잡한 문제는 현재 설정을 복사해 테스트용 사본을 만든 뒤 일상 설정에 임시 변경을 계속 쌓지 않는 것이 좋습니다.

클라이언트 업데이트 후 새 문제가 생겼다면 먼저 설정이 여전히 선택되어 있는지, 커널이 바뀌었는지, TUN 권한이 유지되는지 확인한 뒤 롤백을 고려하세요. 기존 클라이언트의 유지 관리가 중단되었더라도 장기간 계속 사용하는 것은 바람직하지 않습니다. 새 클라이언트로 이전한 후 시스템 프록시, 프록시 그룹과 사용자 지정 오버라이드를 다시 확인하세요. 원본, Meta와 mihomo의 관계는 Clash 커널 버전 차이와 선택 방법에서 확인할 수 있습니다. 클라이언트 버전 변화와 커널 차이를 혼동하지 않도록 주의하세요.

고급 학습 경로: 그래픽 설정에서 관리 가능한 설정으로

먼저 설정을 읽는 법을 익힌 뒤 설정을 다시 작성하세요

고급 설정의 첫 단계는 빈 파일을 만드는 것이 아니라 이미 작동하는 설정을 이해하는 것입니다. 먼저 기본 수신 설정, DNS, 프록시 제공자, 프록시 그룹, 규칙 제공자와 최종 규칙을 식별한 다음 실제 요청 하나가 어떤 필드를 거치는지 추적하세요. 구독이 생성한 설정은 사본을 만들고, 사본에서 최소한의 변경을 한 뒤 클라이언트의 설정 검사 기능으로 확인합니다. YAML은 들여쓰기에 민감합니다. 목록 항목, 객체 계층과 문자열의 특수 문자가 해석 실패를 일으킬 수 있으므로 편집기에서는 공백 들여쓰기를 사용하고 일반 문자가 자동으로 인쇄용 기호로 바뀌지 않도록 주의하세요.

설정 분할은 유지 관리 경계를 중심으로 설계해야 합니다. 구독은 원격 노드를 담당하고, 로컬 오버라이드는 개인 규칙을 담당하며, 규칙 제공자는 재사용 가능한 분류를 담당하고, 전체 설정은 기기 수준의 포트, TUN과 화면 동작을 담당하게 하세요. 구독 업데이트마다 교체되는 파일 하나에 모든 내용을 몰아넣지 마세요. 클라이언트가 merge, override 또는 스크립트를 지원한다면 먼저 병합 순서를 확인해야 합니다. 같은 이름의 필드가 덮어쓰기, 추가 또는 깊은 병합 중 어떤 방식으로 처리되는지가 최종 설정에 직접 영향을 줍니다. 변경 후에는 입력 조각만 보지 말고 클라이언트가 실제로 생성해 커널에 전달하는 설정을 확인하세요.

프록시 제공자로 동적 노드를 관리하세요

proxy-providers:
  main-provider:
    type: http
    url: https://example.invalid/provider.yaml
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: Main
    type: select
    use:
      - main-provider
    proxies:
      - DIRECT

proxy-providers를 사용하면 노드 출처를 주 설정과 분리할 수 있으며, 주 설정에서는 use로 제공자를 참조합니다. 원격 파일은 커널이 지원하는 provider 형식이어야 하고, path는 로컬 캐시 위치를 지정하며 업데이트 간격은 다시 가져오는 빈도를 제어합니다. 상태 확인은 지정된 테스트 주소에 대한 노드 접근 가능성을 판단하지만 모든 대상에서의 실제 사용 경험을 보장하지는 않습니다. 여러 제공자를 함께 사용할 때는 용도별로 프록시 그룹을 만들면 되며 모든 노드를 하나의 거대한 목록에 넣을 필요는 없습니다. 제공자 업데이트에 실패해도 로컬 캐시를 계속 사용할 수 있는 경우가 많으므로 캐시 경로는 클라이언트가 쓰기 가능하고 유지되는 위치에 두어야 합니다.

외부 제어 인터페이스와 LAN 공개를 별도로 관리하세요

external-controller를 사용하면 그래픽 화면이나 관리 패널이 커널 상태를 읽고 전환 작업을 실행할 수 있습니다. 개인용 컴퓨터에서는 우선 루프백 주소로 수신하고, 다른 기기에서 관리해야 할 때만 LAN 수신을 고려하세요. 이 경우에도 접근 인증 정보, 시스템 방화벽과 신뢰할 수 있는 네트워크 대역을 함께 설정해야 합니다. allow-lan은 프록시 포트에 LAN 기기가 연결할 수 있는지를 제어하며 제어 인터페이스와는 다른 스위치입니다. 프록시 포트를 공개한다고 제어 인터페이스까지 공개해야 하는 것은 아니며 그 반대도 마찬가지입니다. LAN을 대상으로 수신하는 모든 설정은 용도와 접근 범위를 명확히 해야 합니다.

소프트 라우터나 서버에서 실행할 때는 커널을 어떤 사용자로 시작할지, 설정과 캐시 디렉터리를 누가 쓸 수 있는지, 서비스 실패 후 어떻게 재시작할지도 결정해야 합니다. 터미널에서 프로세스를 장시간 실행해 두는 것보다 시스템 서비스 관리자를 사용하는 편이 안정적입니다. 커널을 업데이트하기 전에는 현재 실행 파일과 설정을 보존하고, 먼저 설정 검사를 실행한 뒤 서비스를 재시작해 로그를 확인하세요. 컨테이너 배포에서는 포트 매핑, 네트워크 모드, TUN 장치 권한과 설정 볼륨을 명확히 지정해야 하며 호스트의 전체 디렉터리를 컨테이너에 그대로 매핑해서는 안 됩니다.

DNS, 스니핑과 규칙을 하나의 시스템으로 설계하세요

고급 설정에서는 fake-ip, DNS 가로채기, 도메인 스니핑과 규칙 집합을 함께 활성화하는 경우가 많습니다. 공통 목표는 도메인 정보를 최대한 보존해 트래픽을 올바르게 분류하는 것이지만, 중복되거나 충돌하는 설정은 오판을 늘릴 수 있습니다. 스니핑은 일부 HTTP, TLS 또는 QUIC 트래픽에서 도메인을 복원해 IP에 직접 연결하는 앱을 보완할 수 있습니다. 업무 내용을 복호화하는 기능은 아니며 모든 프로토콜에서 도메인을 얻을 수 있는 것도 아닙니다. 먼저 클라이언트의 기본 범위에서 시작하고 문제가 명확할 때만 포트나 제외 항목을 조정하세요.

DNS 경로를 설계할 때는 세 가지 질문을 정리하세요. 시스템 요청은 누구에게 전달되는가, 커널은 어떤 상위 DNS 서버에 조회하는가, 조회 결과는 규칙에 어떻게 참여하는가입니다. nameserver-policy를 사용하면 특정 도메인에 지정된 DNS 서버를 적용할 수 있지만, 범위를 정확하게 설정해 많은 조회가 부적절한 상위 서버로 전송되지 않게 해야 합니다. fallback-filter는 어떤 결과를 보조 조회 로직으로 보낼지 판단하는 기능이므로 지리 정보, 네트워크 대역과 도메인 조건을 함께 이해해야 합니다. 관련 필드의 전체 관계는 nameserver, fallback과 가로채기 매개변수 설명에서 확인할 수 있습니다.

자신만의 변경 절차를 만드세요

관리 가능한 설정을 위해 고정된 절차를 정하세요. 현재 정상 작동하는 설정을 복사하고 이번 변경이 하나의 문제만 해결한다는 점을 적습니다. 수정 후 문법 검사를 실행하고, DIRECT로 복구할 수 있는 환경에서 테스트용 설정을 로드하세요. 연결 기록, 규칙 매칭과 로그를 확인한 뒤 안정적인 경우에만 일상 설정에 병합합니다. 규칙 집합과 프록시 제공자는 출처, 용도와 업데이트 방식을 기록해 두세요. 더 이상 사용하지 않는 필드를 삭제하고 그래픽 설정, 오버라이드 파일과 구독에서 같은 기능을 중복 정의하지 않도록 합니다.

학습 순서는 세 가지 축으로 진행할 수 있습니다. 첫 번째는 규칙 축으로 DOMAIN, IP-CIDR, PROCESS-NAME, RULE-SET과 MATCH의 매칭 범위를 익힙니다. 두 번째는 네트워크 축으로 시스템 프록시, TUN, 라우팅, DNS와 IPv6를 이해합니다. 세 번째는 운영 축으로 설정 분할, 로그, 서비스 관리와 복구를 익힙니다. 이 세 축을 마친 뒤 mihomo의 확장 프로토콜과 특수 규칙 유형을 살펴보세요. 먼저 mihomo 커널 기능 차이를 읽고 어떤 필드가 현재 커널에 속하는지 확인한 다음 설정에 추가할지 결정할 수 있습니다.