Clash / Mihomo 설정 메모

Clash 처음부터 끝까지 익히는 사용 설명서

핵심 개념부터 클라이언트 선택, 설치, 구독 가져오기, 프록시 모드, 규칙 분기, TUN, DNS와 일상적인 유지 관리까지 순서대로 진행합니다. 처음 연결을 빠르게 완료하려면 먼저 빠른 시작 가이드를 따라 하세요. 설정이 적용되는 이유와 문제를 어느 단계부터 점검해야 하는지 이해하려면 이 페이지의 장을 순서대로 읽으면 됩니다.

단계별 학습 경로 Windows · macOS · Android · iOS · Linux 규칙 · DNS · TUN · 유지 관리

1장

핵심 개념: 연결이 거치는 경로부터 파악하기

클라이언트, 코어, 설정 파일의 역할

Clash 생태계는 일반적으로 세 부분으로 구성됩니다. 그래픽 클라이언트는 버튼, 설정 관리 및 시스템 권한을 담당하고, Mihomo 같은 코어는 포트 수신, 규칙 해석, 프록시 연결 수립과 트래픽 전달을 담당합니다. 설정 파일은 노드, 프록시 그룹, 규칙, DNS 및 TUN 매개변수를 정의합니다. 사용자가 화면에서 ‘시스템 프록시’나 ‘TUN 모드’를 누르면 실제로는 클라이언트가 시스템 네트워크 설정을 변경하고 해당 매개변수를 코어에 전달해 실행합니다. 이 관계를 이해하면 문제를 해결할 때 화면의 연결 스위치만 바라보지 않게 됩니다. 화면에 실행 중이라고 표시되는 것은 코어 프로세스가 시작되었다는 뜻일 뿐, 구독이 유효하거나 올바른 정책을 선택했거나 DNS가 정상이고 대상 앱이 프록시 경로를 사용한다는 의미는 아닙니다.

그래픽 클라이언트와 코어는 같은 버전 개념으로 볼 수 없습니다. 클라이언트 업데이트는 주로 화면, 플랫폼 호환성 및 설정 관리 기능을 개선하고, 코어 업데이트는 프로토콜, 규칙 동작, DNS와 네트워크 스택에 중점을 둡니다. 일부 클라이언트는 코어 업데이트 기능을 내장하고, 일부는 설치 패키지에 코어를 함께 포함합니다. 일상적인 사용에서 모든 업데이트를 따라갈 필요는 없지만, 설정 필드를 인식하지 못하거나 프로토콜 핸드셰이크에 실패하거나 새 시스템과의 호환 문제가 발생하면 클라이언트와 코어의 상태를 따로 확인해야 합니다. 둘을 하나의 ‘Clash 버전’으로 묶어 판단하지 마세요.

트래픽 진입점, 정책 판단, 출구

일반적인 연결은 네 단계로 나눌 수 있습니다. 첫째, 브라우저나 앱이 요청을 시스템 프록시 포트로 전달하거나 TUN 가상 네트워크 카드가 요청을 가로챕니다. 둘째, 코어가 대상 도메인, IP, 프로세스 또는 네트워크 유형을 해석합니다. 셋째, 규칙을 위에서부터 매칭해 요청을 특정 프록시 그룹으로 보냅니다. 넷째, 프록시 그룹이 실제 프록시 노드, 직접 연결 또는 거부 동작을 선택합니다. 어느 한 단계라도 끊기면 겉으로는 웹페이지가 열리지 않는 현상으로 나타날 수 있습니다. 시스템 프록시가 꺼져 있으면 진입점 문제이고, 규칙 순서가 잘못되면 판단 문제이며, 노드를 사용할 수 없으면 출구 문제입니다. DNS 응답 이상은 판단 이전 단계에서 발생할 수도 있습니다.

일반적으로 HTTP, SOCKS5 및 mixed-port를 수신 포트로 사용합니다. HTTP 포트는 HTTP 프록시를 명시적으로 지원하는 프로그램에 적합하고, SOCKS5 포트는 SOCKS를 지원하는 도구에 적합합니다. mixed-port는 하나의 포트에서 두 종류의 요청을 모두 받을 수 있습니다. 대부분의 그래픽 클라이언트가 이 포트를 관리하므로 일반 사용자가 직접 수정할 필요는 없습니다. 다른 프로그램이 포트를 사용 중이거나, 로컬 네트워크 장치를 연결하거나, 명령줄 도구에서 프록시를 직접 지정해야 할 때 현재 수신 주소와 포트를 확인하면 됩니다. 127.0.0.1에서 수신하면 로컬 컴퓨터에서만 접근할 수 있습니다. 로컬 네트워크 접근을 허용하면 연결 범위가 넓어지므로 방화벽과 접근 제어도 함께 확인해야 합니다.

설정, 구독, 실행 상태는 서로 다릅니다

구독은 원격에서 관리되는 설정 출처이고, 설정 파일은 클라이언트가 다운로드해 로컬에 저장한 실제 내용입니다. 실행 상태는 코어가 특정 설정을 불러온 뒤의 결과입니다. 구독 주소에 정상적으로 접근할 수 있어도 반환된 내용이 현재 코어의 문법에 맞는다는 보장은 없습니다. 설정을 성공적으로 해석했더라도 포함된 노드가 만료되었을 수 있고, 노드가 연결되더라도 규칙이 요청을 직접 연결로 보낼 수 있습니다. 점검할 때는 ‘구독 업데이트 성공 여부 → 설정 로드 성공 여부 → 프록시 그룹에 선택 가능한 항목이 있는지 → 요청이 예상 규칙에 매칭되었는지 → 출구를 사용할 수 있는지’ 순서로 확인하세요. 단순히 전체 스위치를 반복해서 켜고 끄는 것보다 단계별 점검이 빠릅니다.

단계 담당 내용 일반적인 증상 우선 점검할 항목
클라이언트 화면, 권한, 시스템 설정 스위치를 켤 수 없음, 시작 직후 종료됨 설치 출처, 시스템 권한, 로그
코어 수신, 매칭, 전달 포트가 없음, 설정 로드 실패 코어 로그, 포트 사용 여부, 문법
설정 노드, 프록시 그룹, 규칙, DNS 선택 가능한 노드 없음, 규칙 동작 이상 구독 업데이트 시간, 설정 내용
시스템 네트워크 트래픽이 프록시로 들어가는 경로 브라우저는 되지만 다른 앱은 되지 않음 시스템 프록시, TUN, 앱 프록시 설정

이 장을 마친 뒤에는 다음 원칙을 기억하세요. 연결 문제는 단일 스위치의 문제가 아닙니다. 이후의 모든 설정은 ‘진입점, 판단, 출구’라는 경로 안에서 이해해야 합니다. 그러면 Windows, macOS, Android, iOS, Linux 중 어떤 환경을 사용하더라도 화면 이름이 달라질 뿐 점검 순서는 일관되게 유지할 수 있습니다.

2장

클라이언트 선택: 플랫폼, 권한, 유지 관리 방식으로 결정하기

코어를 직접 실행하기보다 그래픽 클라이언트를 우선 사용

일반적인 데스크톱과 모바일 기기에서는 그래픽 클라이언트를 우선 사용하세요. 그래픽 클라이언트는 설정 저장, 시스템 프록시, 시작 시 실행, 로그 확인, 코어 시작·중지와 권한 요청을 처리하며, 문제가 발생했을 때 현재 상태도 쉽게 확인할 수 있습니다. 이 사이트는 모든 플랫폼에서 Clash Plus를 우선 추천합니다. 통합된 화면에서 구독 가져오기, 정책 전환과 기본 네트워크 인계를 처리하려는 사용자에게 적합합니다. Windows와 macOS에서는 Clash Verge Rev, FlClash도 선택할 수 있습니다. Windows에서는 Clash Nyanpasu도 사용할 수 있으며, 유지 관리가 중단된 Clash for Windows는 보관용 선택지로 남겨 둡니다. macOS에는 유지 관리가 중단된 ClashX Meta도 있습니다. 전체 클라이언트 목록, 플랫폼별 진입점과 최신 설치 패키지는 다운로드 페이지에서 확인하세요.

Android에서는 Clash Plus, Clash Meta for Android, FlClash 및 Surfboard 중에서 선택할 수 있습니다. 모바일에서는 화면보다 시스템 VPN 권한, 백그라운드 실행 제한과 배터리 절전 정책을 먼저 확인해야 합니다. iOS에서는 Clash Plus의 App Store 버전을 사용하며, 시스템이 VPN 설정을 통해 트래픽을 인계합니다. Linux 데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 사용할 수 있습니다. 서버, 라우터, 컨테이너와 데스크톱 환경이 없는 장치에는 Mihomo 코어를 직접 배포하고 설정 파일로 관리하는 방식이 더 적합합니다.

선택할 때 확인할 세 가지 실제 조건

첫째는 시스템 아키텍처입니다. Windows는 보통 x64이고 일부 장치는 ARM64입니다. Apple 칩을 사용하는 Mac은 Apple Silicon 또는 ARM 아키텍처 패키지를 선택하고, 구형 Intel Mac은 x64 패키지를 선택하세요. Linux는 배포판 형식뿐 아니라 CPU 아키텍처도 확인해야 합니다. AMD64, ARM64, ARMv7, MIPS 패키지를 서로 바꿔 사용할 수 없습니다. 시스템 아키텍처를 모를 때는 파일명으로 추측하지 말고 시스템 정보에서 먼저 확인하세요. 설치 패키지를 다운로드했지만 시작할 수 없다면 아키텍처 불일치가 우선 점검 항목입니다.

둘째는 인계해야 할 앱의 범위입니다. 브라우저와 시스템 프록시를 따르는 프로그램만 프록시로 연결하려면 일반 시스템 프록시로 충분합니다. 게임, 명령줄 도구, 스토어 앱, 가상 머신 또는 시스템 프록시 설정을 읽지 않는 소프트웨어에는 TUN이 필요할 수 있습니다. 셋째는 유지 관리 방식입니다. 데스크톱 사용자는 일반적으로 시각적인 구독 업데이트와 정책 선택을 원하고, 서버 사용자는 설정 파일, 서비스 프로세스, 원격 로그와 자동 재시작을 더 중시합니다. 기능이 가장 많은 클라이언트가 반드시 가장 안정적인 것은 아닙니다. 현재 요구를 충족하고 업데이트 경로가 명확하며 로그를 읽기 쉬운지가 더 중요합니다.

사용 환경 권장 선택 중점 점검
Windows / macOS 일상적인 데스크톱 Clash Plus 우선, Clash Verge Rev와 FlClash도 비교 가능 아키텍처, 시스템 프록시, TUN 권한
Android 스마트폰 또는 태블릿 Clash Plus、Clash Meta for Android、FlClash、Surfboard VPN 승인, 백그라운드 제한, 배터리 절전 정책
iPhone / iPad Clash Plus App Store 버전 VPN 설정, 주문형 연결, 시스템 네트워크
Linux 데스크톱 Clash Verge Rev 또는 FlClash 배포판 형식, 데스크톱 권한, 아키텍처
서버 및 라우터 Mihomo 코어 설정 경로, 서비스 관리, 라우팅 및 방화벽

여러 클라이언트가 동시에 시스템을 인계하지 않도록 하기

한 장치에 여러 클라이언트를 설치해 비교할 수는 있지만 시스템 프록시나 TUN을 동시에 활성화해서는 안 됩니다. 두 코어가 수신 포트를 두고 경쟁할 수 있고, 두 클라이언트가 시스템 프록시 설정을 번갈아 덮어써 화면상으로는 켜져 있어도 실제 포트는 다른 프로세스를 가리킬 수 있습니다. 클라이언트를 바꾸기 전에 기존 클라이언트의 시스템 프록시와 TUN을 끄고 프로세스가 종료되었는지 확인한 다음 새 클라이언트를 시작하세요. 새 클라이언트에서 포트 사용 중 메시지가 표시되면 무작정 임의의 포트로 바꾸지 말고 어떤 프로세스가 사용 중인지 확인하세요. 브라우저, 환경 변수 또는 다른 도구가 여전히 기존 포트를 가리킬 수 있습니다.

보관용 클라이언트는 이전 설정과의 호환이나 임시 마이그레이션에는 적합하지만 새 설치의 기본 출발점으로는 적합하지 않습니다. 유지 관리가 중단되었다고 해서 기존 설치가 즉시 작동하지 않는 것은 아니지만 운영 체제 업그레이드, 프로토콜 변경과 코어 필드 업데이트로 호환 문제가 점차 발생할 수 있습니다. 마이그레이션할 때는 먼저 로컬 추가 규칙을 내보내고 정책 선택과 포트 설정을 기록한 뒤 새 클라이언트에서 구독을 가져오세요. 프로그램 폴더 전체를 그대로 복사하면 이전 코어, 캐시와 시스템 통합 상태까지 함께 가져오게 되므로 피해야 합니다.

3장

설치 및 초기화: 되돌릴 수 있는 기본 상태부터 만들기

설치 전 충돌 상태 정리

설치하기 전에 실행 중인 다른 프록시 클라이언트를 종료하고 시스템 프록시, TUN 또는 VPN 설정을 끄세요. Windows에서는 시스템 네트워크 설정에서 수동 프록시가 이전 포트를 가리키고 있지 않은지 확인할 수 있습니다. macOS에서는 현재 네트워크 서비스의 프록시 옵션을 확인하세요. 모바일에서는 상태 표시줄의 VPN이 다른 앱에 의해 유지되고 있지 않은지 확인합니다. 기존 클라이언트를 보관해도 문제는 없지만, 첫 초기화 단계에서는 하나의 프로그램만 네트워크를 제어하게 하는 것이 좋습니다. 설치 후 네트워크에 접근할 수 없을 때 문제가 새 클라이언트에서 발생했는지 명확히 판단할 수 있습니다.

다운로드할 때 운영 체제와 아키텍처에 맞는 파일을 선택하세요. Windows 설치 패키지는 일반적으로 설치 마법사를 통해 사용자 디렉터리나 프로그램 디렉터리에 파일을 씁니다. macOS에서는 앱을 ‘응용 프로그램’ 폴더에 넣고, 처음 실행할 때 시스템의 개인정보 보호 및 보안 설정에서 확인해야 할 수 있습니다. Linux의 deb 또는 rpm 패키지는 배포판에 맞아야 하며, 포터블 패키지와 코어 압축 파일은 경로와 실행 권한을 직접 지정해야 합니다. Android 설치 후에는 VPN 권한을 요청하고, iOS도 App Store에서 설치한 뒤 처음 연결할 때 VPN 설정을 생성합니다. 이 권한은 로컬 트래픽 진입점을 만드는 데 사용되므로 거부하면 클라이언트는 열리지만 실제로 네트워크를 인계할 수 없습니다.

첫 실행에서는 최소한의 설정만 하기

처음 실행할 때 포트, DNS, TUN 스택과 여러 오버라이드를 바로 수정하지 않는 것이 좋습니다. 기본 수신 주소와 포트를 유지한 채 클라이언트가 코어를 시작할 수 있는지 확인하고, 로그, 설정 목록, 프록시 정책과 연결 기록 메뉴를 찾으세요. 그다음 유효한 구독 하나를 가져오고 사용 가능한 정책을 선택한 뒤 시스템 프록시를 활성화합니다. 이제 브라우저로 일반 웹페이지에 접속하면서 연결 기록에 새 요청이 나타나는지 확인하세요. 연결 목록이 전혀 변하지 않는다면 트래픽이 아직 클라이언트에 들어오지 않은 것이므로 노드를 바꾸기보다 시스템 프록시부터 점검해야 합니다.

Windows에서 클라이언트가 서비스 모드나 네트워크 구성 요소를 설치해야 한다면 화면의 안내에 따라 권한을 허용하세요. 서비스 모드는 일반적으로 더 높은 권한으로 TUN, 라우팅 또는 시스템 설정을 관리하는 데 사용되며, 설치 후 클라이언트를 다시 시작해야 할 수 있습니다. macOS의 네트워크 확장이나 보조 서비스도 시스템 확인이 필요합니다. Linux 데스크톱 환경에서는 트레이, 시스템 프록시 기록과 TUN 권한이 데스크톱 세션과 시스템 서비스에 의존합니다. 터미널에서만 그래픽 클라이언트를 시작한다면 터미널을 닫았을 때 프로세스도 함께 종료되는지 확인하세요.

관찰 가능한 신호로 설치 결과 확인

설치 성공 여부는 창이 나타났는지만으로 판단해서는 안 됩니다. 최소한 네 가지를 확인하세요. 코어 로그에 같은 시작 오류가 반복되지 않는지, 로컬 수신 포트가 생성되었는지, 구독 설정을 불러올 수 있는지, 시스템 프록시를 켠 뒤 연결 기록에 브라우저 요청이 나타나는지 확인합니다. 로그에 주소가 이미 사용 중이라고 표시되면 Windows에서는 netstat, macOS 또는 Linux에서는 lsof를 사용해 포트 소유자를 확인할 수 있습니다. 아래 명령은 로컬 수신 상태를 확인할 뿐 네트워크 설정을 변경하지 않습니다.

Windows:
netstat -ano | findstr LISTENING

macOS / Linux:
lsof -nP -iTCP -sTCP:LISTEN

기존 클라이언트가 포트를 사용 중이라면 해당 프로세스를 먼저 종료하고 기존 클라이언트가 변경한 시스템 프록시를 복원하세요. 포트가 수신 중이 아닌데 클라이언트에는 실행 중이라고 표시되면 코어 로그에서 설정 해석 실패, 권한 부족 또는 코어 파일 누락을 확인하세요. 처음부터 방화벽이나 보안 설정을 끄지 마세요. 명확한 로그를 기준으로 원인을 찾는 것이 우선입니다. 로컬 루프백 포트를 만들 수 없는 문제와 원격 연결이 차단된 문제는 서로 다른 유형이므로 처리 방법도 다릅니다.

모바일에서는 시스템의 백그라운드 제한도 고려해야 합니다. Android가 화면이 꺼진 뒤 연결을 끊는다면 배터리 최적화, 백그라운드 활동 제한 또는 시스템의 프로세스 정리가 흔한 원인입니다. 클라이언트의 백그라운드 실행을 허용하고 VPN이 상시 유지되는지 확인하세요. iOS에서 Wi-Fi와 셀룰러 네트워크를 전환할 때 네트워크가 다시 구성되며 잠시 재연결되는 것은 시스템 동작일 수 있습니다. 오래 복구되지 않는다면 VPN 설정을 반복해서 삭제하기보다 클라이언트에서 현재 설정과 정책을 확인하세요.

초기화 완료 기준

  • 클라이언트와 코어가 모두 안정적으로 시작되고 로그에 같은 오류가 반복되지 않습니다.
  • 설정 하나를 가져왔으며 프록시 그룹과 노드 목록을 확인할 수 있습니다.
  • 시스템 프록시를 켠 뒤 브라우저 요청이 연결 기록에 나타납니다.
  • 클라이언트나 시스템 프록시를 끄면 시스템 네트워크가 원래 상태로 돌아옵니다.
  • 복잡한 오버라이드, 스크립트 또는 사용자 지정 DNS를 아직 활성화하지 않아 이후 항목을 하나씩 검증하기 쉽습니다.

이 최소 사용 가능 상태를 유지하는 것이 중요합니다. 이후 규칙 오버라이드, TUN 또는 DNS를 활성화한 뒤 네트워크에 문제가 생기면 항목별로 ‘기본 설정과 시스템 프록시’ 상태로 되돌릴 수 있습니다. 여러 모듈을 한 번에 수정하면 단계는 줄어들지만 문제가 발생했을 때 원인을 특정할 수 없어 결국 재설치하게 됩니다. 재설치한다고 해서 시스템 프록시, 서비스와 로컬 설정이 자동으로 삭제되는 것은 아닙니다.

4장

구독 및 설정: 업데이트 출처, 로드 결과와 로컬 수정

구독을 가져온 뒤 첫 번째 점검

구독은 보통 URL, 클립보드 또는 로컬 파일을 통해 가져옵니다. 추가한 뒤 한 번 수동으로 업데이트하여 클라이언트에 업데이트 시간이 표시되는지 확인하고, 프록시 정책 페이지에 노드와 프록시 그룹이 나타나는지 확인하세요. 구독 이름만 보인다고 내용이 성공적으로 다운로드된 것은 아닙니다. 구독 주소 만료, 네트워크 접근 불가, 응답 형식 오류 또는 변환 결과의 비호환으로 빈 설정 항목만 남을 수 있습니다. 업데이트에 실패하면 업데이트 버튼을 계속 누르지 말고 클라이언트 로그의 HTTP 상태, 해석 메시지와 저장 경로를 먼저 확인하세요.

구독 URL에는 접근 자격 증명이 포함되는 경우가 많으므로 계정 비밀번호처럼 보관해야 합니다. 공개 스크린샷, 질문 게시물 또는 로그 첨부 파일에 올리지 마세요. 기기를 바꿀 때는 브라우저 기록이나 채팅 기록에서 장기간 복사하지 말고 신뢰할 수 있는 경로에서 주소를 다시 받으세요. 설정을 내보낼 때도 출처를 구분해야 합니다. 전체 내보내기에는 구독 주소와 노드 매개변수가 포함될 수 있고, 로컬 규칙이나 오버라이드만 내보내는 방식은 개인 설정을 옮길 때 더 적합합니다.

원격 설정과 로컬 오버라이드의 경계

구독을 다운로드한 뒤 YAML을 직접 편집하는 방식은 일반적으로 장기적인 해결책이 아닙니다. 다음 업데이트에서 원격 내용이 로컬 파일을 덮어쓰면 직접 추가한 규칙, DNS 또는 프록시 그룹이 사라질 수 있습니다. 오버라이드, 병합 또는 확장 스크립트를 지원하는 클라이언트라면 개인 규칙을 별도의 오버라이드 계층에 넣으세요. 오버라이드를 지원하지 않는다면 구독 설정을 로컬 설정으로 복사할 수 있지만 이후 원격 변경 사항이 자동 동기화되지 않는다는 점을 받아들여야 합니다. 유지 관리 전에 클라이언트가 ‘덮어쓰기 업데이트’, ‘병합 업데이트’, ‘실행 설정 생성’ 중 어떤 방식을 사용하는지 확인하세요. 그렇지 않으면 화면에서 수정한 내용이 재시작 후 다시 원래대로 돌아오는 일이 발생합니다.

표준 YAML은 들여쓰기로 계층을 표현하며 탭과 공백을 섞어 사용할 수 없습니다. 목록 항목은 하이픈으로 시작하고, 문자열에 콜론, 해시 또는 특수 문자가 포함되면 따옴표를 붙이는 것이 좋습니다. 설정 로드 실패 위치는 뒤쪽 줄을 가리키는 경우가 많지만 실제 원인은 앞줄의 들여쓰기나 닫히지 않은 따옴표일 수 있습니다. 수정한 뒤에는 범위를 작게 잡아 테스트하고, 매번 하나의 모듈만 변경하며 로드 가능한 이전 파일을 보관하세요. 아래는 구조를 이해하기 위한 최소 예시입니다. 서버 주소는 문서용으로 보존된 주소이므로 실제 연결에는 사용할 수 없습니다.

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

proxies:
  - name: "예시 노드"
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: "demo-user"
    password: "your-password"

proxy-groups:
  - name: "수동 선택"
    type: select
    proxies:
      - "예시 노드"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,수동 선택
  - MATCH,DIRECT

설정 안의 이름은 서로 일치해야 합니다. 규칙이 ‘수동 선택’을 가리킨다면 프록시 그룹에도 같은 이름의 항목이 있어야 합니다. 프록시 그룹이 ‘예시 노드’를 참조한다면 노드 이름도 공백과 대소문자를 포함해 완전히 일치해야 합니다. 흔한 로드 오류는 프로토콜 매개변수 자체보다 노드 이름을 바꾼 뒤 프록시 그룹을 함께 수정하지 않았거나, 설정에 존재하지 않는 그룹 이름을 규칙에 그대로 복사해서 발생합니다. 중국어 이름도 사용할 수 있지만 여러 도구 간에 변환할 때는 짧고 안정적인 이름이 유지 관리에 더 유리합니다.

구독 업데이트 실패를 단계별로 처리하기

먼저 해당 구독 설정에 의존하지 않고도 기기에서 구독 주소에 접근할 수 있는지 확인하세요. 기존 설정이 만료되면 구독 업데이트도 함께 실패하는 경우가 있습니다. 이때는 잠시 프록시를 끄고 직접 연결로 업데이트하거나 다른 정상 설정으로 전환한 뒤 업데이트할 수 있습니다. 응답이 설정 내용이 아니라 웹페이지, 로그인 페이지 또는 오류 메시지라면 웹페이지를 YAML로 저장하려 하지 말고 구독 출처에서 인증 문제를 처리하세요. 다운로드는 성공했지만 해석에 실패한다면 해당 구독이 다른 클라이언트 형식용인지, 현재 코어가 지원하지 않는 필드를 포함하는지 확인하세요.

구독 변환은 노드를 복구하는 도구가 아니라 설정을 생성하는 과정으로 보아야 합니다. 변환을 통해 프록시 그룹, 규칙과 필드를 재구성할 수는 있지만 만료된 노드를 되살리거나 구독 자체의 권한을 바꿀 수는 없습니다. 변환을 사용할 때는 템플릿 출처, 대상 형식과 업데이트 방식을 기록해 몇 달 뒤 특정 규칙이 어디에서 왔는지 설명할 수 있도록 하세요. 접근 자격 증명이 관련된 경우에는 처리 경로와 저장 위치를 더 꼼꼼히 확인하고, 가능한 한 직접 통제할 수 있는 환경에서 처리하세요.

설정 관리의 목표는 파일을 많이 보관하는 것이 아니라 현재 실행 중인 파일이 무엇인지, 어디에서 업데이트되는지, 어떤 내용이 로컬에서 추가되었는지 설명할 수 있는 것입니다. 로컬 설정에는 ‘데스크톱 일상 사용’, ‘시스템 프록시 테스트 전용’, ‘TUN 문제 해결’처럼 용도를 명확히 적고 장기간 사용하지 않는 중복 복사본은 삭제하세요. 설정이 너무 많으면 규칙 자체보다 오래된 파일을 잘못 선택한 사실을 발견하기 어렵습니다.

5장

프록시 모드: 규칙, 글로벌, 직접 연결 중 선택하기

규칙 모드를 일상적인 기본값으로 사용하기

규칙 모드는 설정의 규칙을 한 줄씩 확인해 특정 프록시 그룹으로 보낼지, 직접 연결할지, 거부할지를 결정합니다. 웹사이트와 앱마다 다른 출구를 사용할 수 있고 로컬 서비스, 로컬 네트워크 주소와 프록시가 필요 없는 트래픽을 직접 연결로 유지할 수 있으므로 장기 사용에 적합합니다. 규칙 모드가 예상대로 동작하는지는 규칙 세트의 내용과 순서, DNS 결과 및 프록시 그룹 선택에 달려 있습니다. 모든 네트워크 환경을 자동으로 판단하는 블랙박스가 아니므로 특정 주소가 잘못된 출구로 나가면 클라이언트 전체를 장기간 글로벌 모드로 바꾸기보다 연결 상세 정보에서 매칭된 규칙을 확인하세요.

연결 기록에는 일반적으로 대상 도메인 또는 IP, 매칭 규칙, 정책 체인과 최종 노드가 표시됩니다. 특정 웹사이트를 점검할 때는 연결 목록을 지우거나 필터링한 뒤 요청을 다시 보내 새 연결을 관찰하세요. 브라우저는 주 도메인, 정적 리소스, 로그인 API와 타사 서비스를 동시에 요청할 수 있으므로 페이지 이상이 주 도메인 때문이라는 보장은 없습니다. 실패한 연결과 매칭 규칙을 찾아야 규칙 누락인지, 프록시 그룹 선택 오류인지, 노드 자체의 문제인지 판단할 수 있습니다.

규칙 문제를 분리할 때 글로벌 모드 사용

글로벌 모드는 일반적으로 인계 가능한 대부분의 트래픽을 지정된 정책이나 노드로 보냅니다. 출구를 짧은 시간 동안 검증할 때 적합합니다. 규칙 모드에서 웹사이트에 접근할 수 없지만 글로벌 모드에서 복구된다면 노드에는 연결 능력이 있고 문제는 규칙 매칭, DNS 또는 프록시 그룹 경로에 있을 가능성이 큽니다. 글로벌 모드에서도 실패한다면 노드, 프로토콜, 시스템 시간과 네트워크 환경을 먼저 확인하세요. 글로벌 모드는 진단 도구이자 통합된 출구가 필요한 임시 상황에 사용할 수 있지만 기존 분기 설계를 우회하므로 로컬 네트워크, 로컬 서비스와 프록시가 필요 없는 트래픽에 영향을 줄 수 있습니다.

글로벌 모드로 전환한 뒤 글로벌 프록시 그룹에서 무엇을 선택했는지 확인하세요. 일부 설정은 ‘GLOBAL’ 그룹을 선택 목록으로 구성하므로 노드를 직접 지정해야 합니다. 모드만 바꾸고 유효한 출구를 선택하지 않으면 결과가 규칙 모드와 같을 수 있습니다. 테스트가 끝나면 규칙 모드로 돌아가 대상 앱을 다시 여세요. 일부 프로그램은 이미 수립된 장시간 연결을 재사용하므로 모드 전환만으로 기존 연결의 경로가 즉시 바뀌지 않습니다. 브라우저의 관련 탭을 닫거나 연결이 다시 수립될 때까지 기다리세요.

로컬 네트워크를 확인할 때 직접 연결 모드 사용

직접 연결 모드에서는 인계된 요청이 프록시 노드를 거치지 않고 직접 접속합니다. 현재 네트워크에서 기본 네트워크, DNS와 대상 서비스에 접근할 수 있는지 판단할 때 유용하며, 연결을 관찰하기 위해 클라이언트를 실행한 채 프록시를 일시 중지할 때도 사용할 수 있습니다. 직접 연결 모드는 시스템 프록시를 끈 상태와 같지 않습니다. 트래픽은 여전히 코어로 들어올 수 있지만 최종 동작이 DIRECT일 뿐입니다. 클라이언트를 완전히 종료하려면 시스템 프록시 또는 TUN을 끄고 시스템 네트워크 설정이 복구되었는지 확인하세요.

직접 연결 모드에서도 일반 웹사이트에 접근할 수 없다면 로컬 네트워크, DNS, 시스템 라우팅, 방화벽 또는 남아 있는 다른 VPN이 원인일 수 있습니다. 이때 프록시 노드를 계속 바꾸는 것은 의미가 없습니다. 반대로 직접 연결은 정상이고 글로벌 모드가 실패하면 노드나 프록시 프로토콜을 의심해야 합니다. 직접 연결과 글로벌 모드는 정상인데 규칙 모드만 실패한다면 규칙과 프록시 그룹을 중점적으로 확인하세요. 이 세 모드 비교법으로 범위를 빠르게 좁힐 수 있지만, 캐시의 영향을 피하려면 매번 같은 대상과 같은 네트워크에서 새 연결로 테스트해야 합니다.

모드 주요 용도 적합한 시점 문제 해결 결론
Rule 규칙에 따라 출구 분배 일상적인 사용 매칭 규칙과 정책 체인을 함께 확인해야 함
Global 지정한 정책으로 일괄 전송 짧은 테스트 또는 통합된 출구 규칙 문제를 분리하는 데 사용 가능
Direct 로컬 네트워크로 직접 연결 기본 네트워크 확인 노드와 프록시 프로토콜 문제를 분리하는 데 사용 가능

프록시 그룹이 최종 출구를 결정

모드는 정책 판단에 들어가는 방식만 결정하고, 실제 출구를 선택하는 것은 프록시 그룹입니다. 일반적인 프록시 그룹 유형에는 수동 선택, 자동 지연 측정, 장애 조치와 부하 분산이 있습니다. 수동 선택은 이해하기 쉽고 중요한 용도에 적합합니다. 자동 지연 측정은 테스트 주소와 간격에 따라 결과가 좋은 노드를 선택하지만 테스트 지연 시간이 실제 접속 속도와 같지는 않습니다. 장애 조치는 현재 노드를 사용할 수 없을 때 대체 항목으로 전환하므로 연속성을 중시하는 설정에 적합합니다. 클라이언트마다 프록시 그룹 유형의 이름이 다를 수 있으므로 설정의 type을 기준으로 확인하세요.

자동 선택은 실제 검증을 대신할 수 없습니다. 테스트 주소에 접근할 수 있다는 것은 노드가 해당 테스트 요청을 완료할 수 있다는 뜻일 뿐입니다. 대상 웹사이트는 다른 경로, 프로토콜 또는 지역 정책을 사용할 수 있습니다. 노드 지연 시간은 정상처럼 보이지만 웹페이지가 느리다면 실제 연결 수립 시간, 다운로드 과정과 패킷 손실을 확인하고 소수의 노드를 직접 비교하세요. 너무 짧은 간격으로 지연 시간을 자주 측정하면 백그라운드 요청이 늘고 정책이 노드 사이를 반복해서 전환할 수도 있습니다. 일상적인 설정에서는 적절한 간격을 사용하고 중요한 정책에는 수동 선택 기능을 남겨 두는 편이 좋습니다.

6장

규칙 분기: 매칭 순서, 규칙 유형과 오버라이드 방법

규칙은 위에서 아래로 매칭되며 처음 일치한 순간 중단

Clash 규칙에서 가장 중요한 동작은 순서입니다. 요청은 규칙 목록의 맨 위부터 확인되며 첫 번째로 일치한 규칙이 지정한 정책이 적용되고 이후 규칙은 확인하지 않습니다. 구체적인 도메인 규칙은 넓은 도메인 접미사, GeoIP 또는 최종 기본 규칙보다 앞에 두는 것이 일반적입니다. 넓은 규칙이 먼저 일치하면 뒤의 정확한 규칙을 올바르게 작성했더라도 실행되지 않습니다. ‘사용자 지정 규칙이 적용되지 않음’을 점검할 때는 먼저 연결 기록에서 실제로 어떤 규칙에 매칭되었는지 확인한 다음 규칙 목록의 위치를 비교하세요.

일반적인 규칙에는 DOMAIN 정확한 도메인, DOMAIN-SUFFIX 도메인 접미사, DOMAIN-KEYWORD 도메인 키워드, IP-CIDR IPv4 대역, IP-CIDR6 IPv6 대역, GEOIP 지리적 IP 분류, PROCESS-NAME 프로세스 이름과 마지막의 MATCH가 있습니다. 도메인이 아직 확인 가능한 경우 도메인 규칙으로 가장 직접적으로 판단할 수 있고, IP 규칙은 해석 결과에 의존하며, 프로세스 규칙은 플랫폼과 인계 방식에 의존합니다. 모든 시스템과 클라이언트가 일관된 프로세스 식별 기능을 제공하는 것은 아닙니다.

정확한 조건부터 넓은 기본 규칙 순서로 작성

규칙을 추가할 때는 먼저 대상이 구체적인 호스트인지, 전체 도메인 접미사인지, IP 대역인지, 특정 앱 프로세스인지 결정하세요. 정확한 도메인으로 해결할 수 있다면 너무 넓은 키워드를 바로 사용하지 마세요. 같은 문자열을 포함한 다른 도메인까지 잘못 매칭될 수 있습니다. 도메인 접미사 규칙은 주 도메인과 하위 도메인을 모두 포함하므로 구조가 안정적인 서비스에 적합합니다. IP 대역 규칙은 도메인 정보가 없거나 주소 기준으로 분기해야 하는 서비스에 적합하지만 CDN과 네트워크 지역에 따라 주소가 바뀔 수 있으므로 유지 관리가 필요합니다.

rules:
  - DOMAIN,api.example.com,업무 정책
  - DOMAIN-SUFFIX,example.net,수동 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,수동 선택

no-resolve는 해당 IP 규칙을 매칭할 때 판단을 위해 도메인을 추가로 해석하지 않도록 코어에 지시합니다. 사설 대역처럼 주소 조건이 명확한 경우에 적합합니다. 추가 여부는 규칙 유형과 실제 요구에 따라 결정해야 하며 모든 규칙 뒤에 기계적으로 붙여서는 안 됩니다. MATCH는 최종 기본 규칙으로 일반적으로 맨 끝에 둡니다. 앞에서 매칭되지 않은 요청은 지정된 정책으로 들어갑니다. MATCH를 중간에 넣으면 뒤의 규칙은 실행될 기회를 영원히 잃습니다.

규칙 세트와 Geo 데이터는 추적 가능하게 관리

대규모 설정은 보통 rule-providers를 통해 규칙 세트를 참조하여 주 설정에 수천 개의 규칙을 직접 넣지 않습니다. 규칙 세트를 사용하면 독립적으로 업데이트할 수 있지만 출처, 동작과 업데이트 시간이라는 변수가 추가됩니다. 사용하기 전에 규칙 세트가 어떤 범위를 다루는지, 형식은 무엇인지, 어떤 정책이 참조하는지, 업데이트 실패 시 캐시를 계속 사용하는지 확인하세요. 범위가 크게 겹치는 규칙 세트를 여러 개 겹쳐 사용하지 마세요. 같은 도메인이 어느 규칙 세트에 매칭되는지가 배열 순서에 따라 달라져 나중에 설명하기 어려워집니다.

GeoIP와 지리적 사이트 분류는 로컬 데이터 파일에 의존합니다. 데이터가 오래되면 새로 할당된 주소나 새 도메인이 부정확하게 분류될 수 있고, 데이터 다운로드에 실패해도 클라이언트가 이전 캐시를 계속 사용할 수 있습니다. Clash GeoIP 업데이트를 진행할 때는 먼저 클라이언트에 데이터 업데이트 메뉴가 있는지 확인하고, 로그에서 다운로드와 로드가 성공했는지 확인하세요. 업데이트 후 분기 동작이 갑자기 달라지면 대상 사이트의 표시 내용이나 회사 소재지만으로 IP 분류를 추측하지 말고 업데이트 전후의 매칭 규칙을 비교하세요.

로컬 오버라이드는 올바른 삽입 지점에 배치

클라이언트가 제공하는 ‘앞에 추가’, ‘뒤에 추가’, ‘규칙 병합’의 의미는 서로 다를 수 있습니다. 앞에 추가하는 규칙은 일반적으로 원격 규칙보다 앞에 삽입되므로 우선 매칭되어야 하는 개인 규칙에 적합합니다. 뒤에 추가한 규칙이 원격 MATCH 뒤에 위치하면 실제로 적용되지 않습니다. 오버라이드 기능을 사용할 때는 최종 생성된 실행 설정이나 로그의 규칙 순서를 확인해 사용자 지정 내용이 MATCH보다 앞에 들어갔는지 확인하세요. 편집 상자에서 규칙을 봤다는 사실만으로 코어가 같은 순서로 로드했다는 뜻은 아닙니다.

규칙 디버깅은 하나의 대상에서 시작해야 합니다. 연결 필터를 지우고 대상 도메인에 접속한 뒤 도메인, 해석된 IP, 매칭 규칙, 프록시 그룹과 최종 노드를 기록하세요. 이후 규칙 하나만 조정하고 설정을 다시 로드한 뒤 새 연결을 만드세요. 브라우저 DNS 캐시, 연결 재사용과 서비스 워커가 이전 경로를 유지할 수 있으므로 필요하면 관련 페이지를 닫거나 대상 앱을 다시 시작하세요. 더 자세한 문법과 오버라이드 사례는 Clash 사용자 지정 규칙 문법 자세히 알아보기에서 확인할 수 있습니다.

규칙이 적용되지 않을 때 확인할 항목

  1. 규칙 문법을 코어가 성공적으로 로드했는가.
  2. 규칙이 참조하는 프록시 그룹이 존재하며 이름이 완전히 일치하는가.
  3. 더 넓은 규칙이 앞에서 이미 매칭되었는가.
  4. 사용자 지정 규칙이 최종 MATCH 앞에 삽입되었는가.
  5. 대상 요청이 수정 전에 만들어진 연결을 계속 재사용하고 있는가.
  6. 규칙에 들어오기 전에 다른 구성 요소가 도메인 요청을 변경하거나 해석했는가.

7장

TUN 및 DNS: 더 많은 트래픽을 인계하고 해석 일관성 유지

시스템 프록시와 TUN은 인계 범위가 다릅니다

시스템 프록시는 주로 운영 체제의 프록시 설정을 읽는 앱에 영향을 줍니다. 브라우저와 일부 데스크톱 소프트웨어는 대체로 잘 지원하지만 게임, 명령줄 도구, 스토어 앱, 가상 머신 프로그램 또는 자체 네트워크 스택을 구현한 소프트웨어는 우회할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 더 많은 IP 트래픽을 코어로 전달하므로 적용 범위가 더 넓습니다. TUN은 ‘더 빠른 시스템 프록시’가 아니라 다른 진입 방식이며 라우팅, DNS, 권한, 로컬 네트워크와 다른 VPN의 호환 문제도 가져옵니다.

TUN을 처음 활성화하기 전에 시스템 프록시 모드가 정상적으로 작동하는지 확인하세요. 그러면 구독, 노드와 기본 규칙이 대체로 유효하다는 것을 확인할 수 있어 TUN 실패 시 권한, 가상 네트워크 카드, 라우팅과 DNS로 범위를 좁힐 수 있습니다. 처음부터 TUN, 사용자 지정 DNS, IPv6와 여러 오버라이드를 동시에 켜면 연결이 끊긴 뒤 어느 단계에서 문제가 발생했는지 알기 어렵습니다. 먼저 시스템 프록시를 끄고 기본 TUN 매개변수만 사용해 테스트하세요. 요청이 연결 기록에 들어오는 것을 확인한 뒤 DNS와 우회 규칙을 하나씩 조정합니다.

권한, 라우팅, 네트워크 스택 매개변수

TUN은 가상 인터페이스를 만들고 시스템 라우팅을 수정하므로 데스크톱 시스템에서는 일반적으로 관리자 권한, 보조 서비스 또는 네트워크 확장이 필요합니다. Windows에서는 서비스 모드, 드라이버 상태와 다른 VPN을 확인해야 하고, macOS에서는 네트워크 확장 승인을 확인해야 합니다. Linux에서는 TUN 장치와 적절한 capability 또는 관리자 권한이 필요합니다. 권한이 부족하면 로그에 인터페이스 생성, 라우팅 설정 또는 장치 접근 실패가 표시되는 경우가 많습니다. 이때 노드를 반복해서 바꿔도 결과는 달라지지 않으므로 먼저 시스템 권한을 처리하세요.

일반적인 TUN 스택 이름에는 system, gVisor, mixed가 있으며 실제로 사용할 수 있는 값은 코어와 클라이언트에 따라 다릅니다. system은 운영 체제 네트워크 스택에 더 의존하고, gVisor는 사용자 공간에서 더 많은 네트워크 동작을 처리하며, mixed는 프로토콜에 따라 조합해 처리합니다. 명확한 문제가 없다면 클라이언트 기본값을 유지하세요. 특정 앱이 연결되지 않거나 UDP 이상이 발생하거나 절전 모드 복귀 후 네트워크가 되지 않을 때는 기존 값을 기록한 뒤 스택을 바꿔 비교할 수 있습니다. 한 번에 하나만 수정하고 코어를 다시 시작해 가상 인터페이스를 다시 생성하세요.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  dns-hijack:
    - any:53

auto-route는 라우팅을 자동으로 기록하고, auto-detect-interface는 현재 기본 네트워크 인터페이스를 식별합니다. 장치가 유선, Wi-Fi, 가상 머신 네트워크 카드와 다른 VPN에 동시에 연결되어 있으면 자동 식별이 잘못된 출구를 선택할 수 있습니다. TUN을 켠 뒤 모든 연결이 시간 초과되는 현상이 대표적입니다. 먼저 다른 네트워크 도구를 종료하고 TUN을 다시 활성화한 뒤 기본 인터페이스가 어떻게 바뀌는지 확인하세요. strict-route는 라우팅 제약을 강화해 트래픽 우회를 줄일 수 있지만 로컬 네트워크, 가상 머신 또는 특수 라우팅에 영향을 주기 쉬우므로 처음부터 무작정 켜지 않는 것이 좋습니다.

DNS 모드는 도메인이 규칙으로 들어가는 방식을 결정

DNS는 도메인을 IP로 변환하는 것뿐 아니라 규칙에서 도메인을 볼 수 있는지, 연결이 어느 출구로 나가는지, 해석 경로가 일치하지 않는지에도 영향을 줍니다. Clash DNS의 대표적인 향상 모드에는 redir-host와 fake-ip가 있습니다. redir-host는 실제 해석 결과를 반환하는 방식에 가깝고, fake-ip는 먼저 예약 주소를 매핑해 반환한 뒤 코어가 연결 단계에서 도메인을 복원하므로 규칙 매칭까지 도메인 정보를 보존하기 쉽습니다. 일부 로컬 네트워크 서비스, 장치 검색, 게임 또는 실제 IP에 의존하는 프로그램은 fake-ip-filter에 추가해야 할 수 있습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"

예시에 사용한 공용 해석기는 문법을 보여 주기 위한 것일 뿐입니다. 실제 선택은 사용 중인 네트워크, 설정 규칙과 개인정보 보호 요구를 함께 고려해야 합니다. 설정에서 프록시와 직접 연결 경로별로 DNS를 나눌 수 있다면 프록시 대상 서버를 해석하는 해석기가 아직 수립되지 않은 프록시에 다시 의존하지 않도록 해야 시작 루프를 피할 수 있습니다. Clash DNS 유출이 의심될 때는 특정 검사 웹페이지의 결론만 보지 마세요. 먼저 시스템 DNS 요청이 TUN 또는 DNS 하이재킹으로 인계되었는지 확인하고, 코어 로그, 현재 수신 포트와 실제로 어느 해석기로 전송되는지 확인하세요. 브라우저에 내장된 암호화 DNS가 시스템 경로를 우회할 수도 있으므로 함께 점검해야 합니다.

TUN 문제는 네트워크 복구를 우선해 처리

TUN을 활성화한 뒤 인터넷이 완전히 끊기면 먼저 TUN을 끄고 라우팅이 복구되는지 확인하세요. 끈 뒤에도 연결되지 않으면 클라이언트를 종료하고 시스템에 남은 가상 인터페이스, 프록시 설정 또는 다른 VPN을 확인합니다. 이후 클라이언트를 다시 시작해 시스템 프록지만 사용하여 기본 연결을 검증하세요. 기본 연결이 정상이라면 TUN 로그에서 인터페이스 생성, 기본 라우팅, DNS 수신과 권한 오류를 확인합니다. 로컬 네트워크 장치에 접근할 수 없다면 사설 대역이 DIRECT로 유지되는지, strict-route가 차단하는지, 로컬 주소가 fake-ip로 처리되는지 점검하세요.

절전 모드에서 깨어나거나 Wi-Fi를 전환하거나 유선에서 핫스팟으로 바꾼 뒤 연결이 끊기는 흔한 원인은 기본 인터페이스와 라우팅의 변화입니다. 먼저 클라이언트가 자동으로 다시 구성할 때까지 기다리고, 복구되지 않으면 TUN을 껐다가 다시 켜세요. 자주 발생한다면 클라이언트가 네트워크 변경 시 다시 로드하는 기능을 지원하는지 확인하고 auto-detect-interface도 점검하세요. 시스템에서 컨테이너, 가상 머신 또는 원격 접속 도구를 함께 실행한다면 이들이 만든 네트워크 대역을 기록해 TUN 라우팅이 덮어쓰지 않도록 하세요. TUN의 안정성은 스위치가 켜지는지가 아니라 네트워크 전환, 절전 복귀와 로컬 네트워크 접근에서 결과를 설명할 수 있는지로 판단해야 합니다.

8장

일상적인 유지 관리 및 문제 해결: 설정 유효성부터 점검

가벼운 유지 관리 주기 만들기

일상적인 유지 관리를 위해 매일 설정을 바꿀 필요는 없습니다. 더 안정적인 방법은 구독과 규칙 데이터를 정기적으로 업데이트하고, 업데이트 후 최소한의 검증을 수행하는 것입니다. 설정을 로드할 수 있는지, 자주 사용하는 프록시 그룹에 노드가 있는지, 규칙 모드에서 일반 웹페이지에 접근할 수 있는지, 연결 기록이 예상과 일치하는지 확인하세요. 클라이언트나 코어를 업데이트하기 전에는 현재 설정, TUN 상태, 포트와 로컬 오버라이드를 기록합니다. 업데이트 후에는 기본 연결을 먼저 확인하고 복잡한 옵션을 다시 활성화하세요. 업무 환경에서 안정성이 중요하다면 새 기능 업데이트를 조금 늦춰도 되지만, 시스템 업그레이드나 프로토콜 호환 문제가 발생하면 현재 유지 관리 상태를 확인해야 합니다.

백업의 핵심은 캐시가 아니라 로컬에서 추가한 내용입니다. 구독 출처를 다시 얻는 방법, 로컬 오버라이드 규칙, DNS 조정, 프록시 그룹 수정과 서비스 설정을 보관하세요. 노드 목록이 구독에서 전적으로 생성된다면 여러 스냅샷을 장기간 복사할 필요는 없습니다. 구독에서 다시 얻을 수 없는 개인 설정을 보관하는 것이 중요합니다. 백업 파일에는 용도와 날짜를 표시하고 구독 주소, 노드 자격 증명과 로컬 네트워크 정보가 공개되지 않도록 주의하세요.

연결되었지만 인터넷이 되지 않을 때의 고정 순서

첫째, 설정이 성공적으로 로드되었고 프록시 그룹에 사용 가능한 항목이 있는지 확인합니다. 둘째, 직접 연결 모드로 전환해 로컬 네트워크를 확인한 다음 글로벌 모드에서 명확한 노드를 선택해 규칙의 영향을 배제합니다. 셋째, 시스템 프록시 또는 TUN이 실제로 트래픽을 인계했는지 확인합니다. 연결 기록에 새 요청이 없으면 진입점 문제이고, 요청은 있지만 빠르게 실패한다면 규칙, 정책 체인과 오류 유형을 확인하세요. 넷째, DNS를 점검하고 도메인 접속과 직접 IP 연결 결과를 비교합니다. 다섯째, 포트 충돌, TUN 권한, 다른 VPN, 방화벽과 시스템 시간을 확인합니다.

‘연결됨’은 보통 노드 핸드셰이크 또는 클라이언트 실행 상태를 뜻하며 모든 대상에 접근할 수 있다는 의미는 아닙니다. 특정 웹사이트 하나만 실패하면 해당 사이트가 사용하는 여러 도메인과 매칭 규칙을 먼저 확인하세요. 모든 웹사이트가 실패한다면 출구와 시스템 네트워크를 확인합니다. 브라우저는 되지만 명령줄이 되지 않는다면 명령줄 도구가 시스템 프록시를 읽는지 확인하거나 현재 터미널에 프록시 환경 변수를 설정하세요. 임시 테스트에는 로컬 mixed-port를 사용할 수 있으며 포트는 클라이언트에 실제로 표시된 값을 기준으로 합니다.

Windows PowerShell:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

macOS / Linux:
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"

환경 변수는 현재 터미널과 그 터미널에서 시작한 프로세스에만 적용되며 터미널을 닫으면 일반적으로 사라집니다. 클라이언트 포트가 7890이 아니라면 실제 값으로 바꾸세요. 테스트가 끝난 뒤 임시 변수를 전역 셸 설정에 잘못 기록하지 않도록 주의하세요. 특히 클라이언트가 상시 실행되지 않는 장치에서는 클라이언트를 종료한 뒤에도 명령줄이 존재하지 않는 포트를 계속 가리킬 수 있습니다. 더 자세한 단계별 절차는 Clash 연결됨·인터넷 안 됨 문제 해결 체크리스트를 참고하세요.

지연 시간, 시간 초과, 속도 문제는 나누어 판단

Clash 노드 지연 시간 테스트는 일반적으로 작은 HTTP 요청을 보내며 테스트 주소, DNS, 핸드셰이크 방식과 현재 네트워크의 영향을 받습니다. 지연 시간이 낮다고 다운로드 속도가 빠르거나 대상 서비스가 반드시 작동한다는 뜻은 아닙니다. 시간 초과는 노드에 접근할 수 없거나, 테스트 주소가 차단되었거나, 프로토콜 핸드셰이크에 실패했거나, 로컬 네트워크에서 패킷이 손실되어 발생할 수 있습니다. 노드를 비교할 때는 같은 테스트 주소를 비슷한 시간에 사용하고 실제 웹페이지나 다운로드 동작도 함께 확인하세요. 한 번의 정렬 결과만으로 판단하지 마세요.

속도가 갑자기 떨어지면 먼저 단일 대상만 영향을 받는지 확인한 뒤 직접 연결, 글로벌 모드의 다른 노드와 규칙 모드를 비교하세요. 연결이 예상한 정책으로 전달되었는지, 노드가 자동으로 자주 전환되는지, 백그라운드에서 구독이나 규칙을 업데이트하고 있는지 확인합니다. 무선 네트워크 불안정, 시스템 절전, 모바일 네트워크 전환과 다른 다운로드 작업도 결과에 영향을 줍니다. 특정 시간대나 특정 경로에서만 발생한다면 네트워크 경로 변화일 수 있으며, 클라이언트를 반복해서 재설치해도 보통 해결되지 않습니다.

로그는 문제 발생 시간과 가까운 부분만 수집

문제를 해결할 때 로그 수준을 일시적으로 info 또는 debug로 올리고, 문제를 한 번 재현한 뒤 시간, 대상, 모드와 오류 행을 즉시 기록하세요. debug 로그는 내용이 많으므로 장기간 켜 두기에 적합하지 않으며 가공하지 않은 상태로 공개해서도 안 됩니다. 공유하기 전 구독 주소, 노드 서버, 인증 정보, 로컬 사용자 이름과 파일 경로를 삭제하세요. 유효한 로그에는 문제 발생 전후의 시작, DNS, 규칙 매칭과 연결 오류가 포함되어야 하며 마지막 ‘timeout’ 한 줄만 잘라서는 안 됩니다.

HTTPS 인증서 오류가 발생하면 먼저 시스템 시간, 브라우저 정책, 시스템 인증서 체인과 네트워크 중간 장치를 확인한 뒤 프록시 경로와 관련이 있는지 판단하세요. 일반적인 Clash 전달에는 모든 웹사이트에 복호화 인증서를 설치할 필요가 없습니다. 특정 소프트웨어가 트래픽 분석, 스크립트 수정 또는 다른 중간 처리를 활성화했다면 별도로 확인해야 합니다. 프록시 사용 후 HTTPS 인증서 오류 처리 방법에 따라 단계별로 점검하고 인증서 경고를 무시해 문제를 우회하지 마세요.

증상 먼저 확인할 위치 다음 단계
연결 기록이 비어 있음 시스템 프록시, TUN, 앱 자체 프록시 트래픽 진입점과 수신 포트 확인
모든 요청이 시간 초과됨 노드, 시스템 시간, 네트워크 출구 직접 연결과 글로벌 모드 비교
도메인만 실패함 DNS 수신과 해석 경로 브라우저 암호화 DNS와 하이재킹 확인
규칙 모드 이상 매칭 규칙과 프록시 그룹 글로벌 모드로 노드를 확인한 뒤 순서 조정
절전 모드 후 네트워크 끊김 TUN 인터페이스와 기본 라우팅 TUN을 다시 만들고 인터페이스 식별 확인

9장

고급 설정 경로: 안정적인 설정에서 유지 관리 가능한 설정으로

먼저 개인 요구를 검증 가능한 조건으로 작성

고급 설정은 더 많은 규칙과 스위치를 쌓는 것이 아니라 요구 사항을 검증 가능한 동작으로 바꾸는 것입니다. 예를 들어 ‘업무 도메인은 항상 고정 정책으로 연결’, ‘로컬 네트워크와 개발 환경은 직접 연결 유지’, ‘모바일 네트워크 전환 후 TUN 자동 복구’, ‘규칙 세트 업데이트 실패 시에도 캐시 사용’과 같이 작성할 수 있습니다. 각 목표에는 대응하는 설정, 관찰 방법과 복귀 방안이 있어야 합니다. 특정 오버라이드가 어떤 문제를 해결하는지 설명할 수 없다면 장기 설정에 추가하지 마세요.

기준 설정과 실험 설정을 나누어 만드는 것이 좋습니다. 기준 설정에는 안정적인 구독, 명확한 프록시 그룹, 필요한 규칙과 이미 검증한 DNS/TUN 매개변수만 포함합니다. 실험 설정은 새 규칙 세트, 다른 네트워크 스택 또는 프록시 그룹 동작을 테스트하는 데 사용합니다. 실험이 성공한 뒤 변경 항목 하나만 기준 설정으로 옮기세요. 그러면 설정 해석 실패나 라우팅 이상이 발생해도 많은 과거 변경 사항 속에서 원인을 추측하지 않고 빠르게 사용 가능한 상태로 돌아갈 수 있습니다.

proxy-providers로 동적 노드 관리

노드 출처를 주 설정과 분리해 관리할 때는 proxy-providers로 원격 또는 로컬 노드 제공자를 정의한 뒤 프록시 그룹이 이를 참조하도록 할 수 있습니다. 이렇게 하면 프록시 그룹과 규칙은 안정적으로 유지하고 노드 목록만 일정에 따라 업데이트할 수 있습니다. 제공자에는 유형, 경로, 업데이트 간격과 상태 확인을 명확히 지정해야 합니다. 캐시 경로는 여러 제공자가 같은 파일을 공유하지 않도록 하고, 상태 확인 주소는 장기간 안정적이며 응답이 작고 실제 네트워크 조건에 맞는 대상을 선택하세요.

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription"
    path: "./providers/primary.yaml"
    interval: 21600
    health-check:
      enable: true
      interval: 900
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: "자동 선택"
    type: url-test
    use:
      - primary
    url: "https://www.gstatic.com/generate_204"
    interval: 600

예시 주소는 구조를 설명하기 위한 것일 뿐입니다. 실제 구독 주소는 신뢰할 수 있는 출처에서 받아 안전하게 보관해야 합니다. 업데이트 간격은 짧을수록 좋은 것이 아닙니다. 너무 짧으면 원격 요청과 로컬 재로드가 늘고 노드가 자주 바뀌어 장시간 연결이 끊길 수 있습니다. 상태 확인도 전체적인 사용 가능성을 보장하지 않으며 테스트 대상에 접근할 수 있다는 사실만 확인합니다. 중요한 업무에는 수동 프록시 그룹을 남겨 두고, 필요하면 자동 선택을 후보로 사용하되 유일한 출구로 삼지 마세요.

rule-providers로 규칙 역할 분리

규칙 수가 늘어나면 로컬 네트워크, 업무, 미디어, 개발, 직접 연결과 차단 등 용도별로 규칙 세트를 나눌 수 있습니다. 주 설정에는 참조 순서와 최종 정책만 남겨 각 규칙 세트의 역할을 명확히 하세요. 분리할 때 웹사이트별로 지나치게 세분화된 파일을 만들면 관리 비용이 작은 파일 여러 개로 이동할 뿐입니다. 더 실용적인 기준은 ‘업데이트 출처가 같고, 정책 대상이 같으며, 유지 관리 주기가 비슷한’ 규칙을 함께 묶는 것입니다.

원격 규칙 세트를 업데이트하기 전에 캐시를 보관하고 형식과 behavior 유형이 일치하는지 확인하세요. domain, ipcidr, classical 규칙 세트는 내용 구조가 다르므로 유형을 잘못 작성하면 해석 실패나 매칭 이상이 발생합니다. 규칙 세트를 성공적으로 로드한 뒤에도 연결 기록으로 대표적인 대상 몇 개를 검증해야 합니다. 다운로드 성공만으로 규칙 순서가 올바르거나 대상이 예상 정책으로 들어갔다고 볼 수 없습니다.

코어 배포에는 서비스와 권한 관리가 필요

서버나 라우터에서 Mihomo를 직접 실행하면 그래픽 클라이언트가 대신 처리하던 작업을 직접 해야 합니다. 여기에는 설정 경로, 작업 디렉터리, 로그, 프로세스 감시, 시작 순서, 업데이트와 권한이 포함됩니다. 먼저 포그라운드 명령으로 설정을 로드해 문법 오류가 없는지 확인한 뒤 시스템 서비스 관리에 넘기세요. 처음부터 프로세스를 조용히 백그라운드로 실행하면 시작 실패 원인을 확인하기 어렵습니다. 설정에서 참조하는 상대 경로는 작업 디렉터리를 기준으로 하므로 서비스 관리자가 사용하는 디렉터리가 수동 테스트와 다르면 규칙 세트와 데이터베이스 파일을 찾지 못할 수 있습니다.

mihomo -t -f ./config.yaml
mihomo -d ./runtime -f ./config.yaml

첫 번째 명령은 설정을 확인하고, 두 번째 명령은 실행 디렉터리를 지정해 파일을 로드합니다. 실제 실행 파일 이름과 경로는 다운로드한 파일을 기준으로 하세요. 서비스 계정에는 설정을 읽고 캐시를 쓰며 필요한 네트워크 인터페이스를 만들 권한이 있어야 하지만, 편의를 위해 설정 디렉터리 전체에 불필요한 쓰기 권한을 부여해서는 안 됩니다. 설정을 변경한 뒤에는 먼저 확인 명령을 실행하고 서비스를 다시 로드하세요. 원격 장치가 해당 프록시를 통해 관리 연결을 유지한다면 업데이트 전에 로컬 콘솔이나 복귀 경로도 준비해야 합니다.

모든 기능을 한 번에 완성하지 말고 단계별로 확장

고급 설정 경로를 네 단계로 나눌 수 있습니다. 첫 단계에서는 규칙 모드를 안정적으로 사용하며 연결 기록을 통해 요청 하나를 설명할 수 있어야 합니다. 두 번째 단계에서는 로컬 오버라이드와 규칙 세트를 정리해 구독 업데이트가 개인 설정을 덮어쓰지 않도록 합니다. 세 번째 단계에서는 TUN, DNS와 네트워크 전환을 활성화하고 안정화합니다. 네 번째 단계에서 provider, 서버 배포, 자동 업데이트와 모니터링을 고려하세요. 각 단계에서 일정 기간 사용하며 일상적인 네트워크, 절전 복귀, 로컬 네트워크와 주요 앱에 문제가 없는지 확인한 뒤 다음 단계로 넘어가야 합니다.

학습할 때는 검증하지 않은 설정 조각을 많이 저장하기보다 증상과 결론을 우선 기록하세요. 같은 필드라도 코어, 클라이언트와 운영 체제에 따라 기본값이 다를 수 있으므로 복사하기 전에 현재 실행 설정을 확인해야 합니다. Windows 시스템 프록시, 구독과 UWP 루프백 문제를 다룰 때는 Windows Clash 설치 전체 과정을 참고하세요. 최초 초기화 단계를 다시 정리해야 한다면 Clash 최초 설치 설정 체크리스트로 돌아가면 됩니다.

이후의 모든 변경에도 같은 절차를 적용할 수 있습니다. 목표를 명확히 작성하고, 기준 설정을 백업하고, 한 번에 하나만 수정한 뒤 다시 로드하고 로그와 연결 기록을 확인하세요. 그런 다음 직접 연결, 글로벌, 규칙 모드를 비교합니다. 클라이언트를 바꾸거나 다시 설치해야 한다면 Clash 다운로드 페이지에서 플랫폼과 아키텍처를 확인하세요. 최초 연결만 빠르게 복구하려면 빠른 시작 가이드에 따라 최소 상태를 다시 만드세요. 시스템 설명서의 목적은 설정을 복잡하게 만드는 것이 아니라 모든 스위치에 명확한 위치를 부여하고 모든 문제에 일정한 출발점을 제공하는 것입니다.