Clash 전체 플랫폼 설정
이 페이지에서는 운영체제별 다운로드, 설치, 구독 가져오기와 트래픽 연결 과정을 정리했습니다. 기기 변경, TUN 설정, 플랫폼별 차이를 확인할 때 참고하세요. 처음 사용한다면 사용 가이드를 따라 기본 설정을 마친 뒤, 해당 장에서 권한, 서비스 시작, DNS를 확인하세요. 클라이언트마다 메뉴 이름은 다를 수 있으므로, 메뉴 문구가 아니라 설정의 실제 기능을 기준으로 안내합니다.
권장 순서: 먼저 공통 준비 사항을 확인한 다음 기기에 맞는 장을 살펴보세요. 문제가 생기면 로그를 보관하고 마지막 장의 점검 순서에 따라 원인을 좁혀 가세요.
공통 준비 및 설정 시 유의 사항
클라이언트, 코어, 구독의 차이
Clash 생태계에서 GUI 클라이언트는 설정을 표시하고 실행을 관리하며 시스템 프록시를 설정합니다. 코어는 포트를 열고 규칙을 해석해 연결을 구성합니다. 구독은 서버 정보, 정책 그룹 및 기타 설정을 제공합니다. 이 셋은 서로 다른 요소입니다. 클라이언트를 설치해도 사용할 수 있는 구독이 자동으로 생기지 않으며, 링크를 가져왔다고 코어가 정상적으로 설정을 불러온 것도 아닙니다. 문제를 해결할 때는 프로그램 실행 여부, 설정 해석 여부, 연결이 코어에 전달되는지, 대상 서버로 나가는 경로가 정상인지 각각 확인하세요.
설치 파일을 고르기 전에 시스템 정보에서 운영체제, 프로세서 아키텍처, 현재 사용자 권한을 확인하세요. 이 사이트에서는 지원 플랫폼에 Clash Plus를 우선 제공합니다. 자세한 선택지는 클라이언트 설치 파일에서 확인할 수 있습니다. 클라이언트마다 코어 설정 항목, 시스템 서비스, 가져오기 방식의 지원 범위가 다르므로 확장자가 같다는 이유만으로 설정 호환성을 단정하지 마세요. 유지 관리가 중단된 보관용 클라이언트는 구형 환경을 재현할 때 적합하며, 새 기기에서 처음 사용할 앱으로는 권장하지 않습니다.
설정 출처를 보관하고 인증 정보 노출을 줄이세요
구독 주소에는 계정을 식별할 수 있는 정보가 포함되는 경우가 많으므로 인증 정보처럼 취급해야 합니다. 복사할 때 줄바꿈, 메신저가 덧붙인 문구, 끝의 문장 부호가 섞이지 않았는지 확인하세요. 전체 주소를 스크린샷, 문의 내역, 공개 로그에 노출하지 마세요. 브라우저에서 링크가 열리더라도 브라우저의 네트워크 경로, 요청 헤더, 인증서 환경에서만 요청이 성공했을 수 있습니다. 형식이 지원되지 않는다면 제공자에게 Clash 또는 대상 코어에 맞는 설정 형식인지 먼저 확인하세요.
처음 가져오기 전에 기존 설정을 복사해 두고 현재 선택된 설정 이름을 기록하세요. 원격 구독을 업데이트하면 내려받은 내용이 덮어써질 수 있으므로, 장기간 유지할 사용자 규칙은 클라이언트가 공식 지원하는 덮어쓰기, 병합 또는 확장 설정에 두는 편이 좋습니다. 제품마다 병합 순서가 다르므로 저장 후 실제 적용된 설정을 확인하세요. 기기 간에 복사할 때는 필요한 항목만 옮기고 경로, 네트워크 인터페이스 이름, 로컬 수신 주소는 새 기기에서 다시 확인하세요.
최소한의 연결부터 확인하세요
먼저 규칙 모드를 사용하고, 작동하는 정책 그룹을 선택한 뒤 트래픽 연결 방식을 하나만 활성화하는 것이 좋습니다. 데스크톱에서는 시스템 프록시부터 테스트하고, 모바일에서는 대개 클라이언트가 시스템 VPN 터널을 만듭니다. TUN은 더 많은 앱의 네트워크 연결을 처리하지만 가상 네트워크 인터페이스, 라우팅, DNS라는 변수가 추가됩니다. 처음부터 여러 클라이언트, 전역 모드, TUN을 함께 켜면 로그에서 원인을 찾기 어렵고 중복 라우팅이 남을 수 있습니다.
| 항목 | 기능 | 먼저 확인할 사항 |
|---|---|---|
| 시스템 프록시 | 시스템 설정을 따르는 앱에 프록시 주소 제공 | 로컬 수신 포트가 시스템 설정과 일치하는지 |
| TUN/시스템 터널 | 가상 인터페이스 또는 시스템 네트워크 확장으로 트래픽 수신 | 권한, 라우팅, DNS 설정 |
| 규칙 모드 | 설정 규칙에 따라 연결 경로 선택 | 규칙 적용 순서 및 정책 그룹 이름 |
| 구독 업데이트 | 원격 설정을 다시 가져오기 | 업데이트 대상과 현재 설정이 같은지 |
아래는 로컬 수신 설정을 이해하기 위한 예시이며 서버 정보는 포함하지 않습니다. 이 내용만으로는 프록시 연결을 구성할 수 없습니다. 포트 번호는 정해져 있지 않으며, 다른 서비스가 사용하지 않고 호출 측 설정과 일치하면 됩니다. 기존 설정에 해당 항목이 있다면 같은 키를 중복 추가하지 말고 기존 값을 수정하세요.
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
혼합 포트는 HTTP와 SOCKS 요청을 모두 받을 수 있습니다. LAN 연결 허용 여부는 다른 기기의 접근을 결정하고, 로컬 바인딩 주소는 수신 범위를 추가로 제한합니다. 인증을 설정하지 않았다면 로컬 기기에서만 연결하도록 두어 네트워크에 포트가 노출되지 않게 하세요. 시스템 시간도 먼저 동기화해야 합니다. 시간 차이가 크면 암호화 핸드셰이크나 인증서 확인이 실패할 수 있습니다. 준비가 끝나면 설정을 한 번에 하나씩 바꾸고 바로 테스트한 뒤 새 로그를 확인하세요. 여러 항목을 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.
Windows 설치 및 트래픽 연결
설치 파일 선택 및 첫 실행
시스템 설정의 ‘시스템 정보’에서 프로세서 아키텍처를 확인한 다음 Windows 설치 파일에서 기기에 맞는 클라이언트를 선택하세요. Clash Plus를 우선 고려하고, 필요한 기능에 따라 Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 선택할 수 있습니다. Clash for Windows는 유지 관리가 중단된 보관용 클라이언트입니다. 다른 아키텍처의 파일을 이름만 바꿔 호환 버전처럼 사용하지 마세요. 압축을 푼 폴더를 온전히 유지하지 않은 채 실행 파일만 따로 옮기는 것도 피하세요.
설치 프로그램을 실행할 때는 시스템에 표시되는 파일 출처와 게시자 정보를 먼저 확인하세요. 파일 이름만으로 보안 경고의 타당성을 판단할 수 없습니다. 이상한 점이 있으면 설치를 중단하고 다운로드 출처를 확인하세요. 시스템 보호 기능을 바로 끄지 마세요. 설치 후에는 일반 사용자 권한으로 먼저 실행해 트레이 아이콘, 설정 화면, 로그가 열리는지 확인하세요. 서비스 설치, 가상 네트워크 인터페이스 활성화, 보호된 설정 변경이 필요할 때만 클라이언트 안내에 따라 권한을 높이세요. 항상 관리자 권한으로 실행할 필요는 없습니다.
구독 가져오기 및 현재 설정 확인
설정 관리 화면에서 링크 가져오기를 선택하고 전체 구독 주소를 붙여넣어 저장하세요. 다운로드가 끝나면 해당 설정을 직접 선택하고, 해석 오류가 없는지 확인한 뒤 프록시 또는 정책 그룹 화면에서 연결 경로를 선택하세요. 일부 클라이언트는 ‘설정 다운로드’와 ‘설정 활성화’를 별도 단계로 처리합니다. 목록에 파일이 있다고 해서 코어가 그 설정을 사용 중인 것은 아닙니다. 제공자가 로컬 파일을 전달했다면 파일 가져오기 메뉴를 사용하세요. 파일 경로를 구독 URL 입력란에 붙여넣지 마세요.
가져오기에 실패하면 연결 실패, 응답 형식 오류, 지원하지 않는 항목 중 무엇인지 먼저 확인하세요. 웹페이지에서 로그인 화면이 반환되면 클라이언트가 설정 대신 HTML을 받았을 수 있습니다. 알 수 없는 항목이라는 오류가 나오면 구독이 현재 코어를 대상으로 하는지 확인하세요. 오류를 없애려고 이해하지 못하는 항목을 모두 삭제하지 말고 원본 파일을 보관하세요. 설정이 정상적으로 불러와지면 이름과 정책 그룹 선택을 기록한 뒤 업데이트를 테스트해 다른 설정으로 바뀌지 않았는지 확인하세요.
시스템 프록시, UWP 루프백, TUN
클라이언트에서 시스템 프록시를 켠 뒤 Windows 프록시 설정이 클라이언트의 실제 로컬 주소와 수신 포트를 가리키는지 확인하세요. 브라우저에 프록시 확장 프로그램이 있으면 시스템 설정을 덮어쓸 수 있으므로 테스트 중에는 경로를 하나로 통일하세요. 명령줄 프로그램은 시스템 프록시를 따르지 않을 수 있습니다. 명시적 프록시 요청으로 테스트하면 앱이 연결 대상에서 빠진 문제와 연결 경로 문제를 구분할 수 있습니다. 아래 포트는 설정 화면에 표시된 실제 값으로 바꾸세요. 테스트 주소도 문제가 발생한 사이트로 변경할 수 있습니다.
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com
브라우저는 접속되지만 일부 스토어 앱이 연결되지 않는다면 UWP 앱의 로컬 루프백 주소 접근 제한이 원인일 수 있습니다. 실제로 필요한 앱에 대해서만 루프백 권한을 확인하고, 가능하면 클라이언트의 관리 기능을 사용하세요. 모든 앱의 접근을 일괄 허용하지 마세요. 현재 환경에 TUN이 적합한지 검토할 수도 있지만, TUN을 켜도 구독 유효성이나 규칙 적용 여부 확인을 대신할 수는 없습니다. 조직 정책으로 관리되는 기기라면 해당 관리 기준을 따르세요.
TUN을 처음 켤 때 서비스 설치나 가상 네트워크 인터페이스 생성이 필요할 수 있습니다. 시스템 프록시 테스트가 성공한 것을 확인한 다음 TUN을 켜고, 로그에서 인터페이스 생성, 라우팅 설정, 권한 오류를 확인하세요. 방화벽 알림은 실제 네트워크 범위에 맞게 허용하세요. 로컬에서만 사용할 경우 공용 네트워크의 인바운드 연결을 허용할 필요가 없습니다. 다른 VPN, 보안 소프트웨어의 네트워크 필터, 오래된 가상 네트워크 인터페이스가 라우팅에 영향을 줄 수 있습니다. 문제를 확인할 때는 클라이언트를 반복 설치하는 대신 중복으로 트래픽을 가로채는 기능부터 중지하세요.
자동 실행 및 종료 후 복구
‘자동 실행’은 보통 사용자가 로그인한 뒤 클라이언트 화면을 시작한다는 뜻입니다. ‘서비스 모드’에서는 화면과 별개로 코어가 실행될 수 있으므로 두 기능을 혼동하지 마세요. 사용할 수 있는 구독을 먼저 설정하고 자동 실행을 켠 뒤, 재부팅 후 해당 설정이 자동 선택되는지 확인하세요. 시작 직후 인터넷이 잠시 끊긴다면 네트워크 연결 준비 시간, 서비스 권한, 구독 다운로드에 온라인 연결이 필요한지 확인하세요. 작업 스케줄러와 클라이언트 설정에 시작 작업을 중복 등록하지 마세요.
더 자세한 설치 방법과 예외 사항은 Windows 방화벽, UWP 루프백, TUN 문제 해결을 참고하세요. 문제가 발생했을 때의 네트워크 유형, 권한, 트래픽 연결 방식을 기록해 두면 ‘연결이 안 된다’는 설명만으로는 알기 어려운 원인을 찾는 데 도움이 됩니다.
macOS 설치 및 네트워크 권한
칩 종류와 앱 출처 확인
Apple 메뉴의 ‘이 Mac에 관하여’에서 칩 종류를 확인하고 macOS 설치 파일에서 Apple Silicon 또는 Intel에 맞는 파일을 선택하세요. Clash Plus를 우선 고려하고 Clash Verge Rev 또는 FlClash도 사용할 수 있습니다. ClashX Meta는 유지 관리가 중단된 보관용 클라이언트입니다. 호환성 기능으로 다른 아키텍처의 프로그램을 실행할 수 있더라도 기기에 맞는 설치 파일을 우선 사용하세요. 추가 호환 계층으로 인한 실행 및 권한 문제를 줄일 수 있습니다.
디스크 이미지 파일을 연 뒤 앱을 응용 프로그램 폴더로 옮기고 그 위치에서 실행하세요. 마운트된 설치 이미지에서 계속 실행하지 마세요. 처음 실행할 때 표시되는 보안 안내는 다운로드 출처와 시스템 정보를 함께 확인해 판단하세요. 파일이 손상되었거나 출처가 비정상이라는 메시지가 나오면 기기에 맞는 설치 파일을 다시 받고 시스템 호환성을 확인하세요. 온라인에서 출처가 불분명한 제한 해제 명령을 바로 실행하지 마세요. 보조 서비스를 설치해야 한다면 표시된 확인 창이 현재 작업에서 나온 것이 맞는지 확인하세요.
설정 가져오기 및 네트워크 서비스 구분
설정 화면에 구독 링크를 붙여넣고 다운로드가 끝나면 해당 설정을 선택한 뒤 로그에서 해석 결과를 확인하세요. 브라우저에서 앱으로 가져올 때는 링크를 처리하는 앱이 맞는지 확인하세요. 여러 클라이언트가 설치되어 있으면 링크 연결이 오래된 프로그램으로 지정될 수 있습니다. 앱이 열리지 않으면 클라이언트로 돌아가 링크를 직접 붙여넣으세요. 인증 정보가 포함된 링크를 외부 변환 사이트에 보내지 마세요. 가져오기에 성공하면 규칙 모드와 실제로 사용할 수 있는 정책 그룹을 선택하고 브라우저로 간단히 테스트하세요.
macOS 시스템 프록시 설정은 현재 네트워크 서비스와 연결됩니다. 무선 네트워크, 유선 어댑터 및 다른 네트워크 서비스마다 설정이 다를 수 있습니다. 네트워크를 바꾼 뒤 접속에 문제가 생기면 현재 활성화된 서비스가 클라이언트의 로컬 수신 포트를 사용 중인지 확인하세요. 자동 프록시 구성 스크립트와 수동 웹 프록시는 서로 다른 경로를 만들 수 있으므로 실제로 어느 쪽이 활성화되어 있는지 확인해야 합니다. 아래 명령은 상태를 조회할 뿐 시스템 설정을 변경하지 않습니다. 서비스 이름이 반드시 Wi-Fi인 것은 아니므로 먼저 기기에 등록된 실제 이름을 확인하세요.
networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"
출력된 활성화 상태, 서버 주소, 포트가 클라이언트 설정과 일치해야 합니다. 클라이언트를 종료한 뒤에도 로컬 포트를 가리키면 시스템 요청이 더는 실행 중이 아닌 서비스로 전송됩니다. 복구하려면 시스템 네트워크 설정에서 해당 프록시 항목을 끄고 자동 프록시 설정도 활성화되어 있는지 확인하세요. 현재 상태를 모른 채 네트워크 서비스를 변경하는 명령을 연달아 실행하지 마세요. 무선 네트워크만 복구하고 유선 네트워크를 놓칠 수 있습니다.
TUN, 보조 서비스, DNS
TUN은 클라이언트와 코어에 따라 구현 방식이 다릅니다. 일부는 특권 보조 서비스로 라우팅을 조정하고, 일부는 시스템 네트워크 확장 권한이 필요합니다. 사용 중인 클라이언트의 안내에 따라 권한을 부여하세요. 메뉴의 스위치가 켜져 있어도 로그에서 인터페이스와 라우팅이 실제로 설정되었는지 확인해야 합니다. 시스템을 업그레이드하거나 앱 위치를 옮긴 뒤에는 기존 서비스의 복구 또는 재인증이 필요할 수 있습니다. 클라이언트의 서비스 관리 기능을 이용하고 소유자를 알 수 없는 시스템 파일을 직접 삭제하지 마세요.
TUN을 켠 뒤 회사 내부 도메인만 접속되지 않는다면 노드 전체가 작동하지 않는 것이 아니라 분할 DNS 또는 기업 VPN 라우팅이 원인일 수 있습니다. 접속에 실패한 도메인, 연결 중인 네트워크 서비스, 적용된 규칙을 기록하고 클라이언트가 기존 DNS 경로를 덮어쓰는지 확인하세요. 사내 DNS가 필요한 환경에서는 해당 도메인이 올바른 DNS를 사용하도록 설정해야 합니다. 모든 DNS 요청을 하나의 공용 DNS 서버로 보내는 방식은 적절하지 않습니다. 조치 후에는 사내망과 공용 인터넷을 각각 테스트해 한쪽만 정상화된 것은 아닌지 확인하세요.
시스템 프록시는 시스템 설정을 따르는 프로그램에 주로 영향을 줍니다. 터미널 도구는 프록시를 명시하거나 환경 변수를 설정해야 할 수 있습니다. 환경 변수는 이를 상속하는 프로세스에만 적용되며 전체 시스템의 트래픽을 처리하지는 않습니다. 터미널은 되지만 브라우저가 안 되면 브라우저 확장 프로그램, 캐시, 시스템 네트워크 서비스를 확인하세요. 두 곳 모두 안 되면 클라이언트 로그와 현재 정책 그룹을 확인하세요. 프록시 아이콘 표시만으로 연결 여부를 판단하지 말고 실제 요청을 테스트하세요.
로그인 시 실행, 잠자기, 네트워크 전환
로그인 후 자동 실행이 필요하다면 클라이언트의 시작 옵션을 사용하고 시스템 로그인 항목에서 비활성화되어 있지 않은지 확인하세요. 보조 서비스 실행과 메뉴 막대에 앱이 표시되는 것은 별개입니다. 창을 닫아도 코어가 계속 실행될 수 있습니다. 잠자기에서 깨어나거나 핫스팟을 전환하거나 유선 어댑터를 다시 연결한 뒤에는 인터페이스 이름과 기본 경로가 바뀔 수 있습니다. 먼저 현재 트래픽 연결 방식을 껐다가 다시 켜서 라우팅이 설정되는지 확인하고, 구독을 바로 덮어쓰지는 마세요.
다른 Mac으로 옮길 때 설정을 내보낼 수 있지만 서비스 권한을 다시 부여하고 로컬 파일 경로를 확인한 뒤 정책 그룹을 다시 선택해야 합니다. 개인 인증서, 조직 네트워크 설정, 시스템 키체인 정보는 일반 구독 파일로 전송하지 마세요. 안정적으로 작동하는 것을 확인한 뒤 자동 업데이트, 자동 실행, 기타 확장 설정을 하나씩 복구하세요. 정상 연결 시의 로그 특성을 보관해 두면 문제가 발생했을 때 비교하기 편리합니다.
Android 설치 및 백그라운드 연결
아키텍처에 맞는 앱 설치 및 권한 설정
Android 설치 파일에서는 Clash Plus를 우선 고려하세요. 다른 선택지로 Clash Meta for Android, FlClash, Surfboard가 있습니다. 앱마다 지원하는 설정 형식과 프로토콜이 다르므로 한 앱에서 구독 가져오기에 실패했다고 해서 곧바로 휴대폰 문제라고 단정하지 마세요. 제공자가 지원하는 형식을 확인한 뒤 클라이언트를 선택하세요. 기기에 맞는 아키텍처의 설치 파일을 사용해야 합니다. 구형 기기나 특수한 기기는 시스템 정보를 기준으로 확인하고 휴대폰 브랜드만 보고 선택하지 마세요.
브라우저나 파일 관리자에서 설치 파일을 열면 해당 출처의 앱 설치를 허용하라는 메시지가 표시될 수 있습니다. 필요한 출처에만 권한을 부여하고 설치가 끝난 뒤에는 기기 정책에 따라 해제할 수 있습니다. 기존 앱과 서명이 충돌한다는 안내가 나오면 바로 덮어쓸 수 없는 경우가 많습니다. 필요한 설정을 내보내고 새 앱과 기존 앱의 출처 및 패키지 이름을 확인한 뒤 제거 여부를 결정하세요. 앱을 제거하면 설정, 로그, 권한이 사라질 수 있으므로 비용 없이 시도할 수 있는 첫 번째 문제 해결 방법으로 여기면 안 됩니다.
구독 가져오기 및 시스템 터널 연결
클라이언트의 설정 또는 구독 관리 화면에서 원격 링크를 추가하고 저장한 뒤 업데이트를 실행하세요. 이후 해당 설정을 현재 설정으로 선택합니다. 알아보기 쉬운 로컬 이름을 지정하되 인증 정보 전체를 이름에 넣지 마세요. 로컬 파일을 가져올 때는 시스템 파일 선택기에서 접근 권한을 부여하면 됩니다. 파일이 다운로드 폴더에 있어도 클라이언트에 자동으로 읽기 권한이 생기는 것은 아닙니다. 가져온 뒤 정책 그룹이 정상적으로 표시되는지, 지원하지 않는 항목 오류가 있는지 확인하세요.
시작을 누르면 Android에서 시스템 VPN 연결 요청이 표시되는 경우가 많습니다. 이 VPN 권한은 클라이언트가 기기 트래픽을 받도록 허용하는 기능이며, 원격 연결 경로를 시스템이 자동으로 제공한다는 뜻은 아닙니다. 방금 실행한 앱에서 요청한 것이 맞는지 확인한 다음 허용하세요. 일반적인 사용 환경에서는 시스템 VPN 연결을 한 번에 하나만 사용할 수 있습니다. 다른 VPN, 방화벽, 같은 방식을 사용하는 필터링 앱이 서로 연결을 대체할 수 있으므로 전환할 때는 어느 앱을 중지할지 먼저 확인하세요.
모바일의 시스템 터널은 데스크톱에서 ‘시스템 프록시 설정’을 켜는 것과 다릅니다. 무선 네트워크의 고급 설정에 같은 로컬 프록시를 다시 입력할 필요가 없습니다. Wi-Fi의 수동 HTTP 프록시는 일부 앱과 현재 네트워크에만 적용되는 경우가 많으며, 중복 설정하면 트래픽이 잘못된 포트로 전달될 수 있습니다. 먼저 연결 경로를 하나만 유지하고 브라우저와 대상 앱의 연결 로그가 남는지 확인한 뒤 앱별 분할 연결이나 LAN 서비스를 검토하세요.
앱별 연결 설정 및 백그라운드 제한
클라이언트에서 앱별 선택 기능을 제공한다면 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱은 우회’인지 먼저 확인하세요. 두 모드에서 같은 앱을 선택해도 의미가 정반대입니다. 앱 목록은 트래픽을 터널에 넣을지 결정하고, 도메인 및 주소 규칙은 터널에 들어간 트래픽의 연결 경로를 결정합니다. 두 설정은 분리해서 확인해야 합니다. 로그에 대상 앱의 요청이 전혀 없다면 도메인 규칙을 추가하기보다 먼저 앱 목록을 확인하세요.
화면을 잠근 뒤 연결이 끊기는 문제는 시스템 배터리 관리와 관련된 경우가 많습니다. 먼저 클라이언트의 포그라운드 서비스 알림이 표시되는지 확인하고, 기기의 배터리 설정에서 해당 앱의 백그라운드 실행이 제한되어 있는지 살펴보세요. 제조사마다 자동 실행, 백그라운드 활동, 절전 정책의 이름이 다릅니다. 현재 앱에 관련된 항목만 조정하고 기기의 절전 기능을 전부 끄지 마세요. 화면이 켜져 있을 때, 잠금 상태일 때, 오래 대기한 뒤의 연결을 각각 확인하세요.
‘VPN 항상 사용’과 ‘VPN 없이 연결 차단’은 시스템 수준의 정책입니다. 후자를 켜면 클라이언트가 아직 시작되지 않았거나 설정이 유효하지 않을 때 다른 네트워크 연결도 차단될 수 있습니다. 작동 방식을 이해하고 재부팅 테스트를 마친 뒤에만 활성화하세요. 클라이언트의 자동 재연결 옵션은 시스템 수준의 연결 차단 정책과 작동 시점이 다릅니다. 강제 연결 정책을 해제할 때는 앱 안의 스위치만 끄지 말고 시스템 설정도 복구되었는지 확인하세요.
DNS, 비공개 DNS, 핫스팟 사용 범위
Android 비공개 DNS, 클라이언트 DNS, 앱 자체의 암호화 DNS가 동시에 작동할 수 있습니다. 도메인 접속에 문제가 생기면 현재 설정을 기록한 다음 하나씩 바꿔 비교 테스트하세요. 설정을 한꺼번에 변경하지 마세요. 일부 앱은 DNS 캐시나 장시간 연결을 재사용하므로 DNS를 바꾼 뒤에는 새 요청을 보내야 차이를 확인할 수 있습니다. IP 주소에 접속할 수 있다고 해서 모든 DNS 기능을 계속 꺼야 한다는 뜻은 아닙니다.
휴대폰의 VPN은 핫스팟에 연결된 다른 기기의 트래픽까지 자동으로 처리하지 않습니다. 컴퓨터에서 휴대폰의 프록시를 사용하려면 클라이언트가 LAN 수신을 명시적으로 지원해야 하며, 연결 가능한 주소, 인증, 방화벽도 설정해야 합니다. 이는 핫스팟을 켜는 것과는 별개입니다. 일반적인 모바일 사용에서는 LAN 접근을 꺼 두는 편이 좋습니다. 모바일 데이터에서는 구독 업데이트가 실패하고 Wi-Fi에서는 성공한다면 데이터 사용 권한, 네트워크 제한, 제공자 접속 가능성을 추가로 확인하세요. 네트워크 차이를 설정 손상으로 오해하지 않도록 주의하세요.
iOS 설치 및 터널 설정
스토어에서 Clash Plus 설치
iPhone과 iPad에서는 Clash Plus를 사용할 수 있습니다. 설치 방법은 iOS 클라이언트에서 확인하거나 App Store의 Clash Plus를 바로 여세요. 제품 공식 사이트는 clashplus.io입니다. 설치 전에 스토어 페이지에서 시스템 호환 정보를 확인하고 기기에 표시되는 안내를 기준으로 판단하세요. 다른 플랫폼의 설치 파일을 모바일 기기에 가져오지 마세요. 구독을 사용하기 위해 출처가 불분명한 기기 관리 프로파일을 설치할 필요는 없습니다.
처음 앱을 열면 설정 화면, 프록시 모드, 연결 스위치부터 확인하세요. 알림 권한과 네트워크 터널 권한은 용도가 다릅니다. 알림 권한은 상태나 알림을 표시하는 데 사용하고, 터널을 만들려면 시스템에서 VPN 설정을 승인해야 합니다. 학교나 조직에서 관리하는 기기라면 네트워크 기능이 정책에 따라 제한될 수 있으므로 허용 범위를 먼저 확인하세요. 앱 설치가 끝났다고 바로 사용할 수 있는 설정이 생기는 것은 아닙니다. 구독을 가져온 뒤 올바른 연결 경로를 선택해야 합니다.
링크 가져오기 및 설정 출처 확인
제공자가 전달한 전체 구독 주소를 복사하고 클라이언트에서 링크로 설정을 추가한 다음 로컬 이름을 지정해 저장하세요. 클립보드 접근 권한이 표시되면 붙여넣기 작업이 맞는지 확인하면 됩니다. 브라우저의 빠른 가져오기는 앱 연결 기능을 사용합니다. 앱으로 이동하지 않으면 클라이언트로 돌아가 직접 추가하세요. 같은 링크를 반복해서 열어 구분하기 어려운 설정을 여러 개 만들 필요는 없습니다. 계정 정보가 포함된 구독 주소를 공개 메모나 공유 스크린샷에 저장하지 마세요.
업데이트가 완료되면 해당 설정을 선택한 뒤 정책 그룹을 확인하세요. 가져온 뒤 목록이 비어 있다면 다운로드가 실제로 성공했는지, 응답 내용이 설정인지, 클라이언트가 해당 형식을 지원하는지 확인하세요. 구독의 노드 정보와 규칙이 한 파일에 들어 있을 수도 있고 클라이언트가 지원하는 다른 구조로 분리되어 있을 수도 있습니다. 파일 크기만으로 완전성을 판단할 수는 없습니다. 직접 수정하기 전에 사본을 저장해 두어 들여쓰기나 그룹 이름이 손상되지 않게 하세요.
VPN 설정 허용 및 규칙 확인
처음 연결할 때 시스템에서 VPN 설정 추가를 허용하라는 메시지가 표시될 수 있으며, 기기 암호나 다른 확인 절차가 필요할 수 있습니다. 권한을 부여한 뒤 앱으로 돌아가 연결 상태를 확인하고 브라우저에서 새 요청을 보내세요. 상태 막대에 VPN 표시가 있으면 시스템 터널이 만들어졌다는 뜻이지만, 원격 서버가 정상이라는 뜻은 아니며 모든 요청이 같은 연결 경로를 사용한다는 뜻도 아닙니다. 규칙 모드에서는 일부 도메인이 직접 연결될 수 있으므로 테스트할 때 적용된 규칙과 정책 그룹을 함께 확인하세요.
iOS 클라이언트는 대개 시스템 네트워크 확장 기능으로 트래픽을 받으며 데스크톱의 HTTP 프록시 설정과는 다릅니다. Wi-Fi 세부 설정의 수동 프록시는 별도의 연결 경로이므로 클라이언트를 실행하기 위해 추가로 입력할 필요가 없는 경우가 많습니다. 기기에 다른 VPN 설정이 있다면 현재 어떤 설정이 활성화되어 있는지 확인하세요. 여러 앱 사이에서 반복 전환하면 시스템의 활성 설정이 바뀔 수 있습니다. 문제를 확인하는 동안에는 클라이언트 하나만 실행해 설정 간섭을 줄이세요.
규칙 적용 여부는 이번 연결의 로그를 기준으로 판단하세요. 앱이 기존 연결을 재사용하면 규칙을 바꾼 뒤 원래 페이지를 새로 표시해도 규칙이 다시 적용되지 않을 수 있습니다. 대상 페이지를 닫고 다시 열거나 필요하면 앱을 재시작하세요. 도메인 하나를 확인하려고 기기 전체의 네트워크 설정을 반복해서 초기화하지 마세요. 규칙이 존재하지 않는 정책 그룹을 참조한다면 그룹 이름이나 구독 호환성을 수정하세요. 오류를 감추려고 모든 요청을 영구적으로 전역 모드에 두지 마세요.
백그라운드 실행 및 요청 시 연결
시스템 터널과 앱 화면은 서로 다른 생명 주기로 작동합니다. 다른 앱으로 전환해도 연결이 끊기지 않을 수 있고, 반대로 화면을 강제 종료했다고 해서 터널이 꺼졌다고 단정할 수도 없습니다. 연결을 중지하려면 클라이언트의 연결 스위치를 사용하고 시스템 VPN 상태에서도 확인하세요. 요청 시 연결 기능을 지원한다면 작동 조건을 먼저 읽고 Wi-Fi와 모바일 데이터에서 각각 테스트해 자동 시작, 네트워크 전환 후 재연결, 특정 네트워크 예외 여부를 확인하세요.
화면 잠금을 해제한 뒤 특정 앱이 잠시 로드되지 않으면 새 요청을 보내고 로그를 확인해 기존 연결만 끊긴 것인지 터널 자체가 계속 작동하지 않는 것인지 구분하세요. 배터리 부족, 네트워크 전환, 대상 서비스의 세션 제한도 영향을 줄 수 있으므로 한 번 재연결됐다는 이유만으로 원인을 단정하지 마세요. 네트워크 환경이 바뀌면 구독에 표시된 서버에 접속할 수 있는지도 달라질 수 있습니다. 현재 네트워크에서 직접 테스트하고 다른 네트워크의 결과를 그대로 적용하지 마세요.
기기 변경 및 설정 업데이트
기기를 바꾼 뒤에는 시스템 VPN 권한, 현재 설정, 정책 그룹 선택을 다시 확인해야 합니다. 기기 백업으로 모든 연결 권한이 복원된다고 가정하지 마세요. 설정 파일을 내보내기 전에 구독 인증 정보와 서버 비밀번호가 포함되어 있는지 확인하고 신뢰할 수 있는 경로로만 전송하세요. 데스크톱 코어용 파일에는 수신 포트, 네트워크 인터페이스, 로컬 경로가 들어 있을 수 있습니다. 모바일 클라이언트가 이를 처리하는 방식은 구현에 따라 다르므로 항목을 그대로 옮기기보다 호환되는 설정을 사용하세요.
정기적으로 구독을 업데이트하면 제공자의 변경 사항을 받을 수 있지만, 네트워크에 문제가 있을 때 업데이트를 무한히 반복하지 마세요. 기존 설정이 여전히 작동하는지 확인한 다음 업데이트 요청 성공 여부, 원격 내용 변경 여부, 현재 선택된 설정이 맞는지 살펴보세요. 업데이트 오류에 대한 일반적인 안내는 구독 업데이트 문제에서 확인할 수 있습니다. 정상적으로 불러온 로컬 백업을 보관하면 ‘가져오기 실패’와 ‘새 설정이 작동하지 않음’을 구분하는 데 도움이 됩니다.
Linux 데스크톱 및 코어 배포
GUI 클라이언트 또는 독립 코어 선택
Linux 데스크톱에서는 Linux 설치 파일에서 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 배포판, 프로세서 아키텍처, 패키지 형식을 확인한 뒤 배포판에서 지원하는 방식으로 설치하세요. 다운로드 페이지의 패키지가 모든 배포판과 아키텍처를 지원하는 것은 아닙니다. 다른 운영체제의 설치 파일을 확장자만 바꿔 사용하지 마세요. 설치 시 패키지 관리자가 안내하는 의존성을 확인하고 충돌이 발생하면 원인을 먼저 찾으세요. 검사를 무시하도록 강제하지 마세요.
GUI 클라이언트는 구독을 가져오고 정책을 전환하는 데 적합합니다. 독립 Mihomo 코어는 서버, 라우터 또는 서비스를 직접 관리하는 사용자에게 적합하며, 코어 다운로드에서 확인할 수 있습니다. 코어에는 GUI가 없습니다. 파일을 압축 해제한 뒤 실행 권한, 설정 디렉터리, 실행 방식을 구성해야 합니다. 일반 데스크톱 사용자는 프록시를 쓰기 위해 백그라운드 서비스를 먼저 만들 필요가 없습니다. GUI 클라이언트로 연결 경로를 확인하면 배포 과정에서 생기는 변수를 줄일 수 있습니다.
GUI에서 구독 및 프록시 설정
설치 후 설정 화면에서 원격 구독을 가져오고 다운로드가 완료되면 설정을 선택한 뒤 로그를 확인하세요. GUI가 정상적으로 표시되어도 코어 프로세스가 시작된 것은 아닙니다. 실제 수신 주소와 포트를 확인해야 합니다. 데스크톱 환경마다 시스템 프록시 지원 방식이 다릅니다. 어떤 프로그램은 데스크톱 설정을 읽고, 어떤 프로그램은 환경 변수만 읽으며, 자체 네트워크 설정을 사용하는 프로그램도 있습니다. 따라서 ‘브라우저는 되지만 터미널은 안 된다’고 해서 반드시 노드 문제인 것은 아닙니다.
터미널 테스트에서는 로그인 스크립트를 수정하지 말고 프록시를 임시로 지정하세요. 아래 환경 변수는 현재 셸과 그 뒤에 실행되는 하위 프로세스에만 적용됩니다. 이미 실행 중인 데스크톱 프로그램에는 자동으로 적용되지 않습니다. 테스트가 끝나면 변수를 지워 클라이언트를 종료한 뒤에도 터미널이 로컬 포트로 요청을 보내지 않도록 하세요. 주소와 포트는 클라이언트가 실제로 수신하는 값에 맞추세요. 인증 정보가 포함된다면 비밀번호를 공개적으로 읽을 수 있는 스크립트에 넣지 마세요.
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl --head https://example.com
unset http_proxy https_proxy
여기서는 HTTPS 대상에 HTTP 프록시를 통해 터널을 연결하므로 프록시 주소에 HTTP 프로토콜을 사용하는 것이 모순은 아닙니다. 대문자 환경 변수, 전역 환경 설정 파일, 도구 자체 설정이 테스트 결과에 영향을 주는지도 확인하세요. 컨테이너, 원격 세션, 샌드박스 앱은 별도의 네트워크 또는 환경 경계를 가집니다. 컨테이너 안의 로컬 주소는 대개 호스트와 다르므로 데스크톱 포트를 그대로 사용한 뒤 서비스가 작동하지 않는다고 판단하면 안 됩니다.
독립 코어의 디렉터리 및 실행 사용자
직접 배포할 때는 압축을 푼 실행 파일을 관리 가능한 위치에 두고 실행 권한을 부여하세요. 설정과 실행 데이터는 각각 별도의 디렉터리에 저장하는 것이 좋습니다. 먼저 포그라운드에서 실행해 설정 해석과 포트 수신이 정상인지 확인한 뒤 서비스로 등록하세요. 아래 예시는 실행 파일 이름이 mihomo이고 설정이 사용자 디렉터리의 파일에 저장되어 있다고 가정합니다. 명령만으로 유효한 구독이 생성되거나 원격 서버 정보가 채워지지는 않습니다.
mkdir -p "$HOME/.config/mihomo"
chmod u+x ./mihomo
./mihomo -t -d "$HOME/.config/mihomo"
./mihomo -d "$HOME/.config/mihomo"
테스트가 통과해도 설정을 해석할 수 있다는 뜻일 뿐 원격 서버에 접속할 수 있다는 보장은 없습니다. 서비스로 등록할 때 실행 사용자, 작업 디렉터리, 시작 명령, 설정 경로를 명확히 지정하세요. 서비스 계정이 기본 설정과 다른 파일을 읽는 일이 없도록 해야 합니다. 로그 디렉터리와 업데이트 데이터에도 적절한 쓰기 권한이 필요합니다. 권한 문제를 피하려고 모든 사용자가 모든 파일을 쓸 수 있게 만들지 마세요. 설정에 계정 정보와 제어 인터페이스 인증 정보가 포함될 수 있습니다.
TUN, 라우팅, DNS 권한
TUN은 가상 네트워크 장치 접근과 라우팅 변경이 필요한 경우가 많으므로 적절한 시스템 권한이 필요합니다. GUI 클라이언트는 보조 서비스를 통해 처리할 수 있고, 독립 코어는 실행 권한을 직접 설정해야 합니다. 임의의 파일에 네트워크 관리 권한을 부여하는 명령을 무작정 복사하지 마세요. 바이너리 위치, 업데이트 방식, 보안 범위를 먼저 확인하세요. 바이너리를 교체하면 파일에 부여된 권한이 달라질 수 있으므로 업데이트 후 다시 확인해야 합니다.
활성화한 뒤에는 라우팅 및 DNS 상태 확인 도구로 현재 경로, 수신 포트, 시스템 DNS 서비스 상태의 변화를 살펴보세요. 배포판마다 DNS 관리자가 다를 수 있으므로 여러 구성 요소가 같은 DNS 파일을 반복해서 덮어쓰게 하지 마세요. 원격으로 관리하는 서버라면 두 번째 관리 연결을 유지하고 명확한 복구 방법을 준비하세요. 기본 경로를 잘못 설정하면 현재 연결이 끊길 수 있으므로 GUI 스위치만으로 복구할 수 있다고 기대해서는 안 됩니다.
자동 실행 및 종료 후 잔여 설정 확인
데스크톱 자동 실행 항목은 사용자 세션이 시작된 뒤 실행되고 시스템 서비스는 로그인 전에 시작될 수 있습니다. 백그라운드에서 계속 실행해야 하는지에 따라 방식을 선택하세요. 같은 포트를 사용하는 코어를 두 방식으로 동시에 실행하지 마세요. 재부팅한 뒤에는 서비스 이름이 정상으로 표시되는지만 보지 말고 실제 프로세스, 설정 디렉터리, 수신 포트를 확인하세요. 중지할 때는 먼저 프록시와 라우팅을 복구한 뒤 프로세스를 종료하세요. 포트 충돌이 발생하면 점유 중인 서비스를 확인한 후 조치해 다른 네트워크 프로그램을 잘못 중지하지 않도록 하세요.
자주 발생하는 설정 문제 및 해결 순서
증상에 따라 문제 발생 계층 찾기
문제를 해결하기 전에 운영체제, 클라이언트 이름, 사용 중인 설정, 프록시 모드, 트래픽 연결 방식을 기록하고 문제가 시작되기 전에 마지막으로 변경한 항목도 적어 두세요. 다른 프록시와 VPN을 잠시 중지한 다음 새 요청을 한 번 보내세요. 클라이언트에 요청이 전혀 들어오지 않으면 시스템 프록시, 앱 목록 또는 TUN 라우팅을 확인하세요. 요청은 들어왔지만 연결 경로가 실패하면 정책 그룹과 서버를 살펴보세요. 연결이 성립했는데 페이지에 문제가 있다면 DNS, 규칙, 앱 자체 동작을 추가로 확인하세요.
‘연결됨’ 표시는 로컬 코어가 실행 중이거나 시스템 터널이 만들어졌다는 뜻일 수 있지만 전체 접속 경로가 정상이라는 의미는 아닙니다. 로컬 트래픽 연결과 원격 서버 접속 가능성을 나누어 테스트하면 잘못된 계층을 반복해서 수정하는 일을 줄일 수 있습니다. 자세한 확인 방법은 연결됨으로 표시되지만 웹페이지가 열리지 않을 때 확인할 사항을 참고하세요. 로그에 원격 연결 시간 초과가 명확히 표시된다면 노드 시간 초과 및 연결 실패 해결 순서도 살펴보세요.
규칙 순서, 그룹 이름, 설정 업데이트
규칙은 대개 순서대로 확인되며 조건에 처음 일치하는 규칙이 다음 동작을 결정합니다. 범위가 넓은 규칙을 앞에 두면 더 구체적인 규칙이 적용되지 않을 수 있으므로 기본 처리 규칙은 보통 마지막에 둡니다. 아래 내용은 문법을 설명하기 위한 예시이며 설정에 PROXY라는 정책 그룹이 실제로 있어야 합니다. 그룹 이름이 다르면 현재 설정에 있는 이름으로 바꾸세요. 예시를 적용하려고 빈 그룹을 만들거나 최상위 규칙 키를 중복으로 추가하지 마세요.
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
지리 기반 IP 규칙은 관련 데이터가 정상적으로 제공되어야 하며 도메인이 해석된 결과도 IP 규칙 적용에 영향을 줍니다. 전역 모드는 잠깐 비교할 때 쓸 수 있지만 규칙 설정이 올바르다는 증거는 아닙니다. 특정 사이트에서 문제가 생기면 정책 그룹의 현재 선택만 보지 말고 해당 연결에 적용된 규칙과 최종 연결 경로를 확인하세요. 원격 업데이트로 그룹 이름이 바뀌면 이전 이름을 참조하는 덮어쓰기 규칙이 로드되지 않을 수 있습니다. 업데이트 전후의 오류를 비교하고 필요하면 정상 작동하던 백업을 복원한 뒤 하나씩 옮기세요.
DNS와 TUN의 상호 영향
DNS는 도메인 이름을 접속 가능한 주소로 변환합니다. 프록시 연결이 성공해도 DNS 경로가 올바르다는 보장은 없습니다. 가상 IP 모드를 사용하면 일부 도메인에 매핑용 주소가 할당될 수 있는데, 이는 원격 서버의 실제 주소가 아닙니다. 해당 주소를 다른 기기에 복사하거나 클라이언트를 거치지 않고 사용하면 접속되지 않을 수 있습니다. 특정 앱과 호환하려면 코어 문서에 따라 해당 도메인을 예외로 설정하고 규칙이 도메인 정보를 올바르게 받는지 확인하세요.
사내 도메인, 프린터, 로컬 기기에 접속할 수 없다면 요청이 잘못 터널로 들어갔는지와 DNS가 기존 네트워크에서 계속 제공되는지 먼저 확인하세요. 모든 문제를 공용 DNS로 일괄 변경해 해결하려고 하지 마세요. TUN을 끄고 비교 테스트할 때도 시스템 프록시와 다른 DNS 설정이 여전히 작동 중인지 확인해야 합니다. 그렇지 않으면 기존 경로로 복구한 테스트가 아닙니다. IPv6에도 별도의 주소, DNS, 라우팅이 있습니다. 일부 사이트만 실패한다면 IPv4와 IPv6의 차이를 확인하고 바로 영구적으로 IPv6를 끄지 마세요.
| 증상 | 우선 확인할 항목 | 비교 방법 |
|---|---|---|
| 모든 앱에서 접속할 수 없음 | 기본 네트워크 연결, 남아 있는 프록시, 강제 터널 정책 | 트래픽 연결을 순서대로 끄고 시스템 설정 복구 |
| 일부 앱에서만 실패 | 앱 프록시 설정, 분할 연결 목록, 루프백 제한 | 해당 연결 로그가 남는지 확인 |
| 업데이트 후 설정이 작동하지 않음 | 해석 오류, 그룹 이름 변경, 코어 항목 호환성 | 로컬 백업과 비교하고 설정을 불러와 테스트 |
| 네트워크 전환 후 접속 실패 | 라우팅, DNS 출처, 서버 접속 가능성 | 트래픽 연결을 다시 설정하고 새 요청 전송 |
구독 업데이트 및 지연 시간 테스트 결과
업데이트에 실패하면 먼저 응답 유형을 확인하세요. 연결 시간 초과는 요청이 완료되지 않았다는 뜻이고, 인증 실패는 인증 정보나 계정 상태를 확인해야 합니다. 형식 오류는 받은 내용을 대상 형식으로 해석할 수 없다는 의미입니다. 업데이트 요청이 프록시를 통하는지는 클라이언트 구현과 설정에 따라 다르므로 항상 직접 연결되거나 항상 프록시를 통한다고 가정하지 마세요. 기존 설정으로 연결할 수 있다면 먼저 보관하고, 반복해서 삭제하고 다시 만들지 마세요. 자세한 해결 방법은 도움말 센터의 구독 업데이트 안내를 참고하세요.
지연 시간 테스트는 지정한 요청을 특정 시점에 측정한 결과일 뿐 지속적인 다운로드 속도를 나타내지 않으며 모든 사이트에 접속할 수 있다는 보장도 없습니다. 테스트 주소, 핸드셰이크 단계, 동시 연결 상태에 따라 결과가 달라지므로 동일한 조건에서 비교하세요. 연결 경로를 선택한 뒤에는 실제로 사용할 앱에서 요구 사항이 충족되는지 확인하세요. 자세한 내용은 지연 시간 테스트와 실제 인터넷 속도의 차이를 참고하세요. 한 번의 테스트 수치만으로 연결 로그와 실제 사용 결과를 대신하지 마세요.
문제 상황을 기록한 뒤 안정 상태로 복구
로그를 공유하기 전에 구독 주소, 계정 정보, 서버 비밀번호와 불필요한 개인 네트워크 정보를 삭제하세요. 오류 유형, 발생 시각, 필요한 맥락만 남기면 됩니다. 디버그 수준 로그는 문제를 재현할 때 잠시 사용하고 완료 후에는 일반 수준으로 되돌려 불필요한 데이터가 쌓이지 않도록 하세요. 설정을 바꿀 때마다 결과를 기록하고 개선되지 않으면 원래 값으로 복구하세요. 증상을 설명할 수 있는 구체적인 차이를 찾을 때까지 하나씩 확인하면 됩니다. 안정화된 뒤 자동 업데이트와 자동 실행을 복구하세요. 처음부터 전체 설정 과정을 다시 따라야 한다면 사용 가이드로 돌아가세요. 임시 문제 해결 설정을 장기 기본값으로 두지 마세요.