Clash 전 플랫폼 설정 가이드

공통 준비 사항과 설정 범위

클라이언트, 코어, 구독의 역할 구분하기

Clash 생태계에서 GUI 클라이언트는 설정 가져오기, 정책 그룹 관리, 시스템 프록시 설정, 연결 표시를 담당합니다. mihomo 같은 코어는 설정을 해석하고 로컬 포트를 열어 규칙을 적용합니다. 구독은 프록시, 정책 그룹, 규칙, DNS 설정 등이 포함될 수 있는 설정의 출처입니다. 클라이언트를 설치해도 사용할 수 있는 원격 프록시가 자동으로 생성되지는 않습니다. 시작하기 전에 사용 권한이 있는 구독이나 설정 파일을 준비하고, 제공업체가 안내한 형식과 사용 범위, 업데이트 방법을 확인하세요.

이 가이드에서는 Windows, macOS, Android, iOS에서 Clash Plus를 우선 안내하고, Linux 데스크톱에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 클라이언트마다 구독 형식, 확장 필드, 설정 덮어쓰기 지원이 다르므로 파일 이름만으로 호환성을 판단할 수 없습니다. 다운로드 전에 플랫폼별 다운로드 옵션과 시스템 요구 사항을 확인하고 기기 아키텍처를 살펴보세요. 데스크톱 클라이언트의 버튼 위치를 모바일 앱에 그대로 적용하거나, 이전 버전 코어의 지원 필드 범위를 전체 생태계의 공통 기준으로 간주하지 마세요.

준비물과 백업 순서

구독을 저장할 때는 쿼리 매개변수를 포함한 전체 URL을 보관하되, 공개 채팅이나 스크린샷, 문제 보고서에 공유하지 마세요. URL에 접근 권한이 포함된 경우가 많으므로 유출되면 제공업체에서 다시 발급받아야 합니다. 새 클라이언트를 설치하기 전에 기존 프록시 앱의 종료 방법, 현재 시스템 프록시 상태, 사용자 지정 DNS를 기록하세요. 기존 앱은 잠시 남겨둘 수 있지만 테스트 중에는 트래픽을 처리하는 도구를 하나만 실행하세요. 조직에서 관리하는 기기라면 프록시 변경, 네트워크 확장 설치, 가상 인터페이스 생성이 허용되는지 먼저 확인하세요.

처음 가져온 설정은 가능한 한 그대로 두고, 작동에 필요한 최소한의 항목만 변경하세요. 클라이언트 화면에서 바꾼 설정은 앱 데이터베이스, 오버라이드 파일, 메모리상의 실행 설정에 반영될 수 있으며 구독 원본 자체를 수정하지 않을 수 있습니다. 구독 원본, 사용자 지정 오버라이드, 필요한 앱 설정을 함께 백업하세요. 캐시의 YAML 파일만 복사하면 화면에서 선택한 정책이나 서비스 상태가 빠질 수 있습니다. 기기를 옮기기 전에 로컬 백업을 내보낼 수 있지만 민감한 정보가 포함될 수 있으므로 안전한 위치에 보관하세요.

재현 가능한 검증 기준 만들기

코어를 시작한 뒤 노드부터 바꾸지 말고 로그에서 설정 해석 오류, 포트 충돌, 권한 부족이 있는지 먼저 확인하세요. 아래 포트는 흔히 쓰이는 예시일 뿐 고정값이 아니므로, 테스트에는 클라이언트가 실제로 수신 중인 포트를 사용해야 합니다. 컨트롤 인터페이스는 코어 관리용이며 브라우저의 프록시 주소가 아닙니다. 브라우저를 컨트롤 인터페이스에 연결해도 포트 접속에 성공할 뿐 정상적인 프록시 연결은 되지 않습니다. 수신 주소는 로컬 루프백 범위로 제한하면 서비스가 실수로 LAN에 노출될 위험을 줄일 수 있습니다.

‘코어 시작, 명시적 프록시 요청, 앱의 시스템 프록시, TUN’ 순서로 단계별 검증을 권장합니다. 데스크톱에서는 먼저 명령 하나가 프록시 포트를 명시적으로 거치게 해 설정 경로를 확인한 다음 시스템 프록시를 켜세요. 시스템 프록시를 따르지 않는 앱이나 더 많은 트래픽을 처리해야 할 때만 TUN을 추가하면 됩니다. 이렇게 하면 문제가 생겼을 때 어느 단계에서 변화가 발생했는지 파악할 수 있습니다. 속도 테스트 성공은 해당 테스트 대상의 응답만 확인할 뿐, 모든 웹사이트와 프로토콜, 앱이 정상이라는 뜻은 아닙니다. 연결 로그도 함께 확인하세요.

검증할 때는 대상 주소와 앱을 하나씩 고정하고, 한 번에 설정 하나만 바꾸며 변경 전후의 로그를 기록하세요. 브라우저가 기존 연결을 재사용할 수 있으므로 모드를 바꾼 뒤 새 요청을 보내고, 필요하면 기존 연결을 종료하세요. 계정 로그인이 필요한 사이트는 지역, 시간, 서비스 정책의 영향을 받을 수 있으므로 모든 접속 제한을 프록시 문제로 돌리지 마세요. 첫 배포의 목표는 원인을 설명하고 복구할 수 있는 상태를 만드는 것입니다. 고급 옵션을 한꺼번에 켜는 것이 아닙니다.

Windows 설치 및 설정

클라이언트 설치와 코어 상태 확인

Windows 다운로드에서 Clash Plus를 우선 선택하세요. 다른 화면이나 작업 흐름이 필요하다면 Clash Verge Rev, FlClash, Clash Nyanpasu를 비교해 볼 수 있습니다. Clash for Windows는 유지 관리가 중단된 보관용 클라이언트이므로 새로 설치할 때 기본 선택으로 권장하지 않습니다. 다운로드 전에 시스템 설정에서 시스템 종류를 확인하고 설치 파일의 아키텍처와 지원 범위를 살펴보세요. 설치 프로그램에서 보안 경고가 나타나면 다운로드 출처와 배포 정보를 먼저 확인하고, 설치를 계속하기 위해 시스템 보안 기능을 영구적으로 끄지 마세요.

설치가 끝나면 먼저 일반 사용자로 실행해 클라이언트가 열리는지, 설정 폴더에 쓸 수 있는지, 코어가 실행되는지 확인하세요. 화면은 표시되지만 코어가 반복해서 종료된다면 연결 버튼을 계속 누르지 말고 로그에 처음 나타난 오류를 살펴보세요. 존재하지 않는 파일을 참조하는 이전 설정, 다른 프록시가 사용 중인 포트, 권한이 제한된 폴더 등이 시작 실패의 원인일 수 있습니다. 서비스 모드나 TUN이 필요할 때만 클라이언트 안내에 따라 권한을 높이세요. 일상적으로 사용할 때 앱 전체를 계속 관리자 권한으로 실행할 필요는 없습니다.

구독 가져오기 및 현재 설정 선택

설정 또는 구독 화면에서 원격 설정을 추가하고 전체 URL을 붙여 넣은 다음 알아보기 쉬운 이름을 지정하고 다운로드나 업데이트를 실행하세요. 설정 항목이 목록에 나타난 뒤에는 해당 항목이 현재 실행 설정으로 선택되어 있는지도 확인해야 합니다. 일부 클라이언트는 구독을 여러 개 저장할 수 있지만, 한 번에 실행되는 것은 보통 선택된 설정과 오버라이드 결과입니다. 프록시 목록이 있는데 메인 화면에는 이전 정책 그룹이 보인다면 같은 URL을 반복해서 가져와 복제본을 늘리지 말고 현재 설정 이름과 코어 재로드 결과를 확인하세요.

구독 가져오기가 실패하면 네트워크 요청 오류와 콘텐츠 해석 오류를 먼저 구분하세요. 연결 시간 초과는 유효한 응답을 받지 못했다는 뜻이고, YAML 줄 번호 오류는 콘텐츠를 가져왔지만 형식이나 필드에 문제가 있다는 뜻입니다. 구독 URL에서 로그인 페이지, 권한 안내, JSON 오류가 반환되면 파일 저장에 성공해도 설정을 사용할 수 있는 것은 아닙니다. 업데이트 전후의 정책 그룹 이름과 로그를 비교하고, 목록의 업데이트 시각만으로 판단하지 마세요. 제공업체가 형식을 바꿨다면 해당 형식에 맞는 가져오기 기능을 사용하세요. 오류가 난 필드를 임의로 삭제하지 마세요.

시스템 프록시, 앱별 차이와 TUN

먼저 규칙 모드를 선택하고 기본 정책 그룹에서 사용할 수 있는 프록시를 지정한 다음 시스템 프록시를 켜세요. 브라우저는 대체로 Windows 사용자 프록시 설정을 따르지만 일부 터미널 프로그램, 백그라운드 서비스, 자체 네트워크 설정을 사용하는 앱은 따르지 않습니다. PowerShell에서 아래 명령으로 프록시를 직접 지정해 테스트할 수 있습니다. 명령 별칭에 따른 매개변수 차이를 피하려고 curl.exe를 사용합니다. 실제 포트가 7890이 아니라면 함께 수정하세요. 요청 결과는 클라이언트 연결 로그와 대조해 실제 출구를 확인해야 합니다.

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com
Get-NetTCPConnection -LocalPort 7890 -State Listen

첫 번째 명령은 성공하지만 브라우저가 실패하면 시스템 프록시 주소와 포트, 브라우저 확장 프로그램을 확인하세요. 브라우저는 정상인데 특정 명령줄 도구가 실패하면 해당 도구의 프록시 매개변수나 환경 변수를 살펴보세요. Windows 사용자 프록시 설정은 일부 서비스가 사용하는 WinHTTP 설정과 별개이므로 처음부터 시스템 전체 서비스 프록시를 변경하지 않는 것이 좋습니다. 업무용 PC에서는 조직 정책이 설정을 덮어써 프록시가 자동으로 꺼지거나 주소가 저장되지 않을 수 있습니다. 먼저 권한과 관리 정책을 확인하세요.

TUN은 더 많은 앱의 네트워크 연결을 처리하며 보통 서비스 구성 요소, 가상 인터페이스, 관련 권한이 필요합니다. 켜기 전에 시스템 프록시 경로가 정상인지 확인하고 클라이언트 안내에 따라 서비스를 설치하고 승인하세요. 활성화 후 모든 연결이 끊기면 가상 네트워크 어댑터 생성 여부, 기본 경로 문제, 다른 VPN의 동시 실행 여부를 확인하세요. 출처가 다른 네트워크 드라이버를 반복해서 설치하지 마세요. 먼저 TUN을 끄고 시스템 프록시 기준 상태로 돌아간 뒤 DNS, 경로, 제외할 네트워크를 차례로 점검하세요.

UWP, 종료 후 정리와 업데이트

일부 Microsoft Store 앱은 로컬 루프백 제한 때문에 로컬 프록시 주소에 직접 접속하지 못할 수 있습니다. 클라이언트가 제공하는 루프백 관리 도구를 우선 사용하고 필요한 앱에만 예외를 설정하세요. 원리와 명령은 Windows UWP 루프백 예외 안내를 참고하세요. 루프백 예외는 로컬 접속 제한만 해결하며, 구독 만료, 프록시 연결 실패, 규칙 오류를 해결하지는 않습니다. 이미 TUN으로 앱을 처리 중이라면 두 방식이 섞여 문제를 찾기 어려워지지 않도록 해당 연결이 코어에 들어오는지 먼저 확인하세요.

종료하거나 삭제하기 전에 시스템 프록시와 TUN을 끄고 시스템 설정이 복구됐는지 확인하세요. 클라이언트가 비정상 종료된 뒤 브라우저에 프록시 서버 연결 거부가 표시되면 Windows 프록시 설정이 종료된 로컬 포트를 계속 가리키는지 살펴보세요. 업데이트 전 사용자 오버라이드와 구독 출처를 보관하고, 업데이트 후에는 시작 시 실행 및 서비스 상태를 다시 확인하세요. 화면이 열려도 백그라운드 서비스가 정상이라는 보장은 없습니다. 절전 모드에서 복귀한 뒤 문제가 생기면 재설치부터 하지 말고 연결을 다시 설정하고 구성을 재로드하세요.

macOS 설치 및 설정

아키텍처 선택과 첫 실행 권한 승인

‘이 Mac에 관하여’에서 칩 종류를 확인한 뒤 macOS 다운로드에서 맞는 설치 파일을 선택하세요. Clash Plus를 우선 권장하며 사용 방식에 따라 Clash Verge Rev나 FlClash를 선택할 수도 있습니다. ClashX Meta는 유지 관리가 중단된 보관용 옵션이므로 이전 작업 흐름을 사용하려면 호환성을 별도로 검토해야 합니다. Apple Silicon과 Intel용 설치 파일은 용량만으로 구분할 수 없습니다. 시스템이 변환 실행을 지원하더라도 기기 아키텍처에 맞는 빌드를 우선 선택하세요.

디스크 이미지를 사용하는 경우 앱을 ‘응용 프로그램’ 폴더로 옮긴 뒤 실행하세요. 임시로 마운트한 위치에서 계속 실행하지 마세요. 처음 열 때 시스템 차단 안내가 나오면 출처와 보안 설정의 구체적인 내용을 확인하고 다운로드 폴더 전체의 보안 속성을 일괄 제거하지 마세요. 클라이언트가 네트워크 설정 변경, 보조 도구 설치, 네트워크 확장 추가를 요청하면 현재 앱에서 보낸 요청인지 확인하세요. 보조 서비스를 설치했는데도 시작되지 않는다면 비밀번호 입력 성공 여부만으로 판단하지 말고 앱 로그와 시스템 권한 상태를 살펴보세요.

구독 가져오기와 사용자 설정 보존

설정 관리에서 원격 구독을 추가하고 다운로드와 해석이 완료될 때까지 기다리세요. 해당 설정을 선택한 다음 프록시 선택 화면으로 이동합니다. 메뉴 막대에 실행 상태가 표시되더라도 클라이언트나 코어가 실행 중이라는 뜻일 뿐 새 구독으로 전환됐다는 보장은 없습니다. 처음 가져온 뒤 정책 그룹과 규칙이 모두 있는지 확인하세요. 외부 규칙 세트나 프록시 목록을 참조하는 설정은 해당 리소스가 로드될 때까지 기다려야 합니다. 리소스 요청이 실패해도 앱 전체가 바로 종료되지는 않을 수 있지만 해당 규칙이나 정책 동작에는 영향을 줄 수 있습니다.

로컬 변경 사항은 업데이트 때마다 교체되는 구독 캐시를 직접 편집하지 말고 클라이언트가 지원하는 오버라이드 기능에 넣는 것이 좋습니다. 변경 전에 오버라이드가 구독 해석 전과 실행 설정 생성 후 중 어느 단계에 적용되는지 확인하세요. 클라이언트마다 목록을 병합하는 방식이 다를 수 있습니다. DNS 블록을 여러 개 설정하거나 같은 이름의 정책 그룹이 있으면 최종 결과는 실행 설정을 기준으로 확인하세요. 업데이트 후 로그를 살펴보고 필요한 필드가 유지됐는지 확인해야 합니다. 파일이 저장됐다는 사실만으로 코어가 해당 내용을 사용한다고 단정하지 마세요.

시스템 프록시와 터미널 프록시를 따로 확인하기

시스템 프록시를 켜면 브라우저는 대체로 현재 네트워크 서비스의 프록시 설정을 사용합니다. 기기에 Wi-Fi, 유선 네트워크, 다른 네트워크 서비스가 함께 있다면 네트워크를 전환한 뒤 클라이언트가 올바른 서비스 설정을 업데이트했는지 다시 확인하세요. 터미널 도구는 보통 명시적인 매개변수나 환경 변수가 필요하며 GUI 설정을 모두 자동으로 읽지는 않습니다. 셸 시작 파일을 바로 수정하기보다 일회성 명령으로 검증하는 편이 복구하기 쉽습니다. 아래 명령으로 시스템 프록시 상태와 실제 포트 사용 여부를 각각 확인합니다.

scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl --proxy http://127.0.0.1:7890 --head https://example.com

현재 터미널 세션에서 프록시를 사용하려면 http_proxy와 https_proxy를 임시로 설정할 수 있습니다. HTTPS 요청은 CONNECT 터널을 사용하므로 후자의 값도 HTTP 프록시 주소일 수 있습니다. 도구마다 변수 대소문자 처리와 SOCKS 지원이 다르므로 해당 도구의 설명을 확인하세요. 필요한 경우에만 셸 설정 파일에 추가하고 제거할 위치를 기록하세요. 그렇지 않으면 포트를 바꾸거나 클라이언트를 종료한 뒤에도 터미널이 이전 변수를 참조해 브라우저는 되지만 명령은 모두 실패하는 상황이 생길 수 있습니다.

TUN, LAN, 절전 후 연결 복구

시스템 프록시를 따르지 않는 프로그램의 연결을 처리해야 할 때 TUN이나 클라이언트의 강화된 트래픽 처리 기능을 검토하세요. 관련 기능은 보조 서비스 설치나 시스템 네트워크 구성 요소 승인이 필요할 수 있으며 승인 방법은 macOS 버전과 클라이언트 구현에 따라 다릅니다. 실제 안내에 따라 진행하세요. 다른 클라이언트의 승인 절차를 그대로 적용하지 마세요. 기능을 켠 뒤 DNS와 연결 로그를 확인하고 LAN 기기, 원격 데스크톱, 개발 서버를 테스트해 LAN 주소가 원격 프록시로 잘못 전달되지 않는지 확인하세요.

프린터, 라우터 관리 페이지, 로컬 개발 사이트에 접속할 수 없다면 바로 전역 모드로 바꾸지 말고 LAN 우회와 경로 제외 설정을 확인하세요. 회사 네트워크에서는 사내 DNS로만 조회되는 도메인이 흔하며 공개 DNS가 사내 DNS를 대신할 수 없습니다. 사무실, 핫스팟, 가정용 네트워크로 전환할 때마다 사내 도메인과 직접 연결 규칙을 다시 테스트하세요. 이런 환경에서는 프록시를 자주 바꾸는 것보다 네트워크 변경 전후의 로그와 DNS 결과를 보관하는 편이 원인을 찾는 데 도움이 됩니다.

덮개를 닫아 절전 모드로 전환한 뒤 복귀하면 기존 TCP 세션이 이미 만료됐을 수 있습니다. 코어를 재시작하기 전에 새 요청을 보내거나 기존 연결을 닫으세요. 메뉴 막대에는 정상으로 표시되지만 새 연결이 모두 실패한다면 네트워크가 실제로 복구됐는지, 시스템 프록시가 현재 포트를 가리키는지, 보조 서비스가 실행 중인지 확인하세요. 앱을 삭제하기 전 시스템 프록시와 트래픽 처리 기능을 끄고 클라이언트의 절차에 따라 보조 서비스를 정리하세요. 앱 아이콘만 삭제했다고 모든 네트워크 설정이 복구된 것은 아닙니다.

Android 설치 및 설정

설치 파일, 시스템 권한과 VPN 인터페이스

Android 다운로드에서 Clash Plus를 우선 선택하고 Clash Meta for Android, FlClash, Surfboard와 비교해 볼 수도 있습니다. 클라이언트마다 지원하는 구독 형식과 기능이 다르며, 특히 Surfboard 설정 문법을 mihomo YAML과 동일하게 볼 수 없습니다. 기기는 대체로 ARM 아키텍처를 사용하지만 시스템과 설치 파일 안내를 확인해 선택하세요. 설치가 실패하면 출처가 불분명한 파일을 반복해서 덮어쓰지 말고 아키텍처, 시스템 요구 사항, 기존 앱과의 서명 관계를 먼저 확인하세요.

브라우저나 파일 관리자에서 앱을 설치할 때 해당 출처의 앱 설치를 허용하라는 메시지가 표시될 수 있습니다. 신뢰할 수 있는 현재 출처에만 권한을 부여하고, 설치가 끝나면 기기 관리 방식에 따라 해당 권한을 회수할 수 있습니다. 처음 연결할 때 VPN 권한 대화상자가 나타나는 것은 Android의 트래픽 처리 방식이며, 승인 후에는 보통 시스템 VPN 표시가 나타납니다. 그렇다고 구독을 시스템에서 제공한다거나 모든 앱의 트래픽이 예상대로 분기된다는 뜻은 아닙니다. 처리 범위는 클라이언트의 앱 필터, 경로, 실행 설정에 따라 달라집니다.

구독 가져오기와 첫 연결

설정 화면에서 URL 설정을 추가하거나 파일을 가져오고, 다운로드가 끝나면 현재 설정으로 선택한 뒤 프록시 그룹을 선택할 수 있는지 확인하세요. 공유 메뉴로 가져올 때는 웹페이지 제목이나 잘린 텍스트가 아니라 전체 구독 URL이 전달됐는지 확인해야 합니다. 다른 앱이 클립보드를 읽을 수 있으므로 가져온 뒤 민감한 URL을 클립보드에 오래 두지 마세요. 로그인 후에만 열리는 웹페이지의 링크가 필요하다면 제공업체에서 클라이언트용 구독 주소를 받으세요. 브라우저 로그인 상태로 앱의 요청 인증을 대신할 수는 없습니다.

처음 연결할 때는 규칙 모드를 사용하고 명확한 프록시 정책을 선택한 뒤 시스템 VPN 요청을 승인하세요. 테스트 주소를 브라우저에서 열면서 클라이언트 연결 로그를 확인합니다. 브라우저에서 새 연결이 전혀 보이지 않으면 VPN 서비스가 실행 중인지, 브라우저가 제외됐는지, 현재 실행 설정이 맞는지 먼저 점검하세요. 연결이 코어에 들어왔지만 실패한다면 로그에서 DNS, 원격 핸드셰이크, 규칙 선택을 확인하세요. 상태 표시줄의 열쇠 아이콘만으로 원격 프록시가 작동한다고 판단할 수는 없습니다.

앱별 트래픽 분기와 백그라운드 실행 유지

Android 앱 선택 방식은 보통 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’ 두 가지이며 목록의 의미가 서로 반대입니다. 설정한 뒤 목록에 있는 앱과 없는 앱을 각각 하나씩 테스트해 클라이언트가 어떤 방식으로 동작하는지 확인하세요. 앱별 분기와 도메인 규칙은 서로 다른 단계입니다. 앱이 VPN 처리에서 제외되면 해당 연결은 코어의 규칙에 들어오지 않습니다. 이 경우 MATCH를 수정하거나 정책 그룹을 바꿔도 효과가 없으므로 먼저 앱의 처리 범위를 조정하세요.

화면을 잠근 뒤 연결이 끊기면 배터리 최적화, 백그라운드 활동 제한, 자동 시작, 시스템 정리 정책을 먼저 살펴보세요. 제조사마다 메뉴 이름이 다르므로 시스템의 앱 정보 화면에서 배터리와 백그라운드 권한을 확인할 수 있습니다. 계속 실행해야 하는 클라이언트에만 필요한 설정을 조정하고 시스템 절전 기능 전체를 끌 필요는 없습니다. 설정한 뒤 화면 잠금, 대기, 깨우기, 새 요청까지 한 번에 테스트하면서 서비스 재시작 여부, 설정 재로드 여부, 백그라운드 작업의 별도 네트워크 제한을 확인하세요.

DNS, 다른 VPN, 네트워크 전환

대부분의 Android 기기에서는 같은 사용자 환경에서 일반 VPN 서비스를 하나만 유지할 수 있습니다. 광고 차단, 방화벽, 다른 네트워크 도구가 같은 인터페이스를 점유하면 한 앱을 시작했을 때 다른 앱이 끊길 수 있습니다. 클라이언트가 임의로 종료된다고 오해하지 않도록 다른 VPN 도구를 끈 뒤 먼저 테스트하세요. 시스템의 비공개 DNS 설정도 DNS 경로를 바꿀 수 있으므로 문제를 확인할 때 기존 값을 기록하고 자동으로 잠시 전환해 비교하세요. 원인을 확인한 뒤 장기 설정을 결정하고 보안 설정을 모두 영구적으로 끄지는 마세요.

Wi-Fi에서 모바일 데이터로 전환하면 원격 주소 조회, IPv6 연결 여부, 기존 연결 상태가 달라질 수 있습니다. 기존 연결만 실패한다면 먼저 연결을 끊었다가 다시 연결하세요. 새 연결도 모두 실패한다면 구독의 네트워크 제한, 앱의 모바일 데이터 사용 허용 여부, 현재 네트워크의 웹 로그인 필요 여부를 확인하세요. 포털 인증이 필요한 경우 먼저 로컬 네트워크 로그인을 완료해야 합니다. 이런 문제는 정책 그룹 순서를 바꿔 해결할 수 없으므로 기본 네트워크에서 로그인 페이지에 접속할 수 있는지부터 확인하세요.

시스템 설정에서 VPN 상시 연결과 VPN 미사용 연결 차단을 켜면 클라이언트가 중지된 뒤의 네트워크 동작이 달라집니다. 차단 옵션을 켠 상태에서 서비스가 중단되어 인터넷이 끊기는 것은 시스템이 의도한 보호 동작일 수 있으며 별도의 고장은 아닙니다. 원격 지원을 받기 전에 설정을 복구할 위치를 기록해 두세요. 제한을 해제하는 방법을 모른 채 앱을 삭제하는 상황을 피할 수 있습니다. 구독 자동 업데이트는 백그라운드 요청 조건에도 영향을 받습니다. 화면 잠금, 절전, 모바일 데이터 제한으로 업데이트가 늦어질 수 있으니 구독 업데이트 실패 및 자동 업데이트 설정을 참고하세요.

iOS 설치 및 설정

App Store에서 Clash Plus 설치

iPhone과 iPad에서는 Clash Plus 사용을 권장합니다. iOS 다운로드에서 App Store로 이동하거나 Clash Plus App Store 페이지를 바로 열 수 있습니다. 프로젝트 공식 사이트는 clashplus.io입니다. 설치 전에 App Store에 표시된 시스템 요구 사항과 기능 설명을 확인하세요. 데스크톱 플랫폼에서 같은 이름으로 표시되는 설정이 iOS에서 똑같이 제공되는 것은 아니므로 현재 앱 화면과 시스템 권한 안내를 기준으로 진행하세요.

처음 연결할 때 VPN 설정 추가를 허용하고 기기 암호나 시스템 인증으로 승인해야 할 수 있습니다. 이 설정은 시스템이 해당 트래픽을 앱의 네트워크 확장으로 전달하기 위한 것으로 Wi-Fi 비밀번호나 구독 계정이 아닙니다. 승인 전에 안내에 표시된 앱 출처를 확인하세요. 기기가 구성 프로파일이나 조직 정책으로 관리되는 경우 개인 VPN을 추가할 수 없을 수 있습니다. 구독 URL을 다시 붙여 넣어도 해결되지 않으므로 시스템 설정에서 관리 상태와 허용된 네트워크 구성을 확인하세요.

구독 가져오기와 설정 적용 확인

앱에서 구독 URL이나 파일 가져오기를 사용하고 다운로드가 끝나면 실행할 설정을 선택하세요. Safari에서 링크를 열었다면 구독 리소스인지 서비스 제공업체의 사용자 센터 웹페이지인지 구분해야 합니다. 웹페이지에 내용이 보인다고 해서 복사한 주소가 구독 URL이라는 뜻은 아닙니다. 쿼리 매개변수가 있는 URL은 빠짐없이 보존하세요. 입력기가 문장부호를 바꾸거나 공유 도구가 매개변수를 잘라 요청이 실패할 수 있습니다. 개인 구독이 포함된 페이지를 캡처해 공개 문제 게시판에 올리지 마세요.

가져오기에 성공하면 먼저 프록시 그룹과 선택 항목을 확인한 뒤 VPN에 연결하세요. 설정이 여러 개라면 테스트용 로컬 파일이 아니라 현재 실행할 설정을 선택했는지 확인해야 합니다. 구독 업데이트로 프록시 목록이 바뀌면 앱에 저장된 선택 항목이 이전 이름과 더 이상 일치하지 않을 수 있습니다. 업데이트 후 기본 정책 그룹이 예상한 항목을 선택했는지 확인하세요. 연결 로그에 직접 연결로 표시되더라도 노드가 고장 났다고 단정하지 마세요. 해당 대상에 원래 직접 연결 규칙이 적용되는지, 규칙 모드인지 직접 연결 모드인지 확인해야 합니다.

iOS의 트래픽 처리 방식 이해하기

iOS 클라이언트는 보통 시스템 네트워크 확장으로 트래픽을 처리하므로 Windows처럼 ‘로컬 포트를 입력하고 시스템 프록시를 켜는’ 방법을 그대로 적용할 수 없습니다. Wi-Fi 상세 설정의 HTTP 프록시는 별도의 설정이므로 앱을 연결하기 위해 데스크톱 예시 주소를 임의로 입력하지 마세요. 휴대폰의 127.0.0.1은 휴대폰 자체를 가리키며 같은 네트워크에 있는 컴퓨터를 가리키지 않습니다. 컴퓨터 클라이언트의 루프백 주소를 휴대폰에 복사해도 기기 간 프록시 연결은 되지 않습니다. LAN 공유에는 서버의 접속 허용과 올바른 접근 제어도 필요합니다.

데스크톱 문서의 TUN, 서비스 모드, 시스템 프록시 스위치는 서로 다른 트래픽 처리 방식을 설명하기 위한 것입니다. iOS에서 작동하려면 같은 이름의 버튼을 찾아야 한다는 뜻은 아닙니다. 실제 처리 범위와 DNS 방식, 사용 가능한 규칙은 클라이언트 구현과 시스템 인터페이스가 함께 결정합니다. 특정 앱에서만 실패한다면 규칙을 바꾸기 전에 새 연결이 생성됐는지, 앱 자체 프록시나 별도 네트워크 정책이 있는지 확인하세요. 노드를 바꾼 뒤에도 이미 열린 장기 연결은 이전 경로를 계속 사용할 수 있으므로 새 요청을 보내 비교해야 합니다.

셀룰러 네트워크, 온디맨드 연결과 복구

처음 검증할 때는 다른 VPN 설정을 끄고 안정적인 네트워크에서 수동으로 연결해 기본 경로를 확인한 뒤 온디맨드 연결 같은 자동화 기능을 검토하세요. 자동 연결 규칙이 네트워크 변경에 반응해 사용자가 수동으로 끊은 뒤 다시 연결할 수 있습니다. 문제를 찾을 때는 관련 설정을 기록하고 자동 실행을 잠시 중지하세요. 시스템이나 서드파티의 다른 개인정보 보호 네트워크 기능도 함께 실행 중이라면 각각 따로 테스트해 요청 경로가 여러 단계로 복잡해지지 않도록 하세요. 한 번에 기능 하나만 바꾸고 결과를 비교할 수 있도록 기록하세요.

Wi-Fi에서 셀룰러 데이터로 전환한 뒤 연결이 실패하면 시스템에서 Clash Plus의 셀룰러 데이터 사용을 허용하는지, 현재 네트워크가 실제로 작동하는지, 해당 네트워크에서 원격 주소가 조회되는지 확인하세요. 화면이 잠겨 있을 때 네트워크 확장과 앱의 실행 방식은 다를 수 있으므로 앱이 전면에 표시되지 않는다는 이유만으로 서비스가 중지됐다고 판단하지 마세요. 반복해서 연결이 끊기면 앱 진단 정보와 시스템 VPN 상태를 함께 확인해 끊김이 로컬과 원격 중 어디에서 발생하는지 파악하세요. 규칙이 많은 설정을 사용하는 경우 문제 해결 중 리소스를 계속 추가하지 말고, 먼저 확인된 소규모 설정으로 검증하세요.

연결 후 기기 전체에서 인터넷이 되지 않으면 앱에서 연결을 끊고 시스템 VPN 화면에서 상태를 확인하세요. 필요하면 온디맨드 연결을 잠시 꺼서 끊자마자 다시 연결되는 상황을 방지하세요. 기본 네트워크를 복구한 뒤 최근 구독 업데이트, 규칙 오버라이드, DNS 변경을 확인하세요. 앱을 삭제하기 전에 보관할 설정을 내보내고 다른 기기에서 구독 출처에 계속 접근할 수 있는지도 확인하세요. 단계별 문제 해결 방법은 도움말 센터에서 확인할 수 있습니다. 진단 정보를 공유할 때는 오류 유형과 필요한 필드만 남기고 로그의 민감한 내용은 가리세요.

Linux 데스크톱 및 서버

데스크톱 클라이언트와 헤드리스 배포 구분하기

데스크톱 사용자는 Linux 다운로드에서 Clash Verge Rev나 FlClash를 선택하고 배포판 패키지 형식, 아키텍처, 의존성을 먼저 확인하세요. GUI 클라이언트는 구독 관리와 트레이 조작을 지원하지만 Linux에서는 데스크톱 환경마다 시스템 프록시 지원이 다릅니다. 데스크톱 환경에 설정이 적용돼도 모든 프로그램이 이를 읽는 것은 아닙니다. GUI가 없는 서버에서는 mihomo를 직접 실행하고 설정 파일과 systemd로 관리할 수 있습니다. 두 방식 중 하나를 기본 관리 경로로 정해 GUI 클라이언트와 별도 서비스가 같은 포트를 동시에 점유하지 않도록 하세요.

GUI 앱을 설치한 뒤 먼저 구독을 가져오고 실행 설정을 선택한 다음 로그를 확인하고 데스크톱 프록시를 설정하세요. 터미널 명령이 프록시를 따르지 않는다면 시스템 전역 환경 파일을 바로 수정하지 말고 일회성 명령 매개변수로 연결을 확인하세요. 서버에 배포할 때는 설정 디렉터리와 권한을 먼저 준비하고 실행 계정이 설정과 참조하는 규칙 리소스를 읽을 수 있는지 확인하세요. 서비스에 사용자 홈 전체를 공개하지 말고 권한 오류를 피하려고 모든 사용자에게 재귀적으로 쓰기 권한을 부여하지 마세요. 설정과 구독이 유출될 위험이 커집니다.

명령줄 실행과 설정 테스트

아래 예시는 mihomo 실행 파일이 /usr/local/bin/mihomo에 설치되어 있고 설정이 /etc/mihomo/config.yaml에 있다고 가정합니다. 이 경로는 예시의 기준이므로 실제 배포 경로는 달라도 되지만 명령과 서비스 파일은 같은 경로를 사용해야 합니다. 먼저 전면에서 검증한 뒤 상시 실행 서비스로 설정하세요. 아래 최소 설정은 로컬 수신과 직접 연결만 테스트하며 원격 프록시는 포함하지 않습니다. 실제 구독을 대체할 수 없고 특정 프록시 출구가 작동하는지 증명하지도 않습니다.

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

/usr/local/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml
/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
curl --proxy http://127.0.0.1:7890 --head https://example.com

먼저 테스트 명령을 실행해 설정 해석 오류를 확인한 뒤 전면에서 실행해 수신 로그를 살펴보세요. 규칙 리소스, 지리 데이터베이스, 프록시 목록은 추가 파일이나 네트워크 요청이 필요할 수 있습니다. 문법 검사를 통과했다고 모든 외부 의존성이 사용 가능한 것은 아닙니다. 서비스 제공업체 설정을 사용한다면 전체를 저장한 뒤 다시 테스트하고 참조 경로와 작업 디렉터리를 확인하세요. 전면 검증이 끝나면 프로세스를 종료한 다음 systemd에 맡기세요. 그렇지 않으면 백그라운드 서비스 시작 시 포트 점유 오류만 보고 설정 파일이 손상된 것으로 오해할 수 있습니다.

systemd로 일반 프록시 서비스 관리

전용 시스템 사용자 mihomo를 만들고 해당 사용자에게 작업 디렉터리 읽기와 필요한 쓰기 권한을 부여한 다음 아래 서비스 파일을 만드세요. 이 예시는 TUN을 켜지 않고 일반 사용자로 로컬 프록시를 실행합니다. 가상 인터페이스 권한이 필요한 서비스에 그대로 적용하지 마세요. 사용자 생성 명령은 배포판마다 다르므로 시스템에 포함된 계정 관리 도구를 사용하세요. 설정과 캐시 디렉터리를 함께 사용한다면 업데이트 시 쓰기가 필요한 파일을 분명히 구분해 구독이나 규칙을 갱신할 때 권한 문제가 드러나지 않도록 하세요.

# /etc/systemd/system/mihomo.service
[Unit]
Description=mihomo local proxy
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
UMask=0077

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -b -n 80 --no-pager

설정을 수정한 뒤에는 서비스와 같은 계정 및 경로를 사용해 먼저 테스트하고, 서비스를 재시작한 다음 이번 시작 로그를 확인하세요. network-online.target이 실제로 얼마나 기다리는지는 배포판에 네트워크 대기 서비스가 설정되어 있는지에 따라 달라집니다. 이 대상에 도달했다고 임의의 원격 리소스에 반드시 접속할 수 있는 것은 아닙니다. 구독 업데이트도 이 unit이 자동으로 처리하지 않습니다. 다운로드, 테스트, 교체 절차를 별도로 마련하세요. 새 설정 검증에 실패하면 기존 파일을 보존해 예약 작업이 오류 페이지를 정상 설정으로 덮어쓰지 않도록 하세요.

TUN 권한, 컨테이너와 터미널 환경

Linux에서 TUN을 사용하려면 가상 인터페이스 장치, 네트워크 관리 권한, 적절한 경로 설정이 필요합니다. YAML에 enable: true만 지정했다고 필요한 권한이 갖춰지는 것은 아닙니다. 컨테이너에서는 장치 전달, 네트워크 네임스페이스, 기능 제한도 고려해야 합니다. 먼저 호스트 환경에서 연결 경로를 이해한 다음 컨테이너의 트래픽 처리 방식을 설계하세요. 일반 프록시 서비스와 TUN 서비스에 필요한 권한은 다릅니다. 문제를 감추기 위해 전체 배포를 고권한으로 실행하지 말고 필요한 권한과 범위를 먼저 검토하세요.

터미널 세션에는 필요에 따라 프록시 변수를 설정할 수 있지만 백그라운드 서비스가 대화형 셸의 환경을 모두 상속하지는 않습니다. 반대로 mihomo의 구독이나 리소스 요청이 아직 시작되지 않은 프록시 주소를 가리키지 않는지도 확인하세요. 원격 서버의 기본 경로를 변경하기 전에는 두 번째 관리 세션과 롤백 경로를 준비해 SSH 연결이 끊긴 뒤 접속하지 못하는 상황을 방지하세요. 데스크톱과 헤드리스 설정을 자세히 비교하려면 Linux mihomo 배포 기술 노트를 참고하세요.

설정 문제와 복구

설정 파일 해석 오류와 규칙 이름

YAML은 공백으로 들여쓰며 탭과 섞어 쓰면 안 됩니다. 같은 단계의 들여쓰기를 일관되게 유지하고 목록 항목을 올바른 상위 필드 아래에 작성하세요. 줄 번호 오류가 나면 오류가 표시된 줄뿐 아니라 그 앞줄의 콜론, 따옴표, 들여쓰기도 확인해야 합니다. 서식 있는 텍스트 편집기에 설정을 붙여 넣으면 전각 문장부호나 숨은 문자가 들어갈 수 있으므로 일반 텍스트 편집기를 사용하세요. 오류를 가리기 위해 rules 전체를 삭제하지 마세요. 코어가 시작되는 것과 예상대로 트래픽을 분기하는 것은 별개의 목표이며 규칙을 지우면 모든 연결 경로가 바뀔 수 있습니다.

규칙은 작성된 순서대로 매칭되므로 구체적인 도메인 규칙을 일반적인 기본 규칙보다 앞에 두는 것이 보통입니다. 아래는 규칙 일부이며 PROXY는 실행 설정에 이미 있는 프록시나 정책 그룹이어야 합니다. 구독에서 다른 그룹 이름을 사용한다면 빈 그룹을 새로 만들지 말고 참조 이름을 수정하세요. 설정에서 사용하는 이름은 대개 정확히 일치해야 하므로 대소문자, 공백, 기호 차이로 대상을 찾지 못할 수 있습니다. 규칙 매칭 결과와 정책 그룹의 최종 선택은 따로 확인해야 합니다. 프록시 그룹에 매칭됐더라도 그룹에서 DIRECT를 선택했을 수 있습니다.

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

시스템 프록시는 정상인데 TUN은 실패하는 경우

시스템 프록시는 앱이 직접 프록시 설정을 따르는 방식이고, TUN은 가상 인터페이스와 경로를 통해 더 많은 연결을 처리합니다. 필요한 권한과 DNS 경로, 오류 영향 범위도 다릅니다. 시스템 프록시는 작동하지만 TUN이 실패한다면 구독을 바로 바꾸지 말고 권한과 경로를 먼저 확인하세요. 아래는 mihomo의 TUN 필드 일부이며 단독으로 사용할 수 있는 전체 설정이 아닙니다. 클라이언트가 화면에서 이런 필드를 생성하거나 덮어쓸 수 있습니다. 활성화 전에 완전한 DNS 구성을 함께 마련해야 하며 이 조각만 복사한다고 모든 플랫폼에서 똑같이 작동하는 것은 아닙니다.

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

DNS 하이재킹 설정은 해당되는 기존 DNS 요청을 대상으로 하며 모든 암호화 DNS가 같은 방식으로 코어에 들어온다는 뜻은 아닙니다. 브라우저의 보안 DNS, 시스템 비공개 DNS, IPv6 경로, 앱 자체 리졸버가 관찰 결과를 바꿀 수 있습니다. 도메인 조회 실패와 연결 실패를 먼저 구분한 뒤 resolver, fake-ip, 경로 제외 설정을 조정하세요. 여러 네트워크 계층을 한꺼번에 바꾸지 않도록 TUN 모드와 시스템 프록시의 차이를 참고하세요.

구독 업데이트, 오버라이드와 외부 리소스

구독 업데이트가 실패하면 이전의 정상 설정을 보존하고 상태 코드, 시간 초과 유형, 해석 오류 줄 번호를 기록하세요. 주소 만료, 권한 만료, 웹페이지로 바뀐 응답, 네트워크 연결 실패는 각각 다른 방식으로 처리해야 합니다. 현재 구독을 프록시를 통해서만 업데이트할 수 있는데 프록시도 해당 구독에 의존한다면 안정적인 업데이트 경로를 미리 준비해 시작 단계에서 순환하지 않도록 하세요. 자동 업데이트 간격은 제공업체의 제한과 실제 필요에 맞추고 일시적인 오류를 해결하려고 요청을 반복해서 보내지 마세요.

규칙 세트와 프록시 세트에는 각각 캐시와 업데이트 시간이 있을 수 있으므로 기본 구독 업데이트에 성공해도 모든 리소스가 갱신된 것은 아닙니다. 오버라이드를 수정한 뒤 최종 실행 설정에서 포트, DNS, 그룹 이름, 규칙 순서, 수신 주소를 확인하세요. 클라이언트가 설정 미리 보기나 내보내기를 지원한다면 구독 정보와 인증 내용이 포함될 수 있으므로 내보내기 전에 주의하세요. 다른 사람에게 도움을 요청할 때는 먼저 민감한 내용을 가리세요. 반복되는 해석 오류는 개인 설정 전체보다 문제를 재현하는 최소한의 설정 조각을 공유하는 편이 도움이 됩니다.

증상에 따라 다음 단계 선택하기

문제 해결 기록에는 플랫폼, 클라이언트 이름, 현재 모드, 트래픽 처리 방식, 오류가 발생한 단계, 민감 정보를 가린 관련 로그 한 건 이상을 포함하세요. 노드 속도 테스트, 브라우저 접속, 백그라운드 업데이트를 같은 테스트로 취급하지 마세요. 대상과 요청 경로가 서로 다를 수 있습니다. 특정 웹사이트만 실패한다면 대상 서비스 상태, 출구 지역 정책, 계정 제한도 고려해야 합니다. 무작정 모드를 바꾸기보다 요청이 예상한 정책에 들어갔는지 먼저 확인하면 원격 접속 가능 여부를 더 효과적으로 판단할 수 있습니다.

복구가 끝나면 검증된 최소 변경 사항만 장기 설정에 반영하고 백업을 업데이트하세요. 클라이언트 업데이트, 코어 교체, 기기 이전 후에는 기본 검증을 다시 수행하고 이전 환경의 결과를 그대로 적용하지 마세요. 문제별 빠른 진단은 도움말 센터에서 확인할 수 있고, 설정 항목의 의미는 용어집에서 찾아볼 수 있습니다. 이 페이지는 플랫폼 간 차이에 중점을 둡니다. 처음 설정한다면 기본 연결을 먼저 만든 뒤 고급 기능을 추가하도록 빠른 시작 안내를 따라 진행하세요.