Clash 전체 플랫폼 설치 및 설정 가이드

공통 준비: 클라이언트, 커널, 구독 구분하기

설치 대상과 설정 출처부터 확인하세요

GUI 클라이언트는 구독 가져오기, 정책 그룹 선택, 시스템 설정 변경을 담당하고, 커널은 포트 수신, 프로토콜 처리, 규칙 매칭을 담당합니다. 둘은 서로 다른 계층입니다. mihomo는 커널 프로젝트이며 Clash Verge Rev, FlClash 등은 GUI를 제공합니다. Clash라는 이름이 붙은 앱이라도 설정을 처리하는 방식은 다를 수 있습니다. 이 사이트에서 안내하는 플랫폼은 우선 Clash Plus를 살펴보고, 필요한 기능에 따라 다른 클라이언트를 확인하세요. 소프트웨어 이름만 보고 특정 YAML 필드가 반드시 작동한다고 판단해서는 안 됩니다. 실제 적용 여부는 커널과 클라이언트의 설정 생성 방식에 따라 달라집니다.

서비스 제공업체가 발급한 구독 주소나 정상 작동이 확인된 설정 파일을 준비하세요. 클라이언트에는 보통 연결 가능한 서비스가 포함되어 있지 않습니다. 구독 결과가 완전한 Clash 설정일 수도 있고, 다른 형식의 서버 목록일 수도 있습니다. 후자는 완전한 YAML 설정으로 바로 사용할 수 없습니다. 먼저 제공업체가 안내하는 호환 형식을 확인하세요. Clash 구독 변환이 필요하다면 신뢰할 수 있는 로컬 방식을 우선 사용하세요. 구독 URL의 쿼리 매개변수에는 접근 권한 정보가 포함될 수 있으므로 공개 게시판에 올리지 말고, 문제 해결을 위해 원본 설정 전체를 업로드하지도 마세요.

문제가 생기면 되돌릴 수 있도록 초기 상태를 기록하세요

설치 전에 기존 VPN, 시스템 프록시, 수동 DNS 설정을 기록하고 트래픽을 가로채는 다른 소프트웨어는 잠시 종료하세요. 여러 도구가 기본 경로나 프록시 포트를 동시에 변경하면 로그에 나타난 오류는 원인이 아니라 결과일 수 있습니다. 처음 연결할 때는 클라이언트 하나, 설정 하나, 트래픽 처리 방식 하나만 사용해 확인하세요. 연결이 정상임을 확인한 뒤 시작 프로그램 등록, 자동 업데이트, LAN 공유 같은 기능을 켜면 됩니다. 기존 설정은 백업으로 내보내고 파일 이름과 용도를 기록해 두세요. 테스트용 덮어쓰기 설정을 장기 설정으로 저장하지 않도록 주의하세요.

시스템 시간, 디스크 여유 공간, 기기 아키텍처를 확인하세요. 시간이 크게 틀리면 HTTPS 인증서 검증에 문제가 생길 수 있고, 설치 파일의 아키텍처가 맞지 않으면 실행되지 않거나 추가 호환 계층이 필요할 수 있습니다. 구독 업데이트 실패가 반드시 프록시 문제인 것은 아닙니다. 네트워크 로그인 포털 미인증, 만료된 주소, 계정 만료는 각각 따로 확인해야 합니다. 클라이언트를 실행하기 전에 현재 사용 가능한 네트워크에서 시스템 로그인과 필요한 인증을 마치세요. 문제를 해결할 때는 연결 버튼을 계속 누르는 것보다 작업 순서와 오류 메시지를 기록하는 편이 훨씬 유용합니다.

최소 설정의 범위를 이해하세요

아래는 mihomo의 로컬 수신 설정 일부만 보여 주며 노드, 정책 그룹, 규칙은 포함하지 않습니다. 구독을 대신할 수 없습니다. mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 루프백 주소에 바인딩하고 LAN 접근을 끄면 단일 기기에서 테스트하기에 적합합니다. 포트가 반드시 7890이어야 하는 것은 아니지만 클라이언트, 시스템 프록시, 테스트 명령에서 같은 값을 사용해야 합니다. 처음 실행할 때 외부 제어 인터페이스를 함부로 열지 마세요. 로컬 연결 문제를 해결하려고 모든 네트워크 인터페이스에 수신하도록 설정하면 노출 범위만 넓어지고 문제가 해결되지 않을 수도 있습니다.

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

완전한 설정에서는 보통 위에서 아래 순서로 규칙을 검사하고, 규칙이 일치하면 처리를 멈춥니다. 정책 이름은 실제로 존재하는 정책 그룹이나 노드와 일치해야 합니다. 예시 이름을 그대로 복사해 사용하면 안 됩니다. 가져온 뒤에는 해당 설정이 현재 설정으로 선택되었는지 확인하고 커널이 실행 중인지 점검하세요. 다운로드 성공은 파일을 가져왔다는 뜻일 뿐, 설정 문법이 올바르거나 트래픽이 프록시를 통과한다는 뜻은 아닙니다. 각 상태를 나눠 확인하면 문제 해결 과정에서 불필요한 시행착오를 줄일 수 있습니다.

Windows: 설치, 시스템 프록시, 서비스 모드

아키텍처에 맞는 설치 파일을 받고 처음 실행하기

Windows 설치 파일 목록에서 클라이언트를 선택하세요. 우선 추천하는 클라이언트는 Clash Plus이며, 그다음으로 Clash Verge Rev, FlClash, Clash Nyanpasu를 고려할 수 있습니다. Clash for Windows는 지원이 중단되었습니다. 보관용 클라이언트는 호환성이 꼭 필요한 구형 환경에서만 사용하고, 새로 설정할 때는 계속 유지 관리되는 클라이언트를 우선 선택하세요. “설정 → 시스템 → 시스템 정보”에서 시스템 종류를 확인한 뒤 다운로드 페이지의 아키텍처와 비교하세요. ARM 기기는 운영체제 이름만 보고 일반 데스크톱 설치 파일을 선택하지 말고, 클라이언트의 실제 지원 범위를 먼저 확인하세요.

안정적인 로컬 폴더에 설치하세요. 장기간 실행할 프로그램을 다운로드 임시 폴더, 압축 파일 안, 자동 정리되는 위치에 두지 마세요. 처음 실행할 때 방화벽이나 서비스 설치 권한 요청이 나타날 수 있으니 프로그램의 출처와 용도를 먼저 확인하세요. 이 기기에서만 사용할 경우 LAN으로 들어오는 연결을 따로 허용할 필요는 없습니다. 시스템이 실행을 차단하면 파일 출처, 시스템 요구 사항, 보안 소프트웨어 알림을 먼저 확인하세요. 모든 보안 기능을 끄는 것을 일반적인 설치 절차로 삼아서는 안 됩니다.

구독을 가져온 뒤 설정과 수신 상태를 확인하세요

클라이언트의 구독 또는 설정 화면에서 원격 설정을 추가하고 전체 주소를 붙여 넣은 뒤 업데이트하세요. 설정이 여러 개라면 방금 가져온 항목을 선택하고 업데이트 시간과 노드 목록을 확인하세요. 설정 이름만 표시되고 노드가 없다면 업데이트 로그를 열어 요청 실패, 로그인 웹페이지 응답, 설정 파싱 실패를 구분하세요. DNS부터 변경하지 마세요. 서버가 잘못된 내용을 반환하면 파서는 HTML 페이지를 읽을 수밖에 없습니다. 민감한 주소는 클라이언트 안에만 입력하고 문제 해결용 스크린샷에 전체 주소가 나오지 않도록 하세요.

규칙 모드를 선택하고 실제 사용할 정책 그룹에서 연결 가능한 노드를 고르세요. 그런 다음 클라이언트 설정에서 로컬 프록시 포트를 확인하고 시스템 프록시를 켭니다. Windows 프록시 설정에서 수동 프록시가 루프백 주소와 같은 포트를 가리키는지 확인하세요. 일부 앱은 독립적인 네트워크 스택을 사용하므로 브라우저는 되는데 터미널은 안 되는 상황도 가능합니다. 먼저 PowerShell에서 명시적 프록시 테스트를 실행해 클라이언트 연결 여부와 시스템 트래픽 처리 여부를 따로 확인하세요.

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/
Get-NetTCPConnection -State Listen -LocalPort 7890

첫 번째 명령은 TCP 연결이 가능한지만 확인하고, 두 번째 명령은 프록시를 통해 대상 사이트에 요청을 보냅니다. 일부 PowerShell 환경에서 같은 이름의 별칭으로 인한 매개변수 차이를 피하려면 curl.exe를 사용하세요. 세 번째 명령은 수신 상태를 확인합니다. 권한 부족 메시지가 나오면 관리가 통제되는 상황에서 터미널 권한을 높여 조회하세요. 다른 프로그램이 포트를 사용 중이라면 중복 실행 중인 클라이언트를 종료하거나 현재 클라이언트의 포트를 바꾸고 시스템 설정도 함께 수정하세요. 한쪽만 바꾸면 새로운 문제가 생깁니다.

TUN 활성화 순서와 Windows 관련 문제

시스템 프록시가 정상 작동하는지 확인한 뒤 TUN을 시도하세요. 일부 클라이언트는 가상 인터페이스 생성과 경로 설정을 위해 서비스 구성 요소 설치 및 관리자 권한이 필요합니다. 서비스 모드라고 해서 매번 전체 인터페이스를 관리자 권한으로 실행해야 하는 것은 아닙니다. 클라이언트 안내에 따라 서비스를 설치하거나 시작하고, 로그에서 가상 장치 초기화가 완료되는지 확인한 다음 TUN을 켜세요. 켠 직후 연결이 끊기면 TUN을 꺼서 네트워크를 복구하고 보안 소프트웨어, 다른 VPN, 가상 네트워크 어댑터 충돌을 확인하세요. 네트워크 스택, DNS, MTU를 동시에 바꾸지 마세요.

WSL, Docker, 가상 머신은 별도의 네트워크 환경입니다. Windows의 127.0.0.1을 이 환경들에서 공통으로 사용할 수 있는 호스트 주소라고 간주하면 안 됩니다. 실제 접속 방법은 네트워크 모드와 시스템 설정에 따라 달라집니다. 다른 환경에서 로컬 프록시에 연결해야 한다면 접근 가능한 주소, 접근 제어, 방화벽 범위를 함께 설정하세요. 컨테이너 하나를 연결하려고 프록시를 LAN 전체에 공개하지 마세요. 게임이나 음성 앱에서 UDP를 사용할 때는 상위 노드의 프로토콜 지원도 확인해야 합니다. TUN을 켠다고 노드의 기능이 자동으로 보완되지는 않습니다.

클라이언트를 종료하기 전에 시스템 프록시와 TUN을 먼저 끄세요. 프로그램이 비정상 종료된 뒤 브라우저에서 모두 프록시 오류가 발생한다면 Windows 프록시 설정으로 돌아가 남아 있는 수동 프록시를 지우고 기본 네트워크가 복구되었는지 확인하세요. 전체 연결 경로를 검증한 뒤 시작 시 자동 실행과 자동 연결을 켜고, 실제로 재부팅해 서비스가 인터페이스보다 먼저 준비되는지 확인하세요. 절전 모드에서 깨어나거나 Wi-Fi를 바꾼 뒤 문제가 생기면 현재 설정에 다시 연결해 보세요. 그래도 해결되지 않으면 경로와 DNS를 확인하고, 원인을 파악하기 전에 프로그램을 재설치해 증거를 없애지 마세요.

macOS: 칩 아키텍처, 네트워크 권한, 프록시 복구

설치 파일을 선택하고 시스템 권한을 확인하세요

“이 Mac에 관하여”에서 칩 또는 프로세서 정보를 확인한 뒤 macOS 다운로드로 이동하세요. 우선 추천하는 클라이언트는 Clash Plus이며, 필요에 따라 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. ClashX Meta는 유지 관리가 중단되었으므로 호환성 확인용 보관판으로 취급하세요. Apple Silicon과 Intel용 설치 파일을 올바르게 구분해야 합니다. 호환성 계층으로 실행된다는 이유로 기본 아키텍처를 무시하지 마세요. 설치 전에 클라이언트의 시스템 요구 사항도 확인하세요. 설치 파일을 다운로드할 수 있다고 해서 구형 시스템에서 실행된다는 뜻은 아닙니다.

디스크 이미지로 배포되는 앱은 먼저 “응용 프로그램” 폴더로 옮기고, 이미지 마운트를 해제한 다음 정식 폴더에서 실행하세요. 그러지 않으면 이후 업데이트, 권한 연결, 로그인 항목이 임시 마운트 경로를 가리킬 수 있습니다. 처음 열 때는 시스템 안내에 따라 개발자와 출처를 확인하세요. 시스템 보안 기능이 실행을 차단하면 “개인정보 보호 및 보안”에서 구체적인 이유를 확인하고 프로젝트 안내에 따라 처리하세요. 출처를 알 수 없는 명령어로 파일 속성을 일괄 제거하거나 시스템 전체의 앱 보안 검사를 끄지 마세요.

설정을 가져오고 현재 네트워크 서비스를 확인하세요

클라이언트에 원격 구독을 추가하고 업데이트한 뒤 활성 설정으로 선택하세요. 그런 다음 정책 그룹에 예상한 노드가 포함되어 있는지 확인합니다. 로컬 YAML을 사용한다면 파일을 읽는 위치와 업데이트 방식을 확인하세요. 일부 클라이언트는 가져온 설정을 복사본으로 저장하므로 원본 파일을 계속 수정해도 실행 중인 설정에는 반영되지 않습니다. 사용자 규칙을 장기간 유지하려면 클라이언트가 지원하는 덮어쓰기 또는 병합 기능을 우선 사용하고 최종 생성된 설정을 확인하세요. 구독 캐시 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 저장 성공이 설정 유지 성공을 뜻하지는 않습니다.

시스템 프록시를 켠 뒤 시스템 설정의 네트워크 상세 정보에서 HTTP, HTTPS 또는 SOCKS 프록시 항목을 확인하세요. macOS 프록시 설정은 일반적으로 특정 네트워크 서비스에 연결되어 있으므로 Wi-Fi와 유선 네트워크 사이를 전환한 뒤 다시 확인해야 합니다. 메뉴 막대 아이콘만 확인해서는 안 됩니다. 터미널에서 아래 명령으로 현재 상태를 확인한 다음 명시적 프록시 요청을 테스트하세요. 이 명령은 진단용이며 시스템 프록시를 직접 변경하지 않습니다. 실제 포트가 7890이 아니라면 테스트 포트도 동일하게 바꾸세요.

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

scutil --proxy는 시스템 프록시 관련 상태를 보여 주지만 모든 앱이 해당 설정을 따른다는 것을 증명하지는 않습니다. 브라우저는 되는데 명령줄 도구가 작동하지 않으면 명시적 프록시 인자나 환경 변수가 필요한지 확인하세요. 특정 브라우저만 다르게 작동한다면 확장 프로그램, 별도 프록시, 보안 DNS 설정을 살펴보세요. 여러 계층의 설정이 동시에 적용되면 요청이 클라이언트를 우회하거나 프록시를 두 번 통과할 수 있습니다. 먼저 브라우저 창 하나와 터미널 명령 하나만 사용해 테스트한 뒤 확장 프로그램을 하나씩 다시 활성화하세요.

TUN, 보조 서비스, 네트워크 전환

TUN을 켜려면 보조 서비스, 관리자 권한, 네트워크 확장 기능이 필요할 수 있습니다. 구체적인 동작 방식은 사용 중인 클라이언트에 따라 다릅니다. 시스템 확인 창이 나타나면 앱 이름을 확인하고 권한을 승인한 뒤 클라이언트로 돌아가 로그를 확인하세요. 허용을 눌렀다는 사실만으로 서비스가 실행 중이라고 판단하지 마세요. 이미 삭제한 구형 앱의 경로에서 서비스를 설치했다면 업데이트 후 클라이언트 안내에 따라 보조 구성 요소를 다시 설치해야 할 수 있습니다. 권한 오류와 노드 연결 오류는 서로 다른 단계의 문제입니다. 먼저 장치 생성 실패를 해결한 다음 규칙과 DNS를 확인하세요.

macOS의 도메인별 DNS 해석과 네트워크 서비스 순서는 DNS 동작에 영향을 줍니다. 회사 내부 도메인이 특정 인터페이스의 DNS 서버를 사용해야 하는 경우, 전체 트래픽 처리 기능을 켠 뒤 내부 사이트가 작동하지 않으면 해당 도메인의 기존 DNS 설정을 확인하고 선택적 DNS 해석 또는 우회를 구성하세요. 모든 상황에 공용 DNS 서버를 적용하지 마세요. 절전 모드에서 깨어나거나 핫스팟을 바꾸거나 도킹 스테이션에 연결하면 인터페이스와 경로가 변경될 수 있습니다. 다시 연결하기 전에 현재 네트워크 서비스와 기본 네트워크 인증 완료 여부를 확인하세요.

기본 연결이 복구된 것을 확인한 뒤 로그인 시 자동 실행 여부를 결정하세요. 메뉴 막대 상주, 로그인 항목, 백그라운드 서비스는 서로 다른 상태입니다. 인터페이스가 표시된다고 커널이 설정을 불러온 것은 아니며, 백그라운드 서비스가 실행 중이라고 구독 업데이트까지 성공한 것도 아닙니다. 재부팅 후 설정 선택, 프록시 수신, 대상 요청을 확인해야 제대로 작동하는지 판단할 수 있습니다. 더 이상 사용하지 않는 클라이언트는 먼저 종료하고 네트워크 트래픽 처리를 중단한 뒤 해당 앱의 제거 안내에 따라 보조 서비스를 삭제하세요. 여러 구형 서비스가 같은 포트를 차지하지 않도록 주의하세요.

Android: VPN 권한, 백그라운드 실행, 앱별 설정

설치 파일 아키텍처와 구독 가져오기

Android 설치 파일 목록에서 우선 Clash Plus를 선택하고, Clash Meta for Android, FlClash, Surfboard도 고려할 수 있습니다. 앱마다 가져올 수 있는 형식과 기능 범위가 다릅니다. 특히 Surfboard가 모든 mihomo YAML 필드를 그대로 지원한다고 가정하지 마세요. 먼저 서비스 제공업체가 지원하는 클라이언트와 형식을 확인한 뒤 앱을 선택하세요. 최신 기기는 대체로 ARM64를 사용하지만 실제 기기 아키텍처에 맞는 파일을 선택해야 합니다. 확인이 어렵다면 다운로드 페이지에서 범용 패키지를 제공하는 클라이언트에 한해 범용 패키지를 선택하세요.

브라우저나 파일 관리자에서 설치할 때 Android가 해당 출처의 앱 설치를 허용하도록 요청할 수 있습니다. 실제 사용하는 출처에만 필요한 권한을 주고 설치 후 시스템 설정에서 권한을 회수할 수 있습니다. 서명이 일치하지 않는다는 메시지가 나오면 먼저 다른 출처에서 설치한 같은 이름의 앱이 있는지 확인하세요. 구독을 보관한 유일한 기존 앱을 바로 삭제하지 마세요. 옮기기 전에 내보낼 수 있는 설정과 앱 옵션을 백업하세요. 클라이언트마다 백업 형식이 달라 서로 복원할 수 없는 경우가 많으므로 구독 주소와 사용자 규칙도 따로 보관하세요.

앱 안에서 구독을 추가하고 업데이트한 뒤 현재 설정으로 지정하세요. 구독 업데이트가 계속 진행 중이라면 먼저 연결을 일시 중지하고, 해당 구독에 접근할 수 있는 기본 네트워크를 사용해 업데이트한 뒤 HTTP 오류나 파싱 오류가 표시되는지 확인하세요. 일부 구독은 기존 프록시를 통해서만 접근할 수 있습니다. 이 경우 제공업체 안내에 따라 업데이트 경로를 선택하되, 해당 설정을 가져와야 그 설정을 다운로드할 수 있는 순환 구조가 되지 않도록 하세요. 권한이 있는 다른 네트워크를 통해 처음 가져온 뒤 이후 업데이트 경로를 검증할 수도 있습니다.

시스템 VPN 트래픽 처리와 백그라운드 실행

대부분의 Android 프록시 클라이언트는 시스템 VPN 인터페이스로 앱 트래픽을 처리하며, 처음 실행할 때 시스템 권한 요청이 나타납니다. 여기서 VPN은 운영체제가 제공하는 트래픽 연결 방식이며 특정한 기존 VPN 프로토콜로 바뀐다는 뜻은 아닙니다. 일반적으로 같은 사용자 공간에서는 이와 같은 VPN 서비스를 하나만 실행할 수 있으므로 광고 차단기, 회사 VPN, 다른 프록시 도구와 충돌할 수 있습니다. 다른 트래픽 처리 앱을 먼저 중지하고 현재 앱을 실행한 뒤 상태 표시줄과 클라이언트 로그에서 서비스가 모두 설정되었는지 확인하세요.

연결 후 몇 분은 정상인데 화면을 잠그면 끊기는 경우 배터리 최적화, 백그라운드 활동 권한, 제조사별 자동 시작 제한을 확인하세요. 클라이언트의 백그라운드 실행을 허용하고 시스템에 포그라운드 서비스 알림이 표시되는지 확인하세요. 서비스 유지에 필요한 권한을 숨기려고 끄지 마세요. 일부 시스템은 최근 앱 목록을 정리할 때 앱을 종료할 수도 있어 백그라운드 잠금이 필요한지는 기기 구현에 따라 다릅니다. 설정 메뉴 이름보다 화면을 잠근 채 잠시 기다렸다가 웹페이지를 다시 열어 클라이언트 프로세스, VPN 인터페이스, 설정이 유지되는지 확인하는 것이 중요합니다.

“VPN 항상 사용”과 “VPN을 사용하지 않으면 연결 차단”은 시스템 수준 정책이므로 처음 설정할 때 함께 활성화하지 않는 것이 좋습니다. 후자를 켜면 클라이언트가 실행되지 않거나 업데이트에 실패하거나 시스템이 서비스를 종료할 때 네트워크가 차단되어 휴대전화 자체의 문제로 오해할 수 있습니다. 먼저 재부팅, 화면 잠금, Wi-Fi와 모바일 네트워크 전환을 테스트한 뒤 보안 요구에 따라 설정하세요. 기능을 켠 뒤 인터넷에 연결되지 않으면 시스템 VPN 설정에서 차단 정책을 확인하고, 필요하면 구독 업데이트와 문제 진단을 위해 일시적으로 끄세요.

앱별 설정, 비공개 DNS, 모바일 네트워크 차이

앱별 설정에는 보통 “선택한 앱만 프록시 사용” 또는 “선택한 앱 우회”가 있으며 두 옵션은 의미가 정반대입니다. 저장하기 전에 현재 모드를 확인하세요. 제외된 앱은 클라이언트 내부의 도메인별 분기 규칙도 적용받지 않습니다. 브라우저를 제외했다면 브라우저 도메인 규칙을 수정해도 효과가 없습니다. 먼저 트래픽 처리 대상에 포함된 브라우저 하나만으로 테스트한 다음 다른 앱을 추가하세요. 시스템 구성 요소, 업무용 프로필, 앱 복제본은 서로 다른 환경에 있을 수 있으므로 선택한 클라이언트가 각각의 트래픽을 처리할 수 있는지 따로 확인하세요.

Android의 비공개 DNS, 브라우저 보안 DNS, 클라이언트 내장 DNS가 동시에 도메인 해석에 관여할 수 있습니다. 해석에 실패하면 기존 설정을 기록한 뒤 시스템 자동 DNS와 클라이언트 기본 설정을 기준으로 비교하고 항목을 하나씩 복원하세요. 특정 설정을 끄는 것이 언제나 정답이라고 단정하지 마세요. 모바일 네트워크는 IPv6 또는 다른 NAT 경로를 사용할 수 있습니다. Wi-Fi에서는 정상인데 모바일 네트워크에서 실패한다면 연결 로그, 대상 주소 계열, 노드 접근성을 각각 확인하세요. Wi-Fi에서의 결과를 모바일 네트워크에 그대로 적용하지 마세요.

마지막으로 실제 네트워크 전환을 테스트하세요. Wi-Fi에서 연결한 다음 모바일 네트워크로 바꿔 같은 사이트에 접속하고, 화면을 잠갔다가 다시 사용해 보세요. 단계마다 접속 가능 여부와 로그만 확인하고 연결 검사에 표시된 단일 수치를 서비스 사용 가능 여부의 보증으로 보지 마세요. 한 앱만 실패하면 앱별 규칙, 앱의 네트워크 제한, 프로토콜 요구 사항을 먼저 확인하세요. 모든 앱이 동시에 실패하면 VPN 서비스, 구독 상태, DNS 순서로 점검하세요.

iOS: 앱스토어 설치, 설정 권한, 필요 시 연결

Clash Plus를 설치하고 구독을 저장하세요

iOS에서는 Clash Plus를 우선 추천합니다. App Store의 Clash Plus 페이지에서 설치할 수 있으며, 제품 정보는 공식 웹사이트 clashplus.io에서 확인하세요. 사이트의 iOS 다운로드에도 같은 링크가 있어 다른 기기와 비교하기 편리합니다. 설치 전에 App Store의 호환성 안내를 확인하세요. 설정을 가져오기 전에 시스템 요구 사항을 충족하는지, 기기에 관리 정책이 적용되어 있는지 확인해야 설치 제한을 구독 문제로 오해하지 않습니다.

선택한 클라이언트에서 사용할 수 있는 구독 주소를 준비한 뒤 앱의 설정 또는 구독 관리 메뉴에서 원격 설정을 추가하고 업데이트 결과를 확인하세요. 메뉴 이름은 클라이언트 업데이트에 따라 바뀔 수 있으므로 “원격 설정 추가, 업데이트, 현재 설정으로 지정”이라는 세 가지 작업을 기준으로 과정을 확인하세요. 가져온 직후 모든 자동 기능을 켜지 말고 먼저 서버 목록과 정책 그룹에서 내용이 올바르게 파싱되었는지 확인하세요. 서비스 제공업체가 특정 클라이언트 형식만 제공한다면 호환 방법을 문의하세요. 파일 확장자만 바꿔서는 형식을 변환할 수 없습니다.

다른 기기에서 주소를 복사할 때 메신저가 공백을 넣거나 쿼리 매개변수를 자르거나 기호를 서식 있는 링크로 바꾸지 않았는지 확인하세요. 붙여 넣은 뒤 URL의 프로토콜과 전체 길이를 확인하되, 권한 정보가 포함된 주소를 스크린샷에 표시하지 마세요. 카메라로 QR 코드를 스캔하더라도 입력 오류만 줄어들 뿐 내용의 신뢰성이 보장되지는 않습니다. 구독을 바꾸기 전에 기존 설정 이름과 사용자 규칙을 백업하세요. 원격 설정이 여러 개라면 현재 선택된 설정을 확인해야 합니다. 새 구독을 업데이트해도 이전 설정이 계속 실행될 수 있습니다.

시스템 VPN 상태와 실제 프록시 경로를 구분하세요

처음 연결할 때 앱이 VPN 설정을 추가하도록 허용해야 하며, 기기 암호나 생체 인증으로 시스템 승인을 완료해야 할 수 있습니다. 권한을 승인한 뒤 앱으로 돌아가 연결 결과를 확인하고 시스템 VPN 설정에서 현재 연결을 제공하는 앱을 확인하세요. 시스템에 VPN 표시가 나타나는 것은 터널 인터페이스가 설정되었다는 뜻일 뿐, 상위 노드에 연결되거나 모든 대상 트래픽이 프록시를 통과한다는 뜻은 아닙니다. 다음으로 브라우저에서 직접 연결해야 하는 대상과 프록시를 거쳐야 하는 대상을 각각 열어 보고 앱이 제공하는 연결 기록이나 규칙 기록을 확인하세요.

iOS에서는 데스크톱처럼 “로컬 포트를 설정한 뒤 시스템 프록시를 켜는” 방식을 따라 하지 마세요. 앱은 보통 시스템 네트워크 확장 기능으로 트래픽을 처리합니다. 화면의 규칙 모드, 프록시 모드, 연결 스위치도 서로 다른 계층입니다. 규칙 모드는 도메인, 주소 등 조건에 따라 정책을 선택하고, 전역 모드는 더 많은 트래픽을 선택한 프록시 정책으로 전달하지만 둘 다 노드가 정상 작동해야 합니다. 전역 모드로 바꾼 뒤 연결이 복구되더라도 규칙 또는 정책 선택 문제로 범위를 좁힐 수 있을 뿐 DNS, 권한, 네트워크 환경이 모두 정상임을 증명하지는 않습니다.

같은 기기에 다른 VPN, 콘텐츠 필터, 조직에서 배포한 네트워크 설정이 있다면 먼저 활성화 상태를 확인하세요. 관리 대상 기기에서는 설정 추가나 변경이 금지될 수 있으며, 이 경우 기기 관리자에게 문의해야 합니다. 업무용 네트워크, 인증서, 접근 권한이 포함되어 있을 수 있으므로 시스템 프로파일을 반복해서 삭제하며 문제를 해결하려고 하지 마세요. 개인 기기에서 구형 클라이언트를 정리할 때도 먼저 연결을 끊고 해당 앱 안내에 따라 관련 설정을 제거하세요. 사용 중인 네트워크 설정을 실수로 삭제하지 않도록 주의하세요.

필요 시 연결, 무선 네트워크, 백그라운드 제한

수동 연결이 안정적으로 작동한 뒤 필요 시 연결을 활성화하세요. 이 기능은 조건에 따라 연결을 시작하거나 복구할 뿐, 만료된 구독을 해결하거나 네트워크 로그인 포털 인증을 자동으로 완료해 주지는 않습니다. 호텔이나 공용 Wi-Fi에서 로그인 페이지가 열리지 않으면 프록시를 잠시 끊고 네트워크 인증을 마친 뒤 다시 연결하세요. Wi-Fi와 모바일 데이터를 전환한 뒤 같은 대상에 각각 접속하고 어느 네트워크에서 문제가 발생하는지 확인하세요. 두 네트워크는 DNS, IPv6, 통신사 경로가 다를 수 있으므로 앱의 연결 표시만으로 판단하지 마세요.

iOS의 백그라운드 실행은 데스크톱의 상주 프로세스와 다르므로 앱 화면을 계속 켜 둘 필요는 없습니다. 시스템 VPN 상태와 실제 요청으로 네트워크 확장 기능이 작동하는지 확인하세요. 앱을 다시 열었을 때만 복구된다면 클라이언트 로그, 시스템 절전 상태, 자동 연결 조건을 살펴보고 발생 당시의 네트워크 유형을 기록하세요. 지나치게 복잡한 설정, 큰 규칙 리소스, 외부 리소스 다운로드 실패도 확장 기능의 시작에 영향을 줄 수 있습니다. 먼저 서비스 제공업체가 지원하는 간단한 설정으로 테스트한 뒤 로컬 규칙과 추가 리소스를 단계적으로 추가하세요.

DNS 문제를 확인할 때는 브라우저나 시스템의 다른 개인정보 보호 네트워크 기능도 고려해야 합니다. 이러한 기능은 DNS 해석과 외부 연결 경로를 바꿀 수 있습니다. 되돌릴 수 있도록 기존 상태를 기록하고 한 번에 한 항목만 임시 변경한 뒤 다시 연결해 같은 대상에 요청하고 설정을 복원하세요. 검사 페이지에 표시되는 DNS 서비스 이름만으로 트래픽이 유출되었다고 볼 수는 없습니다. 클라이언트의 트래픽 처리 방식, 쿼리 경로, 대상 연결 기록을 함께 확인해야 합니다. 자세한 내용은 DNS 유출 검사와 fake-ip 문제 해결 노트를 참고하세요.

Linux: 데스크톱 클라이언트와 mihomo 서비스 배포

먼저 데스크톱 설치와 GUI 없는 배포를 구분하세요

데스크톱에서는 Linux 다운로드에서 Clash Verge Rev 또는 FlClash를 선택하고 배포판, CPU 아키텍처, 다운로드 페이지에 실제로 제공되는 패키지 형식을 확인하세요. 데스크톱 클라이언트는 구독 관리와 대화형 정책 전환이 필요한 환경에 적합합니다. 서버나 라우터에서는 독립 mihomo 커널을 우선 고려하세요. 모두 Linux라는 이유로 일반 데스크톱, 경량 컨테이너, 라우터 시스템을 같은 환경으로 취급하면 안 됩니다. 그래픽 의존성, 권한 모델, 서비스 관리자, 사용 가능한 메모리가 다를 수 있습니다.

배포판의 패키지 관리자로 형식에 맞는 GUI 클라이언트를 설치하세요. 공유 라이브러리나 그래픽 구성 요소가 없다는 메시지가 나오면 구체적인 의존성 오류를 확인하고 낯선 웹사이트에서 동적 라이브러리를 하나씩 다운로드하지 마세요. GUI에서 구독을 가져와 설정을 활성화한 뒤 먼저 로컬 프록시가 수신 중인지 테스트하세요. Linux 데스크톱의 시스템 프록시 설정은 모든 앱에 강제 적용되는 단일 경로가 아닙니다. GNOME, KDE, 터미널 도구, 개별 앱이 각각 다른 설정을 사용할 수 있으므로 “시스템 프록시 사용”이 모든 프로그램에 적용되었다는 뜻은 아닙니다.

터미널 프록시와 데스크톱 프록시를 따로 확인하세요

아래 명령은 현재 터미널과 그 터미널에서 실행되는 하위 프로세스에만 영향을 주며 시스템 전체의 경로를 변경하지 않습니다. 여기서 HTTP와 HTTPS 환경 변수는 모두 로컬 HTTP 프록시 주소를 가리킵니다. https_proxy라는 이름은 대상 요청의 유형을 설명하며 프록시 주소 자체를 HTTPS로 입력해야 한다는 뜻은 아닙니다. ALL_PROXY는 SOCKS를 사용하며, socks5h를 지정하면 이 의미를 지원하는 도구가 대상 도메인 해석을 프록시에 맡깁니다. 도구마다 지원하는 변수가 다르므로 해당 문서를 확인하세요.

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

환경 변수를 임시로 설정해 테스트한 다음 셸 시작 파일에 기록할지 결정하세요. 시스템 서비스는 대화형 터미널의 환경 변수를 자동으로 상속하지 않으며, sudo를 사용하면 변수도 제거될 수 있습니다. 따라서 같은 명령이 실행 방식에 따라 실패할 수 있습니다. 패키지 관리자, 컨테이너 빌드 도구, 버전 관리 도구는 별도의 프록시 설정을 가질 수 있으니 출처를 확인하지 않고 설정을 계속 추가하지 마세요. 명시적으로 검사하려면 curl --proxy를 사용하고 대문자 형식의 이전 변수가 환경에 남아 있는지도 확인하세요.

독립 커널은 설정을 검사한 뒤 실행하세요

아래 예시는 systemd를 사용하는 호스트용이며, 로컬 아키텍처에 맞는 mihomo 실행 파일을 /usr/local/bin/mihomo에 둔 것으로 가정합니다. 전용 계정과 접근이 제한된 설정 폴더를 만들고 이미 보유한 완전한 설정을 /etc/mihomo/config.yaml에 저장한 뒤 해당 계정이 필요한 파일을 읽을 수 있도록 하세요. 예시 설정은 TUN을 켜지 않고 로컬 프록시만 제공하므로 처음 배포할 때 프로세스 권한을 확대하지 않습니다. 설정에 사용되는 데이터베이스와 규칙 리소스도 출처가 명확해야 하며 적절한 폴더 쓰기 권한이 필요합니다.

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -m 750 -o mihomo -g mihomo /etc/mihomo
sudo chown mihomo:mihomo /etc/mihomo/config.yaml
sudo chmod 600 /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo

설정을 저장한 다음 파일 권한 명령을 실행하세요. 계정이 이미 있다면 다시 만들 필요가 없습니다. 배포판마다 로그인 차단 셸 경로가 다를 수 있으므로 로컬 시스템의 실제 경로에 맞게 수정하세요. 설정 검사가 통과하면 아래 유닛을 /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
Restart=on-failure
RestartSec=5
UMask=0077
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo --no-pager
sudo journalctl -u mihomo -n 80 --no-pager
ss -lntp
curl -I --proxy http://127.0.0.1:7890 https://example.com/

이 유닛은 구독을 자동 업데이트하거나 투명 프록시를 설정하지 않습니다. 설정을 수정한 뒤 문법 검사를 다시 실행해 통과한 것을 확인한 다음 서비스를 재시작하세요. 시작 로그에 포트 사용 중이라고 표시되면 GUI 클라이언트나 이전 서비스를 먼저 확인하세요. 중복 프로세스를 숨기려고 포트를 계속 바꾸지 마세요. 서버를 로컬에서만 사용할 경우 루프백 주소에 바인딩하세요. 원격 접근은 접근 제한이 적용된 안전한 통신 경로로 제공해야 합니다. 공개 프록시를 인터넷에 노출하지 마세요.

설정 문제 해결: 요청이 통과하는 단계별로 확인하세요

구독 업데이트, 설정 덮어쓰기, YAML 파싱

문제를 해결하기 전에 마지막으로 정상 작동한 설정을 저장하고 현재 오류가 어느 단계에서 발생하는지 기록하세요. 구독 업데이트 실패는 HTTP 상태 코드와 응답 유형을 확인하고, 설정 로드 실패는 행 번호와 필드를 확인하세요. 커널 시작 실패는 포트와 파일 권한을, 대상 연결 실패는 노드, 규칙, DNS를 점검하세요. 이 문제를 모두 “인터넷에 연결할 수 없음”으로 뭉뚱그리면 구독 서버의 응답이 잘못된 상황에서도 로컬 경로를 반복해서 변경하게 됩니다. 연결됨으로 표시되지만 접속할 수 없을 때 확인할 목록을 참고해 각 계층을 점검하고 한 번에 변수 하나만 변경하세요.

YAML은 공백으로 들여쓰기해야 하며 탭을 섞으면 안 됩니다. 목록 항목의 하이픈, 콜론 뒤의 공백, 문자열 내 특수 기호를 확인하세요. 같은 계층에서 dns나 rules를 중복 정의하지 마세요. 어느 부분을 유지할지 파서가 결정하도록 맡길 수는 없습니다. 클라이언트의 로컬 덮어쓰기가 구독 원본 값을 덮을 수 있으므로 최종 적용 내용은 실행 중인 설정을 기준으로 확인하세요. 업데이트 후 사용자 규칙이 사라졌다면 원격 캐시 파일을 직접 수정했는지 확인하고, 계속 유지해야 하는 변경은 클라이언트가 지원하는 덮어쓰기 메뉴로 옮기세요.

DNS, fake-ip, 규칙의 연관 관계

아래 예시는 mihomo의 DNS와 TUN 연결 방식을 보여 줍니다. 기존의 완전한 설정에 병합하고 포트, 권한, 사용 중인 커널의 지원 여부를 확인하세요. 테스트 범위를 줄이기 위해 예시에서는 IPv6를 비활성화했으며, 모든 네트워크에 영구 적용하라는 의미는 아닙니다. dns-hijack는 해당 TUN 경로로 들어오는 일반 DNS 요청을 가로채는 기능입니다. 브라우저가 직접 보내는 암호화 DNS까지 처리한다고 단정할 수 없습니다. 활성화하기 전에 시스템 프록시가 정상 작동하는지 확인하고, 문제가 다시 생기면 TUN만 꺼서 비교하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

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

fake-ip는 매핑된 주소를 반환해 커널이 이후 연결에서도 도메인 정보를 유지하도록 합니다. 노드를 위조하거나 시스템 DNS가 반드시 처리되고 있다는 뜻은 아닙니다. 테스트에서 예약 주소가 보인다고 바로 오류로 판단하지 마세요. 중요한 것은 이후 트래픽이 같은 커널로 들어가는지입니다. 앱에 이전 DNS 결과가 캐시되어 있다면 앱을 재시작한 뒤 다시 테스트하세요. 호환성 문제가 확인된 도메인만 적절한 필터 규칙에 추가하고, 처음부터 모든 도메인을 제외해 기능을 무력화하지 마세요.

respect-rules를 사용하면 관련 DNS 연결에도 분기 규칙이 적용됩니다. 프록시 서버 도메인 자체를 어떻게 해석할지 함께 고려해 DNS 의존성이 순환하지 않도록 하세요. 이 옵션 하나만 선택하면 모든 DNS 유출 경로가 차단되는 것은 아닙니다. nameserver, fallback, 필터 조건도 필드 이름만 보고 단순한 주 서버와 보조 서버 순서라고 판단할 수 없습니다. 여러 매개변수를 조합하려면 mihomo DNS 매개변수 안내를 확인하고 먼저 요청 경로를 파악한 뒤 설정하세요.

규칙 적용, 프로토콜 지원, 복구 순서

규칙 모드에서는 구체적인 도메인 규칙을 넓은 지역 규칙보다 앞에 두고 마지막에 기본 규칙을 남겨 두는 것이 일반적입니다. DOMAIN-SUFFIX는 도메인 정보를 사용할 수 있어야 하며 GEOIP는 대상 주소와 데이터베이스에 따라 작동합니다. 요청이 IP 주소로 나타나면 도메인 규칙과 예상대로 일치하지 않을 수 있습니다. 정책 그룹이 존재하더라도 현재 선택한 정책이 유효하다는 뜻은 아닙니다. 선택한 노드에 연결할 수 있는지 확인하세요. 데이터베이스 로드 오류가 발생하면 리소스 경로나 다운로드 문제를 먼저 처리하세요. 자세한 내용은 GeoIP 및 GeoSite 데이터베이스 업데이트 안내를 참고하세요.

마지막에는 반대 순서로 설정을 복구하세요. 새로 추가한 TUN이나 자동 연결을 먼저 끄고, 남아 있는 시스템 프록시를 제거한 뒤 기록해 둔 DNS 설정을 복원하고 기본 네트워크가 정상인지 확인한 다음 최소 설정으로 다시 연결하세요. 문제가 안정적으로 재현되면 앱별 설정, 덮어쓰기 규칙, 백그라운드 자동 실행을 추가하세요. 문의할 때는 운영체제 종류, 클라이언트 이름, 오류 발생 시각, 개인정보를 가린 로그를 제공하면 됩니다. 구독 주소 전체나 계정 인증 정보는 보내지 마세요. 연결 과정을 처음부터 다시 확인하려면 빠른 시작 가이드를, 증상별 답변은 자주 묻는 질문에서 확인하세요.