Clash 전체 플랫폼 설치·설정 가이드 - Windows, macOS, Android, iOS 및 Linux

1. 설치 전 공통 준비

클라이언트, 코어, 설정 파일의 차이

Clash는 실제로 세 부분으로 구성됩니다. 그래픽 클라이언트는 설정 표시, 정책 전환, 시스템 프록시 제어 및 업데이트 관리를 담당합니다. 코어는 규칙을 해석하고 연결을 생성하며 DNS와 TUN 트래픽을 처리합니다. 설정 파일에는 프록시 진입점, 정책 그룹, 분기 규칙, 포트 및 DNS 매개변수가 저장됩니다. 대부분의 데스크톱·모바일 클라이언트에는 호환 코어가 이미 포함되어 있으므로 일반 사용자가 Mihomo를 별도로 다운로드할 필요는 없습니다. 서버, 라우터, 컨테이너 환경에서 서비스를 직접 운영하거나 프로세스를 직접 관리해야 할 때만 코어를 별도로 배포하면 됩니다.

구독 링크는 클라이언트가 자동으로 생성하는 정보가 아닙니다. 일반적으로 네트워크 서비스 제공업체가 발급하며, 클라이언트는 링크를 읽어 로컬 설정으로 변환할 뿐입니다. 공개 코드 저장소, 클라이언트 공식 웹사이트 및 이 사이트의 다운로드 페이지에서는 바로 사용할 수 있는 프록시 구독을 제공하지 않습니다. 구독 주소를 받았다면 민감 정보로 취급하고 스크린샷, 공개 문의, 공유된 명령 기록 파일 또는 공개 코드 저장소에 넣지 마세요. YAML 파일만 받은 경우에는 로컬 설정으로 가져오면 되며, 먼저 구독 링크로 변환할 필요가 없습니다.

기기에 맞는 클라이언트 선택

처음 설치할 때는 그래픽 클라이언트를 우선 선택하세요. Windows, macOS, Android, iOS에서는 먼저 Clash Plus를 확인할 수 있습니다. Windows와 macOS에서는 인터페이스 취향에 따라 Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 선택할 수 있고, Android에서는 Clash Meta for Android, FlClash 또는 Surfboard를 사용할 수 있습니다. Linux 데스크톱에서는 Clash Verge Rev와 FlClash를 선택할 수 있습니다. Clash for Windows와 ClashX Meta는 유지 관리가 중단되었으므로 기존 환경을 다룰 때만 적합하며, 새 설치의 출발점으로는 권장하지 않습니다. 사용 가능한 모든 다운로드 경로는 클라이언트 다운로드 페이지에 모아 두었으니, 오래된 가이드의 파일명만 보고 현재 패키지의 적합성을 판단하지 마세요.

다운로드 전에 프로세서 아키텍처를 확인하세요. Windows 일반 기기는 x64를 사용하며, Windows on ARM 기기는 클라이언트가 해당 빌드를 제공하는지 확인해야 합니다. Apple Silicon Mac은 arm64, 구형 Intel Mac은 x64 아키텍처입니다. Android 설치 패키지는 arm64, arm 및 범용 빌드로 제공되는 경우가 많습니다. 최근 주류 스마트폰은 대개 arm64이지만 브랜드만으로 판단해서는 안 됩니다. Linux에서는 CPU 아키텍처와 패키지 형식을 함께 구분해야 합니다. Debian과 Ubuntu는 보통 deb, Fedora 계열은 보통 rpm을 사용하며, 압축 패키지는 실행 권한과 서비스 관리를 직접 설정해야 합니다.

플랫폼	우선 선택	설치 전 확인	트래픽 처리 방식
Windows	Clash Plus	x64 아키텍처, 관리자 권한 필요 여부	시스템 프록시 또는 TUN
macOS	Clash Plus	Apple Silicon 또는 Intel	시스템 프록시 또는 TUN
Android	Clash Plus	CPU 아키텍처, 시스템 VPN 권한	로컬 VPN 서비스
iOS	Clash Plus	App Store 계정 및 시스템 권한	Network Extension
Linux	Clash Verge Rev	배포판, 데스크톱 환경, 아키텍처	데스크톱 프록시, TUN 또는 서비스 프로세스

설치에 필요한 정보 정리

시작하기 전에 구독 링크 또는 YAML 파일, 기기 관리자 권한, 정상적으로 인터넷에 연결되는 기본 네트워크, 결과 확인에 사용할 브라우저를 준비하세요. 회사나 학교 기기는 관리 정책으로 프록시, VPN, 네트워크 확장 및 인증서 설정이 잠겨 있을 수 있습니다. 이 경우 클라이언트 설치에 성공해도 시스템 네트워크 상태를 변경하지 못할 수 있습니다. 같은 종류의 클라이언트를 여러 개 연속으로 실행하지 마세요. 두 프로그램이 같은 포트를 동시에 감시하거나 시스템 프록시를 덮어쓰고 TUN 인터페이스를 만들면 시작 실패, 네트워크 루프, 종료 후 연결 복구 불가 문제가 자주 발생합니다.

기본 설정에서는 HTTP와 SOCKS의 공통 진입점으로 mixed-port를 사용하는 경우가 많습니다. 포트 값은 설정에 따라 달라지며 7890이 흔한 예지만, 최종 기준은 클라이언트 화면에 표시된 값입니다. 브라우저나 터미널 프록시를 직접 입력할 때 호스트는 보통 로컬 루프백 주소 127.0.0.1이고, 포트는 실행 중인 설정과 반드시 일치해야 합니다. 구독 서비스의 원격 포트를 시스템 프록시에 잘못 입력하지 말고, 다른 기기의 접속이 꼭 필요한 경우가 아니라면 LAN 주소를 기본 수신 주소로 사용하지 마세요.

규칙, 전체, 직접 연결 모드 이해하기

규칙 모드는 설정의 rules를 위에서 아래로 적용해 도메인, IP, 프로세스 또는 규칙 세트를 매칭하고, 연결을 지정된 정책 그룹으로 전달합니다. 일상적인 사용에서는 기본 선택으로 적합합니다. 전체 모드는 분기 규칙을 무시하고 프록시 가능한 트래픽을 모두 전체 정책으로 전달하므로 규칙 오판 여부를 잠시 확인할 때 유용하지만 장기간 사용하기에는 적합하지 않습니다. 직접 연결 모드는 프록시를 우회하며 기본 네트워크를 복구하거나 문제가 클라이언트에서 비롯되었는지 확인할 때 사용합니다. 모드 전환만으로 잘못된 구독이 수정되거나 정책 그룹의 사용할 수 없는 선택 항목이 자동으로 교체되지는 않습니다.

가져온 뒤에는 먼저 정책 그룹을 확인하세요. 흔한 그룹명으로 Proxy, Auto, Streaming, Final, REJECT가 있습니다. 수동 선택 그룹에서는 사용할 수 있는 정책을 명확히 선택해야 합니다. 자동 테스트 그룹은 설정에 정의된 테스트 방식에 따라 선택 항목을 갱신합니다. Final은 앞선 규칙에 매칭되지 않은 연결을 처리하는 경우가 많고, REJECT는 매칭된 트래픽을 거부합니다. 구독마다 이름이 다를 수 있으므로 고정된 한국어 버튼을 기계적으로 찾지 말고 그룹의 유형과 용도를 기준으로 조작하세요.

2. Windows 다운로드, 설치 및 시스템 프록시 설정

그래픽 클라이언트 다운로드 및 설치

Windows에 새로 설치할 때는 Windows 클라이언트 영역에서 Clash Plus를 선택할 수 있습니다. Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 사용해도 됩니다. Clash for Windows는 유지 관리가 중단되었으므로 이전 설정과의 호환이나 기존 데이터 마이그레이션이 꼭 필요한 경우에만 사용하세요. 다운로드가 끝나면 설치 패키지를 실행합니다. 시스템에 사용자 계정 컨트롤 확인창이 나타나면 파일 출처와 현재 작업을 확인한 뒤 권한을 부여할지 결정하세요. 설치 경로는 일반 로컬 디스크를 사용하고 임시 폴더, 동기화 드라이브 또는 기업 정책의 제한을 받는 폴더는 피하는 것이 좋습니다.

일부 클라이언트는 현재 사용자 설치와 모든 사용자 설치를 제공합니다. 전자는 지속적인 관리자 권한이 필요하지 않은 경우가 많고, 후자는 여러 계정에서 프로그램 파일을 공유하기 편리하지만 설정 데이터는 사용자 폴더별로 따로 저장될 수 있습니다. TUN을 활성화하거나 서비스를 설치하거나 시작 시 자동 실행을 설정하면 첫 작업에서 관리자 권한을 요청할 수 있습니다. 기존 시스템 프록시만 켜는 경우에는 보통 계속 관리자 권한으로 실행할 필요가 없습니다. 항상 관리자 권한으로 실행하면 드래그 앤 드롭, 브라우저 호출 및 일반 사용자 폴더 접근에 불필요한 제약이 생길 수 있으므로 일반적인 해결책으로 사용하지 마세요.

구독 가져오기 및 설정 활성화 확인

설정 파일 또는 Profiles 페이지에서 URL 가져오기를 선택하고 전체 구독 주소를 입력란에 붙여넣은 뒤 다운로드를 실행하세요. 가져오기에 성공했다고 설정이 활성화된 것은 아닙니다. 설정 목록에서 방금 가져온 항목을 선택해 현재 설정으로 지정해야 합니다. 로컬 YAML을 사용한다면 로컬 파일 가져오기를 선택하거나 클라이언트가 허용한 설정 폴더에 파일을 넣으세요. 클라이언트 내부 캐시 파일을 직접 편집하면 구독 업데이트 때 덮어써질 수 있습니다. 장기간 유지할 사용자 규칙은 클라이언트가 제공하는 오버라이드, 병합 또는 스크립트 기능을 사용하세요.

설정을 활성화한 뒤 프록시 모드, 정책 그룹 및 포트를 차례로 확인하세요. 일상 사용에는 규칙 모드가 적합합니다. Proxy 같은 수동 정책 그룹을 열고 구독에 실제로 존재하는 정책을 선택하세요. 설정에 Auto 또는 url-test 그룹이 있다면 먼저 한 번 업데이트를 실행할 수 있습니다. 화면에 녹색 상태가 표시되는지만으로 판단하지 말고, 이후 실제 연결을 확인해야 합니다. 설정을 다운로드한 뒤 목록이 비어 있다면 시스템 프록시 스위치보다 구독 응답 형식, 인증 상태 또는 네트워크 접근 문제일 가능성이 큽니다.

시스템 프록시와 TUN의 적용 범위

Windows 시스템 프록시는 로컬 프록시 주소를 시스템 설정에 기록합니다. WinINET 또는 시스템 프록시 설정을 따르는 브라우저와 데스크톱 애플리케이션은 자동으로 사용하지만, 일부 게임, 명령줄 도구, 스토어 앱 및 자체 네트워크 스택을 구현한 프로그램은 이를 무시할 수 있습니다. 활성화한 뒤 Windows 프록시 설정에서 로컬 주소와 포트를 확인할 수 있습니다. 클라이언트를 정상적으로 종료하면 보통 설정이 복원되지만, 프로세스를 강제 종료하거나 시스템이 비정상적으로 꺼지면 중지된 포트를 가리키는 프록시 항목이 남아 모든 웹페이지가 열리지 않을 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 IP 트래픽을 처리하므로 시스템 프록시를 읽지 않는 애플리케이션에 적합합니다. 처음 활성화할 때 드라이버나 시스템 서비스를 설치하고 관리자 승인을 요청할 수 있습니다. 켠 뒤에는 라우팅 테이블, DNS 및 방화벽이 정상인지 확인하고, TUN이나 전역 VPN 인터페이스를 만드는 다른 소프트웨어를 동시에 실행하지 마세요. 시스템 프록시와 TUN을 함께 켤 수 있는지는 클라이언트 구현에 따라 다릅니다. 처음 문제를 확인할 때는 한 가지 처리 방식만 유지하고 안정성을 확인한 뒤 조합 사용 여부를 결정하세요.

명령줄, 터미널 및 개발 도구

PowerShell, 명령 프롬프트, Git, 패키지 관리자 및 프로그래밍 언어 런타임이 항상 Windows 시스템 프록시를 읽는 것은 아닙니다. 필요하면 현재 터미널 세션에 환경 변수를 설정하고, 포트는 클라이언트의 현재 mixed-port로 바꾸세요. 임시 변수는 해당 터미널과 하위 프로세스에만 영향을 주며 창을 닫으면 사라지므로 테스트에 적합합니다. 사용자 수준 환경 변수에 저장하기 전에는 오프라인 개발, LAN 서비스 또는 컨테이너 도구의 경로가 잘못 바뀌지 않는지 확인하세요.

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

이후 클라이언트를 중지할 때는 영구 저장된 Git 프록시 설정도 함께 삭제해야 합니다. 그렇지 않으면 Git이 계속 꺼진 로컬 포트에 연결합니다. git config --global --unset http.proxy와 해당 HTTPS 명령으로 정리할 수 있습니다. 터미널은 접속되지만 브라우저가 접속되지 않으면 시스템 프록시, 브라우저 확장 및 보안 소프트웨어를 먼저 확인하세요. 브라우저는 접속되지만 터미널이 접속되지 않으면 환경 변수, Git 설정 및 도구 자체의 프록시 항목을 중점적으로 확인합니다.

Windows 특유의 문제 범위

포트 점유는 Windows에서 시작 실패를 일으키는 흔한 원인입니다. 클라이언트 로그에 주소가 이미 사용 중이라고 표시되면 다른 Clash 인스턴스나 남은 프로세스가 있는지 먼저 확인한 뒤 프로세스를 종료할지 mixed-port를 변경할지 결정하세요. 자세한 확인 방법은 포트 점유 확인 절차를 참고하세요. 포트를 변경한 뒤에는 시스템 프록시, 브라우저 수동 프록시, 터미널 환경 변수 및 LAN 기기의 설정도 모두 맞춰야 합니다.

종료 후 네트워크가 끊기면 먼저 Windows 수동 프록시를 끄고 가상 네트워크 어댑터, 프록시 환경 변수 또는 다른 VPN이 남아 있는지 확인하세요. 가상 스위치, 고정 DNS 및 개발 환경 설정까지 함께 지워지므로 네트워크 구성 요소 전체를 즉시 초기화하지 마세요. 먼저 클라이언트 프로세스가 종료되었는지 확인한 다음 시스템 프록시, DNS, 기본 경로, TUN 서비스 순서로 단계적으로 복구하세요. 절전 모드에서 깨어난 뒤에만 문제가 생기면 클라이언트 코어를 재시작한 뒤 TUN을 다시 구성해 보세요. 라우팅 충돌이나 보안 정책이 원인인 경우 잦은 재설치로는 해결되지 않습니다.

3. macOS 설치, 네트워크 확장 및 프록시 전환

프로세서 아키텍처에 맞는 설치 패키지 선택

macOS에서 다운로드하기 전에 ‘이 Mac에 관하여’를 열어 칩 유형을 확인하세요. Apple Silicon은 arm64 빌드, Intel 프로세서는 x64 빌드에 해당합니다. 새로 설치할 때는 macOS 클라이언트 영역에서 Clash Plus를 선택하거나 Clash Verge Rev 또는 FlClash를 사용할 수 있습니다. ClashX Meta는 유지 관리가 중단되었으며 주로 기존 환경 마이그레이션에 사용됩니다. 아키텍처를 잘못 선택하면 프로그램이 시작되지 않거나 변환 계층으로 실행되거나 보조 서비스 설치에 실패할 수 있으므로 파일명에 macOS가 포함되었는지만 보고 호환성을 판단하지 마세요.

일반적인 설치 방법은 디스크 이미지를 열고 애플리케이션을 ‘응용 프로그램’ 폴더로 드래그한 뒤 해당 폴더에서 처음 실행하는 것입니다. 다운로드 폴더나 마운트된 디스크 이미지에서 계속 실행하지 마세요. 자동 업데이트, 로그인 시 실행 및 보조 서비스 경로가 불안정해질 수 있습니다. 시스템이 실행을 차단하면 먼저 다운로드 출처를 확인한 뒤 ‘개인정보 보호 및 보안’에서 관련 안내를 확인하세요. 개별 애플리케이션의 권한 문제를 해결하려고 시스템 보안 설정 전체를 낮추지 마세요.

설정 가져오기 및 메뉴 막대 조작

Profiles 또는 설정 페이지에서 URL로 구독을 가져오거나 로컬 YAML을 가져오세요. 다운로드가 끝나면 설정을 명확히 선택한 뒤 정책 페이지에서 Proxy, Auto 또는 설정에 정의된 다른 그룹을 선택합니다. macOS 클라이언트는 메뉴 막대에 상주하므로 주 창을 닫아도 코어가 중지된 것은 아닙니다. 포트 점유나 남은 프록시를 확인할 때는 메뉴 막대에서 종료하거나 활성 상태 보기에서 관련 프로세스가 계속 실행 중인지 확인해야 합니다.

구독 업데이트는 원격 콘텐츠를 다시 가져옵니다. 클라이언트가 자동 업데이트 간격을 지원한다면 서비스 제공업체의 업데이트 방식에 맞춰 설정하고 지나치게 잦은 폴링은 피하세요. 원격 설정과 로컬 수정이 함께 있으면 다음 업데이트에서 직접 편집한 내용이 덮어써질 수 있습니다. 분기 규칙, DNS 또는 스크립트를 추가해야 한다면 오버라이드 설정을 우선 사용하세요. 전체 프록시 정보가 포함된 설정 파일을 내보내기 전에 저장 위치와 접근 권한을 확인하세요.

시스템 프록시의 작동 방식

시스템 프록시를 켜면 클라이언트가 현재 네트워크 서비스의 웹 프록시와 보안 웹 프록시 설정을 변경합니다. Safari와 시스템 설정을 따르는 앱은 보통 바로 적용되지만, 일부 명령줄 도구, 샌드박스 앱 및 연결을 자체 관리하는 프로그램은 이 설정을 읽지 않습니다. Wi-Fi, 이더넷, 핫스팟으로 전환하거나 새 네트워크 서비스를 추가한 뒤에는 프록시 상태를 다시 확인하세요. macOS의 프록시 설정은 특정 네트워크 서비스와 연결되어 있기 때문입니다.

scutil --proxy를 사용해 시스템이 현재 읽는 프록시 정보를 확인할 수 있습니다. 이 명령은 설정이 기록되었는지만 보여 줄 뿐, 로컬 포트가 연결을 받을 수 있는지 또는 정책 그룹에 사용 가능한 선택 항목이 있는지는 알려 주지 않습니다. 클라이언트가 종료되었는데 프록시 주소가 남아 있다면 클라이언트에서 다시 켠 뒤 정상적으로 종료해 복구 절차를 실행하세요. 시스템 네트워크 설정에서 해당 프록시 항목을 직접 끌 수도 있습니다. 브라우저 확장, 자동 프록시 구성 파일 및 클라이언트 시스템 프록시가 서로 덮어쓰도록 동시에 설정하지 마세요.

scutil --proxy
networksetup -listallnetworkservices
lsof -nP -iTCP:7890 -sTCP:LISTEN

TUN, 시스템 확장 및 권한

macOS의 TUN 모드는 보통 보조 서비스 설치, 가상 인터페이스 생성 또는 네트워크 확장 권한을 필요로 합니다. 처음 활성화할 때 관리자 인증 정보를 입력하고 개인정보 보호 및 보안 설정에서 확인해야 할 수 있습니다. 승인이 끝난 뒤에도 클라이언트로 돌아와 코어가 실제로 시작되었는지 확인하세요. 버튼이 잠시 켜졌다가 자동으로 꺼지면 반복해서 클릭하지 말고 로그에서 권한, 라우팅, DNS 또는 인터페이스 생성 오류를 확인하세요.

TUN은 시스템 프록시를 따르지 않는 앱까지 처리할 수 있지만 다른 VPN, 기업 보안 클라이언트, 가상 머신 네트워크 및 컨테이너 네트워크와 라우팅 충돌을 일으키기 쉽습니다. 문제를 확인할 때는 기본 경로나 DNS 프록시를 만드는 다른 프로그램을 먼저 종료하고 트래픽 처리 도구 하나만 남기세요. LAN 프린터, NAS 또는 개발 서버에 접근할 수 없다면 모든 트래픽을 직접 연결로 바꾸기보다 설정의 사설 주소 직접 연결 규칙과 우회 경로를 확인하세요.

터미널 프록시 및 인증서 범위

Terminal, Homebrew, Git, curl 및 언어 패키지 관리자는 별도로 프록시를 설정해야 할 수 있습니다. 현재 shell에서 HTTP, HTTPS 및 ALL_PROXY를 내보낼 수 있습니다. zsh를 사용하면서 변수를 설정 파일에 기록한다면 해제 방법도 함께 준비하세요. 프록시 변수를 장기간 유지하면 클라이언트가 실행되지 않을 때 터미널에 연결 거부가 발생하고 로컬 개발 서버 접근에도 영향을 줄 수 있습니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

curl -I https://example.com

unset http_proxy https_proxy all_proxy

일반적인 Clash 프록시는 기본 연결을 위해 사용자 지정 루트 인증서를 설치할 필요가 없습니다. HTTPS 복호화, 스크립트 디버깅 또는 특정 도구 체인을 명확히 사용할 때만 인증서 신뢰 설정이 필요합니다. TLS 오류가 발생하면 먼저 시스템 시간, 도메인 확인, 프록시 정책 및 애플리케이션 자체 인증서 저장소를 확인하고, 인증서 검증 비활성화를 장기 해결책으로 사용하지 마세요. 회사 기기의 인증서와 네트워크 확장은 관리 설정의 적용을 받을 수 있으므로 이런 제한은 기기 관리자가 처리해야 합니다.

4. Android 설치, VPN 권한 및 백그라운드 실행

설치 패키지 선택 및 설치 완료

Android에서는 Android 클라이언트 영역에서 Clash Plus를 선택하거나 Clash Meta for Android, FlClash 또는 Surfboard를 사용할 수 있습니다. 설치 패키지는 arm64, arm 및 범용 아키텍처로 제공될 수 있습니다. 최근 주류 기기는 대개 arm64이지만 구형 기기, TV 박스 및 에뮬레이터는 다를 수 있습니다. 확실하지 않다면 클라이언트가 제공하는 범용 빌드를 사용하세요. 시스템에서 패키지를 분석할 수 없다고 표시되면 아키텍처, 시스템 버전, 파일의 완전한 다운로드 여부 및 해당 출처의 앱 설치 허용 여부를 함께 확인해야 합니다.

브라우저나 파일 관리자를 통해 설치할 때 Android는 현재 출처에 설치 권한을 부여하도록 요청합니다. 설치가 끝나면 해당 출처 권한을 취소해도 클라이언트 실행에는 영향이 없습니다. 동일한 패키지명이지만 서명이 다른 버전이 이미 설치되어 있으면 덮어쓰기 설치가 거부될 수 있습니다. 이 경우 보존할 설정을 먼저 내보낸 다음 기존 앱을 삭제하고 다시 설치하세요. 특히 로컬 오버라이드, 스크립트 및 수동으로 가져온 YAML은 삭제 전에 앱 데이터가 자동으로 복구된다고 가정하지 마세요.

구독 가져오기 및 로컬 VPN 생성

클라이언트를 연 뒤 설정 페이지에서 구독 URL을 추가하고 식별하기 쉬운 이름을 입력한 다음 업데이트를 실행하세요. 업데이트가 끝나면 해당 설정을 현재 설정으로 선택하고 프록시 그룹에서 정책을 고릅니다. 처음 연결할 때 Android는 VPN 연결 요청을 표시합니다. 이는 앱이 로컬 VPN 인터페이스를 만들 수 있도록 시스템이 권한을 부여하는 절차입니다. 승인하면 상태 표시줄에 보통 VPN 표시가 나타납니다. 이 표시는 인터페이스가 만들어졌다는 뜻일 뿐이므로 브라우저나 클라이언트 로그로 트래픽이 실제로 전달되는지 확인해야 합니다.

Android에서는 일반 VPN 서비스를 보통 한 번에 하나만 활성 상태로 둘 수 있습니다. 시스템이 이미 다른 VPN, 회사 업무 프로필 네트워크 또는 광고 차단 도구에 연결되어 있으면 새 연결이 기존 연결을 교체하거나 시스템에서 거부할 수 있습니다. 프라이빗 DNS와 Clash 내부 DNS가 서로 다른 확인 경로를 만들 수도 있습니다. 도메인은 열리지 않지만 IP 직접 접속은 정상이라면 프라이빗 DNS 설정을 잠시 확인하고 설정의 nameserver, fallback 또는 fake-ip 동작을 점검하세요.

앱별 분기 및 우회 설정

모바일 클라이언트는 앱별로 프록시를 사용하거나 우회하거나 특정 앱에만 적용하는 기능을 제공하는 경우가 많습니다. 은행 앱, LAN 제어, 화면 미러링 또는 VPN에 민감한 앱을 직접 연결로 유지하거나 브라우저와 통신 도구만 처리할 때 유용합니다. 앱 목록을 수정한 뒤에는 규칙이 적용되도록 VPN 인터페이스를 다시 만들어야 합니다. 시스템 앱은 여러 패키지로 구성될 수 있으므로 홈 화면 아이콘 이름만으로 관련 프로세스 전체를 포함할 수 없습니다.

규칙 모드는 여전히 설정 규칙에 따라 대상 연결의 방향을 결정하고, 앱별 분기는 그보다 앞선 단계에서 특정 앱이 Clash에 들어올지 결정합니다. 둘을 혼동하지 마세요. 앱을 우회하도록 설정하면 해당 트래픽은 도메인 규칙에 들어오지 않으므로 규칙에 프록시가 명시되어 있어도 적용되지 않습니다. 특정 앱을 점검할 때는 먼저 앱별 분기 목록을 확인하고, 그다음 규칙 매칭과 정책 그룹을 확인한 뒤 해당 앱이 QUIC, 사용자 지정 DNS 또는 인증서 고정을 사용하는지 확인하세요.

백그라운드 제한 및 시스템에 의한 연결 회수

Android 제조사는 백그라운드 활동, 배터리 사용 및 자동 시작을 추가로 제한하는 경우가 많습니다. 화면을 잠근 뒤 일정 시간이 지나면 연결이 끊기거나, 최근 작업을 정리하면 VPN이 사라지거나, 모바일 네트워크 전환 후 복구되지 않는 식으로 나타납니다. 시스템 설정에서 클라이언트의 백그라운드 실행을 허용하고, 기기에서 제공하는 옵션으로 과도한 배터리 최적화를 끄며, 필요한 자동 시작을 허용하세요. 제조사마다 메뉴 이름은 다르지만 핵심은 시스템이 클라이언트 프로세스를 동결하거나 VPN 서비스를 제한하지 않게 하는 것입니다.

Android 시스템의 상시 연결 VPN은 네트워크 변경 후 복구를 시도할 수 있지만, 설정이 안정적인지 확인하기 전에는 ‘VPN 없이 연결 차단’을 동시에 켜지 않는 것이 좋습니다. 구독이 만료되거나 클라이언트가 충돌하거나 코어 시작에 실패하면 기기가 완전히 인터넷에 연결되지 않을 수 있습니다. Wi-Fi, 모바일 네트워크, 절전 모드 복귀 및 재시작 후 동작을 먼저 확인한 다음 엄격한 모드의 사용 여부를 결정하세요. 일시적으로 네트워크를 복구해야 한다면 클라이언트 화면만 닫지 말고 시스템 VPN 페이지에서 먼저 연결을 끊으세요.

핫스팟, LAN 및 IPv6

휴대폰에서 핫스팟을 켰을 때 핫스팟에 연결된 기기가 Clash를 거치는지는 시스템 버전, 클라이언트 기능 및 전달 구현에 따라 달라집니다. 일반적인 Android VPN은 보통 본체 앱의 트래픽만 보장하므로 핫스팟에 연결된 다른 기기까지 자동으로 처리된다고 가정하지 마세요. 공유가 필요하다면 클라이언트가 핫스팟 전달 또는 LAN 연결 허용을 명시적으로 제공하는지 확인하고, 하위 기기에서 휴대폰의 LAN 주소와 프록시 포트를 직접 설정하세요. 이때 앱의 LAN 수신을 허용하고 공용 네트워크에서의 접근 위험에도 주의해야 합니다.

일부 모바일 네트워크는 IPv6를 우선 사용합니다. 설정이 IPv4 DNS만 제공하거나 규칙이 IPv4만 다루면 앱마다 결과가 다를 수 있습니다. 장기적인 해결책으로 시스템 IPv6를 바로 끄지 마세요. 먼저 코어의 IPv6 스위치, DNS 응답, 규칙 매칭 및 프록시 진입점이 해당 연결을 지원하는지 확인하세요. 로그에서 도달할 수 없는 IPv6 주소에 연결을 시도하는 것으로 보이면 원인 확인을 위해 설정을 임시로 조정한 뒤 네트워크 환경에 따라 듀얼 스택 사용 여부를 결정하세요.

Android 쪽 로그는 문제의 계층을 판단하는 중요한 근거입니다. 설정 해석 오류는 보통 코어가 시작되기 전에 나타나고, DNS 오류는 확인 실패나 시간 초과로 표시됩니다. 정책 문제는 규칙 매칭 후 연결 실패로 나타나며, 앱이 제외된 경우에는 해당 요청 자체가 전혀 기록되지 않을 수 있습니다. 이 네 가지 계층에 따라 확인하는 편이 클라이언트를 계속 바꾸는 것보다 원인을 찾기 쉽습니다.

5. iOS 설치, 설정 가져오기 및 필요 시 연결

App Store에서 Clash Plus 설치

iPhone과 iPad에서는 iOS 다운로드 영역에서 Clash Plus의 App Store 페이지로 이동할 수 있으며, 클라이언트 공식 웹사이트는 clashplus.io입니다. 설치 후 처음 실행하면 시스템에서 VPN 설정 추가를 요청할 수 있습니다. 이 권한은 Network Extension을 생성하기 위한 것이며 모든 연결이 이미 프록시를 사용한다는 뜻은 아닙니다. 승인한 뒤에도 설정을 가져오고 정책을 선택한 다음 연결을 시작해야 합니다.

iOS의 네트워크 처리는 시스템 확장이 관리하므로 데스크톱 시스템 프록시 스위치를 사용하지 않습니다. 상태 표시줄이나 제어 센터에 VPN 표시가 나타나면 확장이 연결 상태라는 뜻입니다. 앱의 기본 화면을 닫아도 확장이 계속 실행될 수 있으며, 시스템 설정에서 연결을 끊으면 앱의 상태도 함께 갱신되어야 합니다. 문제를 확인할 때는 앱 화면과 ‘설정’의 VPN 상태를 모두 확인해 한쪽 화면만으로 판단하지 마세요.

구독 가져오기 및 로컬 설정

설정 페이지에서 구독 URL을 추가하고 업데이트한 뒤 해당 설정을 선택하세요. 다른 앱에서 구독 링크를 복사했다면 앞뒤에 공백이나 줄바꿈이 붙었는지, 메신저에서 잘리지 않았는지 확인하세요. 파일 앱으로 YAML을 가져올 때는 시스템 공유 메뉴에서 Clash Plus로 보내고, 설정 목록에서 가져오기 결과를 확인할 수 있습니다. 설정 파일이 외부 규칙 세트를 참조한다면 처음 로드할 때 관련 리소스도 다운로드해야 합니다. 기본 YAML만 성공적으로 가져왔다고 모든 규칙 리소스가 준비된 것은 아닙니다.

정책 그룹 선택 방식은 다른 플랫폼과 같습니다. 규칙 모드는 규칙에 따라 트래픽을 분기하고, 수동 그룹은 실제 정책을 선택해야 하며, 자동 그룹은 설정의 테스트 방식에 따라 선택을 갱신합니다. 모바일 네트워크 환경은 자주 바뀌므로 Wi-Fi에서 사용할 수 있는 정책이 셀룰러 네트워크에서도 연결된다고 보장할 수 없습니다. 특정 네트워크에서만 실패하면 설정을 유지한 채 Wi-Fi와 셀룰러 네트워크의 로그를 비교하세요. DNS, 모드 및 정책을 동시에 바꾸면 변수를 구분할 수 없습니다.

필요 시 연결 및 시스템 네트워크 전환

필요 시 연결은 시스템 네트워크 상태에 따라 확장을 자동으로 시작하므로 안정성을 확인한 설정에 적합합니다. 활성화하기 전에 수동으로 전체 연결을 한 번 완료하고 Wi-Fi, 셀룰러 네트워크 및 화면 잠금 복귀를 각각 테스트하세요. 필요 시 연결 규칙을 잘못 설정하면 신뢰할 수 있는 LAN에서도 자동으로 처리되어 프린터, 화면 미러링 및 가정용 기기 접근에 영향을 줄 수 있습니다. LAN 접근이 필요하다면 사설 주소 직접 연결 규칙을 유지하고 로컬 네트워크 권한이 부여되었는지 확인하세요.

iOS는 네트워크 전환, 배터리 부족 및 시스템 리소스 부족 상황에서 네트워크 확장을 다시 만들 수 있습니다. 잠시 연결이 끊기면 먼저 확장이 다시 협상할 때까지 기다린 뒤 앱 로그를 확인하세요. 연결 중 상태에서 반복적으로 멈추면 시스템 설정에서 VPN 연결을 끊고 클라이언트로 돌아와 다시 시작하세요. 여러 VPN 설정을 필요 시 연결 상태로 동시에 유지하면 시스템의 선택 동작을 판단하기 어려워집니다.

DNS, QUIC 및 앱별 차이

Safari, 기본 앱 및 타사 브라우저는 서로 다른 연결 방식을 사용할 수 있습니다. 일부 앱은 HTTP/3 또는 사용자 지정 확인을 우선 시도하므로 브라우저는 되지만 특정 앱만 시간 초과가 발생할 수 있습니다. 설정의 DNS 모드, 규칙 및 UDP 지원이 함께 결과에 영향을 줍니다. UDP를 끈 뒤 특정 앱이 복구된다면 UDP 전달 또는 QUIC 경로에 문제가 있을 가능성이 있습니다. 이는 원인 확인을 위한 단서일 뿐이며, 모든 UDP를 끄는 것을 장기적인 해결책으로 삼아서는 안 됩니다.

fake-ip 모드는 도메인에 예약 주소를 반환한 뒤 코어가 도메인을 복원해 규칙을 매칭합니다. 일반적으로 분기 일관성을 높일 수 있지만 LAN 검색, 일부 기기 제어 앱 및 특수 도메인은 필터 목록에 추가해야 할 수 있습니다. redir-host는 실제 DNS 응답에 가까워 호환 방식이 다릅니다. 두 모드 중 모든 네트워크에 적용되는 정답은 없으므로 설정 규칙, LAN 요구 사항 및 로그를 기준으로 선택하세요. 누수 및 nameserver의 전체 확인 방법은 DNS 확인 및 설정 안내를 참고하세요.

배터리, 백그라운드 및 설정 관리

네트워크 확장이 연결을 계속 처리하면 일정한 배터리 전력을 사용합니다. 규칙 수, DNS 조회, 로그 수준 및 네트워크 품질도 실제 사용량에 영향을 줍니다. 일상적으로 debug 로그를 장시간 유지하지 마세요. 상세 로그는 짧은 재현과 확인에 적합하며, 점검이 끝나면 일반 수준으로 되돌려야 합니다. 배터리 소모가 갑자기 늘었다면 VPN 아이콘이 얼마나 오래 표시되었는지만 보지 말고 연결 재시도, DNS 루프 또는 여러 자동 테스트 그룹의 잦은 실행 여부를 먼저 확인하세요.

구독을 업데이트하기 전에 현재 정책 그룹 선택을 기록해 두면 좋습니다. 일부 설정 업데이트는 정책 그룹을 다시 만들며 이름이 바뀌어 기존 선택이 기본 항목으로 돌아갈 수 있습니다. 업데이트 후 갑자기 접속할 수 없다면 설정 활성화 여부, 정책 그룹에 선택 항목이 남아 있는지, 규칙 리소스 다운로드 완료 여부, 확장 재생성 여부를 순서대로 확인하세요. 앱 삭제 및 재설치는 로컬 오버라이드와 이전 로그도 함께 삭제하므로 설정 백업과 기본 점검 이후에 진행해야 합니다.

iOS에서는 데스크톱 시스템처럼 전체 라우팅 테이블과 수신 프로세스를 직접 확인할 수 없으므로 클라이언트 로그와 비교 테스트에 더 의존합니다. 한 번에 조건 하나만 바꾸세요. 먼저 정책을 바꾸고, 다음으로 모드를 바꾸고, 마지막으로 DNS를 확인하는 방식이 좋습니다. 같은 단계에서 설정을 다시 만들고 네트워크까지 전환하면 복구되더라도 실제 원인을 확인할 수 없습니다.

6. Linux 데스크톱 클라이언트 및 코어 서비스 배포

데스크톱 환경별 설치 선택

Linux 데스크톱에서는 Linux 다운로드 영역에서 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 설치 전에 배포판, CPU 아키텍처 및 패키지 형식을 확인하세요. Debian, Ubuntu 및 파생 시스템은 보통 deb, Fedora와 RHEL 계열은 보통 rpm을 사용합니다. 패키지 관리자로 로컬 패키지를 설치하면 의존성도 함께 확인할 수 있습니다. 실행 파일을 직접 압축 해제하는 경우에는 데스크톱 항목, 권한, 자동 시작 및 업데이트를 직접 처리해야 합니다.

데스크톱 환경마다 시스템 프록시 지원 방식이 통일되어 있지 않습니다. GNOME, KDE 및 경량 데스크톱은 프록시 설정을 기록하는 위치가 다르고, 일부 앱은 환경 변수를 읽으며 일부는 데스크톱 설정을 읽고, 둘 다 무시하는 앱도 있습니다. 따라서 그래픽 클라이언트에 ‘시스템 프록시가 켜짐’으로 표시되어도 브라우저, 터미널 및 대상 앱을 각각 확인해야 합니다. Wayland와 X11 자체가 프록시 기능을 직접 결정하는 것은 아니지만 트레이 아이콘, 권한 팝업 및 데스크톱 통합 동작에는 영향을 줄 수 있습니다.

설정 가져오기 및 수신 포트 확인

그래픽 클라이언트의 구독 가져오기 절차는 다른 데스크톱 플랫폼과 같습니다. URL 추가, 업데이트, 설정 선택, 정책 그룹 선택 후 시스템 프록시 또는 TUN을 켭니다. 코어를 사용하는 경우 권한이 제한된 폴더에 설정을 저장하고 명령줄에서 경로를 지정해 시작하세요. 시작 전에 설정 테스트를 실행하면 서비스가 반복적으로 재시작되는 문제를 피할 수 있습니다. 각 Mihomo 빌드의 매개변수는 현재 프로그램의 도움말을 기준으로 해야 하며, 일반적인 실행 형식은 다음과 같습니다.

mihomo -t -f /etc/mihomo/config.yaml
mihomo -d /etc/mihomo

ss -lntp | grep 7890
journalctl -u mihomo --no-pager -n 100

-t는 설정을 해석할 수 있는지 확인하고, -f는 단일 설정 파일을 지정하며, -d는 작업 디렉터리를 지정합니다. 작업 디렉터리에는 캐시, 규칙 세트 및 데이터베이스가 포함될 수 있으므로 실행 사용자는 필요한 읽기·쓰기 권한을 가져야 합니다. 권한 오류를 없애려고 전체 디렉터리를 모든 사용자가 쓸 수 있게 바꾸지 마세요. 서비스 프로세스는 전용 저권한 계정을 사용하고 TUN 생성, 경로 변경 또는 제한된 리소스 바인딩에 필요한 경우에만 최소 권한을 부여해야 합니다.

systemd 서비스 및 자동 시작

서버나 장기간 실행하는 데스크톱 호스트에서는 systemd로 코어를 관리할 수 있습니다. 서비스는 기본 네트워크가 사용 가능해진 뒤 시작하고, 비정상 종료 시 합리적인 간격으로 재시도해야 합니다. 설정을 업데이트하기 전 구문 검사를 실행한 뒤 서비스를 다시 로드하거나 재시작하세요. 아래 예시는 바이너리와 설정 디렉터리가 해당 경로에 준비되어 있다고 가정합니다. 실제 사용자명과 경로는 로컬 환경에 맞게 조정해야 합니다.

[Unit]
Description=Mihomo proxy core
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

서비스 유닛으로 저장한 뒤 먼저 systemctl daemon-reload를 실행하고, 서비스를 시작한 다음 로그를 확인하세요. 자동 시작은 수동 실행이 안정적인지 확인한 뒤 활성화해야 합니다. 서비스가 시작하자마자 반복적으로 실패한다면 자동 재시도를 먼저 중지하고 설정 테스트를 직접 실행하세요. 계속 재시작하면 로그가 빠르게 가득 차고 경로가 반복해서 변경될 수 있습니다. 서비스를 업그레이드할 때는 이전 바이너리와 설정 백업을 보관해 호환성 문제가 생기면 되돌릴 수 있도록 하세요.

환경 변수, 데스크톱 프록시 및 TUN

터미널 도구는 http_proxy, https_proxy 및 all_proxy를 사용할 수 있습니다. 변수명이 대소문자 형태로 함께 존재하면 도구마다 읽는 규칙이 다를 수 있습니다. 서버의 systemd 서비스는 사용자 shell 설정을 자동으로 상속하지 않으므로 서비스 유닛이나 전용 환경 파일에서 명시해야 합니다. 한 명령에만 프록시가 필요한 경우 변수의 범위를 명령 앞부분으로 제한해 전체 시스템에 영향을 주지 않도록 하는 것이 좋습니다.

http_proxy=http://127.0.0.1:7890 \
https_proxy=http://127.0.0.1:7890 \
curl -I https://example.com

all_proxy=socks5://127.0.0.1:7890 git fetch

Linux TUN 배포에는 가상 인터페이스, 정책 라우팅, DNS 및 방화벽 규칙이 관련됩니다. 코어는 /dev/net/tun에 접근하고 인터페이스 생성 및 네트워크 설정 변경에 필요한 권한을 가져야 합니다. 컨테이너에서 실행할 때는 TUN 장치와 네트워크 권한도 명시적으로 전달해야 합니다. 현재 nftables, iptables 또는 정책 라우팅을 이해하지 못한 상태에서 전체 규칙을 지우는 명령을 그대로 복사하지 마세요. 원격 연결이 끊길 수 있습니다. 라우터와 보조 라우터 환경은 OpenWrt 배포 개요에서 계속 확인할 수 있습니다.

권한, DNS 및 컨테이너 범위

장기간 root로 직접 실행하면 일부 권한 문제를 우회할 수 있지만, 설정 스크립트, 외부 규칙 및 관리 인터페이스로 인한 위험이 커집니다. 전용 계정을 사용하고 capabilities 또는 서비스 관리로 최소 권한을 부여하는 편이 적절합니다. 관리 제어 포트를 로컬에서만 사용할 경우 루프백 주소에 바인딩하세요. LAN 접근이 꼭 필요하다면 접근 제어와 호스트 방화벽을 함께 설정하고 공용 인터넷에 직접 노출하지 마세요.

systemd-resolved, NetworkManager, dnsmasq 및 Clash DNS가 로컬 DNS 포트를 두고 경쟁하거나 서로 전달할 수 있습니다. 먼저 조회 경로를 명확히 그려 보세요. 앱은 누구에게 요청을 보내는지, 시스템 stub은 어디로 전달하는지, Clash는 어느 주소에서 수신하는지, 상위 nameserver는 어디에 있는지를 확인해야 합니다. 포트 충돌이 발생해도 시스템 해석 서비스를 무작정 중지하지 말고 수신 주소나 전달 관계를 조정하세요. 컨테이너 내부의 127.0.0.1은 호스트가 아니라 컨테이너 자신을 가리킵니다. 컨테이너 앱이 호스트 프록시를 사용하려면 게이트웨이 주소와 수신 범위를 명확히 설정해야 합니다.

7. 공통 설정 파일, DNS, 규칙 및 TUN 매개변수

설정 파일의 기본 구조

Clash 설정은 YAML을 사용합니다. 들여쓰기는 계층만 표현하므로 탭을 임의로 섞어 쓰면 안 됩니다. 키 뒤의 콜론에는 올바른 공백을 유지하고 목록 항목에는 하이픈을 사용하세요. 설정에는 보통 수신 포트, 실행 모드, 로그 수준, 프록시 정의, 정책 그룹, 규칙 제공자, DNS 및 최종 규칙이 포함됩니다. 구독으로 생성된 전체 설정은 길 수 있지만, 문제를 확인할 때는 먼저 최상위 구조가 올바른지 확인한 뒤 구체적인 프록시 진입점을 살펴보세요.

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

위 예시는 구문을 설명하기 위한 것이며 사용할 수 있는 프록시 정의를 포함하지 않습니다. mixed-port는 HTTP와 SOCKS 연결을 모두 받고, allow-lan은 다른 기기의 연결 허용 여부를 결정하며, bind-address는 수신 주소를 제한합니다. mode는 규칙, 전체 또는 직접 연결 동작을 결정하고, log-level은 로그의 상세도를 제어합니다. 사용 중이지만 않다면 포트 값은 무엇이든 가능하므로 예시 값을 고정해서 사용할 필요는 없습니다. 수신 포트를 변경한 뒤에는 모든 외부 프록시 설정도 함께 바꿔야 합니다.

allow-lan 및 수신 주소

로컬에서만 사용할 때는 allow-lan: false를 유지하고 루프백 주소에 바인딩하는 것이 명확합니다. 같은 LAN의 다른 기기가 프록시를 사용해야 한다면 LAN 접근을 켜고 클라이언트가 실제로 LAN 인터페이스에서 수신하는지 확인하세요. 그런 다음 다른 기기에서 Clash가 실행 중인 기기의 LAN IP와 mixed-port를 입력합니다. 호스트 방화벽에서는 해당 포트를 허용해야 하지만 모든 네트워크 프로필에 무조건 개방해서는 안 됩니다.

LAN 연결 허용은 다른 기기와 트래픽을 자동으로 공유하거나 게이트웨이를 설정하지 않습니다. 하위 기기에서 HTTP/SOCKS 프록시를 직접 설정하거나 게이트웨이에서 투명 전달을 처리해야 합니다. 모바일 기기가 현재 Wi-Fi를 벗어나면 기존 LAN 주소에 접근할 수 없으므로 수동 프록시를 지워야 합니다. 공용 Wi-Fi에서는 수신 포트를 열지 않는 것이 좋습니다. 꼭 필요하다면 최소한 출발지 네트워크 대역을 제한하고 제어 인터페이스가 함께 노출되지 않았는지 확인하세요.

규칙 매칭 순서 및 정책 그룹

규칙은 위에서 아래 순서로 매칭되며, 일반적으로 첫 번째 매칭 이후에는 계속 진행하지 않습니다. 따라서 더 구체적인 도메인, 프로세스 및 사설 네트워크 규칙을 포괄적인 규칙보다 앞에 배치하고 MATCH는 보통 마지막에 둡니다. DOMAIN은 전체 도메인을, DOMAIN-SUFFIX는 도메인 접미사를, DOMAIN-KEYWORD는 키워드를, IP-CIDR은 주소 대역을 매칭합니다. IP 규칙은 DNS 확인을 유발할 수 있으며, 확인을 건너뛸 수 있는지는 구문과 코어 지원 여부에 따라 다릅니다.

정책 그룹은 프록시 진입점 자체가 아니라 여러 정책을 선택, 테스트 또는 대체하기 위한 논리 계층입니다. select 그룹은 사용자가 직접 선택하고, url-test는 테스트 주소와 간격에 따라 선택을 갱신하며, fallback은 보통 사용 가능 여부 순서로 전환하고, load-balance는 설정된 정책에 따라 연결을 분배합니다. 테스트 결과는 테스트 대상과 당시 네트워크만 반영하며 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 테스트 간격을 지나치게 짧게 설정하면 연결과 배터리 사용량이 늘어나므로 화면을 자주 갱신하려고 계속 탐색하지 마세요.

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - provider-a
      - provider-b
    url: https://www.gstatic.com/generate_204
    interval: 600

DNS 모드 및 조회 경로

DNS 설정의 목적은 도메인 확인뿐 아니라 확인 결과, 규칙 매칭 및 프록시 연결을 일관되게 유지하는 것입니다. fake-ip 모드는 예약 주소를 반환하고 코어가 도메인 매핑을 기록한 뒤 연결 단계에서 도메인을 복원하므로 안정적인 도메인 분기가 필요한 환경에 적합한 경우가 많습니다. redir-host는 실제 확인 결과를 반환해 일부 LAN 및 특수 앱에서 더 직관적이지만 분기 경로가 다릅니다. 선택하기 전에 클라이언트가 시스템 DNS를 처리하는지, Clash에 들어오지 않은 앱이 어디로 조회하는지 이해해야 합니다.

nameserver는 일반 상위 DNS이고, fallback은 다른 조회 경로를 제공하며, default-nameserver는 DoH 또는 DoT 상위 서버 자체의 도메인을 확인할 때 자주 사용합니다. 상위 서버에 도메인을 입력하면서 기본 확인도 같은 상위 서버에 의존하면 시작 의존성 루프가 생길 수 있습니다. 브라우저의 보안 DNS가 시스템 경로를 우회할 수도 있습니다. DNS 누수를 확인할 때는 브라우저 설정, 시스템 해석기 및 Clash 로그를 함께 확인해야 하며 단일 웹페이지 결과만으로 판단하지 마세요.

TUN 매개변수 및 엄격한 라우팅

TUN 모드의 일반적인 매개변수에는 활성화 여부, 프로토콜 스택 구현, 자동 라우팅, 인터페이스 자동 감지 및 엄격한 라우팅이 있습니다. 플랫폼과 코어 버전에 따라 지원 범위가 다를 수 있으며, 클라이언트 화면이 이 필드를 대신 생성하기도 합니다. 자동 라우팅을 켜면 코어가 필요한 경로를 추가하고, 인터페이스 자동 감지는 Wi-Fi, 이더넷 또는 모바일 네트워크가 바뀔 때 출구를 식별합니다. 엄격한 라우팅은 트래픽 우회를 줄일 수 있지만 가상 머신, 컨테이너 또는 LAN 라우팅과 충돌할 가능성이 더 큽니다.

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

처음 활성화할 때는 보수적인 설정으로 시작하세요. 필요한 필드만 켜고 브라우저, 터미널, LAN 및 절전 모드 복귀가 정상인지 확인한 뒤 엄격한 라우팅이나 DNS 하이재킹을 조정합니다. 시스템에 기업 VPN, 가상 스위치, 컨테이너 브리지 또는 여러 기본 경로가 있다면 활성화 전후의 라우팅 차이를 기록하세요. TUN은 시스템 프록시가 작동하지 않을 때의 만능 대체 수단이 아닙니다. 해결하는 것은 트래픽 처리 범위이며 잘못된 구독, 오류 정책 또는 원격 연결 실패를 고치지는 못합니다.

8. 설정 업데이트, 연결 이상 및 복구 절차

계층별로 확인하고 여러 변수를 동시에 바꾸지 않기

문제 해결은 기본 네트워크, 클라이언트 프로세스, 설정 로드, 수신 포트, 트래픽 처리, 규칙 매칭, 정책 연결 및 DNS 순서로 확인해야 합니다. 먼저 직접 연결로 전환하거나 클라이언트를 완전히 종료해 기기 자체가 인터넷에 연결되는지 확인하세요. 다음으로 시스템 트래픽은 처리하지 않은 상태에서 클라이언트를 시작해 코어가 정상적으로 실행되는지 확인합니다. 그 뒤 로컬 프록시 포트를 통해 명확한 테스트를 한 번 실행하고, 마지막으로 시스템 프록시 또는 TUN을 켜세요. 이렇게 하면 문제가 코어 이전에 있는지 시스템 트래픽 처리 이후에 있는지 구분할 수 있습니다.

한 번에 조건 하나만 바꾸세요. 구독 업데이트, 클라이언트 전환, DNS 변경, TUN 활성화 및 정책 교체를 동시에 하지 마세요. 여러 작업을 한꺼번에 수행하면 복구되어도 원인을 확인할 수 없습니다. 클라이언트 로그는 먼저 info 수준으로 확인하고, 더 자세한 내용이 필요할 때만 잠시 debug로 전환하세요. 로그를 공유하기 전에는 구독 URL, 인증 필드, 프록시 주소 및 기기 정보를 삭제하세요.

구독 업데이트 실패

구독 업데이트에 실패하면 먼저 URL이 완전한지, 만료되지 않았는지, 복사 과정에서 공백이 생기지 않았는지, 기본 네트워크에서 해당 주소에 접근할 수 있는지 확인하세요. HTTP 상태 오류는 보통 인증, 요청 빈도 제한 또는 서버 상태에서 발생합니다. 연결 시간 초과는 DNS, 현재 프록시 경로 또는 네트워크 차단일 수 있습니다. 다운로드에는 성공했지만 해석에 실패한다면 응답 내용이 예상한 YAML이 아니거나 변환 형식이 잘못되었을 가능성이 큽니다. 시스템 프록시 스위치만 반복해서 켜고 끄는 것을 유일한 해결책으로 삼지 마세요.

기존 설정은 사용할 수 있지만 새 설정을 업데이트할 수 없다면 기존 설정을 먼저 보존하고 브라우저나 curl로 구독 주소를 별도로 요청해 응답 형식을 확인하세요. 업데이트가 현재 프록시를 거치는지 직접 연결되는지는 클라이언트 구현에 따라 다르므로 필요한 경우 처리 방식을 임시로 바꿔 비교하세요. 설정에 원격 규칙 세트가 포함되어 있으면 주 구독을 성공적으로 가져온 뒤에도 규칙 리소스 다운로드 단계에서 실패할 수 있습니다. 로그에서 구체적인 URL과 리소스 유형을 구분해 확인하세요.

시작 실패 및 포트 충돌

로그에 address already in use가 표시되면 수신 주소 또는 포트가 이미 사용 중이라는 뜻입니다. 흔한 원인은 같은 클라이언트의 두 인스턴스 실행, 종료되지 않은 이전 코어, 같은 포트를 사용하는 다른 프록시 프로그램 또는 시스템 서비스가 다른 인스턴스를 자동으로 시작한 경우입니다. Windows에서는 netstat와 작업 관리자로 확인하고, macOS와 Linux에서는 lsof 또는 ss를 사용할 수 있습니다. 프로세스의 용도를 확인한 뒤 종료하세요. 포트 번호만 보고 알 수 없는 시스템 프로세스를 바로 종료하지 마세요.

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

mixed-port를 변경하기로 했다면 클라이언트 화면, 시스템 프록시, 환경 변수, 브라우저 수동 프록시 및 LAN 기기를 모두 새 값으로 바꿔야 합니다. YAML만 변경했는데 클라이언트가 실제로 오버라이드 설정을 사용한다면 시작 후 포트가 다시 바뀔 수 있습니다. 자세한 분기는 포트 7890 점유 확인 방법을 참고하세요.

연결되었지만 웹페이지가 열리지 않음

먼저 정책 그룹이 빈 그룹이나 사용할 수 없는 상위 그룹이 아니라 실제 정책을 선택했는지 확인하세요. 그다음 요청 로그를 살펴보세요. 로그가 전혀 없으면 트래픽이 클라이언트에 들어오지 않은 것입니다. 규칙 매칭은 되었지만 연결에 실패하면 정책 또는 원격 서버 문제일 수 있습니다. 도메인 확인만 실패하면 DNS를 우선 확인하세요. 브라우저에서 인증서 또는 프로토콜 오류가 발생하면 시스템 시간, QUIC, 인증서 저장소 및 중간 네트워크를 확인해야 합니다. 전체 모드 전환은 규칙의 영향을 판단하는 데만 도움을 줄 뿐 장기 사용에 적합하다는 뜻은 아닙니다.

일부 웹사이트만 이상하다면 해당 도메인이 어떤 규칙과 최종 정책에 매칭되었는지 확인하세요. 규칙은 위에서 아래로 실행되므로 앞의 포괄적인 규칙이 뒤의 정확한 규칙을 가로챌 수 있습니다. 특정 앱만 이상하다면 시스템 프록시를 무시하는지, 앱별 분기에서 제외되었는지, UDP 또는 사용자 지정 DNS를 사용하는지 확인하세요. 이때 TUN은 처리 범위를 확인하는 데 사용할 수 있지만, 요청이 실제로 들어왔는지는 로그로 확인해야 합니다.

DNS 이상 및 누수 확인

도메인은 실패하지만 IP에는 접근할 수 있다면 보통 DNS 경로 문제입니다. 시스템 DNS 대상, Clash DNS 수신 포트, nameserver 접근 가능 여부, 브라우저 보안 DNS 및 TUN의 DNS 하이재킹 설정을 확인하세요. fake-ip에서 예약 주소가 보인다고 자동으로 이상인 것은 아닙니다. 핵심은 연결이 코어에 의해 처리되고 원래 도메인으로 복원되는지입니다. 앱이 Clash를 우회해 fake-ip 주소에 직접 접근하면 실패하므로 처리 범위나 필터 규칙을 조정해야 합니다.

DNS 누수 확인은 한 번의 웹페이지 테스트에만 의존해서는 안 됩니다. 활성화 전후의 DNS 서버를 비교하고, 클라이언트 로그에 대상 조회가 기록되는지 확인하며, 명령줄 도구로 시스템 기본 해석기를 지정해 테스트하세요. 기업 네트워크, 모바일 네트워크 및 브라우저 자체의 암호화 DNS가 추가 경로를 만들 수 있습니다. 전체 절차는 DNS 누수 확인 및 fake-ip 설정 실전을 참고하세요.

TUN 활성화 후 LAN 또는 가상 머신이 작동하지 않음

TUN은 라우팅 우선순위를 바꾸며 엄격한 라우팅과 DNS 하이재킹은 영향 범위를 더 넓힐 수 있습니다. LAN이 작동하지 않으면 먼저 사설 주소 직접 연결 규칙을 확인하고, 라우팅 테이블에서 대상 네트워크 대역을 어느 인터페이스가 담당하는지 살펴보세요. 가상 머신, Docker, WSL 및 컨테이너 플랫폼은 보통 자체 사설 네트워크 대역을 만듭니다. 물리 LAN이나 프록시 예약 주소와 겹치면 충돌이 발생할 수 있습니다. 장기적인 임시방편으로 특정 기기 IP 하나만 추가하지 말고 전체 네트워크 대역과 실제 출구를 확인하세요.

strict-route를 끄거나 DNS 하이재킹을 일시 중지하는 것은 원인 확인 방법으로 사용할 수 있지만, 어떤 변경으로 연결이 복구되었는지 기록해야 합니다. 절전 모드, 네트워크 전환 또는 VPN 재연결 후에만 문제가 생긴다면 인터페이스 자동 감지가 갱신되지 않았을 수 있습니다. 전체 기기를 재부팅하는 것보다 코어를 재시작하거나 TUN을 다시 만드는 편이 보통 더 직접적인 방법입니다. Linux 서버에서는 nftables, 정책 라우팅 및 역방향 경로 필터링도 확인하고, Windows와 macOS에서는 다른 VPN 및 보안 클라이언트를 확인하세요.

되돌릴 수 있는 유지 관리 습관 만들기

클라이언트를 업데이트하거나 설정을 크게 변경하기 전에 현재 사용할 수 있는 설정, 오버라이드 파일 및 주요 설정 기록을 보관하세요. 민감한 구독이 포함된 파일을 공개 위치에 백업하지 마세요. 변경 후에는 설정 해석, 코어 시작, 단일 포트 프록시, 시스템 프록시 또는 TUN, DNS, LAN 및 절전 모드 복귀를 각각 확인하세요. 어느 한 단계라도 실패하면 계속 변경을 덧붙이지 말고 최근의 명확하게 작동하는 상태로 돌아가세요.

초기 설정을 빠르게 완료하려면 Clash 빠른 시작 가이드로 돌아가세요. 클라이언트를 다시 선택해야 한다면 클라이언트 비교 리뷰를 확인하세요. 정책 그룹, 설정 파일, fake-ip, mixed-port 같은 용어는 용어집에서 따로 살펴볼 수 있습니다. 다운로드 출처를 명확히 하고, 설정을 계층별로 보관하며, 한 번에 한 항목만 변경하고, 로그를 계층별로 판단하는 흐름이 특정 클라이언트 화면의 고정된 위치를 외우는 것보다 안정적입니다.