FULL MANUAL · 전체 플랫폼 설치 설정
Clash 전체 플랫폼 설치 설정 총정리
5개 플랫폼별로 한 장씩 구성했으며 흐름은 동일합니다: 다운로드 → 설치 → 구독 가져오기 → 트래픽 인계 → 플랫폼별 함정. 전체 플랫폼에 공통되는 설정 파일 지식과 문제 해결법은 마지막 두 장에 모아두어 각 장에서 중복하지 않습니다.
SCOPE · 이 페이지의 위치
이 페이지와 사용 가이드의 역할 구분: 사용 가이드는 "따라 하면 바로 연결되는" 최단 경로만 다루는 빠른 시작 가이드이고, 이 페이지는 각 플랫폼의 다운로드부터 TUN까지 모든 과정과 예외 상황을 다루는 체계적인 참고 매뉴얼입니다. 처음 설정할 때는 먼저 사용 가이드를 따라 하고, 가이드에서 다루지 않은 세부 내용이 필요할 때 이 페이지의 해당 장을 찾아보세요.
설치 파일과 클라이언트 목록은 클라이언트 다운로드 페이지를 기준으로 하며, 개별 질문은 헬프 센터에서, 용어 설명은 용어 사전에서 확인하세요.
CH-01 PREPARE · 공통 준비
시작하기 전에: 코어, 구독, 두 가지 트래픽 인계 방식
이 장에서는 세 가지를 다룹니다: 클라이언트와 코어의 역할 구분, 사용 가능한 구독 링크 준비, 시스템 프록시와 TUN 두 트래픽 인계 방식의 차이 이해. 이 개념들은 이후 5개 플랫폼 장 전체를 관통하므로 몇 분만 투자해 읽어두면 반복적인 문제 해결 과정을 크게 줄일 수 있습니다.
클라이언트와 코어의 역할 구분
흔히 말하는 Clash는 실제로 두 계층으로 구성됩니다: 코어는 트래픽 전달, 규칙 매칭, DNS 처리를 담당하고, GUI 클라이언트는 인터페이스, 구독 관리, 시스템 설정 반영을 담당합니다. 현재 주요 클라이언트는 대부분 Mihomo 코어를 탑재하고 있으며, 본문에서 다루는 TUN, fake-ip, 규칙 매칭 등의 기능은 모두 코어가 제공하고 클라이언트는 이를 시각적인 스위치로 만들어 보여줄 뿐입니다. 이 점을 이해하면 여러 현상이 설명됩니다: 서로 다른 클라이언트의 핵심 동작은 대체로 동일하며 차이는 인터페이스와 플랫폼 통합에 집중되어 있고, 클라이언트 버전과 코어 버전은 별개의 업데이트 라인이며, 어떤 기능이 "이 클라이언트에는 있는데 저 클라이언트에는 없다"고 느껴지는 경우 대부분 인터페이스에 노출되지 않았을 뿐 코어 단에는 실제로 존재합니다.
클라이언트 선택은 고민할 필요가 없습니다: 각 플랫폼의 1순위 추천은 모두 Clash Plus이며, Linux 데스크톱은 Clash Verge Rev를 추천합니다. 전체 목록과 설치 파일은 클라이언트 다운로드 페이지에서, 인터페이스·코어·유지보수 상태 비교는 《주요 Clash 클라이언트 선택 가이드》에서 확인하세요.
구독 링크: 계정 정보 수준으로 관리하기
구독 링크는 서비스 제공자가 생성한 HTTP(S) 주소로, 클라이언트가 이를 불러오면 노드와 규칙이 포함된 전체 설정을 가져올 수 있습니다. 두 가지 상식을 기억하세요: 첫째, 구독 링크는 계정 정보와 동등한 수준이므로 유출되면 계정을 공유하는 것과 같아 공개된 곳에 붙여넣지 마세요. 둘째, 서비스 제공자마다 출력 형식이 조금씩 다르며 흔히 Clash YAML과 Base64 두 종류가 있는데, 호환성과 변환 방법은 《Clash 구독 형식 알아보기》에서 확인하세요. 가져오기 전에 받은 것이 구독 링크 자체인지, 단일 노드 공유 링크가 아닌지 먼저 확인하세요. 후자는 노드 하나만 담고 있어 완전한 규칙 세트를 만들 수 없습니다.
시스템 프록시와 TUN: 두 가지 트래픽 인계 방식
모든 플랫폼의 트래픽 인계는 두 가지 경로뿐입니다. 시스템 프록시: 클라이언트가 로컬에서 리스닝 포트(흔히 7890)를 열고 "127.0.0.1:포트"를 운영체제의 프록시 설정에 기록하면, 시스템 프록시를 따르는 애플리케이션(브라우저와 대부분의 인터넷 소프트웨어)의 트래픽이 여기를 거칩니다. 구현이 가볍고 부담이 적지만 명령줄 도구, 일부 게임, 시스템 구성 요소는 이를 우회합니다. TUN 모드: 코어가 가상 네트워크 카드를 생성해 네트워크 계층에서 모든 아웃바운드 트래픽을 인계하며, 프록시 설정을 읽지 않는 프로그램까지 포함합니다. 대신 더 높은 권한이 필요합니다 — Windows는 시스템 서비스 설치, macOS는 보조 도구 권한 부여, Linux는 root 또는 권한 부여, 모바일은 시스템 VPN 승인이 필요합니다.
본문 전체를 관통하는 철칙 하나: 한 번에 하나의 인계 방식만 켜야 합니다. 시스템 프록시와 TUN을 동시에 켜면 트래픽 루프, DNS 이상 등 원인을 찾기 어려운 문제가 발생하며, 8장에서 다루는 "알 수 없는 오류" 대부분의 근본 원인이 여기에 있습니다. 용어가 낯설 때는 언제든 용어 사전을 참고하세요.
설치 전 확인 목록
- 시스템 버전이 기준을 충족하는지 확인: 일반적으로 Windows 10 64비트 이상, macOS 11 이상이 요구되며, 더 이전 버전은 다운로드 페이지의 각 플랫폼 설명을 참고하세요.
- 사용 가능한 구독 링크를 준비하고 브라우저에서 접속해 내용이 반환되는지 확인하세요 — YAML 텍스트나 긴 인코딩 문자열이 반환되면 정상입니다.
- 관리자 / root 권한을 확보하세요. TUN 모드와 시스템 서비스 설치 모두 이 권한이 필요합니다.
- 다른 프록시·부스터 소프트웨어를 먼저 종료하거나 제거하세요: 이들은 Clash와 포트 및 가상 네트워크 카드를 두고 충돌하며, 설치 단계에서 가장 흔한 문제 원인입니다.
5개 플랫폼 개요는 다음과 같으며, 앵커 링크를 클릭하면 해당 장으로 바로 이동합니다:
CH-02 WINDOWS · 플랫폼 장
Windows: 설치, 시스템 프록시, TUN 서비스
Windows는 설정 항목이 가장 많은 플랫폼입니다: 설치 차단, 시스템 프록시 기록, TUN 서비스 설치, UWP 루프백 제한 등 각각 넘어야 할 관문이 있으며, 이 장에서는 작업 순서대로 하나씩 설명합니다.
다운로드 및 설치
다운로드 페이지의 Windows 항목에서 설치 파일을 받으세요. 1순위는 Clash Plus이며, Clash Verge Rev, FlClash, Clash Nyanpasu가 대안입니다. Clash for Windows는 유지보수가 종료되어 보관용으로만 남겨두었으니 새로 설치하는 것은 권장하지 않습니다. 설치 파일은 .exe 형식이며 더블클릭으로 실행하면 됩니다. SmartScreen의 파란색 차단 창이 뜨면 "추가 정보" → "실행"을 클릭하세요. 이는 새로 배포된 설치 파일에 대한 시스템의 일반적인 안내일 뿐 파일에 문제가 있다는 의미는 아닙니다. 설치 경로는 기본값을 유지하거나 최소한 한글(다국어)이나 공백이 포함된 폴더는 피하는 것을 권장합니다 — 일부 코어 구성 요소는 특수 문자 경로의 설정 폴더를 처리할 때 소리 없이 실패하며, 나중에 원인을 찾는 비용이 경로를 바꾸는 것보다 훨씬 큽니다. 설치 완료 후 첫 실행 시 Windows 방화벽이 알림을 띄울 수 있는데, 전용 네트워크를 체크하고 액세스를 허용하세요.
구독 가져오기
클라이언트를 열고 "구독" 또는 "설정" 페이지로 이동해 구독 링크를 붙여넣은 뒤 가져오기 / 업데이트를 클릭하세요. 성공하면 설정 목록에 새 항목이 나타나고 "프록시" 페이지에서 노드 그룹을 볼 수 있습니다. 가져오기 오류가 발생하면 먼저 브라우저에서 해당 링크에 직접 접속해 연결 가능한지 확인한 뒤 8장의 구독 오류 항목을 참고하세요. 가져오기에 성공하면 구독 자동 업데이트를 켜두고 간격을 12~24시간으로 설정하는 것을 권장합니다.
시스템 프록시 켜기
클라이언트 메인 화면에서 "시스템 프록시" 스위치를 켜세요. 실제로는 127.0.0.1과 혼합 포트(기본값은 대부분 7890)를 Windows 프록시 설정에 기록하는 것입니다. 확인 방법: "설정 → 네트워크 및 인터넷 → 프록시"를 열어 "프록시 서버 사용"이 켜져 있고 주소가 일치하는지 확인하세요. 브라우저로 해외 사이트에 접속해 연결을 확인하고, IP 조회 사이트로 출구 주소가 바뀌었는지 확인하세요. 특히 주의할 점: 클라이언트를 종료하기 전에 시스템 프록시 스위치를 먼저 끄세요. 프로세스를 강제로 종료하면 프록시 설정이 시스템에 남아 클라이언트 종료 후 전체 네트워크가 끊기는 현상이 나타날 수 있습니다 — 이런 경우 시스템 프록시 설정에서 수동으로 끄면 복구됩니다.
TUN 모드 켜기
명령줄 도구, 게임, 시스템 구성 요소까지 프록시를 거치게 하려면 TUN 모드를 사용하세요. 처음 켤 때 클라이언트가 시스템 서비스 설치를 요청하며(관리자 승인 필요), 이 서비스가 높은 권한으로 코어를 실행하고 가상 네트워크 카드를 생성합니다. 성공적으로 켜지면 "네트워크 연결"에 Mihomo / WinTun 가상 네트워크 카드가 추가됩니다. TUN을 켤 때는 시스템 프록시 스위치를 꺼두어야 합니다. 둘을 동시에 켜면 트래픽 루프나 DNS 이상이 발생할 수 있습니다. 서비스 설치가 실패하면 클라이언트를 관리자 권한으로 다시 실행해 보세요. 계속 실패하면 클라이언트 설정에서 남아 있는 서비스를 제거한 뒤 다시 설치하세요.
플랫폼별 함정
- 포트 점유: 보안 소프트웨어나 개발 디버깅 도구가 7890을 자주 점유하며, 시스템 프록시를 켰는데도 전체 네트워크가 안 되는 현상으로 나타납니다. 원인 파악과 포트 변경 방법은 8장의 포트 충돌 항목을 참고하세요.
- UWP 앱 루프백: 스토어 앱은 기본적으로 로컬 루프백 주소 접근이 금지되어 프록시를 거치지 않습니다. 일부 클라이언트는 "UWP 루프백 예외" 도구를 제공하며, 대상 앱을 체크하면 적용됩니다.
- 백신 오탐: 코어가 가상 네트워크 카드와 시스템 서비스를 생성하는 동작이 보안 소프트웨어에 의해 차단될 수 있습니다. 설치 전에 설치 폴더를 신뢰 목록에 추가하면 나중에 하나씩 허용하는 것보다 편리합니다.
- 잔여 네트워크 카드: 여러 클라이언트를 반복해서 설치/제거하면 사용되지 않는 TAP / WinTun 유령 네트워크 카드가 남을 수 있습니다. 장치 관리자의 "네트워크 어댑터"에서 제거하세요.
- 부팅 시 자동 실행: 바로가기를 시작 폴더에 직접 넣지 말고 클라이언트 설정에서 켜세요. 이렇게 하면 시스템 서비스도 올바른 순서로 함께 실행됩니다.
시스템 프록시와 TUN은 하나만 켜세요. 방식을 전환할 때는 기존 것을 먼저 끄고 새 것을 켜야 합니다. 순서가 뒤바뀌는 것이 Windows에서 "전환하면 바로 끊기는" 문제의 첫 번째 원인입니다.
CH-03 MACOS · 플랫폼 장
macOS: 칩 선택, 보안 권한 부여, 시스템 프록시
macOS 장의 핵심은 두 가지입니다: 올바른 칩 아키텍처의 설치 파일을 설치하는 것, 그리고 시스템의 보안 권한 부여 절차를 통과하는 것. 권한 부여는 최초 실행과 버전 업데이트 후에만 나타나며, 한 번 설정하면 장기간 유효합니다.
칩과 설치 파일 선택
macOS 설치 파일은 칩에 따라 Apple Silicon(arm64)과 Intel(x64) 두 버전으로 나뉩니다. 왼쪽 상단 애플 메뉴 → "이 Mac에 관하여"를 클릭해 "칩" 항목이 Apple M 시리즈면 arm64를, Intel이면 x64를 선택하세요. 아키텍처를 잘못 설치하면 첫 실행 시 충돌하거나 변환 실행으로 성능이 크게 떨어집니다. 클라이언트 선택은 Windows와 비슷합니다: 1순위는 Clash Plus, 대안은 Clash Verge Rev, FlClash이며, ClashX Meta는 유지보수가 종료되어 보관용으로만 남아 있습니다. 다운로드 페이지의 macOS 항목에서 dmg를 받아 열고, 앱 아이콘을 Applications 폴더로 드래그하면 설치가 완료됩니다.
최초 실행과 보안 권한 부여
처음 열 때 "개발자를 확인할 수 없음" 또는 "확인되지 않은 개발자"라는 안내가 나올 수 있습니다. 처리 방법: "시스템 설정 → 개인정보 보호 및 보안"을 열고 페이지 하단에서 차단된 앱 관련 안내를 찾아 "그래도 열기"를 클릭하세요. 이후 클라이언트가 시스템 프록시를 기록하거나 보조 서비스를 설치할 때도 각각 한 번씩 권한 요청이 뜨는데, 로그인 비밀번호를 입력하거나 Touch ID로 확인하면 됩니다. 이런 권한 요청은 최초 실행과 주요 버전 업데이트 후에만 나타나며 매번 묻지는 않습니다.
구독 가져오기와 시스템 프록시
가져오기 과정은 다른 플랫폼과 동일합니다: 구독 페이지에서 링크를 붙여넣고 → 업데이트 → 프록시 페이지에서 노드 그룹이 나타나는지 확인하세요. "시스템 프록시"를 켠 뒤에는 "시스템 설정 → 네트워크 → (현재 인터페이스) → 세부 사항 → 프록시"에서 확인할 수 있습니다: 웹 프록시(HTTP)와 보안 웹 프록시(HTTPS)가 127.0.0.1과 클라이언트 포트를 가리켜야 합니다. macOS의 프록시 설정은 네트워크 서비스(Wi-Fi, 유선, Thunderbolt 브리지)별로 따로 저장되므로, Wi-Fi에서 유선으로 전환한 뒤 프록시가 작동하지 않으면 시스템 프록시 스위치를 한 번 다시 켜서 클라이언트가 현재 활성 인터페이스에 다시 기록하도록 하세요.
TUN 모드 켜기
macOS에서 TUN을 켜려면 클라이언트가 더 높은 권한으로 코어를 실행해야 합니다: 처음 켤 때 권한 있는 보조 도구 설치나 네트워크 확장 권한 부여를 요청하며, 안내에 따라 확인하세요. 성공하면 터미널에서 ifconfig를 실행했을 때 새로 추가된 utun 인터페이스를 볼 수 있습니다. Windows와 마찬가지로 TUN과 시스템 프록시는 둘 중 하나만 선택합니다. TUN을 켠 뒤 인터넷이 안 되면 먼저 DNS 설정이 이전 설정에 덮여 있는지, 기업용 보안 소프트웨어가 네트워크 확장 채널을 점유하고 있는지 확인하세요.
플랫폼별 함정
- 종료 후 잔여 설정: 클라이언트를 강제 종료하면(정상 종료가 아닌 경우) 시스템 프록시가 켜진 상태로 남아 네트워크가 끊길 수 있습니다. 네트워크 설정에서 프록시를 수동으로 끄거나 클라이언트를 다시 열어 정상적으로 종료하세요.
- 시스템 업그레이드: 주요 버전 업그레이드 후 보안 권한이 초기화될 수 있습니다. 첫 실행 시 "개인정보 보호 및 보안"에서 다시 허용하면 되며, 설정은 사라지지 않습니다.
- MDM 장치: 회사에서 일괄 관리하는 Mac은 프로파일을 통해 프록시와 VPN 설정이 잠겨 있을 수 있습니다. 이런 제한은 클라이언트가 우회할 수 없으므로 장치 관리자에게 문의해야 합니다.
- 여러 클라이언트 공존: Clash 계열 클라이언트를 여러 개 동시에 설치하는 것은 문제없지만, 한 번에 하나만 실행해야 합니다. 그렇지 않으면 서로 시스템 프록시 설정을 두고 충돌합니다.
CH-04 ANDROID · 플랫폼 장
Android: VPN 권한 부여와 백그라운드 유지
Android에는 별도의 시스템 프록시 스위치가 없으며, 클라이언트는 모두 시스템 VPN 인터페이스를 통해 트래픽을 인계하는데, 이는 TUN과 동등한 효과입니다. 이 장의 핵심은 올바른 아키텍처 설치, 충분한 권한 부여, 백그라운드 유지 설정입니다.
다운로드와 ABI 선택
Android 설치 파일은 프로세서 아키텍처(ABI)에 따라 구분됩니다: 최근 몇 년간의 주력 모델은 모두 arm64-v8a를 선택하고, 오래되거나 저가형 기기는 armeabi-v7a일 수 있습니다. 아키텍처가 확실하지 않으면 범용 패키지인 universal을 선택하세요. 용량은 크지만 모든 기기와 호환됩니다. 클라이언트 순서는 다운로드 페이지와 동일합니다: 1순위 Clash Plus, 대안으로 Clash Meta for Android, FlClash, Surfboard가 있으며, 설치 파일은 다운로드 페이지의 Android 항목에서 받을 수 있습니다.
설치와 VPN 권한 부여
APK를 설치할 때 시스템이 "알 수 없는 앱 설치 허용 안 함"으로 한 번 막을 수 있습니다: 설정에 들어가 현재 설치 소스(브라우저 또는 파일 관리자)에 대해 허용을 켜고 돌아와 계속하세요. 클라이언트의 연결 버튼을 처음 누르면 시스템이 "연결 요청" 대화상자를 띄우는데 — 이는 Android의 VpnService 권한 부여로, 반드시 허용해야 합니다. 승인이 완료되면 상태 표시줄에 열쇠 아이콘이 나타나며 터널이 연결되었음을 의미합니다. 이 권한은 앱별로 기억되며, 제거 후 재설치하면 다시 부여해야 합니다.
구독 가져오기
설정 / 구독 페이지에서 링크를 붙여넣어 가져오세요. 일부 클라이언트는 QR 코드 스캔이나 클립보드에서 한 번에 인식하는 기능을 지원합니다. 모바일 네트워크 환경에서는 구독 자동 업데이트를 켜고 간격을 24시간 정도로 설정하는 것을 권장하며, 이렇게 하면 노드 변경이 너무 오래 지연되지 않습니다. 업데이트 실패의 대표적인 원인과 해결법은 《Clash 구독 업데이트 실패 해결법》에서 확인하세요.
백그라운드 유지
제조사 커스텀 시스템은 백그라운드 프로세스 정리가 매우 적극적이어서, "연결이 잘 되다가 끊긴다", "화면 잠금 후 한동안 지나면 트래픽이 끊긴다" 같은 현상은 대부분 시스템이 클라이언트를 강제 종료한 것입니다. 세 가지 조치를 함께 하세요: 첫째, 시스템 배터리 설정에서 클라이언트를 "제한 없음 / 최적화 안 함"으로 설정. 둘째, 자동 실행 관리(제조사마다 명칭이 다름)에서 자동 실행과 백그라운드 실행을 허용. 셋째, 멀티태스킹 화면에서 클라이언트 창을 잠금. 세 가지를 모두 적용해야 장시간 유지가 보장되며, 하나만 적용하면 일부 기기에서는 여전히 강제 종료될 수 있습니다.
플랫폼별 함정
- 프라이빗 DNS 충돌: 시스템 "프라이빗 DNS"(DoT)를 특정 호스트명으로 설정하면 DNS 조회가 클라이언트를 우회해 라우팅 이상이 발생할 수 있으니 "자동"으로 되돌리는 것을 권장합니다.
- VPN 상호 배타: Android는 한 번에 하나의 앱만 VpnService를 보유할 수 있어, Clash를 켜면 다른 VPN 앱이 밀려나고 반대의 경우도 마찬가지이며 이는 시스템의 기본 동작입니다.
- 앱별 프록시: 대부분의 클라이언트는 앱 단위 허용 / 제외 목록을 지원합니다. 네트워크 환경에 민감한 뱅킹 앱은 제외 목록에 추가해 직접 연결로 처리할 수 있습니다.
- 절전 모드: 적극적인 절전 모드는 백그라운드 네트워크를 제한합니다. 장시간 대기 상황에서는 끄거나 최소한 클라이언트만 예외로 지정하세요.
- 재부팅 동작: 일부 시스템은 재부팅 후에도 VPN 권한은 유지되지만 자동으로 연결되지 않습니다. 클라이언트의 "부팅 시 자동 연결" 옵션을 자동 실행 권한과 함께 켜야 합니다.
CH-05 IOS · 플랫폼 장
iOS: App Store 설치와 VPN 설정
iOS 클라이언트는 App Store를 통해 배포되며, 설정 과정은 5개 플랫폼 중 가장 짧습니다. 주의할 점은 VPN 설정 관리와 네트워크 전환 후의 터널 동작에 집중되어 있습니다.
클라이언트 받기
iOS 플랫폼은 Clash Plus를 1순위로 추천하며, App Store에서 검색해 설치하면 됩니다. 스토어 바로가기는 다운로드 페이지의 iOS 항목에서 확인하세요. 클라이언트 공식 사이트는 clashplus.io이며 플랫폼 지원 현황과 기능 설명을 확인할 수 있습니다. App Store 버전은 스토어에서 자동 업데이트되므로 설치 파일을 수동으로 받을 필요가 없으며, 이것이 iOS 장에 "아키텍처 선택" 항목이 없는 이유입니다.
구독 가져오기와 첫 연결
클라이언트를 열고 구독 페이지로 이동해 구독 링크를 붙여넣어 가져오세요. iOS에서 더 빠른 방법은 Safari에서 먼저 링크를 복사한 뒤 클라이언트를 실행하면 클립보드를 인식해 가져올지 물어보므로 확인만 하면 됩니다. 처음 연결을 누르면 시스템이 "'Clash Plus'이(가) VPN 설정을 추가하려고 합니다" 대화상자를 띄우는데, "허용"을 누르고 Face ID / Touch ID 또는 비밀번호로 확인하세요 — 이는 iOS 네트워크 확장의 표준 권한 부여이며, 설정은 "설정 → 일반 → VPN 및 기기 관리 → VPN" 목록에 나타납니다. 연결에 성공하면 상태 표시줄에 VPN 표시가 나타나며 터널이 연결되었음을 의미합니다.
모드 선택과 노드 전환
iOS 클라이언트도 규칙 / 전체 / 직접 연결 세 가지 모드를 제공하며, 일상적으로는 규칙 모드를 유지하면 됩니다. 세 모드의 동작 차이는 《규칙 모드, 전체 모드, 직접 연결 모드 차이 완전 정리》에서 확인하세요. 노드 전환은 프록시 페이지에서 진행합니다: 그룹에 대해 지연 시간 테스트를 한 번 실행해 값이 낮고 안정적인 노드를 선택하세요. 노드를 바꿀 때 연결을 끊고 다시 연결할 필요는 없으며, 터널은 유지된 채로 코어가 내부에서 아웃바운드 변경을 처리합니다.
시스템 VPN 설정의 경계
"설정"의 VPN 스위치와 클라이언트 안의 연결 버튼은 같은 터널을 제어합니다: 시스템 설정에서 VPN을 끄면 클라이언트도 동시에 끊김 상태로 표시됩니다. VPN 설정을 삭제하면(설정 → 일반 → VPN 및 기기 관리) 권한을 회수하는 것과 같아, 다음 연결 시 클라이언트가 다시 추가를 요청합니다. 여러 프록시 앱이 각자 자신의 VPN 설정을 유지하며, 한 번에 하나만 활성화될 수 있어 서로 대체되는 것은 시스템의 정상 동작이며 오류가 아닙니다.
플랫폼별 함정
- 네트워크 전환 재연결: Wi-Fi와 셀룰러 간 전환 시 터널이 잠시 재구성되며, 몇 초간 트래픽이 끊기는 것은 정상입니다. 오래도록 복구되지 않으면 수동으로 한 번 끊고 다시 연결하세요.
- 저전력 데이터 모드: 셀룰러나 Wi-Fi에서 "저전력 데이터 모드"를 켜면 백그라운드 트래픽이 제한되어 구독 자동 업데이트와 터널 안정성에 영향을 줄 수 있으므로, 자주 사용하는 네트워크에서는 끄는 것을 권장합니다.
- 필요시 연결: 일부 클라이언트는 "필요시 연결" 규칙을 제공해 네트워크 활동이 있을 때 시스템이 자동으로 VPN을 실행합니다. VPN이 "꺼지지 않고 자동으로 다시 켜지는" 경우, 클라이언트에서 필요시 연결을 먼저 끈 뒤 연결을 끊으세요.
- 지역 계정: App Store 앱의 노출 여부는 스토어 지역에 따라 달라집니다. 검색이 안 될 경우 다운로드 페이지에 제공된 스토어 링크를 기준으로 이동하세요.
- 절전 영향: iOS 저전력 모드는 백그라운드 활동을 제한합니다. 장시간 잠금 후 첫 접속 시 간헐적으로 지연이 늘어날 수 있으며, 화면을 켜면 자연히 회복됩니다.
CH-06 LINUX · 플랫폼 장
Linux: 데스크톱 클라이언트, 환경 변수, TUN 권한
Linux 장은 두 갈래로 나뉩니다: 데스크톱 사용자는 GUI 클라이언트를 설치하며 과정은 다른 플랫폼과 비슷합니다. 서버와 라우터 사용자는 Mihomo 코어를 직접 실행하며 설정 파일과 systemd로 관리합니다. 이 장에서는 두 갈래 모두 전체 단계를 제공합니다.
데스크톱 클라이언트 설치
Linux 데스크톱은 Clash Verge Rev를 추천하며, 대안은 FlClash입니다. 설치 파일은 다운로드 페이지의 Linux 항목에서 받으세요. Debian / Ubuntu 계열은 deb 패키지로 설치합니다:
sudo apt install ./clash-verge-rev_amd64.deb
dpkg -i가 아니라 apt install ./패키지명을 사용하세요. 전자는 의존성을 자동으로 채워줍니다. Fedora 계열은 대응하는 rpm 패키지에 dnf install을 사용하세요. 설치가 끝나면 앱 메뉴에서 실행하고, 구독 가져오기는 다른 플랫폼과 동일합니다: 구독 페이지에 링크를 붙여넣고 → 업데이트 → 프록시 페이지에서 노드 그룹 확인.
프록시 적용의 세 가지 방식
Linux에서 "시스템 프록시"는 단일 스위치가 아니며, 적용 범위가 넓어지는 순서로 세 가지 방식을 사용합니다. 첫째, 데스크톱 환경 프록시: GNOME / KDE의 네트워크 설정에 프록시 설정 항목이 있으며, GUI 클라이언트의 "시스템 프록시" 스위치가 여기를 기록합니다. 해당 설정을 따르는 데스크톱 앱에 적용됩니다. 둘째, 환경 변수: 터미널과 대부분의 명령줄 도구는 다음 변수를 읽습니다:
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
임시로 사용할 때는 현재 터미널에서 바로 실행하고, 장기간 사용할 때는 ~/.bashrc나 ~/.zshrc에 기록하세요. 환경 변수는 이후 새로 시작하는 프로세스에만 적용되며, 이미 실행 중인 프로그램은 감지하지 못한다는 점에 주의하세요. 셋째, TUN 모드: 환경 변수를 읽지 않는 프로그램까지 포함해 모든 트래픽을 인계합니다. GUI 클라이언트에서 TUN을 켜려면 권한 부여가 필요하며, Clash Verge Rev는 권한 있는 서비스 설치를 안내합니다. 코어를 직접 실행하는 경우 root 권한이나 바이너리에 네트워크 권한 부여가 필요합니다:
sudo setcap 'cap_net_admin,cap_net_bind_service=+ep' ./mihomo
서버: 코어 + systemd
데스크톱 환경 없이 Mihomo 코어를 직접 사용하는 경우입니다. 다운로드 페이지 코어 항목에서 해당 아키텍처의 압축 파일을 받으세요(x86 서버는 amd64, ARM 기기는 비트 수에 따라 arm64 또는 armv7 선택). 압축을 풀어 /usr/local/bin에 넣고, 설정 파일은 /etc/mihomo/config.yaml에 둡니다. systemd로 관리하세요:
[Unit]
Description=Mihomo Daemon
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
[Install]
WantedBy=multi-user.target
/etc/systemd/system/mihomo.service로 저장한 뒤:
sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
journalctl -u mihomo -f
마지막 명령은 코어 로그를 실시간으로 보여줍니다. 첫 실행 시 반드시 확인하세요: 설정 문법 오류, 포트 점유 등이 여기에 바로 나타납니다. 설정을 수정한 뒤에는 systemctl restart mihomo로 재시작해 적용하세요.
플랫폼별 함정
- 배포판 차이: Arch 계열은 AUR에서 패키지를 받을 수 있지만 버전이 공식 설치 파일과 동기화되지 않을 수 있으니, 문제가 생기면 먼저 다운로드 페이지의 공식 패키지와 비교해 패키징 요인을 제외하세요.
- Wayland 트레이: 일부 Wayland 데스크톱은 트레이 아이콘 지원이 완전하지 않아 클라이언트 창을 닫으면 입구를 찾지 못할 수 있습니다. 앱 메뉴에서 다시 실행하면 메인 창이 다시 나타납니다.
- DNS 인계: TUN을 켠 뒤 해석 이상이 있으면 systemd-resolved가 코어의 DNS 하이재킹과 충돌하는지 확인하고, 필요하면 설정의 dns 섹션에서 리스닝을 조정하세요.
- 방화벽: firewalld / ufw를 사용하는 기기에서 로컬 네트워크의 다른 기기가 프록시를 사용하려면 혼합 포트를 허용하고 설정에서
allow-lan: true를 켜야 합니다. - 라우터 기기: MIPS 등 임베디드 아키텍처는 mips-softfloat 코어 패키지를 선택하세요. 리소스가 제한된 기기는 규칙 수를 줄여 메모리 사용량을 낮추는 것을 권장합니다.
CH-07 CONFIG · 전체 플랫폼 공통
설정 파일과 구독: 구조, 필드, 업데이트 메커니즘
5개 플랫폼의 클라이언트는 결국 모두 동일한 YAML 설정을 기반으로 동작합니다. 구조를 이해하면 "어디를 눌러야 하는지"의 표면적인 수준을 넘어, 클라이언트의 각 스위치가 실제로 무엇을 바꾸는지 직접 이해할 수 있습니다. 이 장에서는 설정을 직접 작성할 것을 요구하지 않습니다 — 구독이 이미 완전한 내용을 생성해주기 때문입니다 — 다만 읉을 줄 알아야 합니다.
최상위 구조 개요
일반적인 설정의 골격은 다음과 같습니다:
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
dns:
enable: true
enhanced-mode: fake-ip
proxies:
- name: "노드A"
type: vless
server: example-server.com
port: 443
proxy-groups:
- name: "PROXY"
type: select
proxies: ["노드A", "자동 선택"]
- name: "자동 선택"
type: url-test
proxies: ["노드A"]
url: https://www.gstatic.com/generate_204
interval: 300
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
여섯 부분이 각자의 역할을 담당합니다: 공통 필드는 포트와 실행 모드를 정의하고, dns 섹션은 도메인 해석 정책을 결정하며, proxies는 노드 목록이고, proxy-groups는 노드를 선택 가능한 정책 그룹으로 묶으며, rules는 각 연결이 어느 그룹으로 갈지 결정합니다. 클라이언트 화면의 "프록시 페이지"가 렌더링하는 것이 바로 proxy-groups이고, "모드 전환"이 바꾸는 것이 mode 필드입니다.
자주 쓰는 필드 요약
| 필드 | 흔한 값 | 설명 |
|---|---|---|
| mixed-port | 7890 | HTTP와 SOCKS를 통합한 혼합 리스닝 포트, 시스템 프록시가 이를 가리킴 |
| allow-lan | false / true | 로컬 네트워크 기기가 이 포트에 접속해 프록시를 사용할 수 있게 할지 여부 |
| mode | rule / global / direct | 규칙 분류 / 전부 프록시 / 전부 직접 연결 |
| log-level | info / debug | 로그 레벨, 문제 해결 시 임시로 debug로 조정 |
| enhanced-mode | fake-ip / redir-host | DNS 강화 모드, fake-ip가 대부분 상황의 기본값 |
| interval | 300 | url-test 그룹의 자동 속도 테스트 간격, 단위 초 |
규칙 매칭 방식
rules 목록은 위에서 아래로 순서대로 매칭되며, 일치하면 즉시 멈추고 마지막의 MATCH는 기본값 역할을 합니다. 흔한 규칙 유형: DOMAIN-SUFFIX는 도메인 접미사, DOMAIN-KEYWORD는 도메인 키워드, GEOIP는 목적지 IP의 국가, IP-CIDR은 IP 대역 기준입니다. "순서에 민감하고 일치하면 멈춘다"는 점을 이해하면 많은 분류 의문이 해결됩니다: 특정 사이트가 예상대로 프록시를 거치지 않는다면 보통 더 앞선 위치에서 다른 규칙에 걸린 경우입니다. 세 가지 mode의 차이는 《규칙 모드, 전체 모드, 직접 연결 모드 차이 완전 정리》에서 확인하세요.
구독 업데이트의 동작 세부사항
구독을 업데이트하면 클라이언트가 원격 YAML을 다시 받아와 로컬 설정을 전체적으로 대체합니다 — 즉 설정 파일을 직접 수동으로 고친 내용은 다음 업데이트 시 덮어씌워진다는 의미입니다. 장기적으로 커스터마이징(사용자 규칙 추가, 포트 변경 등)이 필요할 때는 클라이언트가 제공하는 오버라이드 / 병합 기능(예: Clash Verge Rev의 Merge / Script)을 사용해 구독 외부에서 변경 내용을 선언하면 매번 업데이트 후 자동으로 다시 적용됩니다. 자동 업데이트는 전체 플랫폼에서 켜두고 간격을 12~24시간으로 설정하는 것을 권장합니다. 업데이트 실패의 분류별 해결법은 《Clash 구독 업데이트 실패 해결법》에서, 형식 비호환 시 변환 방법은 《Clash 구독 형식 알아보기》에서 확인하세요.
YAML은 들여쓰기와 콜론 뒤 공백에 민감합니다. 수동 편집 후 코어가 "설정 해석 실패"를 보고한다면 열에 아홉은 들여쓰기 레벨이나 전각/반각 콜론 문제입니다. 수정한 뒤 클라이언트에서 먼저 다시 로드해 검증하고 편집기를 닫으세요.
CH-08 ISSUES · 전체 플랫폼 공통
설정 관련 자주 발생하는 문제: 증상별 원인 파악
이 장에서는 5개 플랫폼에 공통되는 빈도 높은 문제를 증상별로 정리해, 각 항목마다 원인 파악 경로와 처리 방법을 제시합니다. 더 많은 개별 질문은 헬프 센터에서 확인하세요.
구독 가져오기 또는 업데이트 실패
세 단계로 원인을 파악하세요. 1단계, 브라우저에서 구독 링크에 직접 접속: 열리지 않으면 링크가 만료됐거나 로컬 네트워크가 안 되는 것입니다. 전자는 서비스 제공자에게 다시 받고, 후자는 일단 사용 가능한 노드로 전체 모드로 임시 접속해 구독을 받은 뒤 복구하세요. 2단계, 브라우저는 열리지만 클라이언트가 오류를 보고: 대부분 서비스 제공자가 User-Agent로 클라이언트 접근을 제한했거나 반환 형식이 클라이언트와 호환되지 않는 경우입니다 — 전자는 클라이언트 구독 설정에서 UA를 조정하고, 후자는 형식 변환이 필요합니다. 3단계, 가져오기는 성공했지만 노드 목록이 비어 있음: 받은 것이 구독 링크가 아니라 단일 노드 공유 링크일 수 있고, 또는 구독 내용이 Base64인데 클라이언트가 YAML만 인식하는 경우일 수 있습니다. 전체 진단 흐름은 관련 기술 노트에서 확인하세요.
프록시를 켰는데 인터넷이 안 됨
가까운 곳부터 순서대로 확인하세요. 로컬 단계: 시스템 프록시와 TUN이 동시에 켜져 있지 않은지, 다른 프록시 소프트웨어가 백그라운드에서 충돌하고 있지 않은지 확인하세요. 클라이언트 로그(또는 Linux의 journalctl -u mihomo)에 포트 점유 오류가 있는지 확인하세요. 노드 단계: 프록시 페이지에서 지연 시간 테스트를 실행하세요. 전부 타임아웃이면 구독 전체 문제 또는 로컬에서 서버까지의 경로가 안 되는 것이니 그룹을 바꾸거나 서비스 제공자에게 문의하세요. 일부만 타임아웃이면 해당 노드만 문제이니 전환하면 됩니다. 규칙 단계: 해외 사이트는 열리는데 특정 사이트만 이상하다면 대부분 규칙이 예상과 다르게 매칭된 경우입니다. 모드를 임시로 전체로 바꿔 확인해보세요 — 전체에서는 정상인데 규칙 모드에서 이상하면 규칙 문제임을 확인할 수 있습니다.
포트 충돌
증상: 클라이언트 로그에 bind / listen 실패가 나타나거나, 시스템 프록시를 켰는데 전체 네트워크가 안 됩니다. Windows에서는 netstat -ano | findstr 7890, macOS / Linux에서는 lsof -i :7890으로 점유 중인 프로세스를 찾으세요. 점유하고 있는 프로그램을 종료하거나 클라이언트 설정에서 혼합 포트를 7891 등 빈 포트로 변경하세요. 포트를 변경하면 시스템 프록시 지정은 클라이언트가 자동으로 동기화하지만, 환경 변수나 타사 소프트웨어에 하드코딩된 이전 포트는 수동으로 업데이트해야 합니다.
DNS 오염과 해석 이상
증상: 지연 시간 테스트는 정상인데 웹페이지가 열리지 않거나, 도메인이 명백히 잘못된 주소로 해석됩니다. 처리 순서: 설정의 dns 섹션에 enable: true와 enhanced-mode: fake-ip가 설정되어 있는지 확인하세요. 시스템 레벨에서 다른 DNS 구성 요소가 가로채고 있지 않은지 확인하세요(Android 프라이빗 DNS, Linux systemd-resolved, 라우터 DNS 캐시). TUN과 시스템 프록시 두 인계 방식을 전환해 비교하면 문제가 해석 계층인지 전달 계층인지 구분할 수 있습니다. fake-ip 모드에서 일부 오래된 앱이 가상 IP에 적응하지 못하면 dns 섹션의 fake-ip-filter에서 해당 도메인을 제외할 수 있습니다.
속도가 느림
먼저 계층을 나누고 나서 조치하세요: 노드 자체(같은 노드가 다른 기기에서도 똑같이 느린지), 전송 회선(피크 시간대에 규칙적으로 느려지는지, 프로토콜을 바꾸면 개선되는지), 로컬 설정(규칙 수가 너무 많은지, DNS가 돌아가는 경로인지). 세 계층별 테스트 방법과 처리 방법은 《Clash 속도 저하 계층별 진단법》에서 자세히 다루므로 여기서는 반복하지 않습니다. 경험상 "느림"을 먼저 지연 시간 값과 대역폭 값으로 수치화한 뒤 노드를 바꿀지 설정을 조정할지 결정하는 것이, 감으로 이것저것 바꿔보는 것보다 훨씬 효과적입니다.
클라이언트 업데이트와 설정 이전
클라이언트를 업그레이드해도 구독과 설정에는 영향이 없습니다. 이들은 사용자 데이터 폴더에 저장되므로 덮어쓰기 설치만 하면 됩니다. 클라이언트나 기기를 바꿀 때는 기존 설정을 내보낼 필요 없이 구독 링크를 새 환경에서 다시 가져오는 것이 가장 깔끔합니다 — 설정은 구독으로 생성되므로 링크 자체가 완전한 이전 수단입니다. 수동으로 옮겨야 하는 것은 오버라이드 / 병합 스크립트 같은 구독 외부의 로컬 커스터마이징뿐입니다. 클라이언트 간 이전(예: 유지보수가 종료된 Clash for Windows에서 벗어나기)도 마찬가지이며, 선택 참고는 클라이언트 비교를, 설치 파일은 모두 다운로드 페이지에서 받으세요.
한 번에 변수 하나만 바꾸세요: 노드 변경, 모드 변경, 인계 방식 변경, DNS 변경 — 하나씩 바꿀 때마다 확인하세요. 여러 곳을 동시에 바꿔 우연히 고쳐지더라도 어느 단계가 효과가 있었는지 알 수 없어, 다음에 재발하면 처음부터 다시 시작해야 합니다.