전체 플랫폼 설치·설정

준비 사항 및 설정 범위

먼저 기기의 운영체제, 프로세서 아키텍처, 사용 중인 구독을 확인한 다음 클라이언트를 다운로드하세요. 데스크톱에서는 시스템 정보에서 아키텍처를 확인하고, 모바일에서는 운영체제 버전과 기기 모델을 살펴보면 됩니다. 클라이언트는 인터페이스, 설정 관리, 네트워크 트래픽 처리를 담당하며, mihomo 같은 커널은 설정을 해석하고 연결을 전달합니다. 두 역할을 혼동하지 마세요. 설치 화면이 정상적으로 표시되어도 구독을 사용할 수 있다는 뜻은 아니며, 구독을 가져왔더라도 시스템 트래픽이 커널로 전달된다는 보장은 없습니다. 이후에는 이 세 단계를 각각 확인해야 합니다.

클라이언트와 구독 형식 선택

Windows, macOS, Android, iOS에서는 Clash Plus를 먼저 살펴보고, Linux에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 클라이언트마다 기능 메뉴와 설정 저장 방식이 다르므로, 이 가이드에서는 특정 화면의 버튼 위치를 공통 기준으로 삼지 않고 ‘설정’, ‘정책 그룹’, ‘시스템 프록시’와 같은 기능 이름으로 설명합니다. 다운로드 전에는 유지 관리 상태도 확인하세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단된 보관용 선택지이므로 새 기기의 기본 클라이언트로 권장하지 않습니다.

사용 권한이 있는 구독 링크나 로컬 설정 파일을 준비하세요. 구독 주소에는 계정 식별 정보가 포함될 수 있으므로 공개 게시판, 스크린샷, 온라인 변환 사이트에 붙여 넣지 마세요. 완전한 Clash YAML에는 보통 노드, 정책 그룹, 규칙이 포함됩니다. 노드 목록만 있는 콘텐츠는 클라이언트 템플릿이 필요하거나 구독 제공업체에서 호환 형식으로 내보내야 할 수 있습니다. 형식 오류가 발생하면 먼저 다운로드된 파일이 설정 텍스트인지 확인하세요. 로그인 페이지, 접근 거부 메시지, 만료 안내일 수도 있습니다. 파일 확장자만으로 내용을 판단해서는 안 됩니다.

설정, 모드, 네트워크 트래픽 처리 구분하기

설정을 목록으로 가져온 다음 해당 항목을 선택해 활성화해야 합니다. 이후 정책 그룹에서 사용할 출구를 선택하고, 프록시 모드는 우선 Rule로 설정하세요. Rule은 규칙에 따라 직접 연결 또는 프록시를 선택합니다. Global은 커널로 들어온 연결에 전역 정책을 적용하고, Direct는 직접 연결을 사용합니다. 이 모드들은 트래픽이 커널에 들어온 뒤 어떻게 처리할지를 정할 뿐, 모든 앱의 트래픽을 커널로 보내지는 않습니다. 따라서 Global로 전환해도 시스템 프록시가 꺼진 문제는 해결되지 않으며, TUN에 필요한 시스템 권한을 대신하지도 않습니다.

되돌릴 수 있는 기준 상태 유지

처음 설정할 때는 트래픽 처리 방식을 하나만 활성화하고, 정상 작동을 확인한 뒤 기능을 추가하세요. 기존 시스템 프록시 설정, 다른 VPN 상태, 클라이언트 포트를 기록해 두세요. DNS, TUN, 규칙, 구독을 한꺼번에 변경하면 문제가 생겼을 때 원인을 찾기 어렵습니다. 테스트용 설정을 복사해 사용하고, 평소 쓰는 구독 항목은 원본 그대로 보관하세요. 구독 자동 업데이트는 직접 수정한 내용을 덮어쓸 수 있습니다. 계속 유지해야 하는 변경 사항은 클라이언트에서 지원하는 덮어쓰기, 병합 또는 스크립트 설정에 적용하고, 실제 실행 설정에 반영됐는지 확인하세요.

설정이 끝나면 프록시를 사용해야 하는 사이트와 직접 연결해야 하는 사이트에 각각 접속한 뒤, 연결 페이지에서 대상 도메인, 적용 규칙, 최종 출구를 확인하세요. 지연 시간 테스트는 한 번의 탐색 결과일 뿐, 모든 서비스 프로토콜이 정상 작동한다는 증거는 아닙니다. 단계별 설정이 필요하면 구독 가져오기 단계를 확인하고, 용어가 낯설다면 정책 그룹 설명을 읽은 뒤 해당 플랫폼 섹션으로 이동하세요.

Windows 설치 및 트래픽 처리

Windows 클라이언트 다운로드에서 Clash Plus를 먼저 확인하고 기기 아키텍처에 맞는 설치 파일을 선택하세요. Windows의 ‘설정 → 시스템 → 정보’에서 프로세서와 시스템 종류를 확인할 수 있습니다. x64와 ARM64는 서로 바꿔 쓸 수 있는 표기가 아닙니다. 일부 앱이 호환성 계층에서 실행되더라도 네트워크 서비스 구성 요소까지 호환된다는 보장은 없습니다. 설치 전에 기존 클라이언트를 종료하세요. 특히 시스템 트레이에서 계속 실행 중인 프로그램이 있으면 로컬 수신 포트를 서로 차지하거나 시스템 프록시 설정을 반복해서 덮어쓸 수 있습니다.

설치를 마치고 커널 실행 확인

설치 마법사의 안내에 따라 프로그램을 설치한 뒤 시작 메뉴에서 실행하세요. 포터블 버전을 사용한다면 안정적인 경로에 먼저 압축을 푸세요. 압축 파일 미리 보기에서 바로 실행하거나 정리될 수 있는 임시 폴더에 장기간 두지 마세요. 첫 실행 후 상태 페이지나 로그를 열어 커널이 계속 종료되지 않는지 확인하세요. 프로그램 창은 열리지만 커널이 시작되지 않는다면 오류 메시지에서 경로, 포트, 설정 항목을 먼저 살펴보세요. 연결 버튼을 반복해서 누르는 것으로는 해결되지 않습니다.

네트워크 서비스 구성 요소 설치와 일반적인 프로그램 실행은 별개의 작업입니다. 클라이언트가 서비스 설치를 요청하면 현재 실행 중인 프로그램에서 보낸 안내인지 확인한 뒤 시스템 요청에 따라 권한을 허용하세요. 관리자 권한이 없는 업무용 기기에서는 시스템 프록시를 먼저 시도하되, 조직 정책을 우회해 드라이버나 서비스를 설치하지 마세요. 보안 소프트웨어가 차단하면 이벤트 세부 정보를 확인해 차단된 파일과 설치 출처를 점검하세요. 보안 기능 전체를 끄는 것을 기본 설치 절차로 삼지 마세요. 프로그램을 업그레이드하기 전에 설정 디렉터리와 덮어쓰기 내용을 기록해 두세요. 제거 과정에서 정리되는 것을 일반적인 업데이트로 착각하지 않도록 주의해야 합니다.

구독 가져오기 및 시스템 프록시 켜기

설정 또는 구독 페이지에서 URL 가져오기를 선택하고 전체 주소를 붙여 넣은 뒤 저장하고 업데이트하세요. 다운로드가 완료되면 해당 설정을 선택하고 정책 그룹에서 사용할 출구를 고릅니다. 로컬 YAML을 가져올 때는 파일 가져오기 메뉴를 이용하세요. 구독 URL 입력란에 파일 경로를 넣으면 안 됩니다. QR 코드는 주소를 입력하는 또 다른 방법일 뿐이므로, 인식된 주소의 출처도 확인해야 합니다. 가져오기 방법 세 가지의 차이는 URL, QR 코드, 로컬 YAML 가져오기 안내를 참고하세요.

우선 Rule 모드를 유지하고 클라이언트에서 시스템 프록시를 켠 다음, Windows 프록시 설정에서 주소가 로컬 기기를 가리키는지, 포트가 실행 설정과 일치하는지 확인하세요. 흔히 사용하는 로컬 주소는 127.0.0.1이지만 포트는 클라이언트에 실제로 표시된 값을 따라야 합니다. 브라우저 확장 프로그램에 별도의 프록시 규칙이 있을 수 있습니다. 문제를 확인할 때는 중복으로 트래픽을 처리하는 확장 프로그램을 끄고 기존 페이지 연결을 닫은 뒤 다시 접속하세요. 웹페이지가 열리는지만 확인해서는 부족합니다. 클라이언트의 연결 목록에서 해당 요청도 찾아야 합니다.

TUN 권한 및 일반적인 충돌

시스템 프록시를 따르지 않는 앱이 있을 때 TUN 활성화를 고려하세요. 클라이언트 안내에 따라 서비스를 설치하거나 활성화하고, 가상 네트워크 인터페이스와 라우팅이 정상적으로 설정됐는지 확인합니다. 처음 테스트할 때는 시스템 프록시를 끄고 TUN만 사용하세요. 작동을 확인한 뒤 클라이언트 권장 방식에 따라 함께 사용할 수 있습니다. 활성화 후 모든 사이트에 연결되지 않으면 즉시 TUN을 끄고 다른 VPN, 가상 머신 네트워크 도구, 전체 트래픽 필터링 프로그램이 동시에 실행 중인지 확인하세요. 기기가 직접 연결로 복구되는지는 트래픽 처리 문제와 상위 노드 문제를 구분하는 데 중요한 단서입니다.

netstat -ano | findstr ":7890"
netsh winhttp show proxy

첫 번째 명령은 예시 포트의 사용 여부를 확인합니다. 결과가 나오면 수신 상태와 프로세스 번호를 함께 살펴 어떤 프로그램이 사용하는지 확인해야 합니다. 두 번째 명령은 WinHTTP 프록시 설정을 보여 줍니다. 이 설정은 현재 사용자의 시스템 프록시와 별개이므로, 직접 연결로 표시되더라도 클라이언트의 시스템 프록시 기능이 작동하지 않는다고 단정할 수 없습니다. 두 설정을 일치시키려고 WinHTTP를 무작정 변경하지 마세요. 해당 설정에 의존하는 프로그램이 있을 때만 맞게 구성하고, 원래 상태로 되돌리는 방법도 기록해 두세요.

클라이언트를 종료한 뒤에도 브라우저에서 프록시 연결 오류가 계속되면 Windows 프록시 설정에 로컬 프록시가 남아 있는지 확인하세요. 절전 모드에서 깨어난 뒤나 네트워크를 바꾼 뒤에만 문제가 생긴다면 먼저 연결을 다시 설정하고, 클라이언트 서비스 상태를 확인한 후 트래픽 처리 기능을 재시작하세요. 모든 설정을 바로 삭제하지 마세요. 원본 로그와 실패한 요청의 발생 시각을 보관하면 로컬 포트, DNS, 규칙, 노드 출구 중 어디에 문제가 있는지 더 빠르게 판단할 수 있습니다.

macOS 설치 및 권한

macOS 다운로드에서 Clash Plus를 선택하고 ‘이 Mac에 관하여’에 표시된 칩 종류에 따라 Apple Silicon 또는 Intel 설치 파일을 고르세요. 다른 인터페이스를 원한다면 Clash Verge Rev와 FlClash도 선택할 수 있으며, ClashX Meta는 보관용 클라이언트입니다. 앱 아이콘이나 파일 이름에 Mac이 들어 있다는 이유만으로 아키텍처를 판단하지 마세요. 다른 클라이언트로 바꾸기 전에 기존 프로그램의 시스템 프록시와 백그라운드 서비스를 종료하세요. 그렇지 않으면 새 프로그램이 정상 실행되더라도 이전 프로그램이 계속 네트워크 설정을 제어할 수 있습니다.

안정적인 위치에 설치하고 권한 설정

다운로드한 디스크 이미지를 연 뒤 앱을 ‘응용 프로그램’ 폴더로 드래그하고 해당 폴더에서 실행하세요. 마운트된 이미지에서 계속 실행하지 마세요. 시스템을 재시동하거나 이미지를 꺼내면 로그인 항목이나 보조 프로그램에서 원래 경로를 찾지 못할 수 있습니다. 시스템에서 다운로드한 앱에 관한 안내가 표시되면 다운로드 위치와 앱 정보를 확인한 뒤 ‘개인정보 보호 및 보안’에서 가능한 조치를 살펴보세요. 보안 속성을 제거하거나 시스템 보안 기능을 끄는 방법을 일반적인 설치 절차로 삼지 마세요. 명시적인 권한 안내와 출처를 알 수 없는 파일은 각각 따로 판단해야 합니다.

보조 서비스, 네트워크 확장 프로그램, VPN 구성에 대한 승인은 시스템 수준의 변경이며 안내 방식은 클라이언트 구현에 따라 다릅니다. 현재 앱의 안내에 따라 권한을 부여한 뒤 시스템 팝업이 사라졌는지만 보지 말고 클라이언트에서 서비스가 준비됐는지 확인하세요. 기기 관리가 적용된 컴퓨터에서는 사용자가 네트워크 구성 요소를 승인하지 못할 수 있습니다. 이 경우 관리 정책을 따라야 합니다. 설치가 실패하면 시스템에 표시된 안내 원문, 앱 경로, 칩 종류를 기록하세요. 같은 파일을 다시 설치하는 것만으로는 권한 범위 문제가 해결되지 않는 경우가 많습니다.

설정을 가져오고 활성 네트워크 서비스 확인

설정 관리에서 구독 URL을 추가하고, 업데이트한 뒤 해당 항목을 활성화하고 정책 그룹에서 출구를 선택하세요. 처음에는 다른 VPN을 끈 상태로 시스템 프록시를 통해 브라우저 접속을 확인하세요. macOS의 프록시 설정은 네트워크 서비스마다 적용됩니다. Wi-Fi, 이더넷, 도킹 스테이션의 네트워크 어댑터가 서로 다른 서비스일 수 있습니다. 네트워크를 바꾼 뒤 프록시가 작동하지 않으면 과거에 설정한 Wi-Fi 항목만 보지 말고 현재 사용하는 네트워크 서비스를 확인하세요. 클라이언트에 시스템 프록시 자동 설정 기능이 있더라도 현재 서비스에 적용됐는지 점검해야 합니다.

scutil --proxy
networksetup -listallnetworkservices

scutil --proxy 명령으로 시스템 프록시 정보를 확인할 수 있으며, 다른 명령으로 네트워크 서비스 이름을 나열할 수 있습니다. 활성화 여부, 프록시 서버, 포트가 클라이언트 설정과 일치하는지 확인하세요. 터미널에서 실행하는 프로그램은 시스템 설정을 읽지 않을 수 있습니다. 브라우저는 되지만 명령줄 프로그램은 안 된다고 해서 곧바로 노드 문제라고 판단하지 마세요. 먼저 해당 프로그램이 지원하는 프록시 방식을 확인한 다음 적절한 환경 변수나 명령줄 인수를 사용하세요. 지원하지 않는 입력란에 HTTP 프록시 주소를 잘못 넣지 않도록 주의하세요.

TUN, 절전 모드 복귀, 설정 유지

더 많은 앱의 트래픽을 처리해야 할 때 TUN을 켜고 클라이언트 안내에 따라 관련 서비스를 승인하세요. 시작 로그에 권한 부족, 기기 생성 실패, 라우팅 설정 실패가 표시되면 구독을 계속 바꾸지 말고 해당 시스템 작업부터 해결해야 합니다. TUN을 설정한 뒤에는 DNS가 예상한 경로로 전달되는지도 확인하세요. 가상 인터페이스가 있다고 해서 도메인 이름이 올바르게 조회되는 것은 아닙니다. 기업용 VPN, 가상화 소프트웨어, 다른 네트워크 확장 프로그램도 라우팅을 변경할 수 있으므로 충돌 원인을 찾을 때는 꼭 필요한 구성 요소만 한 번에 하나씩 테스트하세요.

설정을 수정할 때는 구독 원본 파일과 실행 중 생성되는 파일을 구분하세요. 구독 원본은 업데이트 때 덮어쓰일 수 있고, 실행 파일은 시작할 때마다 다시 생성될 수 있습니다. 어느 쪽이든 직접 수정한 내용이 계속 유지된다는 보장은 없습니다. 클라이언트의 지속 설정용 덮어쓰기 기능을 우선 사용하고, 적용 후 최종 설정을 확인하세요. 업그레이드 전에 구독 출처, 덮어쓰기 내용, 필요한 로컬 규칙을 백업하세요. 구독 주소는 민감 정보로 취급하고 설정 디렉터리 전체를 공개 저장소에 동기화하지 마세요.

클라이언트를 제거하거나 바꾸기 전에 시스템 프록시와 TUN을 끈 뒤 앱을 종료하세요. 앱을 휴지통으로 옮기는 것만으로는 승인된 네트워크 구성이나 백그라운드 보조 구성 요소가 함께 제거되지 않을 수 있습니다. 클라이언트에서 제공하는 서비스 제거 메뉴를 사용하고 시스템 네트워크 설정에 잔여 항목이 있는지 확인하세요. 직접 연결을 복구한 뒤 대체 클라이언트를 실행하면 두 프로그램이 프록시 상태를 서로 덮어쓰는 일을 막고, 새 문제가 어느 단계에서 시작됐는지 명확히 알 수 있습니다.

Android 설치 및 백그라운드 실행

Android 다운로드에서는 Clash Plus를 먼저 살펴보세요. 설정 호환성에 따라 Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수도 있습니다. 최신 기기는 대체로 ARM64를 사용하지만 기기 아키텍처와 설치 파일 안내를 기준으로 확인해야 합니다. 구형 기기는 다른 아키텍처나 범용 패키지가 필요할 수 있으므로 파일을 바꿔 가며 반복 설치하지 말고 먼저 확인하세요. 기존 앱과 충돌한다는 안내가 나오면 앱 이름, 패키지 출처, 서명 관련 메시지를 살펴보고 설정을 백업한 뒤 설치 출처를 바꿀지 결정하세요.

설치 권한 및 로컬 VPN 작동 방식

브라우저나 파일 관리자로 설치 파일을 열면 해당 출처에서 앱을 설치하도록 허용하라는 메시지가 표시될 수 있습니다. 실제로 사용하는 출처에만 권한을 부여하고 설치가 끝난 뒤에는 기존 제한을 다시 적용할 수 있습니다. 설치에 실패하면 저장 공간, 시스템 호환 조건, 서로 다른 서명의 앱을 덮어쓰려는 것은 아닌지 먼저 확인하세요. 앱을 제거하면 앱 전용 데이터도 사라질 수 있으므로 구독과 덮어쓰기 내용을 백업하지 않은 상태에서 제거를 첫 번째 해결책으로 삼지 마세요. 로컬 YAML도 알아보기 쉬운 위치에 따로 저장해 다운로드 파일을 정리할 때 함께 삭제되지 않도록 하세요.

처음 프록시 서비스를 시작하면 Android에서 VPN 연결을 허용하라는 메시지가 표시됩니다. 이는 앱이 시스템 인터페이스를 통해 로컬 가상 네트워크 경로를 만드는 권한이며, 구독 제공업체의 설정이 정상이라는 뜻은 아닙니다. 휴대전화의 다른 VPN, 일부 방화벽, 네트워크 필터 앱도 같은 시스템 기능을 사용할 수 있어 보통 동시에 독립적으로 실행할 수 없습니다. 다른 앱의 연결이 끊기면 기존 VPN 상태부터 확인하세요. Clash가 강제로 종료됐거나 노드가 불안정한 것으로 오해하지 않도록 주의해야 합니다.

구독 활성화 및 앱별 적용 범위

설정 목록에 원격 구독을 추가하고 이름과 전체 주소를 입력한 뒤 업데이트가 완료되면 활성 설정으로 지정하고 정책 그룹에서 출구를 선택하세요. QR 코드로 가져올 때는 인식된 주소가 예상한 구독 주소인지 확인하세요. 전체 주소가 포함된 스크린샷을 그대로 올려 도움을 요청하지 마세요. 가져오기에 성공했는데 사용할 정책 그룹이 없다면 구독에 노드 데이터만 들어 있거나 클라이언트 템플릿이 필요한 형식일 수 있습니다. Surfboard 설정 형식과 Clash YAML은 서로 같은 형식이 아닙니다. 클라이언트를 바꾸기 전에 구독 제공업체가 해당 출력 형식을 지원하는지 확인하세요.

연결을 시작한 뒤 브라우저에서 요청을 하나 테스트하고 연결 로그를 확인하세요. 모바일에서는 보통 VPN을 통해 트래픽을 처리하므로 데스크톱의 시스템 HTTP 프록시 설정 절차를 그대로 따를 필요가 없습니다. 클라이언트에서 앱별 프록시를 지원한다면 현재 ‘선택한 앱만 적용’과 ‘선택한 앱 제외’ 중 어떤 모드인지 확인하세요. 두 설정의 의미는 정반대입니다. 잘못 선택하면 브라우저는 되지만 대상 앱의 연결 기록이 남지 않을 수 있습니다. 적용 범위를 변경한 뒤에는 대상 앱을 완전히 종료하고 다시 시작하세요. 기존 세션은 즉시 새 설정을 따르지 않을 수 있습니다.

배터리 제한, 네트워크 전환, 자동 시작

화면을 잠근 뒤 연결이 끊겼다가 화면을 켜면 복구되는 경우, 시스템의 백그라운드 실행, 배터리 사용, 자동 시작 제한부터 확인하세요. 기기 제조업체마다 메뉴 위치가 다르므로 앱 정보에서 관련 설정을 찾아 클라이언트가 필요한 동안 실행될 수 있도록 허용하세요. 최근 앱 목록의 잠금, 알림 표시, 배터리 최적화는 각각 다른 기능입니다. 하나만 켰다고 다른 제한까지 해제됐다고 단정하지 마세요. 모든 앱의 제한을 일괄적으로 풀지 말고 백그라운드 종료가 원인인지 확인한 뒤 프록시 클라이언트만 조정하세요.

Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결이 끊길 수 있으며 앱에서 세션을 다시 만들어야 합니다. 모바일 네트워크에서만 실패한다면 앱의 모바일 데이터 사용이 차단됐는지, 구독 업데이트가 현재 네트워크에 의존하는지, 노드 프로토콜이 해당 네트워크에서 작동하는지 확인하세요. Android의 비공개 DNS와 클라이언트 DNS 설정이 모두 조회 과정에 영향을 줄 수 있습니다. 도메인 문제가 발생하면 두 설정의 상태를 기록하고 되돌릴 수 있도록 한 항목씩 비교 테스트하세요. 모든 DNS 기능을 한꺼번에 끄지 마세요.

앱 문제를 확인할 때는 먼저 해당 앱이 프록시 적용 범위에 있는지 확인하고, 연결 로그에 관련 도메인이 기록됐는지 살펴보세요. 기록은 있지만 출구가 잘못됐다면 규칙을 확인하고, 출구가 올바른데도 실패할 때 노드, DNS, 앱 자체의 네트워크 요구 사항을 추가로 테스트하세요. 지연 시간이 정상이어도 서비스 연결이 제한될 수 있습니다. 구독 업데이트 실패와 프록시 연결 실패는 따로 다뤄야 합니다. 구독 업데이트 실패 및 자동 새로고침 설정을 참고해 유효한 설정을 반복해서 삭제하고 다시 만들지 않도록 하세요.

iOS 설치 및 VPN 설정

iOS에서는 Clash Plus를 권장합니다. App Store의 Clash Plus 페이지에서 설치할 수 있으며, 제품 정보는 공식 사이트 clashplus.io에서 확인하세요. 설치 전에 스토어에 표시된 기기 호환 조건을 살펴보고 사용 가능한 저장 공간도 확인하세요. 앱 설치와 네트워크 프록시 활성화는 별개의 단계입니다. 처음 실행하면 설정 관리와 연결 메뉴를 먼저 살펴보세요. 유효한 구독도 없이 시스템 VPN 설정을 반복해서 승인하고 삭제하지 마세요.

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

클라이언트와 호환되는 구독 URL을 준비한 뒤 설정 관리의 링크 메뉴에서 추가하세요. 붙여 넣은 주소 앞뒤에 공백이나 줄바꿈이 있는지, 메신저에서 붙은 문장 부호가 있는지 확인하세요. 계정 매개변수가 포함된 주소는 그대로 유지해야 합니다. 업데이트가 완료되면 해당 설정을 선택하고 예상한 정책 그룹이 표시되는지 확인한 뒤 사용할 출구를 고르세요. 파일에서 YAML을 가져올 때는 클라이언트의 파일 선택 또는 공유 기능을 사용하세요. 가져온 뒤에도 설정을 활성화해야 합니다. 파일이 휴대전화에 저장됐다고 해서 클라이언트가 이미 사용 중인 것은 아닙니다.

구독 링크와 노드 공유 링크는 서로 다른 구조를 사용할 수 있습니다. 노드 하나에 전체 규칙과 정책 그룹이 들어 있지 않을 수 있으므로 모든 가져오기 메뉴를 서로 바꿔 쓸 수 있는 텍스트 입력란으로 생각하지 마세요. 제공업체가 전용 클라이언트 링크를 제공했다면 최종적으로 어떤 설정 형식으로 연결되는지 먼저 확인하세요. 다운로드에 실패하면 주소에 접근할 수 없는지, 콘텐츠가 호환되지 않는지, 구독이 만료됐는지 구분해서 확인하세요. Rule과 Global을 반복해서 바꿔도 구독 서버가 반환하는 파일 내용은 달라지지 않으며, 로그인 페이지를 설정 파일로 잘못 인식한 문제도 해결되지 않습니다.

VPN 승인 및 실제 출구 확인

처음 연결을 시작할 때 시스템 안내에 따라 VPN 설정 추가를 허용하고 기기에서 요구하는 본인 확인을 완료하세요. 이 권한으로 클라이언트가 시스템 네트워크 경로를 만들 수 있지만 모든 도메인이 프록시를 통과한다는 뜻은 아닙니다. 앱에서 Rule 모드를 유지하고 테스트 사이트에 접속한 뒤 연결 기록에서 적용 규칙과 출구를 확인하세요. 상태 표시줄이나 시스템 설정에 VPN 연결로 표시되더라도 네트워크 경로가 연결된 상태라는 의미일 뿐입니다. 설정 규칙에서 직접 연결을 선택할 수 있고, 선택한 노드가 특정 요청을 처리하지 못할 수도 있습니다.

기업용 VPN, 다른 프록시 앱, 네트워크 필터 도구를 함께 사용한다면 현재 어떤 설정이 연결을 만들었는지 먼저 확인하세요. 전환하기 전에 기존 연결을 끄고 Clash Plus를 시작해야 시스템 상태를 잘못 판단하지 않습니다. 필요 시 연결 같은 시스템 기능은 네트워크 변경 후 이전 설정을 다시 시작할 수도 있으므로 시스템 VPN 설정을 함께 확인하세요. 관리 기기의 네트워크 정책에서 변경을 제한할 수 있습니다. 이 경우 기기 관리 요구 사항을 따라야 하며 개인 프록시를 복구하려고 관리 설정을 삭제해서는 안 됩니다.

백그라운드, DNS, 로컬 네트워크 접근

iOS 네트워크 확장 프로그램과 앱 인터페이스는 서로 다른 실행 상태입니다. 앱을 벗어나도 프록시가 반드시 중지되는 것은 아니며, 반대로 앱이 작업 목록에 남아 있어도 연결이 유효하다는 뜻은 아닙니다. 현재 VPN 상태와 새로 생성된 연결 기록을 기준으로 판단하세요. 연결이 끊길 때 앱 화면에 계속 머무는 것으로 해결하려 하지 마세요. 구독 업데이트 오류, 확장 프로그램 종료, 네트워크 전환이 있었는지 먼저 확인하세요. 시스템에서 앱의 모바일 데이터 사용을 제한한 경우에도 Wi-Fi에서만 반복 테스트하지 말고 클라이언트의 실제 동작을 함께 살펴봐야 합니다.

로컬 네트워크 기기, 프린터, 로컬 서비스를 사용할 수 없다면 먼저 대상 주소가 프록시 규칙에 걸리는지, 클라이언트에서 로컬 네트워크 우회나 관련 라우팅 옵션을 제공하는지 확인하세요. 직접 연결 규칙을 추가하기 전에는 네트워크 대역의 출처를 확인하고, 출처를 모르는 주소 범위 전체를 직접 연결로 지정하지 마세요. 도메인이 조회되는데도 기기에 접속할 수 없다면 로컬 네트워크 접근 권한, 대상 포트, 네트워크 격리가 원인일 수도 있습니다. 웹페이지가 열리는지만으로 판단하지 마세요. 변경할 때마다 연결을 다시 설정하고 실제로 어떤 규칙이 적용됐는지 확인하세요.

자동 업데이트 주기는 구독 제공업체의 요구 사항과 클라이언트 지원 여부에 맞게 설정하세요. 모바일 운영체제의 백그라운드 실행은 시스템 스케줄에 따라 처리되므로 간격을 설정했다고 해서 매번 정해진 시각에 새로고침이 완료되는 것은 아닙니다. 외출하기 전에 직접 한 번 업데이트해 설정을 계속 활성화할 수 있는지 확인하고, 설정을 바꾸기 전에는 사용할 수 있는 항목을 보관하세요. 연결 후에도 특정 앱이 실패한다면 재설치부터 하지 말고 ‘새 요청이 기록되는지, 규칙이 올바른지, 출구를 사용할 수 있는지’ 순서로 확인하세요. 자세한 서비스 연결 확인 절차는 첫 연결 및 프록시 적용 확인을 참고하세요.

Linux 데스크톱 및 커널 배포

Linux 데스크톱 사용자는 Clash Verge Rev 및 FlClash를 먼저 확인하고, 서버나 라우터 사용자는 mihomo 커널을 살펴보세요. 그래픽 클라이언트는 대개 설정, 시스템 트레이, 서비스 관리를 통합해 제공합니다. 커널만 별도로 실행하려면 설정 디렉터리, 프로세스 관리, 로그, 네트워크 트래픽 처리를 직접 구성해야 합니다. 그래픽 클라이언트가 관리하는 파일과 수동으로 배포한 파일을 같은 디렉터리에서 함께 사용하지 말고, 두 커널이 동일한 주소와 포트를 동시에 수신하지 않도록 하세요.

아키텍처와 설치 종속성 확인

uname -m으로 프로세서 아키텍처를 확인한 뒤 배포판에 맞는 패키지 형식을 선택하세요. Debian, Ubuntu 등의 시스템은 보통 deb 패키지를 사용하고, RPM 계열 배포판은 해당 패키지를 선택해야 합니다. 패키지 형식이 같다고 해서 필요한 모든 실행 종속성이 동일한 것은 아닙니다. 다운로드 페이지에 없는 아키텍처를 파일 이름만 바꿔 호환되는 것처럼 사용하지 마세요. 배포판의 패키지 관리자로 로컬 패키지를 설치하면 종속성 오류를 명확하게 확인할 수 있습니다. 구성 요소가 없다는 메시지가 표시되면 현재 시스템의 소프트웨어 저장소를 이용해 해결하고 다른 배포판의 동적 라이브러리를 임의로 복사하지 마세요.

그래픽 프로그램이 시작되지 않으면 터미널에서 해당 프로그램을 실행해 오류 출력을 확인하고, 디스플레이 환경, 데스크톱 통합, 커널 설정 문제를 구분하세요. 원격 SSH 세션에는 완전한 데스크톱 환경이 없으므로 데스크톱 클라이언트 절차를 그대로 적용하기 어렵습니다. 서버에서는 대개 커널과 명확한 앱별 프록시 설정만으로 충분합니다. TUN이 필요한지는 트래픽을 처리할 범위에 따라 달라지며 배포 성공에 반드시 필요한 것은 아닙니다. 시스템 서비스를 설치하기 전에 실행 사용자와 설정 경로를 정해 임시 다운로드 디렉터리에 의존하지 않도록 하세요.

그래픽 클라이언트 가져오기 및 데스크톱 프록시

그래픽 클라이언트에서 구독을 가져와 업데이트하고 활성화한 다음 정책 그룹에서 출구를 선택하세요. 시스템 프록시를 켜더라도 GNOME, KDE, 개별 앱마다 프록시 설정을 읽는 방식이 다를 수 있습니다. 데스크톱의 한 가지 스위치가 모든 터미널 프로그램에 자동으로 적용되는 것은 아닙니다. 먼저 브라우저 연결이 목록에 표시되는지 확인하고 프록시가 필요한 명령줄 도구는 별도로 설정하세요. 표준 환경 변수를 지원하는 프로그램이라면 현재 셸에서 임시로 프록시를 설정해 테스트한 뒤, 정상 작동을 확인하고 지속 설정에 기록할지 결정하세요.

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

위 예시대로 사용하려면 로컬 HTTP 또는 혼합 프록시가 예시 포트에서 실제로 수신 중이어야 합니다. https_proxy에 HTTP 주소를 사용하는 것은 프록시에 연결할 때 HTTP 프로토콜을 쓴다는 뜻이지, 대상 HTTPS 연결을 일반 HTTP로 낮춘다는 의미가 아닙니다. 프로그램마다 변수 이름, 대소문자, SOCKS 지원 여부가 다르므로 해당 프로그램의 안내를 따르세요. 새 터미널이나 이미 실행 중인 서비스에는 나중에 설정한 변수가 자동으로 전달되지 않습니다. 따라서 브라우저, 터미널, 시스템 서비스의 연결을 각각 확인해야 하며 한 곳만 테스트하고 전체에 적용됐다고 판단해서는 안 됩니다.

독립 커널, 권한 및 서비스 범위

mihomo를 독립적으로 사용할 때는 아키텍처에 맞는 커널을 압축 해제하고 전용 설정 디렉터리를 만든 다음 실제 설정을 해당 디렉터리의 config.yaml로 저장하세요. 아래 명령은 실행 파일이 현재 디렉터리에 있고 설정 파일이 사용자 디렉터리의 mihomo-config에 있다고 가정합니다. 먼저 구문을 확인한 다음 포그라운드에서 실행해 로그를 살펴보고 정상적으로 수신되는지 확인한 뒤 서비스 관리자를 사용할지 결정하세요. 구문 검사를 통과해도 설정을 해석할 수 있다는 뜻일 뿐, 노드, 규칙 참조, 원격 리소스에 모두 접근할 수 있다는 보장은 없습니다.

chmod +x ./mihomo
./mihomo -t -d "$HOME/mihomo-config"
./mihomo -d "$HOME/mihomo-config"

systemd 서비스를 만들 계획이라면 안정적인 절대 경로를 사용하고 작업 디렉터리, 실행 사용자, 재시작 정책을 명확히 지정하세요. 일반 로컬 프록시에 관리자 권한이 필요하지 않을 수 있지만 TUN 인터페이스 생성, 라우팅 변경, DNS 트래픽 처리에는 해당 권한이나 기능이 필요할 수 있습니다. 편의를 위해 모든 그래픽 인터페이스를 root로 실행하지 마세요. 백그라운드 서비스가 시작되지 않으면 해당 서비스 로그를 확인하고 설정 디렉터리 권한과 리소스 파일 경로를 중점적으로 살펴보세요. 포그라운드에서 실행된다고 해서 서비스 사용자도 같은 파일을 읽을 수 있는 것은 아닙니다.

TUN을 활성화한 뒤 기본 라우트, DNS 관리 방식, 다른 VPN 상태를 확인하세요. NetworkManager, systemd-resolved, 클라이언트가 각각 네트워크의 일부를 관리할 수 있습니다. DNS 설정 파일을 직접 덮어쓰면 다시 연결할 때 설정이 무효가 될 수 있습니다. 먼저 DNS를 누가 관리하는지 확인한 뒤 해당 통합 방식을 사용하세요. 서버에서는 방화벽도 확인해야 합니다. 로컬 프록시와 제어 인터페이스는 기본적으로 로컬 기기에서만 사용해야 하며 원격 조작이 편리하다는 이유로 공용 네트워크에 개방해서는 안 됩니다. 서비스를 중지한 뒤 라우팅과 DNS가 복구됐는지 확인하고 다음 트래픽 처리 테스트를 진행하세요.

설정 확인 및 문제 진단

재현 가능한 실패 요청 하나를 기준으로 문제를 확인하세요. 대상 도메인, 발생 시각, 현재 설정, 트래픽 처리 방식을 기록한 뒤 연결이 커널에 전달됐는지 살펴보세요. 연결 기록이 없다면 시스템 프록시, 앱 프록시, TUN 적용 범위를 먼저 확인하세요. 기록은 있지만 출구가 잘못됐다면 규칙 순서와 정책 그룹을 살펴보세요. 출구가 올바른데 요청이 실패한다면 노드, DNS, 대상 서비스 상태를 확인합니다. 구독 업데이트만 실패하고 기존 설정은 계속 사용할 수 있다면 먼저 구독을 가져오는 경로를 확인하세요. 두 문제를 모두 ‘인터넷 연결 안 됨’으로 묶어 처리하지 마세요.

포트 설정 및 제어 인터페이스

mixed-port는 HTTP와 SOCKS 프록시 요청을 모두 받는 수신 포트입니다. external-controller는 제어 인터페이스이며 일반 프록시 포트가 아닙니다. 브라우저를 제어 인터페이스에 연결하면 오류가 발생하고, 프록시 모드를 바꿔도 해결되지 않습니다. 아래는 확인에 사용할 기본 설정 예시입니다. 적용하기 전에 전체 설정에 병합해야 하며 직접 연결 출구만 포함하고 프록시 노드는 제공하지 않습니다. 포트 번호는 예시이므로 이미 사용 중이면 실행 설정, 시스템 프록시, 앱 프록시에서 동일하게 변경하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: LOCAL
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,LOCAL
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

수신 주소와 로컬 네트워크 접근 허용 여부는 가속 옵션이 아니라 보안 경계입니다. 기기 안에서만 사용한다면 루프백 연결만 유지하면 됩니다. 신뢰할 수 있는 기기에 프록시를 제공해야 한다면 바인딩 주소, 인증, 방화벽, 연결된 네트워크를 확인하세요. 특히 제어 인터페이스 연결에 실패했다고 모든 네트워크 어댑터에서 바로 사용할 수 있도록 열어서는 안 됩니다. 포트 충돌이 의심되면 먼저 해당 포트를 사용하는 프로세스를 찾아 이전 커널인지 확인한 뒤 기존 프로그램을 종료할지 포트를 바꿀지 결정하세요. 정체를 알 수 없는 시스템 프로세스를 임의로 종료하지 마세요.

규칙 순서, DNS, Fake-IP

규칙은 보통 위에서부터 순서대로 적용되므로 구체적인 규칙을 관련 기본 처리 규칙보다 앞에 두고 MATCH는 대개 마지막에 둡니다. 규칙에서 참조하는 정책 그룹 이름은 실제로 존재해야 하며 철자와 대소문자도 일치해야 합니다. 구독에 특정 노드가 있어도 규칙이 자동으로 그 노드를 사용하는 것은 아닙니다. 실제 출구는 일치한 정책 그룹과 그룹 내 현재 선택에 따라 달라집니다. 변경 후 대상 연결을 새로 만들어 확인하세요. 기존 장기 연결은 이전 출구를 계속 사용할 수 있습니다. 설정 절차는 규칙 분기 설정을 참고하세요.

Fake-IP는 예약된 주소와 도메인 사이에 매핑을 만들며, 규칙 판단은 커널이 도메인 정보를 알고 있는지에 따라 달라집니다. 일반적인 공용 IP 주소가 아닌 값이 반환됐다는 이유만으로 DNS 조회 실패라고 판단하지 마세요. 실제 호환성 문제가 있다면 적절한 필터 설정에 해당 도메인을 추가하고 현재 커널에서 사용하는 필터 모드를 확인하세요. 출처를 모르는 목록을 통째로 복사하지 마세요. 시스템 캐시, 브라우저 자체 조회, 클라이언트 DNS가 여러 경로를 만들 수 있으므로 한 번에 하나씩 바꿔 확인하세요. 자세한 원리는 Fake-IP DNS 매핑 설명을 참고하세요.

GeoIP 업데이트 및 설정 덮어쓰기

먼저 설정에서 기존 GeoIP 데이터 파일을 사용하는지, geodata 모드를 활성화했는지 확인하세요. 모드에 따라 필요한 리소스와 경로가 다릅니다. 인터페이스의 업데이트 동작이 현재 사용 중인 데이터를 덮어쓰는지는 로그와 실행 설정으로 확인해야 합니다. GeoIP 업데이트로 모든 규칙 문제가 해결되지는 않습니다. 도메인 규칙이 먼저 일치할 수 있고, 규칙 집합마다 업데이트 주기가 다르며, 일부 매칭 방식은 DNS 조회 여부에도 영향을 줍니다. 데이터베이스를 읽을 수 없다는 오류가 발생하면 재시작만 반복하지 말고 다운로드 완료 여부, 디렉터리 권한, 설정 경로를 확인하세요.

리소스 업데이트와 구독 업데이트도 별도로 기록해야 합니다. 원격 규칙 집합 업데이트에 실패하면 접근 경로와 캐시를 사용할 수 있는지 먼저 확인하세요. 구독을 교체해도 규칙 집합 상태는 바뀌지 않을 수 있습니다. 사용자 지정 규칙을 계속 유지하려면 덮어쓰기 설정에 작성하고 구독 업데이트 후 최종 실행 설정을 확인하세요. YAML은 공백으로 들여쓰기하며 목록, 키 이름, 중첩 수준을 올바르게 유지해야 합니다. 구문 검사에 통과한 뒤에도 시작 로그를 확인해 원격 참조와 규칙 그룹이 실제로 불러와졌는지 확인하세요.

변경 후 네트워크 연결이 완전히 끊겼다면 현재 트래픽 처리 기능을 끄고 직접 연결을 복구한 다음 마지막으로 변경한 항목을 되돌리세요. 전체 점검 순서는 연결은 됐지만 웹페이지가 열리지 않을 때 단계별 점검 목록을 참고하고, 일반적인 질문은 문제 해결에서 확인하세요. 복구한 뒤에는 직접 연결과 프록시 연결을 각각 다시 테스트해 문제가 실제로 해결됐는지 확인하세요. 브라우저 캐시나 기존 연결이 우연히 작동한 결과일 수도 있습니다.