Clash Meta전체 플랫폼 설치 및 설정

# 01장 · preparation

공통 준비 사항과 설정 범위

클라이언트, 코어, 구독의 차이

Clash Meta는 생태계에서 계속 사용되는 이름이며, 관련 코어는 현재 보통 mihomo라고 부릅니다. 클라이언트는 설정 표시, 노드 관리, 시스템 권한 요청과 코어 실행을 담당합니다. 코어는 프록시 프로토콜, DNS, 규칙 매칭을 처리하고, 구독은 노드나 전체 설정을 제공합니다. 클라이언트를 설치했다고 바로 사용할 수 있는 연결 경로가 생기는 것은 아닙니다. 이용 권한이 있는 구독이나 직접 구성한 노드가 필요합니다. 구독의 유효 기간, 지원 프로토콜, 기기 수 제한은 제공업체의 안내를 확인하세요. 클라이언트 설치가 성공했다고 구독까지 유효한 것은 아닙니다.

데스크톱과 모바일에서는 우선 Clash Plus를 확인하세요. Linux에서는 Clash Verge Rev 또는 FlClash로 시작할 수 있습니다. 전체 다운로드 목록은 다운로드 센터에서 확인하세요. 선택하기 전에 운영체제, 프로세서 아키텍처, 설치 방식을 확인하고, 파일 이름에 플랫폼명이 있다고 해서 호환된다고 판단하지 마세요. 데스크톱 GUI는 직접 조작할 때 편리하고, mihomo 코어 패키지는 설정·프로세스·서비스를 직접 관리하려는 사용자에게 적합합니다. GUI마다 구독 관리 방식이 다르므로, 아래 설명은 작업 목적을 기준으로 하며 모든 화면에 같은 이름의 버튼이 있다고 가정하지 않습니다.

호환되는 설정과 복구 가능한 환경 준비

가져오려는 파일이 Clash YAML 설정인지, 노드 목록인지, 다른 프로그램의 설정 형식인지 먼저 확인하세요. 완전한 설정에는 보통 프록시, 정책 그룹, 규칙이 포함됩니다. 노드만 있는 파일에는 정책 그룹과 규칙을 별도로 구성해야 합니다. Base64로 인코딩된 노드 링크는 완전한 Clash 설정이 아니며, sing-box JSON은 확장자만 바꿔 가져올 수 없습니다. 형식 확인과 로컬 변환의 범위는 구독 형식 비교 노트를 참고하세요. 변환 전에 원본 파일을 보관하고, 접속 정보가 포함된 링크를 신뢰할 수 없는 서비스에 제출하지 마세요.

처음 설정하기 전에 다른 프록시 클라이언트를 종료하고, 기존 시스템 프록시 및 VPN 상태를 기록하세요. 회사나 학교에서 관리하는 기기라면 프록시 변경, 네트워크 확장 설치, 라우트 추가가 허용되는지 먼저 확인하세요. 시스템 시간과 구독 계정 상태, 현재 네트워크에서 구독 주소에 접속할 수 있는지도 점검합니다. 가져올 때 알아보기 쉬운 이름을 지정하고 해당 설정을 활성 설정으로 선택하세요. 설정 목록에 파일이 보인다고 해서 실행 중인 코어가 그 파일로 전환된 것은 아닙니다.

최소한의 연결부터 확인하고 라우팅 범위를 넓히세요

권장 순서는 설정 가져오기, 규칙 모드 선택, 대상 정책 그룹에서 노드 선택, 시스템 프록시 활성화 후 브라우저 테스트입니다. 규칙 모드는 코어로 들어온 트래픽의 분기 방식을 정하고, 시스템 프록시는 시스템 설정을 따르는 앱이 코어로 들어오는 경로를 제공합니다. TUN은 가상 네트워크 인터페이스로 더 많은 트래픽을 처리하며, 추가 권한이 필요하고 라우트와 DNS에 영향을 줄 수 있습니다. 먼저 최소 연결 경로가 작동하는지 확인한 다음 TUN을 활성화하면 노드·권한·라우트 문제를 혼동하지 않을 수 있습니다.

아래는 설정 필드 예시일 뿐 노드는 포함되어 있지 않으므로 단독으로 프록시 연결을 만들 수 없습니다. 포트 값은 현재 클라이언트 설정과 일치해야 합니다. 클라이언트가 해당 필드를 관리한다면 실행 중 생성되는 파일을 직접 수정하지 말고, 클라이언트의 설정 또는 오버라이드 기능을 사용하세요. 우선 로컬에서만 수신하도록 두는 편이 안전합니다. LAN 공유가 필요하다면 인증과 방화벽을 함께 확인하세요.

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

# 02장 · windows

Windows 설치 및 트래픽 라우팅

설치 파일을 선택하고 처음 실행하기

Windows 다운로드에서 Clash Plus를 선택하세요. 다른 UI를 원한다면 Clash Verge Rev, FlClash, Clash Nyanpasu를 차례로 확인할 수 있습니다. Clash for Windows는 개발이 중단된 보관용 클라이언트이므로 새 기기의 기본 선택으로 권장하지 않습니다. 시스템 설정의 ‘정보’에서 프로세서 종류를 확인한 뒤 다운로드 카드의 지원 범위를 대조하세요. ARM 기기와 일반적인 x64 설치 파일을 혼동하지 말고, 파일이 더블 클릭으로 실행되는지만으로 아키텍처 호환성을 판단하지 마세요.

설치 프로그램을 실행할 때 시스템 안내를 읽고 파일 출처를 확인한 뒤 진행하세요. 압축을 풀어 실행하는 배포 형식이라면 고정된 폴더에 먼저 압축을 푸세요. 압축 파일 미리보기에서 바로 실행하지 마세요. 처음 실행한 뒤 트레이 아이콘과 기본 화면이 모두 열리는지 확인하고, 로그에서 설정 파싱 오류나 포트 바인딩 오류가 있는지 살펴보세요. 설치 권한과 일상적인 실행 권한은 별개입니다. 서비스나 가상 네트워크 인터페이스 설치 등 권한 상승이 명확히 필요한 단계에서만 해당 권한을 부여하세요. 일반적인 시스템 프록시 테스트를 위해 항상 관리자 권한으로 실행할 필요는 없습니다.

구독을 가져와 활성 설정 확인하기

설정 또는 구독 화면에서 URL 가져오기를 선택하고 전체 구독 주소를 붙여 넣은 뒤 다운로드와 파싱이 끝날 때까지 기다리세요. 로컬 YAML을 가져온다면 확장자 표시가 꺼져 이중 확장자로 저장되지 않았는지 확인하세요. 새로 가져온 설정을 선택한 뒤 프록시 화면에 예상한 정책 그룹이 표시되는지 확인합니다. 구독 업데이트는 성공했는데 노드 목록이 바뀌지 않았다면 현재 활성 설정, 구독 만료 여부, 제공업체의 응답 내용을 먼저 확인하세요. 바로 프로그램을 재설치하지 마세요. 재설치로 서버가 오류 페이지를 반환하는 문제를 해결할 수는 없습니다.

규칙 모드에서 규칙이 실제로 참조하는 정책 그룹을 찾아 사용 가능한 노드를 직접 선택하세요. 그룹 안에 다른 그룹이 중첩되어 있을 수 있습니다. 최종 출구는 화면에서 가장 눈에 띄는 노드 이름이 아니라 마지막 단계의 선택에 따라 결정됩니다. 클라이언트의 지연 시간 테스트를 실행해 유효한 결과가 나온 노드를 고른 뒤 실제 접속을 확인하세요. 테스트 실패는 해당 테스트 요청이 완료되지 않았다는 뜻일 뿐, 모든 프로토콜과 대상에 연결할 수 없다는 결론을 내릴 근거는 아닙니다.

시스템 프록시 확인 후 TUN 단계적으로 활성화

시스템 프록시를 켠 뒤 Windows 네트워크 설정에서 프록시 서버 주소가 로컬 수신 주소를 가리키는지, 포트가 클라이언트 설정과 일치하는지 확인하세요. 일반적인 브라우저는 시스템 프록시를 따르지만 터미널, 게임, 일부 다운로드 도구는 자체 네트워크 설정을 사용할 수 있습니다. 분기 방식이 명확한 사이트를 열면서 클라이언트의 연결 패널도 확인하세요. 해당 연결이 새로 표시되지 않는다면 규칙 순서를 조정하기 전에 앱의 진입 경로부터 점검해야 합니다. 브라우저 확장 프로그램이 시스템 설정을 덮어쓸 수도 있으므로 테스트 중에는 영향을 잠시 배제하세요.

시스템 프록시를 따르지 않는 앱까지 처리해야 할 때만 TUN을 활성화하세요. 클라이언트가 서비스 설치나 권한 부여를 요청하면 완료한 뒤 로그에서 가상 네트워크 인터페이스 생성, 라우트 추가, DNS 처리 결과를 확인하세요. 회사 VPN, 가상 머신 네트워크 인터페이스, 보안 소프트웨어는 기본 라우트와 상호작용할 수 있습니다. 활성화 후 모든 연결이 끊기면 먼저 TUN을 꺼서 기존 환경을 복구한 뒤 하나씩 점검하세요. 처음부터 시스템 프록시와 TUN을 함께 켤 필요는 없습니다. 각각 따로 테스트하면 어떤 진입 경로가 달라졌는지 파악하기 쉽습니다.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com

위 PowerShell 예시는 혼합 포트가 7890이라고 가정합니다. 실제 설정에 맞게 조정하세요. 포트 테스트 성공은 TCP 수신 포트에 연결할 수 있다는 뜻일 뿐입니다. 이후 요청은 노드, DNS, 대상 사이트, 규칙을 거쳐야 합니다. curl.exe를 사용하면 명령줄 프로그램을 명확히 호출할 수 있어 일부 PowerShell 환경에서 같은 이름의 별칭으로 인해 발생하는 인수 차이를 피할 수 있습니다. 이 테스트는 프록시를 명시적으로 지정하므로 앱이 시스템 프록시를 따르는지에 의존하지 않습니다. 로컬 수신 문제와 시스템 설정 문제를 구분할 때 유용합니다.

종료, 절전 모드, 포트 충돌

종료하기 전에 시스템 프록시를 끄고 시스템 설정이 복구됐는지 확인한 다음 클라이언트를 종료하세요. 프로그램이 비정상 종료된 뒤 브라우저가 인터넷에 연결되지 않으면 로컬 주소를 가리키는 프록시 설정이 남아 있는지 확인하세요. 이 경우 시스템 프록시를 복구하면 되며 모든 네트워크 설정을 삭제할 필요는 없습니다. 절전 모드에서 깨어난 뒤 노드 연결이 끊겼다면 연결을 다시 만들거나 코어를 재시작한 다음 구독 업데이트가 필요한지 판단하세요. 포트 충돌이 발생하면 이미 수신 중인 프로세스를 찾아보세요. 중복 실행 문제를 감추려고 포트를 계속 바꾸지 마세요. 첫 연결 확인 방법은 노드 선택 및 프록시 적용 확인을 참고하세요.

# 03장 · macos

macOS 권한 및 네트워크 서비스

칩에 맞는 클라이언트 선택

‘이 Mac에 관하여’에서 Apple Silicon과 Intel 중 어떤 프로세서를 사용하는지 확인한 뒤 macOS 다운로드에서 해당 설치 파일을 선택하세요. 먼저 Clash Plus를 확인하고, Clash Verge Rev 또는 FlClash도 사용할 수 있습니다. ClashX Meta는 개발이 중단된 보관용 선택지로 남아 있습니다. 다운로드 페이지의 아키텍처 선택 항목과 시스템 요구 사항을 함께 확인하세요. 클라이언트 이름만으로 호환성을 판단하면 안 됩니다. 변환 실행과 네이티브 실행에는 제약이 다를 수 있으므로 기기 아키텍처에 맞는 배포 파일을 우선 선택하세요.

배포 파일이 디스크 이미지라면 설치 안내에 따라 앱을 ‘응용 프로그램’ 폴더에 넣고, 고정된 위치에서 실행하세요. 임시로 마운트한 위치에서 계속 실행하지 않는 것이 좋습니다. 시스템 보안 안내는 출처와 앱 서명 정보를 확인해 판단하세요. 출처를 알 수 없거나 파일이 손상됐거나 예상과 다른 안내가 표시되면 시스템 보안 기능을 바로 끄지 말고 다운로드 페이지에서 파일을 다시 확인하세요. 처음 실행한 뒤 메뉴 막대 아이콘과 로그를 확인해 앱과 코어가 정상적으로 작동하는지 살펴본 다음 시스템 프록시 또는 네트워크 확장 권한을 처리하세요.

설정 가져오기 및 로컬 오버라이드

설정 관리 화면에서 구독을 가져오고 다운로드와 파싱이 끝나면 활성 설정으로 지정하세요. 프록시 화면에서 정책 그룹, 노드, 규칙이 모두 있는지 확인합니다. 구독 이름만 표시되고 프록시 항목이 없다면 구독 형식과 응답 내용을 확인하세요. macOS 앱의 설정 데이터는 보통 사용자 디렉터리 아래 앱 데이터 위치에 저장되며 정확한 경로는 클라이언트에 따라 다릅니다. 다른 프로그램의 경로를 추측하기보다 클라이언트의 ‘설정 폴더 열기’ 또는 비슷한 기능을 사용하세요.

구독을 업데이트하면 원격 설정 내용으로 바뀌므로 다운로드된 파일을 직접 편집하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 개인 규칙 추가, DNS 수정, 포트 변경이 필요하면 클라이언트에서 지원하는 오버라이드·병합·확장 설정 기능을 우선 사용하고 결과를 확인하세요. 클라이언트마다 배열을 대체하는지 추가하는지가 다를 수 있습니다. 특히 사용자 지정 규칙이 기본 처리 규칙보다 실제로 앞에 배치됐는지 확인하세요. 수정 전에 복구 가능한 로컬 사본을 저장하되, 접속 정보가 포함된 백업을 공개 저장소와 동기화하지 마세요.

현재 네트워크 서비스의 프록시 확인

시스템 프록시를 활성화한 뒤 시스템 네트워크 설정에서 사용 중인 Wi-Fi 또는 유선 네트워크 서비스의 프록시 옵션을 확인하세요. 네트워크 서비스마다 설정이 다를 수 있으므로 유선 네트워크에서 Wi-Fi로 바꾼 뒤에는 현재 서비스의 설정을 다시 확인해야 합니다. HTTP, HTTPS, SOCKS 설정 방식은 클라이언트에 따라 다릅니다. 다른 클라이언트의 화면을 보고 항목을 그대로 입력하지 마세요. 시스템 명령으로 적용 상태를 확인할 수 있지만 출력에 환경 정보가 포함될 수 있으니 공개하기 전에 민감 정보를 가리세요.

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

프록시를 명시한 요청은 성공하는데 브라우저 접속이 연결 패널에 표시되지 않는다면 브라우저 프록시 확장, 별도 프록시 설정, 현재 네트워크 서비스를 우선 확인하세요. 터미널 명령은 그래픽 인터페이스의 시스템 프록시 설정을 모두 자동으로 따르지 않을 수 있습니다. 사용하는 도구에 맞게 프록시 인수나 환경 변수를 설정해야 합니다. 환경 변수는 이를 읽는 프로세스에만 적용됩니다. 새 터미널과 이미 실행 중인 개발 도구가 서로 다른 환경을 사용할 수도 있으므로 같은 터미널에서 다시 테스트하세요.

TUN 권한, 네트워크 전환 및 복구

TUN을 사용하려면 클라이언트 안내에 따라 네트워크 확장 또는 보조 서비스에 필요한 권한을 부여하세요. 구체적인 승인 방식은 구현에 따라 다릅니다. 승인 창이 사라졌다고 트래픽 처리가 완료된 것은 아닙니다. 로그에서 인터페이스 생성, 라우트 설치, DNS 시작이 성공했는지 확인하세요. 회사 VPN을 함께 사용하는 경우 VPN이 라우트와 DNS를 강제로 설정할 수 있습니다. 이러한 충돌은 조직의 네트워크 정책에 따라 처리해야 하며, 관리 설정을 덮어쓰려 해서는 안 됩니다. 먼저 각 도구를 따로 활성화해 결과를 확인한 뒤 함께 사용할 수 있는지 판단하세요.

절전 모드에서 깨어나거나 핫스팟으로 전환할 때, 포털 인증이 필요한 네트워크에 접속할 때는 기본 라우트가 바뀔 수 있습니다. 호텔이나 공공 Wi-Fi에서 웹 인증이 필요하다면 먼저 트래픽 처리를 일시 중지하고 인증을 마친 뒤 프록시를 다시 테스트하세요. TUN을 끈 뒤에도 연결되지 않으면 현재 네트워크 서비스에 시스템 프록시 설정이 남아 있는지, 다른 VPN이 실행 중인지 확인하세요. 모든 네트워크 서비스를 삭제하거나 DNS를 초기화하고 클라이언트까지 재설치하지 마세요. 한 번에 하나의 조건만 바꿔야 복구 원인을 파악하고 이후 진단에 필요한 기록도 남길 수 있습니다.

# 04장 · android

Android 권한 및 백그라운드 실행

앱 설치 및 설정 가져오기

Android 다운로드에서 먼저 Clash Plus를 선택하세요. 필요에 따라 Clash Meta for Android, FlClash, Surfboard도 확인할 수 있습니다. 기기가 지원하는 프로세서 아키텍처를 확인한 뒤 설치 파일을 받으세요. 모든 Android 기기가 같은 아키텍처를 사용하는 것은 아닙니다. 시스템에서 현재 브라우저나 파일 관리자의 앱 설치를 허용하라고 하면 이번 설치에 필요한 출처 권한만 부여하고, 설치 후에는 원래 설정으로 되돌릴 수 있습니다. 설치 충돌이 발생하면 서명이 다른 동명의 앱이 이미 설치되어 있는지 먼저 확인하세요. 기존 앱 데이터를 바로 삭제하지 마세요.

처음 앱을 열고 구독 링크나 로컬 설정 파일을 가져오세요. 시스템 파일 선택기로 가져올 때 클라이언트가 실제로 파일 읽기 권한을 받았는지 확인하세요. 파일 이름만 표시된다고 읽을 수 있는 것은 아닙니다. 다운로드가 끝나면 해당 설정을 직접 선택하고 프록시 화면에 정책 그룹이 나타나는지 확인하세요. 기존 설정에 현재 클라이언트가 지원하지 않는 필드나 프로토콜이 있으면 파싱 실패나 일부 기능 누락이 발생할 수 있습니다. 가져오기 로그를 기준으로 확인하고, 프록시를 지원한다는 이유만으로 설정이 완전히 호환된다고 가정하지 마세요.

VpnService와 코어로 트래픽이 들어가는 방식

Android 프록시 클라이언트는 보통 VpnService로 로컬 VPN 인터페이스를 만들어 기기 트래픽을 앱으로 전달합니다. 시스템에 표시되는 VPN 연결 권한 요청은 앱이 네트워크를 처리하도록 허용하는 단계일 뿐, 원격 노드에 연결됐다는 뜻은 아닙니다. 최종 출구는 설정, 정책 그룹, 규칙에 따라 달라집니다. 권한을 승인한 뒤 연결을 시작하고 시스템 VPN 상태와 클라이언트 로그를 확인한 다음 테스트 대상에 접속하세요. 열쇠 아이콘이나 VPN 표시만으로 구독, 노드, DNS가 모두 정상이라고 판단할 수는 없습니다.

일반 데스크톱의 ‘시스템 프록시’ 스위치를 Android에 그대로 적용할 수는 없습니다. Wi-Fi 네트워크의 수동 프록시는 해당 네트워크와 앱에만 영향을 줄 수 있으며 VpnService를 통한 트래픽 처리와는 다릅니다. Android에서는 일반적인 VPN 앱 두 개가 같은 서비스 슬롯을 동시에 사용할 수 없는 경우가 많습니다. 다른 VPN, VPN 기반 필터링 도구, 방화벽이 시작되면 현재 클라이언트가 밀려날 수 있습니다. 연결이 다른 앱으로 대체되면 노드를 계속 바꾸기 전에 시스템 VPN 설정에서 충돌 여부를 확인하세요.

규칙, 앱별 설정 및 백그라운드 제한

먼저 규칙 모드에서 기본 설정을 테스트한 뒤 앱별 설정을 조정하세요. 앱별 설정은 어떤 앱이 VPN으로 들어갈지를 정하고, 도메인 규칙은 들어온 트래픽의 출구를 결정합니다. 서로 다른 계층의 설정입니다. 대상 앱을 VPN에서 제외하면 해당 앱이 접속하는 도메인에 프록시 규칙을 추가해도 적용되지 않습니다. 허용 목록이나 제외 목록을 바꾼 뒤 일부 클라이언트는 VPN 인터페이스를 다시 만들어야 합니다. 이전 연결이 기존 경로를 계속 사용하지 않도록 대상 앱 연결을 끊었다가 다시 여세요.

시스템 절전 정책은 화면이 잠긴 뒤 클라이언트 실행을 제한할 수 있습니다. 백그라운드에서만 연결이 끊긴다면 앱의 배터리 정책, 백그라운드 실행, 자동 시작, 제조사 제공 작업 고정 기능을 확인하세요. 설정 경로는 시스템마다 다릅니다. 필요한 백그라운드 활동만 허용한 뒤 화면을 잠시 꺼 두고 로그가 계속 기록되는지 확인하세요. 모든 앱을 예외 목록에 추가하지 마세요. 제조사별 설정 방법은 VpnService 권한 및 배터리 최적화 예외를 참고하세요. VPN을 계속 실행하면 리소스가 사용되며, 모든 기기에서 같은 성능을 보장할 수는 없습니다.

비공개 DNS, 네트워크 전환 및 업데이트

Android에서는 비공개 DNS, 브라우저 보안 DNS, 클라이언트 DNS, 모바일 네트워크 DNS가 동시에 작동할 수 있습니다. 설정에서 DNS 트래픽을 처리하도록 했다면 먼저 경로를 하나씩 설명할 수 있도록 유지하고, 비교 테스트 전에 비공개 DNS의 기존 상태를 기록하세요. 오류가 보인다고 서버, Fake-IP, 모든 DNS 스위치를 한꺼번에 바꾸지 마세요. 먼저 요청이 코어에 들어오는지 확인한 다음 특정 도메인에서만 이름 해석 오류가 발생하는지 살펴보세요. IPv6도 네트워크 아이콘만 보고 판단하지 말고 라우트 처리 기능과 함께 확인해야 합니다.

Wi-Fi에서 모바일 네트워크로 전환한 뒤 연결이 잠시 끊기면 네트워크가 준비될 때까지 기다린 다음 클라이언트를 다시 연결하고 구독 주소에 접속할 수 있는지 확인하세요. 핫스팟에 연결된 기기의 트래픽이 휴대폰 VPN으로 들어간다고 보장할 수 없습니다. 휴대폰에서 접속된다고 핫스팟 공유도 정상이라고 판단하지 마세요. 구독 자동 업데이트는 백그라운드 제한과 네트워크 상태의 영향을 받습니다. 필요하면 앱을 열고 직접 업데이트한 뒤 활성 설정을 확인하세요. 앱 업데이트 전에는 필요한 설정을 보관하고, 데이터 처리는 마이그레이션이나 서명 충돌 해결이 꼭 필요한 경우에만 하세요.

# 05장 · ios

iOS 설정 가져오기 및 VPN

Clash Plus 설치 및 설정 지원 범위 확인

iOS 다운로드에서 Clash Plus의 App Store 페이지로 이동할 수 있습니다. 앱 정보는 공식 웹사이트 clashplus.io에서도 확인하세요. 설치 전에 스토어에 안내된 시스템 요구 사항과 기능 설명을 읽어보세요. Clash 설정은 하나의 생태계 형식이며, 가져오기를 지원한다고 해서 모든 클라이언트가 mihomo의 모든 필드를 구현한 것은 아닙니다. 고급 DNS, 스크립트, 특정 프로토콜 설정을 사용한다면 현재 앱의 지원 범위를 먼저 확인하세요. 데스크톱 설정이 모두 동일하게 작동한다고 가정하지 마세요.

iOS 프록시 앱은 시스템 네트워크 확장으로 트래픽을 처리하며, 데스크톱 코어 프로세스를 직접 실행하는 방식과 다릅니다. Windows와 똑같은 서비스 설치 버튼을 찾거나 데스크톱의 가상 네트워크 인터페이스 설정을 휴대폰에 그대로 대응시키지 마세요. 설정을 인식하는지, VPN 확장이 성공적으로 시작되는지, 대상 연결이 예상한 경로를 따르는지를 기준으로 확인하세요. 같은 이름의 스위치가 화면에 없다면 기능 설명을 확인하세요. 알 수 없는 시스템 프로파일을 가져와 기능을 억지로 추가하지 마세요.

구독 링크, 파일, QR 코드

설정 화면에서 링크 가져오기를 선택하고 전체 구독 주소를 붙여 넣은 다음 가져오기를 실행하세요. 입력한 뒤 프로토콜, 경로, 쿼리 매개변수가 모두 포함됐는지 확인하고 끝에 공백이나 줄바꿈이 들어가지 않도록 하세요. 클라이언트가 파일 가져오기를 지원하면 시스템 파일 선택기나 공유 메뉴에서 YAML을 선택할 수 있습니다. 클라우드 파일이 아직 로컬에 다운로드되지 않았다면 읽을 수 있을 때까지 기다리세요. 가져온 뒤 해당 설정을 현재 사용 설정으로 지정하고 정책 그룹에 예상한 노드가 있는지 확인하세요. 구독 기록만 보여서는 충분하지 않습니다.

QR 코드는 보통 구독 주소나 노드 링크를 담는 다른 방식일 뿐, 형식 호환성 문제를 자동으로 해결하지 않습니다. 스캔 전후에 출처를 확인하고 구독 QR 코드를 공개 게시판에 올리지 마세요. 시스템 공유 메뉴에 클라이언트가 없다면 앱으로 돌아와 지원되는 가져오기 방식을 사용하세요. 브라우저에서 YAML을 직접 열려고 반복해서 시도할 필요는 없습니다. 구독 요청에 로그인 페이지나 오류 안내가 반환되면 앱에서 파싱 오류가 표시될 수 있습니다. 이때는 앱의 형식을 점검하기 전에 구독 접근 권한부터 확인하세요.

VPN 권한 및 첫 연결 확인

활성 설정과 노드를 선택한 뒤 연결을 시작하세요. 시스템에서 VPN 설정 추가를 허용하라는 메시지가 표시되면 기기 인증으로 승인해야 할 수 있습니다. 이 권한은 앱이 관리하는 VPN 연결을 설정하기 위한 것이며 구독이 유효하다는 뜻은 아닙니다. 승인 후 앱으로 돌아와 시작 결과를 확인하고 브라우저에서 테스트 대상에 접속하세요. 앱에 연결 또는 로그 화면이 있다면 대상 도메인, 규칙, 출구를 확인합니다. 세부 정보가 충분하지 않다면 명확한 직접 연결 대상과 프록시 대상의 결과를 비교하세요. 단일 사이트 접속 실패만으로 전체 상태를 판단하지 마세요.

규칙 모드를 기본 테스트 환경으로 사용하는 것이 좋습니다. 전역 모드는 앱에 들어온 연결을 전역 정책에 맡기는 경우가 많지만, 모드 이름만 보고 모든 시스템 트래픽이 처리된다고 단정할 수는 없습니다. 실제 범위는 시스템과 앱 구현에 따라 달라집니다. 직접 연결 모드에서도 VPN이 종료되는 것은 아니며 DNS와 라우트 처리는 계속될 수 있습니다. 원래 네트워크를 완전히 복구해 비교하려면 앱의 VPN 연결을 중지한 뒤 같은 대상에 다시 접속하세요. 두 테스트에서 트래픽 처리 상태만 달라지도록 해야 합니다.

네트워크 전환, DNS 및 유지 관리

다른 VPN 앱, 관리형 기기의 네트워크 정책, 시스템의 개인정보 보호 네트워크 기능은 실제 접속 경로를 바꿀 수 있습니다. 연결이 서로 대체되는 경우 시스템 VPN 목록에서 현재 활성화된 앱이 무엇인지 먼저 확인하세요. 현재 클라이언트와 무관한 기업 설정을 삭제하지 마세요. 공공 Wi-Fi에서 포털 인증이 필요하면 프록시를 잠시 중지하고 로그인할 수 있습니다. 인증을 마친 뒤 연결을 복구하고 도메인 해석을 다시 확인하세요. 네트워크 접속 절차가 끝나기 전에 노드를 계속 바꾸지 마세요.

화면 잠금, Wi-Fi와 셀룰러 네트워크 전환 후 문제가 생기면 앱에서 다시 연결한 뒤 특정 네트워크에서만 발생하는지 확인하세요. 배터리 부족, 시스템 백그라운드 작업, 네트워크 확장 상태가 함께 영향을 줄 수 있으므로 앱 화면이 계속 열려 있는지만으로 판단하지 마세요. 구독 업데이트 후 현재 정책 그룹 선택이 유지됐는지 확인하세요. 노드가 삭제되거나 이름이 바뀌면 기존 선택을 다시 지정해야 할 수 있습니다. 전체 과정은 iOS 앱 설치 및 설정 가져오기 노트를 참고하세요. 문제를 해결할 때는 현재 클라이언트가 실제로 지원하는 옵션을 기준으로 판단하세요.

# 06장 · linux

Linux 데스크톱 및 코어 서비스

GUI와 독립 코어 중 선택

데스크톱 사용자는 Linux 다운로드에서 권장 클라이언트인 Clash Verge Rev를 선택하거나 FlClash를 사용할 수 있습니다. 배포판의 패키지 관리 방식, 프로세서 아키텍처, 데스크톱 세션, 설치 파일 요구 사항을 먼저 확인하세요. DEB를 지원한다고 모든 Linux 환경에서 사용할 수 있는 것은 아닙니다. 서버나 라우터에 설치하려면 mihomo 코어 다운로드를 확인하세요. 독립 코어에는 구독, 시스템 프록시, 실행 권한을 관리하는 GUI가 없습니다. 이 작업은 직접 설정해야 하며, 설정 디렉터리와 실행 계정을 명확히 파악해야 합니다.

데스크톱 클라이언트를 설치한 뒤 먼저 일반 사용자로 실행해 로그와 설정 화면을 사용할 수 있는지 확인하세요. 그래픽 앱에 필요한 시스템 구성 요소는 배포판에서 지원하는 방법으로 설치하고, 관계없는 사이트에서 같은 이름의 공유 라이브러리를 임의로 다운로드하지 마세요. 데스크톱 메뉴에 아이콘이 없으면 배포 패키지가 제공하는 실행 경로로 시작 오류를 확인한 뒤 데스크톱 통합을 점검하세요. 서버에서는 부팅 시 자동 실행 서비스로 등록하기 전에 코어와 설정을 포그라운드에서 확인하는 편이 오류를 파악하기 쉽습니다. 서비스가 재시작되면서 첫 오류가 감춰지는 것도 막을 수 있습니다.

설정 가져오기, 경로 및 문법 확인

GUI 사용자는 설정 화면에서 구독을 가져와 활성 설정으로 지정하세요. 독립 코어 사용자는 전체 YAML을 경로가 명확한 디렉터리에 저장한 뒤 파일 읽기 권한을 확인해야 합니다. 설정에 접속 정보가 있다면 다른 로컬 계정의 읽기를 제한하고 백업에도 같은 제한을 적용하세요. 상대 경로는 보통 코어의 작업 디렉터리나 설정 디렉터리를 기준으로 해석됩니다. 규칙 모음, 지리 데이터, 로컬 제공자 파일을 찾지 못하면 파일을 여러 디렉터리에 복사해 보지 말고 경로가 해석되는 방식을 먼저 확인하세요.

mkdir -p "$HOME/.config/mihomo"
chmod 700 "$HOME/.config/mihomo"
mihomo -t -d "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

이 명령은 실행 가능한 mihomo가 설치되어 있고 전체 설정을 해당 디렉터리의 config.yaml에 저장했다고 가정합니다. 설정 검사를 먼저 실행해 통과하면 포그라운드에서 시작하세요. 검사를 통과했다는 것은 설정이 받아들여졌다는 뜻이지, 원격 노드에 접속할 수 있다거나 외부 규칙 리소스가 이후에도 갱신된다는 뜻은 아닙니다. 권한 오류가 발생하면 디렉터리 소유자와 프로세스 계정을 확인하세요. 설정 디렉터리 전체를 모든 사용자가 쓸 수 있도록 바꾸지 마세요.

데스크톱 프록시와 터미널 환경을 따로 확인

Linux 데스크톱 환경마다 시스템 프록시 저장 방식이 다르고, 앱이 해당 설정을 따르는 정도도 제각각입니다. GUI에서 시스템 프록시를 켠 뒤 현재 데스크톱 네트워크 설정을 확인하고 대상 앱의 연결이 표시되는지 살펴보세요. 명령줄 도구에는 보통 프록시 인수나 환경 변수를 별도로 지정해야 합니다. 브라우저는 되는데 패키지 관리자는 안 된다고 해서 곧바로 노드 문제라고 볼 수는 없습니다. 모든 셸 시작 파일을 바로 수정하기보다 임시 환경 변수로 테스트하면 쉽게 되돌릴 수 있습니다. 테스트 후 설정을 지속할지 결정하세요.

curl --proxy http://127.0.0.1:7890 --head https://example.com
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1
unset http_proxy https_proxy no_proxy

여기서 https_proxy 값은 여전히 HTTP 프록시 진입점입니다. HTTPS 대상은 해당 진입점을 통해 터널을 만들며, 로컬 프록시 포트 자체에 TLS를 요구하는 것은 아닙니다. 도구마다 대문자·소문자 환경 변수와 제외 목록 지원 방식이 다릅니다. 권한 상승으로 명령을 실행하면 현재 환경을 상속하지 않을 수도 있습니다. 도구 하나를 작동시키려고 모든 시스템 서비스에 프록시 변수를 설정하지 마세요. 해당 도구의 문서와 실행 계정을 확인한 뒤 필요한 범위에만 적용하세요.

TUN, 서비스 관리 및 방화벽

TUN은 가상 네트워크 장치, 라우트, DNS를 다루므로 보통 적절한 네트워크 관리 권한이 필요합니다. 컨테이너에서는 호스트가 필요한 장치 접근과 권한을 허용해야 합니다. 컨테이너 내부 설정이 올바르다고 호스트 트래픽까지 처리되는 것은 아닙니다. 데스크톱 클라이언트에 서비스 모드가 있다면 안내된 설치 절차를 따르세요. 독립 코어는 권한 범위를 이해한 뒤 배포판의 서비스 관리 기능을 사용해야 합니다. 편의를 위해 모든 그래픽 프로그램을 계속 root로 실행하지 마세요.

서비스를 등록할 때는 실행 파일 경로, 설정 디렉터리, 실행 계정을 명확히 지정하세요. 자동 시작을 설정하기 전에 포그라운드 테스트를 마치세요. 문제를 진단할 때는 먼저 다른 코어가 이미 포트를 사용하고 있는지 확인한 다음 서비스 로그에서 종료 원인을 살펴보세요. 시스템 방화벽, 다른 VPN, 컨테이너 네트워크가 라우트를 바꿀 수 있습니다. 혼합 포트를 열었다고 외부 인터넷에서 접속할 수 있어야 하는 것은 아닙니다. 기본적으로 로컬에서만 수신하도록 설정하세요. LAN 공유가 꼭 필요하다면 접근 범위, 인증, 호스트 방화벽, 신뢰할 수 없는 네트워크를 함께 고려해 프록시 진입점이 아무에게나 노출되지 않도록 하세요.

# 07장 · configuration-faq

설정 FAQ 및 문제 해결 순서

먼저 어느 계층에서 실패하는지 확인

먼저 문제가 발생하는 범위를 기록하세요. 설정을 가져올 수 없는지, 코어가 시작되지 않는지, 모든 앱이 실패하는지, 특정 대상만 문제가 있는지 확인합니다. 가져오기 실패는 구독 응답, 파일 형식, 파싱 오류를 살펴보세요. 시작 실패는 포트, 경로, 권한을 확인합니다. 연결은 됐지만 접속에 실패한다면 규칙, DNS, 노드, 대상 응답을 살펴보세요. 한 번에 하나의 변수만 바꾸고 테스트 전후 로그 일부를 저장하세요. 구독 업데이트, 모드 전환, TUN 활성화, DNS 변경을 한꺼번에 하면 일시적으로 접속이 복구되더라도 원인을 알기 어렵고 다음에 재현됐을 때 대처하기 힘듭니다.

로그의 시간 초과가 항상 같은 원인을 뜻하지는 않습니다. 구독 가져오기, DNS 요청, 노드 핸드셰이크, 대상 접속 중 어느 단계에서 발생했는지 오류 전후의 대상 주소와 함께 확인하세요. 연결 거부 오류라면 수신 상태와 포트를 우선 점검하고, 인증서 오류라면 시스템 시간, 대상 이름, 네트워크 환경을 확인하세요. 진단을 위해 로그 수준을 잠시 높이면 단서를 더 얻을 수 있습니다. 진단이 끝나면 적절한 수준으로 되돌려 도메인과 연결 정보가 장기간 과도하게 기록되지 않도록 하세요. 로그를 공개하기 전에 민감 정보를 반드시 삭제하세요.

규칙 매칭 및 정책 그룹의 실제 출구

규칙은 일반적으로 위에서부터 순서대로 매칭되며, 처음 일치하는 규칙이 지정한 정책을 사용합니다. 사용자 지정 규칙을 최종 MATCH 뒤에 두면 보통 적용되지 않습니다. 존재하지 않는 정책 그룹을 참조해도 설정 오류가 발생합니다. 아래 예시는 현재 설정에 PROXY라는 정책 그룹이 이미 있다고 가정하고 매칭 관계만 보여 줍니다. 완전한 구독 설정으로 단독 사용할 수 없습니다. GEOIP 판단에는 관련 데이터와 파싱 조건이 필요합니다. 도메인 규칙과 IP 규칙의 결과를 대상 사이트 이름만으로 추측하지 마세요.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

프록시 규칙에 매칭됐는데도 직접 연결된다면 해당 정책 그룹에서 DIRECT를 선택했는지, 중첩 그룹이 다른 직접 연결 그룹을 가리키는지 확인하세요. 전역 모드로 바꾼 경우에도 방금 선택한 노드가 자동으로 사용된다고 가정하지 말고 전역 정책의 선택을 확인해야 합니다. 규칙·전역·직접 연결 모드의 차이는 세 가지 프록시 모드 설명을 참고하세요. 새 규칙을 테스트할 때는 기존 연결을 끊고 다시 접속하세요. 이미 열린 장기 연결은 규칙 변경 직후 새 출구로 바뀌지 않을 수 있습니다.

Fake-IP, DNS, TUN의 관계

Fake-IP는 DNS 응답으로 매핑용 가상 주소를 돌려주고, 코어는 매핑을 이용해 도메인을 복원한 뒤 트래픽을 분기합니다. 원격 노드 주소가 아니며 DNS 오염의 증거로 단정할 수도 없습니다. 앱에 가상 주소가 캐시된 상태에서 클라이언트가 종료되거나 트래픽 처리 경로가 바뀌면 DNS 응답과 라우팅이 맞지 않을 수 있습니다. DNS와 트래픽 처리 설정을 일관된 상태로 복구한 다음 대상 앱을 재시작하거나 관련 캐시를 비우세요. 가상 주소를 장기간 사용하는 호스트 매핑에 직접 넣지 마세요.

TUN을 활성화해도 모든 DNS 요청이 예상대로 처리되는 것은 아닙니다. 앱 자체의 암호화 DNS, 시스템 비공개 DNS, IPv6 라우트, 다른 VPN이 경로에 영향을 줍니다. 요청과 규칙이 실제로 어떻게 처리되는지 확인한 뒤 설정이 적용됐는지 판단하세요. LAN 기기 이름, 프린터, 사내 도메인은 로컬 DNS에 접근해야 할 수 있습니다. 필요한 경우 대상에 맞는 DNS 정책이나 Fake-IP 제외 규칙을 설정하세요. 모든 도메인을 직접 연결로 바꾸지 마세요. 개념 설명은 DNS 및 네트워크 스택 용어를 참고하세요.

복구 가능한 설정과 업데이트 범위 유지

구독을 자동 업데이트하기 전에 로컬 오버라이드 규칙을 보관하고, 업데이트 후 정책 그룹 이름, 노드 선택, 생성된 DNS 설정을 확인하세요. 상위 설정에서 정책 그룹 이름이 바뀌면 기존 오버라이드가 존재하지 않는 항목을 참조할 수 있습니다. 설정은 로드되지만 동작이 달라졌다면 편집기 원본만 보지 말고 최종 적용된 설정을 비교하세요. 클라이언트, 코어, 구독은 서로 다른 업데이트 경로입니다. 한 계층의 업데이트가 성공했다고 다른 계층도 바뀌었다고 보면 안 됩니다. 문제 해결 기록에는 이 세 항목의 상태를 각각 적어 두세요.