Clash 전 플랫폼
설치·설정 가이드

공통 준비: 클라이언트와 설정 구분하기

클라이언트는 실행을, 구독은 연결 정보를 담당합니다

Clash 생태계에는 모든 기기에서 쓸 수 있는 단일 설치 파일이 없습니다. 클라이언트는 조작 가능한 앱이고, 코어는 설정을 읽어 규칙을 적용하고 연결을 전달합니다. mihomo는 이 생태계에서 널리 쓰이는 코어입니다. Clash.Meta는 mihomo로 발전해 왔지만, 구형 클라이언트가 새 필드를 지원하지 않을 수도 있습니다. 다운로드 전에 운영체제, 프로세서 아키텍처, 클라이언트의 유지보수 상태를 확인하고 구독 제공업체가 지원하는 설정 형식도 살펴보세요. 파일 이름에 Clash가 들어 있다고 해서 모두 호환되는 것은 아닙니다.

처음 선택할 때는 Clash Plus를 우선 살펴보세요. 다른 클라이언트는 플랫폼과 사용 방식에 맞춰 고르면 됩니다. 앱을 설치해도 사용할 수 있는 노드가 자동으로 생기지는 않습니다. 구독은 보통 개인 접근 정보가 포함된 링크로, 노드·정책 그룹·규칙 등의 설정을 제공합니다. 링크를 받으면 클라이언트 구독 주소인지, 계정 로그인 페이지나 웹 공유 주소인지 먼저 확인하세요. 브라우저에서 페이지가 열린다고 해서 클라이언트가 해당 주소를 읽을 수 있는 것은 아닙니다.

기기 환경과 연결 전제 조건 기록하기

먼저 기기 시간, 저장 공간, 기본 네트워크를 확인하세요. 시간이 크게 어긋나면 암호화 연결의 인증에 문제가 생길 수 있으며, 네트워크에 웹 인증 절차가 있다면 먼저 완료해야 합니다. 회사나 학교에서 관리하는 기기는 앱 설치, VPN, 네트워크 확장이 제한될 수 있습니다. 관리 정책을 끄는 방식으로 해결하지 마세요. 컴퓨터 외관이나 휴대폰 브랜드로 아키텍처를 추측하지 말고 시스템 정보에서 확인하세요. 모바일 기기에서는 다른 VPN, 패킷 캡처 도구, 로컬 VPN을 사용하는 필터링 앱이 실행 중인지도 살펴보세요.

기준 상태 네 가지를 기록해 두는 것이 좋습니다. 현재 직접 연결이 되는지, Wi-Fi와 모바일 데이터 중 무엇을 쓰는지, 수동 프록시가 설정되어 있는지, 프린터나 LAN 서버에 접속해야 하는지 확인하세요. 클라이언트를 켠 뒤 문제가 생기면 기존 네트워크 문제인지 새 설정 때문인지 구분하는 데 도움이 됩니다. 처음부터 시스템 프록시, TUN, 사용자 지정 DNS, 전역 모드를 한꺼번에 켜지 마세요. 가장 단순한 연결부터 확인한 다음 기능을 하나씩 추가하세요.

규칙 모드와 설정 파일의 역할 구분하기

규칙 모드는 설정의 규칙에 따라 연결 출구를 선택한다는 뜻이며, 모든 요청이 프록시를 통과하는 것은 아닙니다. 전역 모드는 일반적으로 모드 설정을 따르는 연결에 전역 정책을 적용하지만, 시스템 차원의 트래픽 처리를 대신하지는 않습니다. 직접 연결 모드는 프록시를 우회할 때 사용합니다. 처음 설치했다면 규칙 모드를 선택한 뒤 실제 규칙에서 참조하는 정책 그룹의 노드를 고르세요. 사용되지 않는 그룹만 수정해도 현재 요청의 출구는 바뀌지 않습니다.

YAML은 들여쓰기로 데이터를 구성하는 텍스트 형식입니다. 아래 예시는 자주 쓰이는 필드 몇 가지를 보여줄 뿐, 노드가 포함된 완성된 설정 파일이 아닙니다. 기존 설정의 해당 위치에 병합해야 하며 같은 계층에 동일한 키를 두 번 쓰거나 탭을 공백 대신 사용하면 안 됩니다. 클라이언트에 시각적 설정 메뉴가 있다면 그곳에서 조정하는 편이 좋습니다. 화면에서 생성한 설정과 직접 편집한 파일이 서로 덮어쓸 수 있습니다.

mode: rule
log-level: info
allow-lan: false
ipv6: false

모든 설치 파일은 다운로드 페이지에서 확인할 수 있습니다. 기존 클라이언트에서 옮기려면 먼저 지원 종료 후 설정 백업 및 이전 방법을 읽으세요. 기존 설정을 보관하고 새 클라이언트가 작동하는지 확인한 다음 이전 앱을 제거하세요. 이전하는 동안 트래픽을 처리하는 클라이언트는 하나만 실행해야 라우팅이나 프록시 포트 충돌을 피할 수 있습니다.

Windows: 설치부터 시스템 프록시와 TUN 설정까지

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

Windows 다운로드에서 Clash Plus를 먼저 확인한 다음 필요에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 비교하세요. Clash for Windows는 지원이 중단된 보관용 선택지이므로 새 환경을 구축할 때는 권장하지 않습니다. ‘설정 → 시스템 → 시스템 정보’에서 시스템 종류를 확인하고 다운로드 페이지의 지원 안내와 대조하세요. 아키텍처 안내가 없다면 다른 아키텍처용 설치 파일을 기본 지원되는 것으로 간주하지 마세요.

다운로드한 뒤 기존 프록시 클라이언트를 종료하고 설치를 진행하세요. 일반 설치와 관리자 권한이 필요한 서비스 설치는 별개입니다. 앱 화면이 실행된다고 해서 TUN에 필요한 백그라운드 서비스까지 준비된 것은 아닙니다. 보안 경고가 나타나면 파일 출처와 앱 정보를 확인하세요. 경고를 피하려고 시스템 보호 기능을 전부 끄지 마세요. 조직 정책으로 설치가 차단된다면 기기 관리자에게 문의하세요. 설치가 끝나면 먼저 앱을 열고, 문제가 발생한 단계를 파악할 수 있도록 당장은 시작 프로그램으로 등록하지 마세요.

구독을 가져오고 현재 사용 중인 설정 확인하기

설정 또는 구독 화면에서 URL 가져오기를 선택하고 알아보기 쉬운 이름을 입력한 뒤 전체 구독 주소를 붙여 넣고 저장하세요. 복사 과정에서 앞뒤에 공백이 들어갔다면 제거하되 쿼리 매개변수는 직접 지우지 마세요. 다운로드와 파싱이 끝날 때까지 기다린 뒤 해당 설정을 직접 선택하세요. 일부 클라이언트는 ‘구독 저장’과 ‘설정 활성화’를 별도 단계로 나눕니다. 목록에 새 항목이 생긴 것만으로 코어가 해당 설정을 사용한다고 볼 수는 없습니다.

정책 그룹 화면에서 규칙 모드를 선택하고 그룹에 선택 가능한 노드가 있는지 확인하세요. DIRECT만 남아 있거나 그룹 목록이 비어 있다면 시스템 프록시를 반복해서 켜기보다 구독 형식과 파싱 로그를 먼저 확인하세요. 노드 테스트에 성공하면 실제로 해당 출구가 필요한 웹사이트를 브라우저에서 열어 보세요. 테스트 결과는 테스트 당시 해당 주소에 연결할 수 있었음을 보여줄 뿐, 모든 사이트와 프로토콜, 로그인 과정이 정상임을 보장하지는 않습니다.

먼저 시스템 프록시를 켜고 필요할 때 TUN 사용하기

시스템 프록시는 브라우저 같은 일반 앱의 연결을 먼저 확인하기에 적합합니다. 클라이언트에서 기능을 켜면 시스템 프록시 주소는 보통 로컬 루프백 주소를 가리키며, 포트는 클라이언트에 표시된 값을 기준으로 합니다. 아래 명령은 클라이언트의 혼합 포트가 실제로 7890일 때만 해당 포트를 명시해 요청을 보내는 예입니다. 명령을 그대로 따라 하려고 정상 작동 중인 포트를 7890으로 바꾸지 마세요.

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

명령으로는 연결되는데 특정 앱에서 안 된다면 해당 앱이 시스템 프록시를 따르는지, 자체 프록시 설정이 있는지 확인하세요. TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하므로 시스템 프록시를 읽지 않는 프로그램에 적합합니다. 기능을 켤 때는 클라이언트 안내에 따라 서비스를 설치하거나 권한을 허용한 뒤, 로그에 인터페이스 또는 라우팅 오류가 있는지 확인하세요. 모든 권한 문제를 해결하는 상시 대책으로 ‘앱 전체를 관리자 권한으로 실행’하지 마세요.

포트 충돌, 절전 후 복구, 종료 후 설정 잔류 해결하기

시작할 때 포트 사용 중 경고가 뜨면 기존 클라이언트가 트레이나 백그라운드에서 실행 중인지 확인하고, 개발용 프록시나 컨테이너 도구도 살펴보세요. 정체를 모르는 시스템 프로세스를 함부로 종료하지 마세요. 포트를 바꿔야 한다면 클라이언트, 수동 프록시 설정, 터미널 환경 변수를 모두 확인해야 합니다. 시스템 프록시와 WinHTTP 프록시는 서로 다른 설정이며, 일부 백그라운드 프로그램은 자체 연결 방식을 사용할 수 있습니다.

컴퓨터가 절전 모드에서 돌아오거나 Wi-Fi를 바꾸거나 회사 VPN에 연결하면 라우팅과 DNS가 달라질 수 있습니다. 먼저 클라이언트의 트래픽 처리 기능을 껐다가 다시 켜서 복구되는지 확인하세요. 같은 문제가 반복되면 해당 시간대의 로그를 저장하세요. 클라이언트를 종료하기 전 시스템 프록시를 먼저 끄세요. 비정상 종료됐다면 시스템 프록시 설정에 루프백 주소가 남아 있는지 확인하세요. 앱은 종료됐는데 브라우저가 로컬 포트를 계속 가리키면 모든 페이지가 갑자기 열리지 않을 수 있습니다.

마지막으로 시작 시 실행을 설정하고 한 번 재부팅해 백그라운드 서비스, 설정 선택, 정책 그룹이 복구되는지 확인하세요. ‘LAN 연결 허용’을 사용하려면 수신 주소, 방화벽 인바운드 규칙, 인증 설정도 이해해야 합니다. 이 기기에서만 쓸 경우에는 꺼 두면 됩니다. 개별 문제는 FAQ에서 확인할 수 있습니다. 앱 하나의 문제 때문에 전체 환경을 다시 설치할 필요는 없습니다.

macOS: 칩 아키텍처와 네트워크 권한 확인하기

아키텍처에 맞는 파일을 다운로드해 앱 설치하기

‘이 Mac에 관하여’를 열어 Apple Silicon인지 Intel 프로세서인지 확인한 다음 macOS 다운로드에서 알맞은 설치 파일을 고르세요. Clash Plus를 우선 확인하고 Clash Verge Rev와 FlClash도 비교할 수 있습니다. ClashX Meta는 지원이 중단되어 기존 환경을 알아볼 때는 참고할 수 있지만, 새 기기에 기본 선택으로 설치하는 것은 권장하지 않습니다. 호환 기능을 통해 다른 아키텍처의 앱을 실행할 수 있더라도 보조 서비스와 네트워크 기능이 완전히 같다는 뜻은 아닙니다.

디스크 이미지의 앱을 설치할 때는 안내에 따라 ‘응용 프로그램’ 폴더로 복사한 뒤 해당 위치에서 실행하세요. 마운트된 설치 이미지에서 계속 실행하지 마세요. 이렇게 하면 앱 업데이트, 보조 프로그램 경로, 로그인 항목을 일관되게 관리하기 쉽습니다. 시스템 보안 경고가 나타나면 다운로드 출처와 서명 정보를 확인하고 시스템이 안내하는 절차에 따라 처리하세요. 온라인에서 찾은 시스템 보안 검사 전체 해제 명령을 바로 실행하지 마세요.

구독을 가져온 뒤 최소한의 연결부터 확인하기

클라이언트의 설정 화면에서 URL 구독을 추가하고 저장한 뒤 파싱이 끝날 때까지 기다리세요. 설정을 활성화한 다음 정책 그룹이 모두 표시되는지 확인하고 규칙 모드와 실제로 사용할 출구를 선택하세요. 구독 제공업체가 일반 설정, mihomo 설정, 다른 클라이언트용 형식을 구분한다면 현재 코어에 맞는 항목을 선택하세요. 파일을 가져올 수 있다고 해서 모든 확장 필드가 적용된 것은 아니므로 로그의 미지원 필드 안내도 확인해야 합니다.

첫 테스트는 시스템 프록시로 진행하세요. macOS 프록시 설정은 네트워크 서비스마다 적용되므로 Wi-Fi와 유선 네트워크에 각각 설정이 있을 수 있습니다. 네트워크를 바꾼 뒤 클라이언트는 켜져 있는데 브라우저 연결 기록이 없다면 현재 네트워크 서비스의 프록시 설정을 확인하세요. 브라우저 확장 프로그램, 개발 도구, 터미널도 각자 프록시를 설정할 수 있으므로 한 앱의 결과만으로 컴퓨터 전체를 판단할 수는 없습니다.

네트워크 확장, 보조 서비스, TUN 권한

TUN이 필요하다면 클라이언트의 안내에 따라 권한을 허용하세요. 구현에 따라 특권 보조 프로그램, 시스템 네트워크 확장 등 방식이 다를 수 있으므로 모든 클라이언트에서 같은 창이 나타난다고 가정하지 마세요. 권한은 보통 시스템 설정의 개인정보 보호, 보안 또는 네트워크 관련 화면에서 확인합니다. 처음 권한을 허용한 뒤에는 클라이언트로 돌아가 기능을 다시 켜고 코어 로그를 살펴보세요. 시스템 팝업이 닫혔다는 이유만으로 트래픽 처리가 성공했다고 볼 수는 없습니다.

기능 스위치가 저절로 꺼진다면 보조 서비스가 제대로 설치됐는지, 시스템에서 아직 승인해야 할 항목이 있는지, 기존 클라이언트가 같은 리소스를 점유하는지 먼저 확인하세요. 기존 서비스와 설정을 남긴 채 여러 번 재설치해도 문제가 해결되지 않을 수 있습니다. 먼저 기존 앱을 정상 종료하고, 앱이 제공하는 방법으로 서비스를 비활성화하세요. 익숙하지 않은 시스템 폴더나 네트워크 장치를 직접 삭제하지 마세요.

scutil --proxy
scutil --dns
route -n get default

아래 읽기 전용 명령 세 가지는 프록시, DNS, 기본 라우트를 각각 확인합니다. 기능을 켜기 전후로 비교할 수 있습니다. 출력에 특정 리졸버가 표시되어도 모든 조회가 해당 리졸버를 사용한다는 뜻은 아닙니다. 시스템은 네트워크 인터페이스, 도메인 범위, 우선순위에 따라 조회 경로를 선택할 수도 있습니다. 출력을 공유하기 전 개인 네트워크 정보를 가리세요. DNS를 분석할 때는 주소 한 줄만 보고 결론 내리지 말고 클라이언트 로그와 실제 접속 도메인을 함께 확인하세요.

LAN, 절전, 네트워크 전환 문제 해결하기

TUN을 켠 뒤 프린터, 파일 공유, 로컬 개발 서비스에 문제가 생기면 대상이 루프백 주소인지, 사설 IP인지, LAN 검색에 의존하는 이름인지 먼저 구분하세요. 사설 주소 직접 연결 규칙으로 해결되는 문제는 일부뿐입니다. 멀티캐스트 검색, 링크 로컬 도메인, 가상 머신 네트워크에는 클라이언트의 별도 제외 설정이 필요할 수 있습니다. LAN 대역 전체를 외부 프록시로 무작정 보내거나 프린터를 쓰려고 전역 모드를 계속 사용하지 마세요.

노트북 덮개를 닫아 절전한 뒤 네트워크에 다시 연결하면 기존 연결 세션이 끊겼을 수 있습니다. 네트워크가 복구될 때까지 기다린 다음 클라이언트 연결을 다시 설정하세요. DNS가 이전 네트워크의 결과를 계속 사용한다면 트래픽 처리 기능을 껐다가 켜서 변화를 확인하세요. 휴대폰 핫스팟, 회사 네트워크, 집 네트워크를 오갈 때는 인증 페이지와 다른 VPN도 주의해야 합니다. 프록시를 살피기 전에 기본 네트워크가 정상인지 확인해야 상위 네트워크 단절을 설정 손상으로 오해하지 않습니다.

다른 Mac으로 옮길 때는 구독을 다시 가져온 다음 필요한 재정의 설정과 규칙을 복원하는 것이 좋습니다. 보조 서비스, 절대 경로, 이전 기기의 네트워크 인터페이스 이름까지 그대로 옮기지 마세요. 브라우저, 터미널, 자주 쓰는 앱에서 실제로 확인한 뒤 로그인 시 실행을 켜고 앱 종료 시 시스템 프록시가 정상적으로 복구되는지 확인하세요.

Android: VpnService 권한과 백그라운드 실행 유지

설치 전에 아키텍처와 기존 앱 확인하기

Android 다운로드에서 Clash Plus를 먼저 확인하고, 필요에 따라 Clash Meta for Android, FlClash, Surfboard를 선택하세요. 클라이언트마다 지원하는 설정 형식이 다르며, 특히 Surfboard는 임의의 mihomo YAML을 그대로 가져올 수 있다고 가정하면 안 됩니다. 구독 제공업체의 형식 안내를 먼저 확인한 뒤 클라이언트를 고르세요. 아키텍처는 시스템의 실제 지원 여부를 기준으로 판단해야 합니다. 기기가 64비트 프로세서를 사용한다고 해서 시스템이 64비트 앱만 실행하는 것은 아닙니다.

외부에서 다운로드한 앱을 설치할 때는 현재 브라우저나 파일 관리자의 앱 설치를 허용하라는 메시지가 표시될 수 있습니다. 이번에 사용할 출처에 필요한 권한만 허용하고, 설치가 끝나면 해당 출처의 설치 권한을 꺼도 됩니다. 업데이트 과정에서 서명이 일치하지 않는다고 나오면 이전 앱을 바로 삭제하지 마세요. 먼저 구독과 재정의 설정을 내보내고 새 설치 파일이 같은 배포 경로에서 제공됐는지 확인하세요. 앱을 바로 삭제하면 앱 전용 저장소에 보관된 데이터도 함께 사라질 수 있습니다.

구독 가져오기와 시스템 VPN 권한 설정하기

설정 화면에서 URL 구독을 추가하고 저장한 다음 다운로드가 끝날 때까지 기다린 후 현재 설정으로 선택하세요. 정책 그룹으로 이동해 노드가 있는지 확인하고 규칙 모드를 선택합니다. 처음 연결을 시작하면 Android에서 VPN 연결 요청이 표시됩니다. VpnService는 시스템이 제공하는 인터페이스로, 클라이언트가 이를 사용해 트래픽을 받는 로컬 가상 터널을 만듭니다. VPN 아이콘이 표시된다고 해서 트래픽이 반드시 원격 서버를 통과하는 것은 아닙니다.

권한을 허용하기 전에 팝업에 표시된 앱 이름을 확인하세요. 권한을 거부해도 클라이언트에 설정과 노드 목록은 보일 수 있지만, 다른 앱의 트래픽은 처리할 수 없습니다. 연결을 다시 시작해 권한 요청을 띄우세요. 시스템에서 팝업이 계속 나타나지 않는다면 다른 VPN, 업무 프로필의 VPN, 기기 관리 제한을 확인하세요. 일반적으로 Android에서는 일반 앱 두 개가 같은 사용자 공간의 VPN 터널을 동시에 사용할 수 없습니다.

규칙 모드, 앱별 분할, VPN 상시 연결

먼저 규칙 모드를 유지하고 브라우저로 한 번 확인한 다음 앱별 분할을 설정하세요. 앱별 분할은 ‘선택한 앱만 포함’하거나 ‘선택한 앱 제외’하는 상반된 방식일 수 있으므로 체크하기 전에 안내를 읽으세요. 제외된 앱은 코어 로그에 나타나지 않을 수 있으므로 노드를 바꿔도 프록시가 복구되지 않습니다. 결제 앱, LAN 기기 제어 앱, 업무 앱에 문제가 생기면 한 번에 여러 앱을 제외하지 말고 하나씩 테스트하세요.

시스템 VPN 설정의 ‘VPN 상시 연결’은 지정한 VPN 앱과 시스템의 연결을 유지합니다. ‘VPN 연결 없이는 연결 차단’은 터널이 설정되지 않았을 때 네트워크를 막을 수 있습니다. 두 옵션은 서로 다른 기능입니다. 재부팅과 네트워크 전환 뒤에도 클라이언트가 복구되는지 먼저 확인한 다음 차단 옵션을 고려하세요. 그렇지 않으면 구독 만료, 앱 제한, 시작 실패로 휴대폰 전체가 일시적으로 인터넷에 연결되지 않을 수 있습니다.

화면을 잠그면 연결이 끊길 때는 배터리 제한부터 확인하세요

화면이 꺼진 뒤 연결이 끊기고 켜면 복구된다면 앱의 배터리 설정을 먼저 확인하세요. 클라이언트의 백그라운드 활동을 허용하거나 배터리 최적화 대상에서 제외하세요. 일부 제조사의 기기에서는 자동 시작 허용이나 백그라운드 작업 관리자에서 앱을 유지하는 설정도 필요합니다. 시스템마다 메뉴 이름은 다르지만 화면을 잠근 뒤에도 VPN 서비스가 실행되도록 하는 것이 핵심입니다. 알림 권한과 지속 알림도 클라이언트 안내에 따라 설정하세요. 다만 알림을 켜는 것만으로 배터리 예외 설정을 대신할 수는 없습니다.

화면을 켠 상태에서 한 번 속도 측정한 것으로 문제가 해결됐다고 판단하지 마세요. 연결한 뒤 일정 시간 화면을 잠그고, 다시 켜서 클라이언트 서비스 상태와 연결이 끊긴 시간을 확인하세요. 그런 다음 Wi-Fi와 모바일 데이터를 각각 테스트합니다. 데이터 절약 모드, 백그라운드 데이터 제한, 제조사 절전 모드도 결과에 영향을 줄 수 있습니다. 구체적인 경로는 VpnService 권한 및 배터리 최적화 제외 설정 안내를 참고해 항목별로 확인하세요.

DNS, 핫스팟 공유, 클라이언트 간 이전

Android의 비공개 DNS, 브라우저 보안 DNS, 클라이언트 내부 DNS 설정이 동시에 적용될 수 있습니다. 도메인 조회에 실패하면 각 설정을 먼저 기록하고 한 번에 한 항목씩 바꿔 확인하세요. DNS라는 글자가 보인다고 전부 끄지 마세요. 요청을 보낸 앱, VPN 통과 여부, 최종 리졸버를 확인해야 합니다. 노드 주소에도 DNS 조회가 필요합니다. 노드 서버 도메인을 조회할 수 없다면 이후 규칙이 올바르더라도 연결을 만들 수 없습니다.

휴대폰에서 핫스팟을 켠다고 해서 핫스팟에 연결된 기기가 휴대폰 앱의 VPN 경로를 자동으로 공유하는 것은 아닙니다. 시스템마다 전달 방식과 권한 제한이 다르므로 ‘LAN 연결 허용’을 핫스팟 프록시 기능으로 이해하면 안 됩니다. 클라이언트를 이전할 때는 앱별 목록, 배터리 설정, VPN 권한도 다시 확인하세요. 이런 설정은 보통 YAML 파일과 함께 옮겨지지 않습니다. 화면 잠금, 재부팅, 네트워크 전환을 각각 테스트한 다음 기존 클라이언트를 비활성화하거나 삭제하세요.

iOS: 앱스토어 설치, 설정 호환성, VPN 연결

App Store에서 Clash Plus 설치하기

iOS에서는 Clash Plus를 우선 사용하세요. iOS 다운로드에서 이동하거나 Clash Plus App Store 페이지를 바로 열 수 있습니다. 제품 공식 웹사이트는 clashplus.io입니다. 설치 전에 App Store에 표시된 iOS 호환 요구 사항을 확인하고 기기의 실제 운영체제와 스토어 정보를 기준으로 판단하세요. 데스크톱 클라이언트의 기능 목록을 모바일 앱에 그대로 적용하지 마세요.

앱을 처음 열면 설정 가져오기와 연결 화면을 먼저 찾고, 고급 옵션을 한꺼번에 많이 바꾸지는 마세요. iOS 앱은 일반적으로 시스템 네트워크 확장으로 VPN 터널을 만듭니다. 시스템 권한과 구독 내용은 별개입니다. 터널 생성을 허용해도 노드가 생기는 것은 아니며, 구독을 가져와도 시스템이 앱의 네트워크 처리를 허용한 것은 아닙니다. 두 절차를 각각 완료하고 확인해야 합니다.

링크 이름만 보지 말고 가져오기 형식을 확인하세요

클라이언트가 지원하는 가져오기 메뉴에 구독 주소를 붙여 넣고 저장한 뒤 해당 설정을 선택하세요. 파일 가져오기를 지원한다면 파일 형식과 포함된 필드 범위도 확인해야 합니다. Clash 생태계의 설정은 구현 간에 완전히 통일된 표준이 아닙니다. 코어 확장, 규칙 제공자, 로컬 파일 경로, 스크립트 기능이 서로 다를 수 있습니다. 데스크톱에서 불러올 수 있는 YAML도 모바일에서는 조정하거나 구독 제공업체의 호환 형식을 사용해야 할 수 있습니다.

가져오기에 실패하면 다운로드 실패인지 파싱 실패인지 오류 유형부터 확인하세요. 다운로드 실패라면 링크 유효성, 네트워크 인증 필요 여부, 주소가 복사 과정에서 잘렸는지 확인합니다. 파싱 실패라면 응답이 설정 파일인지, 로그인 페이지나 오류 메시지가 섞이지 않았는지 살펴보세요. 전체 구독 주소를 공개 게시판에 붙여 넣지 마세요. 도움을 요청할 때는 오류 유형과 필드 이름만 남기고 링크 매개변수, 노드 비밀번호, 개인 계정 정보를 가리세요.

VPN 설정 추가를 허용하고 출구 선택하기

처음 연결을 시작할 때 시스템에서 VPN 설정 추가를 요청하고 기기 암호나 생체 인증으로 확인할 수 있습니다. 완료한 뒤 앱으로 돌아가 연결 상태를 확인하고 시스템 VPN 목록이 현재 앱에 해당하는지 살펴보세요. 앱에서 생성한 VPN 설정과 기기 관리 프로파일은 서로 다른 개념입니다. 일반 구독을 가져오면서 출처를 알 수 없는 관리 프로파일을 설치할 필요는 없으며, 일반 프록시 연결을 위해 기기 전체의 관리 권한을 부여할 필요도 없습니다.

앱이 지원하는 범위에서 규칙 모드를 선택한 뒤 실제로 사용 중인 정책 그룹에서 노드를 고르세요. 페이지는 열리는데 특정 앱이 연결되지 않는다면 모든 네트워크 옵션을 바꾸기 전에 앱별 분할 설정이 있는지 확인하세요. iOS의 일부 앱은 기존 연결을 유지할 수 있으므로 정책을 바꾼 뒤 앱을 다시 열거나 연결을 다시 설정해야 새 출구가 적용될 수 있습니다. 테스트할 때는 캐시된 페이지와 새로 보낸 요청도 구분하세요.

화면 잠금과 네트워크 전환은 별도로 확인하세요

iOS의 VPN 네트워크 확장과 앱의 전면 화면은 수명 주기가 다르므로 Android의 백그라운드 잠금 방법을 그대로 적용할 수 없습니다. 백그라운드 실행을 시험하려고 앱을 반복해서 강제 종료하지 마세요. 앱에서 정상적으로 홈 화면으로 돌아간 뒤 화면을 잠그고, 다시 연결할 때 상태를 확인하세요. 저전력 모드, 네트워크 전환, 시스템 리소스 상태가 연결 복구에 영향을 줄 수 있습니다. 앱이 멀티태스킹 화면에 남아 있는지만 보지 말고 연결을 다시 설정해야 하는지 확인하세요.

Wi-Fi에서 모바일 데이터로 전환하면 기존 연결이 끊기고 다시 설정될 수 있습니다. 특정 Wi-Fi에서만 실패한다면 해당 네트워크의 인증 페이지와 접속 제한부터 확인하세요. 다른 VPN, 기기 관리 정책, 시스템 개인정보 보호 관련 네트워크 기능이 동시에 켜져 있다면 현재 상태를 기록한 뒤 하나씩 꺼서 충돌 여부를 확인하세요. 모든 문제를 노드 탓으로 돌리거나 비교 기준을 잃을 정도로 시스템 네트워크 설정을 한꺼번에 초기화하지 마세요.

구독 업데이트와 이전에 대비해 복구 경로 유지하기

구독을 업데이트하기 전에 기존 로컬 규칙이나 앱에서 지원하는 설정 백업을 보관하고, 업데이트 후 정책 그룹 이름과 선택이 바뀌지 않았는지 확인하세요. 노드가 삭제되거나 그룹 이름이 바뀌면 기존 선택이 무효가 될 수 있습니다. 휴대폰과 컴퓨터에서 같은 구독을 사용하더라도 구독 서비스의 기기 수와 동시 연결 조건을 따라야 합니다. 같은 링크를 가져올 수 있다고 해서 기기 수 제한 없이 동시에 연결할 수 있는 것은 아닙니다.

휴대폰을 바꾸면 앱을 다시 설치하고 구독을 다시 가져온 뒤 권한을 허용하는 것이 좋습니다. 시스템 백업이 VPN 상태까지 완전히 복원한다고 가정하지 마세요. 브라우저 접속, 자주 쓰는 앱, 화면 잠금, 모바일 데이터 테스트를 마친 다음 이전 기기의 설정을 정리하세요. 클라이언트별 차이는 모바일 Clash 클라이언트 비교에서 지원 범위를 확인하세요. 다른 앱의 조작 방법을 현재 화면의 고정된 경로로 여기지 마세요.

Linux: 데스크톱 프록시와 독립 코어 배포

데스크톱 클라이언트와 서버 코어 구분하기

Linux 다운로드에서는 데스크톱 환경에 적합한 Clash Verge Rev, FlClash 등의 GUI 클라이언트를 제공합니다. 독립형 mihomo 코어는 서버, 라우터, 서비스를 직접 관리해야 하는 환경에 더 적합합니다. 배포판, 패키지 형식, 프로세서 아키텍처를 확인한 뒤 설치 파일을 고르세요. Debian 계열과 RPM 패키지 관리자를 사용하는 배포판은 확장자가 비슷하다고 패키지를 혼용할 수 없으며 데스크톱 구성 요소의 의존성도 다를 수 있습니다.

데스크톱 사용자는 의존성과 제거 내역을 관리하기 쉽도록 패키지 관리자로 해당 클라이언트를 설치하는 것이 좋습니다. 실행한 뒤 설정 화면에서 URL 구독을 가져오고 활성화한 다음 정책 그룹과 규칙 모드를 확인하세요. 권한 문제를 피하려고 GUI 앱 전체를 관리자 계정으로 계속 실행하지 마세요. TUN에 필요한 특권 서비스는 클라이언트 문서에 따라 설치하고, 앱 화면 권한과 네트워크 인터페이스 권한을 따로 처리하세요.

시스템 프록시와 터미널 환경은 따로 설정해야 합니다

GNOME, KDE 등의 데스크톱 환경에는 각각 네트워크 프록시 설정이 있지만 모든 앱이 이를 따르지는 않습니다. 명령줄 프로그램은 환경 변수나 별도의 설정 파일을 사용하는 경우가 많고 컨테이너 안의 프로그램은 자체 네트워크 공간을 사용합니다. 클라이언트에서 시스템 프록시를 켰는데 터미널은 직접 연결되는 것도 흔한 상황이며, 반드시 코어 문제라는 뜻은 아닙니다. 먼저 프록시를 명시한 요청으로 수신 포트를 확인한 뒤 해당 프로그램의 프록시 설정을 살펴보세요.

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

아래 예시는 혼합 포트가 7890이라고 가정하므로 실제 설정에 맞춰야 합니다. 환경 변수는 이를 상속하는 프로세스에만 적용되며 이미 실행 중인 프로그램에는 자동으로 반영되지 않습니다. 도구마다 환경 변수 이름의 대소문자 처리도 다를 수 있습니다. 여기서는 현재 셸에서만 임시 설정하세요. 작동 여부를 확인한 뒤 로그인 설정에 저장할지 결정하면 됩니다. 클라이언트가 실행되지 않을 때 모든 유지보수 명령이 네트워크에 연결되지 않도록 프록시 변수를 시스템 전체 설정에 넣지 마세요.

독립형 코어는 포그라운드에서 테스트한 뒤 서비스로 관리하기

독립 배포 전에 실행 파일과 완전한 설정을 준비하고 권한이 명확한 디렉터리에 두세요. 아래에서는 프로그램이 /usr/local/bin/mihomo에, 설정 파일이 /etc/mihomo/config.yaml에 있다고 가정합니다. 먼저 구문을 검사한 다음 포그라운드에서 실행해 구독 참조, 로컬 규칙 파일, 수신 포트가 정상인지 확인하세요. 구문 검사 통과는 설정을 읽을 수 있다는 뜻일 뿐, 노드 연결이나 라우팅이 정상이라는 보장은 아닙니다.

/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

포그라운드에서 정상 작동하는 것을 확인한 뒤 배포판에 맞는 서비스 관리자를 사용하세요. systemd 서비스에는 프로그램 경로, 설정 디렉터리, 실행 사용자, 재시작 정책, 로그 확인 방법을 명시해야 합니다. 일반 로컬 프록시는 최소 권한으로 실행할 수 있습니다. TUN은 네트워크 인터페이스 생성과 라우팅 변경을 포함하므로 추가 권한 설계가 필요합니다. 출처를 알 수 없는 서비스 파일을 그대로 복사하지 말고, 다른 사용자가 읽을 수 있는 시작 매개변수에 구독 인증 정보를 넣지 마세요.

TUN, DNS, 컨테이너 네트워크의 경계

TUN을 켜기 전에 시스템에 TUN 장치가 있는지, 서비스 계정에 필요한 권한이 있는지 확인하세요. 자동 라우팅은 다른 VPN, 정책 라우팅, 컨테이너 브리지, 원격 관리 경로와 충돌할 수 있습니다. 원격 서버에서는 복구 방법을 특히 미리 준비하세요. 새 라우팅이 현재 SSH 관리 연결을 끊지 않는지 먼저 확인한 뒤 지속 설정을 적용하세요. 유일한 원격 세션에서 모든 트래픽을 가로채도록 시험한 직후 서비스를 재시작하지 마세요.

DNS는 NetworkManager, systemd-resolved 또는 다른 구성 요소가 관리하는 경우가 많습니다. /etc/resolv.conf를 언제든 영구적으로 직접 편집할 수 있는 일반 파일이라고 가정하지 마세요. 링크이거나 서비스가 생성한 파일일 수 있습니다. 기존 관리 경로를 먼저 확인한 뒤 클라이언트가 쿼리를 받는 방법, 상위 DNS로 전달되는 경로, 노드 서버 도메인 조회 방법을 정하세요. 컨테이너 안에서 루프백 주소는 컨테이너 자신을 가리키며 호스트의 프록시를 자동으로 가리키지 않습니다.

코어를 업데이트하기 전에 현재 프로그램과 설정을 저장하세요. 업데이트 후 테스트 명령을 실행하고 서비스를 다시 시작한 다음 시작 로그를 확인하세요. 필드 호환성 문제가 있다면 Clash, Meta, mihomo 코어 차이를 참고하세요. 오류가 난다고 필드를 무작정 전부 삭제하지 마세요. 로컬 요청, DNS, 원격 관리, 재부팅 후 복구까지 정상임을 확인해야 배포가 완료된 것입니다.

설정 FAQ: 다시 설치하지 말고 연결 경로를 따라 점검하기

구독 다운로드 실패와 설정 파싱 실패 구분하기

먼저 오류가 어느 단계에서 발생했는지 확인하세요. 연결 시간 초과, 도메인 조회 실패, 서버의 요청 거부는 구독을 가져오는 문제입니다. 들여쓰기, 필드 유형, 존재하지 않는 참조에 관한 오류라면 설정 파싱 문제입니다. 구독 주소가 웹페이지를 반환하면 클라이언트가 페이지 내용을 YAML로 파싱할 수 있어 오류 위치가 실제 문제와 무관할 수 있습니다. 첫 줄 오류의 들여쓰기만 고치지 말고 링크가 유효하며 예상한 형식의 응답을 반환하는지 확인하세요.

업데이트 후 갑자기 실패했다면 이전에 작동하던 설정을 보관하고 변경 범위를 비교하세요. 구독의 그룹 이름, 규칙 제공자, 프로토콜 필드가 바뀌었을 수 있으며 구형 코어가 지원하지 않을 수도 있습니다. 클라이언트의 설정 검사와 로그를 확인한 다음 클라이언트를 업데이트할지 호환되는 구독 형식으로 바꿀지 결정하세요. 서드파티 온라인 변환 서비스는 구독 내용을 볼 수 있습니다. 한 번의 가져오기 오류를 해결하려고 개인 링크를 불분명한 서비스에 넘기지 말고 정보 노출 범위를 먼저 확인하세요.

노드 테스트는 성공하는데 웹페이지가 열리지 않는 경우

‘앱 → 트래픽 처리 → 규칙 → 정책 그룹 → 노드 → 대상 사이트’ 순서로 확인하세요. 클라이언트에 연결 기록이 없다면 시스템 프록시, VPN 권한, 앱 제외 설정을 먼저 살펴보세요. 기록은 있는데 DIRECT로 연결된다면 적용된 규칙을 확인하고, 예상한 그룹에 연결됐는데 노드가 잘못 선택됐다면 그룹 내 선택을 살펴보세요. 출구가 올바른데도 실패하면 DNS, 핸드셰이크, 대상 서비스 제한을 확인합니다. 한 번에 조건을 하나씩 바꿔야 어떤 단계가 결과를 개선했는지 알 수 있습니다.

전역 모드는 규칙 문제를 잠시 구분하는 데 도움이 될 수 있지만 모든 문제의 최종 해결책으로 쓰면 안 됩니다. 테스트가 끝나면 원래 모드로 되돌리세요. 노드 지연 시간은 특정 테스트 요청의 결과로, 테스트 주소·시간 초과 설정·네트워크 상태에 영향을 받습니다. 단순한 다운로드 속도 순위로 볼 수 없습니다. 연속 속도 측정은 휴대폰 배터리를 더 소모할 수 있습니다. 자동 선택 정책이 필요하다면 url-test, fallback, load-balance의 차이를 먼저 이해한 다음 정책 그룹 설정 자세히 보기를 참고하세요.

사용자 지정 규칙이 적용되지 않는 이유

규칙은 보통 위에서 아래로 검사하므로 구체적인 규칙을 포괄적인 기본 규칙보다 앞에 배치해야 합니다. 정책 이름은 기존 정책 그룹 이름과 정확히 일치해야 하며 공백과 대소문자도 확인하세요. 아래 예시는 순서를 설명하는 일부 규칙으로, 사설 주소는 직접 연결하고 지정 도메인도 직접 연결한 뒤 마지막에 ‘수동 선택’을 사용합니다. 해당 정책 그룹이 이미 있어야 합니다. 참조 대상 그룹을 만들지 않고 규칙만 복사하면 작동하지 않습니다.

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,수동 선택

클라이언트에서 구독 재정의, 규칙 우선 적용, 설정 병합을 사용한다면 다운로드 캐시만 수정하지 말고 지속적으로 보관되는 재정의 설정을 편집하세요. 그렇지 않으면 구독 업데이트 때 수정 사항이 덮어써집니다. 규칙이 맞아 보이는데 적용되지 않는다면 요청이 도메인 이름과 IP 중 무엇을 사용하는지, 설정 변경 전에 연결이 이미 시작됐는지, 화면에 원본 파일과 최종 실행 설정 중 어느 쪽이 표시되는지도 확인하세요. 구독을 반복해서 새로 고치는 것보다 최종 설정을 비교하는 편이 효과적입니다.

DNS 실패, IPv6, LAN 문제

DNS는 도메인을 IP 주소로 변환하는 과정이며, 조회에 성공해도 연결은 실패할 수 있습니다. 노드 서버 도메인과 대상 웹사이트 도메인을 구분하세요. 앞의 도메인 조회에 실패하면 프록시 출구 자체를 만들 수 없습니다. Fake-IP를 사용하는 경우 내부 매핑을 위한 주소가 표시될 수 있는데, 이것이 반드시 오류는 아닙니다. 다만 해당 연결이 같은 처리 경로를 계속 거쳐야 합니다. 호환 문제가 있다면 설정을 이해한 뒤 특정 도메인만 제외하세요. 주소 범위 전체를 함부로 바꾸지 마세요.

IPv6도 경로 전체를 확인해야 합니다. 시스템이 주소를 받았는지, DNS가 해당 레코드를 반환하는지, 클라이언트가 트래픽을 처리하는지, 노드가 IPv6 출구를 지원하는지 살펴보세요. 문제 범위를 좁히기 위해 특정 옵션을 끌 수는 있지만 모든 네트워크에서 IPv6를 꺼야 한다는 뜻은 아닙니다. LAN 문제는 라우팅과 직접 연결 규칙부터 확인한 뒤 검색 프로토콜과 이름 조회를 살펴보세요. 프록시 오류, 인증서 오류, LAN 검색 실패를 모두 같은 ‘연결 안 됨’ 문제로 묶지 마세요.

백업, 복구, 문의 시 필요한 정보

신뢰할 수 있는 백업에는 구독 출처, 로컬 재정의 설정, 필요한 규칙 파일, 클라이언트 설정 안내가 포함되어야 합니다. 민감 정보는 별도로 보호하세요. 복구할 때는 가장 최근의 정상 상태를 되돌린 뒤 변경 사항을 하나씩 재현하세요. 클라이언트, 구독, DNS를 동시에 바꾸지 마세요. 문의할 때는 운영체제, 클라이언트 이름, 트래픽 처리 방식, 오류가 발생한 단계, 민감 정보를 가린 로그를 제공하세요. 문제를 찾는 동안에만 상세 로그를 켜고 확인이 끝나면 일반 수준으로 되돌려 불필요한 접속 정보가 오래 기록되지 않도록 하세요.

문제가 특정 설정 하나로 좁혀졌다면 FAQ를 확인하세요. 용어가 기억나지 않는다면 용어집을, 처음부터 순서대로 연결을 다시 설정하려면 빠른 시작 가이드를 참고하세요. 이 안내서의 기본 원칙은 작동하는 상태를 먼저 저장하고 연결 경로를 단계별로 확인하는 것입니다. 요청이 어느 단계에서 멈추는지 알면 앱을 반복해서 삭제하고 설치하지 않아도 문제를 해결할 수 있습니다.