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

공통 준비: 클라이언트, 구독, 트래픽 처리 방식

인터페이스·코어·설정 파일을 구분하세요

Clash는 일반적으로 규칙 기반 프록시 도구를 가리키며, 실제로 설치할 때는 구체적인 클라이언트를 선택해야 합니다. 클라이언트는 인터페이스를 제공하고 설정을 관리하며 시스템 권한을 요청합니다. 코어는 연결을 받아 도메인을 해석하고 트래픽을 분기합니다. mihomo는 이 생태계의 코어 중 하나입니다. 인터페이스가 정상적으로 열려도 코어가 실행 중이라는 뜻은 아니며, 노드 목록이 표시되어도 시스템 트래픽이 프록시로 전달된다는 보장은 없습니다.

일반적인 기기라면 Clash Plus부터 사용해 보세요. 다른 인터페이스나 기능이 필요하면 다운로드 센터의 플랫폼별 목록을 참고하세요. 여러 클라이언트가 동시에 네트워크를 처리하도록 설정하지 마세요. 로컬 포트, 시스템 프록시, 가상 네트워크 어댑터를 두고 충돌할 수 있습니다. 클라이언트를 바꾸기 전에는 기존 포트와 트래픽 처리 방식을 기록하고, 기존 클라이언트를 종료한 뒤 새 클라이언트를 실행하면 변경 원인을 파악하기 쉽습니다.

설정 파일은 보통 YAML 형식이며 노드, 프록시 그룹, 규칙, DNS 설정이 포함될 수 있습니다. 클라이언트마다 가져올 수 있는 형식이 다르므로 파일 확장자만 보고 호환 여부를 판단할 수 없습니다. 불러오기에 실패하면 먼저 로그에서 문법 오류, 미지원 필드, 다운로드 실패 중 무엇을 알리는지 확인한 다음 파일을 수정할지 구독 형식을 바꿀지 결정하세요.

구독을 준비하고 접근 정보를 안전하게 관리하세요

클라이언트 자체가 곧바로 사용할 수 있는 프록시 서비스는 아닙니다. 시작하기 전에 사용 권한이 있는 구독 URL이나 로컬 설정을 준비하고 서비스 이용 기간이 유효한지 확인하세요. 주소를 복사할 때는 구독 제공업체의 복사 버튼을 사용해 안내 문구, 줄바꿈, 끝의 공백이 함께 들어가지 않도록 하세요. 노드 공유 링크만 있다면 클라이언트가 해당 형식을 지원하는지 먼저 확인하세요. 아무 웹 주소나 구독으로 가져올 수 있는 것은 아닙니다.

구독 링크에는 접근 정보가 포함될 수 있으므로 비밀번호처럼 취급하세요. 문제를 확인할 때는 오류 유형만 설명하고 공개 댓글에 전체 주소를 붙여 넣거나 실제 노드 비밀번호가 포함된 설정을 업로드하지 마세요. 도움을 요청할 때는 구독 매개변수, 서버 주소, 인증 정보를 삭제하고 필드명, 들여쓰기, 오류가 난 줄 주변의 구조만 남기세요. 구독 변환을 이용하기 전에 구독 변환 안내를 확인하세요.

가져오기가 끝나면 현재 설정으로 선택되어 있는지 확인하고, 프록시 그룹에 선택할 수 있는 노드가 있는지 살펴보세요. 일부 클라이언트는 설정 다운로드와 활성화를 별도 단계로 처리합니다. 업데이트 버튼이 성공했다는 것은 파일을 가져왔다는 뜻일 뿐입니다. 새 설정을 불러오지 못하면 이전 설정을 계속 사용할 수도 있으므로 현재 설정 이름과 로그를 함께 확인하세요. 성공 메시지만으로 적용 여부를 판단하면 안 됩니다.

시스템 프록시와 TUN 중 하나를 선택해 중복 처리를 피하세요

시스템 프록시는 시스템 프록시 설정을 따르는 앱의 연결을 로컬 수신 포트로 전달하므로 브라우저 접속부터 확인하기 좋습니다. TUN은 가상 네트워크 인터페이스로 더 다양한 연결을 받으며 라우팅과 DNS 설정도 필요합니다. 둘은 단순한 상하 관계가 아닙니다. 시스템 프록시만으로 충분하다면 먼저 트래픽 처리 범위를 좁게 유지하세요. 시스템 프록시를 따르지 않는 앱이 있다면 TUN을 고려할 수 있습니다.

설치 전에 다른 VPN 및 프록시 프로그램을 잠시 종료하세요. 특히 기본 경로를 변경하는 도구에 유의하세요. 업무용 기기는 조직 정책의 제한을 받을 수 있으므로 관리 요구사항을 우회해서는 안 됩니다. 웹 로그인 인증이 필요한 네트워크라면 먼저 인증을 완료한 뒤 프록시를 활성화하세요. 그렇지 않으면 구독 요청에 설정 파일 대신 인증 페이지가 반환될 수 있습니다.

정해진 순서에 따라 첫 연결을 확인하세요

먼저 코어를 실행하고 설정을 가져와 활성화한 다음 규칙 모드를 선택하세요. 이어서 특정 노드를 선택하고 마지막으로 트래픽 처리 방식을 하나만 켭니다. 클라이언트의 연결 페이지를 열어 알려진 대상에 접속한 뒤 해당 연결과 규칙 기록이 나타나는지 확인하세요. 테스트할 때는 설정을 한 번에 하나씩만 변경하고 기존 값도 기록해 두세요. 노드, DNS, 모드를 동시에 바꾸면 성공하거나 실패해도 원인을 찾기 어렵습니다.

Windows: 설치, 서비스 모드, 시스템 프록시

아키텍처에 맞는 설치 파일을 선택하고 첫 실행하기

Windows 다운로드에서 Clash Plus를 우선 확인하고, 필요에 따라 Clash Verge Rev, FlClash 또는 Clash Nyanpasu를 선택하세요. Clash for Windows는 더 이상 유지 관리되지 않습니다. 보관된 설치 파일은 기존 환경을 이전할 때 사용할 수 있지만 새 기기의 기본 선택으로는 권장하지 않습니다. 이름이 비슷한 클라이언트라도 설정 폴더가 다를 수 있으므로 바꾸기 전에 필요한 설정을 내보내세요.

시스템 설정의 ‘시스템 > 정보’에서 시스템 종류를 확인하고 프로세서 아키텍처와 운영체제 비트 수를 구분하세요. 다운로드 페이지에 기기에 맞는 빌드가 없다면 파일 이름을 바꿔 설치하려고 하지 마세요. 설치 프로그램을 실행해 안내에 따라 설치 위치를 선택하고, 첫 실행은 일반 사용자 권한으로 진행하세요. 시스템 서비스나 드라이버 설치처럼 권한 상승이 명시적으로 필요한 작업에 한해 승인을 허용하세요.

방화벽 알림이 표시되면 실제 사용 범위에 따라 허용 여부를 결정하세요. 이 기기에서만 사용할 프록시라면 다른 기기에 로컬 네트워크 접근을 허용할 필요가 없습니다. 가정 내 다른 기기와 프록시를 공유해야 한다면 네트워크 유형, 수신 주소, 방화벽 범위를 먼저 확인하세요. 프로그램을 실행하려고 방화벽 전체를 끄면 문제와 무관한 네트워크 접근까지 허용하게 됩니다.

구독을 가져오고 설정 적용 여부 확인하기

설정 또는 구독 페이지에서 URL로 가져오기를 선택하고 전체 구독 주소를 붙여 넣은 다음 알아보기 쉬운 이름을 지정하세요. 다운로드가 끝나면 해당 설정을 선택하고 프록시 그룹에 노드가 표시되는지 확인합니다. 처음에는 규칙 모드를 사용하고 노드를 수동으로 선택해 자동 전략 변경이 문제 확인에 영향을 주지 않도록 하세요. 구독을 준비하는 방법은 구독 가져오기 가이드를 참고하세요.

클라이언트에서 파싱 오류가 표시되면 로그에서 오류 위치를 확인하세요. YAML 들여쓰기에는 공백을 사용하며 목록 항목 앞의 하이픈도 구조의 일부입니다. 다른 클라이언트의 설정 파일 전체를 그대로 덮어쓰지 마세요. 일부 확장 필드는 특정 코어에서만 지원됩니다. 새 설정을 불러오지 못하면 이전에 사용할 수 있던 설정으로 되돌린 뒤 새 파일을 따로 확인하세요. 문제가 기기 전체의 인터넷 연결 중단으로 번지는 것을 막을 수 있습니다.

먼저 시스템 프록시를 확인하고 TUN은 필요한 경우에만 켜세요

클라이언트에서 시스템 프록시를 켠 뒤 Windows 프록시 설정에서 로컬 주소와 포트를 확인하세요. 인터페이스에 HTTP 포트가 표시될 수도 있고 혼합 포트가 사용될 수도 있으므로 현재 클라이언트에 표시된 값을 기준으로 삼으세요. 브라우저는 접속되지만 특정 앱만 연결되지 않는다면 앱 자체 프록시 설정이 있는지, 시스템 프록시를 따르지 않는지 확인하세요. 노드 문제라고 바로 단정하지 마세요.

TUN이 필요하면 클라이언트 안내에 따라 서비스 모드나 관련 네트워크 구성요소를 먼저 설치한 다음 TUN을 켜세요. 서비스 설치 완료와 서비스 실행 중은 서로 다른 상태입니다. 스위치가 바로 꺼지면 로그에서 권한, 장치 생성, 라우팅 기록 오류를 확인하세요. 정상적으로 켜진 뒤에는 시스템 트레이 아이콘만 보는 대신 연결 페이지에 대상 앱의 요청이 들어오는지 확인하세요.

일부 보안 프로그램은 가상 네트워크 어댑터, 서비스 프로세스, 네트워크 필터링 작업을 제한할 수 있습니다. 로그에 명확히 표시된 권한 문제를 확인하고 클라이언트 폴더 전체를 광범위한 예외에 추가할 필요는 없습니다. 다른 VPN이 실행 중이라면 먼저 종료한 뒤 다시 시도하세요. 회사 내부망, 원격 데스크톱, 프린터에 접근해야 한다면 TUN을 켜기 전에 사설 네트워크 경로가 잘못 처리되지 않는지 확인하세요.

종료 후 인터넷 연결 불가 및 포트 사용 중 문제

클라이언트를 종료한 뒤에도 Windows가 더는 수신하지 않는 로컬 프록시를 가리키면 시스템 프록시를 따르는 앱의 연결이 실패합니다. 클라이언트를 다시 실행해 시스템 프록시를 끈 다음 시스템 프록시 설정이 복구됐는지 확인하세요. 해당 프록시를 더 이상 사용하지 않는다면 남아 있는 수동 프록시 항목만 삭제하세요. 조직에서 배포한 자동 구성 스크립트나 기존 네트워크 정책은 임의로 삭제하지 마세요.

로그에 수신 대기 실패가 나타나면 기존 클라이언트가 포트를 사용 중인지 확인하세요. 다음 명령은 예시 포트의 수신 상태를 확인할 때만 사용합니다. 실제 포트가 다르면 설정 페이지에 표시된 포트로 바꾸세요. 프로세스 번호로 어떤 프로그램인지 확인한 뒤 충돌하는 프로그램을 정상적으로 종료하세요. 정체를 모르는 시스템 프로세스를 강제 종료하지 마세요.

netstat -ano | findstr :7890

브라우저가 자체 프록시 확장을 계속 사용하면 시스템 설정이 정상이어도 이전 포트로 연결될 수 있습니다. 테스트할 때는 확장 기능을 잠시 중지하고 기본 네트워크 설정으로 결과를 비교하세요. 컴퓨터를 재시작하면 일부 임시 상태가 초기화될 수 있지만 프록시 주소, 서비스 상태, 설정 오류 확인을 대신할 수는 없습니다. 네트워크가 복구되면 실제 원인을 기록해 다음 시작 때 같은 문제가 반복되지 않도록 하세요.

자동 시작 설정 후에도 상태를 확인할 수 있게 유지하세요

정상적으로 시작하고 연결한 뒤 종료하는 과정을 한 번 완료하고 나서 자동 시작을 설정하세요. 그래픽 인터페이스 실행, 백그라운드 서비스, 프록시 자동 활성화는 각각 별도의 옵션일 수 있습니다. 인터페이스가 시작됐다고 네트워크 트래픽이 이미 처리되고 있다고 판단하지 마세요. 재부팅 후 로그인해 현재 설정과 연결 기록을 확인하세요. 특히 서비스가 사용자 세션보다 먼저 시작될 때 사용자 폴더의 설정을 읽을 수 있는지 점검해야 합니다. 공통 확인 방법은 자동 시작 문제 해결을, 플랫폼별 자세한 절차는 Windows 설치 및 방화벽 가이드를 참고하세요.

macOS: 설치 권한, 보조 서비스, 네트워크 확장

칩 아키텍처와 클라이언트 유지 관리 상태 확인

Apple 메뉴의 ‘이 Mac에 관하여’에서 Apple Silicon 또는 Intel 프로세서 사용 여부를 확인한 다음 macOS 다운로드에서 맞는 설치 파일을 선택하세요. Clash Plus를 우선 확인하고 Clash Verge Rev 또는 FlClash도 사용할 수 있습니다. ClashX Meta는 더 이상 유지 관리되지 않으며 기존 설정 호환이나 이전 용도에 적합합니다. 이름에 Meta가 포함됐다고 계속 유지 관리된다는 뜻은 아닙니다.

디스크 이미지를 연 다음 앱을 ‘응용 프로그램’ 폴더로 복사하고 해당 폴더에서 실행하세요. 다운로드 폴더나 디스크 이미지에서 계속 실행하면 보조 서비스 경로, 자동 시작 항목, 업데이트 동작이 불안정해질 수 있습니다. 기존 파일과 충돌한다는 안내가 나타나면 실행 중인 클라이언트를 종료하고 설정을 백업한 뒤 정상적인 교체 절차를 따르세요. 자동 시작되는 복사본을 여러 개 남겨두지 마세요.

처음 실행할 때 보안 경고가 나타나면 다운로드 출처를 고려해 판단하세요. 신뢰할 수 있는 경로에서 파일을 다시 받고 다운로드가 완료됐는지, 시스템과 호환되는지 확인하세요. 인터넷에 떠도는 시스템 보호 전체 비활성화 명령을 그대로 실행하지 마세요. 그래도 ‘손상됨’ 또는 열 수 없다는 안내가 나타나면 macOS 설치 및 권한 안내에 따라 항목별로 확인하세요. 모든 차단을 같은 문제로 취급하면 안 됩니다.

구독을 가져오고 앱 권한과 설정 문제를 구분하세요

앱을 실행한 뒤 설정 관리에서 구독 주소를 추가하고 가져오기가 끝나면 현재 설정으로 지정하세요. 노드가 표시되면 규칙 모드와 수동 노드를 선택합니다. 가져오기 버튼은 성공했지만 목록이 비어 있다면 구독 응답이 로그인 페이지나 오류 안내인지 확인하고 클라이언트가 해당 형식을 지원하는지도 살펴보세요. 시스템 네트워크 권한을 허용해도 구독 문법 오류가 해결되지는 않으므로 두 문제를 따로 확인해야 합니다.

시스템 프록시 설정이나 높은 권한이 필요한 네트워크 작업을 위해 클라이언트가 보조 도구 설치를 요청할 수 있습니다. 현재 작업과 관련된 권한 요청인지 확인하고 앱 이름도 살펴본 뒤에만 허용하세요. 시스템 계정 암호를 입력하는 것은 시스템 변경을 승인하기 위한 것이며, 구독에 암호를 기록하는 것과는 다릅니다. 권한 요청이 계속 반복되면 보조 서비스 설치 여부와 앱이 원래 설치 경로에 있는지 확인하세요.

키체인 알림은 별도로 판단하세요. 앱이 민감한 설정을 저장하거나 읽는 것과 관련될 수 있으므로 프록시를 사용한다는 이유만으로 모든 요청을 허용해서는 안 됩니다. 계정 암호를 변경했거나 시스템을 이전했다면 키체인 상태 때문에 읽기에 문제가 생길 수도 있습니다. 요청을 보낸 앱이 실제로 사용 중인 앱인지 먼저 확인하고 시스템 안내에 따라 처리하세요. 관련 없는 키체인 문제를 노드 인증 오류로 오인하지 마세요.

현재 네트워크 서비스의 시스템 프록시 확인

시스템 프록시를 켠 뒤 시스템 설정의 네트워크 세부 정보에서 현재 사용 중인 네트워크 서비스를 확인하세요. Wi-Fi, 유선 네트워크 어댑터, 기타 연결은 각각 다른 프록시 설정을 저장할 수 있습니다. 한 네트워크에서 적용된다고 다른 네트워크에서도 동일하게 작동하는 것은 아닙니다. 자동 프록시 스크립트를 사용하는 업무 환경이라면 클라이언트 전환 전에 기존 설정을 확인해 조직에서 요구하는 프록시 주소가 덮어써지지 않도록 하세요.

테스트에는 시스템 프록시 설정을 따르는 브라우저를 먼저 사용하고 클라이언트 연결 페이지에서 해당 도메인을 찾으세요. 터미널 도구는 그래픽 시스템의 프록시 설정을 자동으로 읽지 않을 수 있으므로 터미널 접속 실패만으로 시스템 프록시가 작동하지 않는다고 판단할 수 없습니다. 앱 자체 프록시 옵션이 있다면 명확한 경로 하나만 사용하세요. 시스템 프록시가 클라이언트를 가리키고 클라이언트는 다시 다른 프록시 도구로 전달하는 순환을 피해야 합니다.

클라이언트를 종료하기 전에 시스템 프록시를 끄고 직접 연결이 복구되는지 확인하세요. 비정상 종료로 로컬 프록시 주소가 남았다면 클라이언트를 다시 열어 상태를 복구한 뒤 정상적으로 종료할 수 있습니다. 수동으로 정리할 때는 해당 클라이언트에 속한다고 확실히 알 수 있는 항목만 수정하세요. 원래 필요한 자동 검색, 자동 구성, 다른 네트워크 서비스 설정은 유지해 한 문제를 고치려다 전체 네트워크 설정을 망가뜨리지 않도록 하세요.

TUN, 네트워크 확장, 내부망 라우팅

macOS 클라이언트마다 보조 서비스, 가상 인터페이스, 네트워크 확장 등 네트워크를 처리하는 방식이 다릅니다. 모든 프로그램에 같은 권한 창이 나타나야 한다고 생각하지 말고 현재 클라이언트의 안내를 따르세요. 네트워크 확장 요청이 실제로 나타나면 시스템 설정의 관련 개인정보 보호, 보안 또는 확장 관리 항목에서 허용한 뒤 클라이언트로 돌아와 상태를 확인하세요.

TUN을 켤 수 없다면 먼저 시스템 권한과 보조 서비스를 확인하고, 다음으로 라우팅과 DNS를 살펴보세요. 켠 뒤 일부 웹사이트만 접속된다면 다른 VPN, 필터링 프로그램, 기업용 네트워크 구성요소가 동시에 경로를 변경하는지 확인하세요. 필요하지 않은 도구를 하나씩 중지해 비교 테스트하고 모든 네트워크 서비스를 한꺼번에 삭제하지 마세요. 로컬 네트워크 기기에 접근할 수 없다면 사설 네트워크의 직접 연결과 라우팅 제외를 확인하세요.

잠자기에서 깨어난 뒤 네트워크가 잠시 달라지는 현상도 따로 기록할 필요가 있습니다. 기기의 주소, 기본 게이트웨이, DNS가 바뀌었는데 백그라운드 연결은 이전 상태를 유지할 수 있습니다. 현재 네트워크 연결이 완료될 때까지 기다린 뒤 코어 로그를 확인하고, 필요하다면 트래픽 처리 기능만 재시작하세요. 매번 시스템 전체를 재시작해야 복구된다면 구독을 계속 바꾸기보다 잠자기 전후 로그를 보관하는 편이 원인 파악에 도움이 됩니다.

Android: 앱 설치, VPN 권한, 백그라운드 실행

기기 아키텍처에 맞는 앱을 선택하고 기존 설정을 보존하세요

Android 다운로드에서 설치 파일을 선택하세요. Clash Plus를 우선 확인하고, Clash Meta for Android, FlClash, Surfboard도 선택할 수 있습니다. 최근 기기는 대부분 ARM64를 사용하지만 기기 아키텍처와 클라이언트 지원 여부를 확인해야 합니다. 기기 아키텍처를 확인하기 어렵고 다운로드 페이지에 해당 빌드가 명시된 경우에는 범용 패키지를 사용할 수 있습니다. 모든 휴대전화가 같은 프로세서 환경이라고 가정하지 마세요.

브라우저나 파일 관리자로 설치할 때 Android에서 해당 출처의 앱 설치를 허용하라는 메시지가 나타날 수 있습니다. 이번에 사용할 출처에만 필요한 권한을 허용하고 설치 후에는 원래 설정으로 되돌릴 수 있습니다. 업데이트 설치 중 서명이 일치하지 않는다는 안내가 나타나도 기존 앱을 바로 삭제하지 마세요. 구독 이름, 앱별 설정, 로컬 덮어쓰기 설정을 먼저 백업한 다음 설치 파일의 출처와 같은 클라이언트인지 확인하세요.

시스템 버전, 제조사별 사용자 지정, 앱 권한 관리에 따라 메뉴 위치가 달라질 수 있지만 확인 순서는 같습니다. 먼저 설치와 실행이 가능한지 확인하고 그다음 네트워크 처리를 설정하세요. 앱이 시작하자마자 종료된다면 시스템 호환성과 설치 파일 아키텍처를 확인해야 하며 DNS를 바꿔 해결할 수 없습니다. 알 수 없는 출처의 드라이버 패치를 설치하지 마세요. Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 사용합니다.

구독을 가져오고 첫 VPN 안내의 의미를 확인하세요

설정 관리에서 원격 구독을 추가하거나 로컬 파일을 가져오세요. 설정 이름을 지정하고 업데이트한 뒤 현재 설정으로 전환해 프록시 그룹에 노드가 있는지 확인합니다. 일부 클라이언트는 업데이트가 끝난 후 메인 화면으로 돌아가 연결을 시작해야 합니다. 파일을 가져온 경우 이후 원격 구독을 새로고침해도 로컬 파일이 자동으로 업데이트되지 않습니다. 오래된 노드를 계속 사용하지 않도록 설정의 업데이트 출처를 확인하세요.

처음 연결을 시작하면 시스템에서 VPN 연결을 설정할지 묻습니다. 여기서 VPN은 Android가 제공하는 네트워크 트래픽 처리 인터페이스를 뜻하며 다른 기존 VPN 서비스에 자동으로 연결된다는 의미가 아닙니다. 권한을 허용해야 클라이언트가 시스템에서 전달하는 트래픽을 받을 수 있습니다. 권한을 취소하면 노드 목록과 규칙이 불러와져도 앱 연결을 처리하지 않습니다.

Android에서는 일반 VPN 인터페이스 하나만 동시에 작동하는 경우가 많습니다. 다른 VPN, 로컬 VPN을 사용하는 필터링 도구, 일부 방화벽 앱을 실행하면 현재 연결을 대체할 수 있습니다. 스위치가 바로 꺼지거나 상태가 계속 바뀌면 구독과 노드를 다시 확인하기 전에 다른 앱이 인터페이스를 사용 중인지 살펴보세요. 같은 주소를 반복해서 가져오지 마세요.

앱별 프록시와 로컬 네트워크 접근

Android 클라이언트는 보통 데스크톱 시스템의 프록시 스위치를 사용하지 않고 VPN 처리 범위에서 연결을 다룹니다. 앱별 목록에는 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’처럼 서로 반대되는 방식이 있을 수 있습니다. 변경하기 전에 현재 모드의 설명을 읽고 대상 앱 하나의 연결 기록을 확인한 뒤 의미를 파악하고 나머지를 추가하세요.

특정 앱이 연결 페이지에 전혀 나타나지 않으면 제외 목록에 있는지, 업무 프로필 공간에 있는지, 다른 사용자로 실행되는지 확인하세요. 개인 공간과 업무 공간은 시스템이 제공하는 네트워크 범위가 다를 수 있습니다. 앱별 설정을 변경한 뒤 VPN을 다시 연결하고 대상 앱을 다시 열어야 할 수도 있습니다. 기존 연결이 새 트래픽 처리 경로로 자동 전환되지는 않습니다.

화면 미러링, 프린터, 라우터 관리 페이지 등은 로컬 네트워크 접근을 사용합니다. 프록시를 켠 뒤 이런 기능이 작동하지 않으면 사설 주소의 직접 연결 규칙과 클라이언트의 로컬 네트워크 우회 옵션을 확인하세요. 로컬 네트워크에서 휴대전화의 프록시에 연결하도록 허용하는 기능과 휴대전화가 로컬 네트워크를 우회하는 기능은 서로 다릅니다. 앞 기능은 수신 대기와 공유에, 뒤 기능은 라우팅 범위에 관한 것이므로 하나의 스위치로 두 기능을 처리할 수 없습니다.

실제 연결이 끊기는 원인을 확인해 백그라운드 실행을 조정하세요

화면이 켜져 있을 때는 정상인데 잠금 후 연결이 끊긴다면 배터리 최적화, 백그라운드 실행, 제조사의 앱 정리 정책부터 확인하세요. 클라이언트의 백그라운드 활동을 적절히 허용한 뒤 화면을 잠가 다시 테스트하고 시스템 VPN 아이콘과 앱을 다시 열었을 때의 로그를 살펴보세요. 모든 앱에 백그라운드 권한을 줄 필요는 없습니다. 배터리 사용량 알림만으로 코어에 문제가 생겼다고 판단하지 말고 실제 연결이 끊겼는지 확인하세요.

‘항상 사용 VPN’과 ‘VPN 없이 연결 차단’은 시스템 수준 기능이므로 켜기 전에 복구 방법을 확인하세요. 후자를 활성화하면 VPN 연결이 없을 때 네트워크가 제한되므로 구독이나 클라이언트에 문제가 생겨도 기기 전체가 인터넷에 연결되지 않을 수 있습니다. 설정이 안정적으로 작동하는지 확인하고 시스템 VPN 설정 위치를 기억한 다음 활성화 여부를 결정하세요. 연결 실패를 해결하는 스위치가 아닙니다.

Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 모바일 네트워크의 IPv6, UDP 지원, 현재 노드 경로도 다를 수 있습니다. 먼저 같은 노드를 두 네트워크에서 비교한 뒤 노드나 프로토콜을 바꾸세요. 앱 하나만 실패하면 앱별 처리 범위를 확인하고 모든 앱이 실패하면 VPN 상태와 기본 네트워크를 살펴보세요. 영향 범위에 따라 점검 대상을 좁힐 수 있습니다.

iOS: 앱 설치, 설정 가져오기, 온디맨드 연결

Clash Plus를 설치하고 기능 위치를 확인하세요

iPhone과 iPad에서는 App Store에서 Clash Plus를 설치할 수 있으며, 제품 정보는 공식 사이트 clashplus.io에서 확인할 수 있습니다. iOS 다운로드 안내를 먼저 살펴봐도 됩니다. 설치 후 앱을 열어 설정, 프록시 그룹, 연결 상태가 표시되는 위치를 확인한 다음 기존 구독을 가져오세요. 시스템 VPN 설정 화면을 구독 관리 메뉴로 착각하지 않도록 주의하세요.

모바일 운영체제의 트래픽 처리 방식은 데스크톱과 다릅니다. Windows의 서비스 설치 절차를 그대로 따라 하거나 같은 이름의 가상 네트워크 드라이버를 찾을 필요가 없습니다. 클라이언트는 보통 시스템 네트워크 확장으로 VPN 구성을 설정합니다. 권한과 연결 상태는 시스템 설정에서 관리하고, 노드·프록시 그룹·규칙은 클라이언트에서 관리하므로 두 화면의 정보는 용도가 다릅니다.

처음 실행할 때 알림, 네트워크 등의 권한 요청이 표시될 수 있으므로 각 요청을 기능에 따라 판단하세요. 첫 연결을 위한 VPN 구성 권한은 일반 알림 권한과 다릅니다. 네트워크 처리 권한을 취소했다면 앱으로 돌아가 연결을 다시 시작하고 시스템 안내에 따라 승인하세요. 알림 권한을 켜도 프록시가 자동으로 적용되거나 누락된 구독 설정이 추가되지는 않습니다.

구독을 가져온 뒤 연결을 반복하기보다 프록시 설정부터 확인하세요

앱의 설정 관리에서 구독을 추가하고 전체 주소를 붙여 넣어 업데이트하세요. 공유 메뉴로 파일을 가져왔다면 지원되는 설정이 실제로 들어 있는지 확인하세요. 가져온 뒤 현재 설정으로 지정하고 프록시 그룹에서 선택할 수 있는 항목을 확인합니다. 설정 이름은 로컬에서 구분하기 위한 것으로 용도에 맞게 지정할 수 있지만 계정 암호나 전체 접근 주소를 이름에 저장하지 마세요.

노드 목록은 있는데 접속할 수 없다면 먼저 특정 노드를 선택하고 현재 모드를 확인하세요. 규칙 모드는 규칙에 따라 정책을 선택하고, 전역 모드는 해당 연결을 전역 정책에 전달합니다. 전역 모드로 노드 문제를 해결할 수는 없습니다. 첫 연결을 확인할 때는 변수를 잠시 줄이되, 평소에는 접속 목적과 내부망 요구사항에 맞는 모드를 선택하세요. 잘못된 규칙을 가리려고 전역 모드를 계속 사용할 필요는 없습니다.

구독 업데이트와 이미 설정된 연결은 서로 다른 과정입니다. 업데이트에 성공한 뒤 현재 설정이 적용됐는지 확인해야 합니다. 이미 열려 있는 장시간 연결은 기존 경로를 계속 사용할 수도 있습니다. 새 설정을 테스트할 때는 대상 앱을 다시 열고 필요하면 VPN을 재연결한 뒤 클라이언트에서 새 연결 기록을 확인하세요. 같은 캐시 페이지를 새로고침하는 것만으로 새 규칙의 적용 여부를 판단하지 마세요.

VPN 상태, 온디맨드 연결, 다른 네트워크 도구

연결을 시작하고 시스템 VPN 구성 권한을 허용한 뒤 시스템 설정에서 연결 상태를 확인하고 테스트 대상에 접속하세요. VPN이 연결됐다고 표시되면 시스템 통신 경로가 만들어진 것입니다. 상위 노드가 작동한다는 뜻은 아닙니다. 로그에 연결 기록은 있지만 요청이 계속 실패하면 시스템 VPN 구성을 반복해서 삭제하기보다 노드 인증, 서버 접속 가능 여부, 대상에 적용된 규칙을 확인하세요.

온디맨드 연결은 조건을 만족할 때 시스템이 연결을 시작하도록 하는 기능이지 앱이 계속 화면에 떠 있어야 한다는 뜻은 아닙니다. 조건에는 네트워크 종류나 클라이언트가 제공하는 정책이 포함될 수 있으며 자세한 내용은 현재 인터페이스를 기준으로 확인하세요. 처음 설정할 때는 수동 연결로 정상 작동 여부를 확인한 뒤 온디맨드 규칙을 켜세요. 그렇지 않으면 문제 확인 중 자동 재연결되어 스위치를 끌 수 없는 것처럼 보일 수 있습니다.

다른 VPN이나 네트워크 확장을 사용하는 도구가 현재 경로에 영향을 줄 수 있습니다. 문제를 확인할 때는 불필요한 도구를 잠시 중지하고 시스템에 이전 VPN 구성이 남아 있는지 살펴보세요. 더 이상 사용하지 않는 것이 확실할 때만 기존 구성을 삭제하고, 먼저 해당 앱에서 연결을 중지하세요. 관리되는 기기의 네트워크 정책은 직접 변경할 수 없을 수 있으므로 기기 관리 요구사항을 따르고 우회하려 하지 마세요.

네트워크 전환, DNS, 로컬 네트워크의 경계

호텔이나 공항 네트워크에서는 먼저 인증 페이지에 로그인해야 할 수 있습니다. 인증 전에 프록시가 자동 연결되면 구독 업데이트나 노드 연결이 실패할 수 있습니다. 온디맨드 연결을 잠시 끄고 네트워크 인증을 마친 다음 수동으로 연결하세요. 인증 페이지의 리디렉션 주소를 구독으로 저장하지 말고 공용 네트워크에서 실패했다는 이유만으로 기존의 정상 설정을 덮어쓰지 마세요.

Wi-Fi와 모바일 네트워크의 경로는 다르므로 전환 후 잠시 재연결되는 현상을 확인하세요. 특정 Wi-Fi에서만 실패하면 네트워크 인증 상태, DNS, 방화벽 제한을 비교하고 모든 네트워크에서 실패하면 노드와 구독을 점검하세요. 테스트 중 요청이 클라이언트 연결 페이지에 나타나는지 기록하면 트래픽 처리 범위 문제와 상위 연결 문제를 구분할 수 있습니다.

로컬 네트워크 권한은 주변 기기를 찾는 일부 앱에 영향을 주지만 올바른 프록시 규칙을 대신하지는 않습니다. 홈 네트워크 저장 장치, 화면 미러링 기기, 라우터 페이지에 접속할 수 없다면 대상이 로컬 주소인지 확인한 뒤 클라이언트의 직접 연결 또는 우회 설정을 살펴보세요. 열리지 않는 도메인을 전부 직접 연결 목록에 추가하지 마세요. 대상에 프록시가 필요한 경우 문제만 규칙 처리 단계에서 직접 연결 단계로 옮겨갈 수 있습니다.

iOS에서 확인할 수 있는 로그와 백그라운드 동작은 시스템 방식의 영향을 받습니다. 앱 전환 화면에서 앱을 닫는 것이 시스템 VPN을 중지한다는 뜻은 아니며, 해당 화면에 앱이 남아 있다고 연결이 정상이라는 뜻도 아닙니다. 시스템 연결 상태, 클라이언트 기록, 실제 접속 결과를 함께 확인하세요. 사용을 중지할 때는 온디맨드 연결을 끄고 VPN을 중지한 다음 네트워크가 의도한 경로로 복구됐는지 확인하세요.

Linux: 데스크톱 클라이언트와 mihomo 백그라운드 서비스

데스크톱 설치는 배포판에 맞는 패키지 형식부터 선택하세요

데스크톱에서는 Linux 다운로드에서 권장 클라이언트인 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 배포판에 맞춰 DEB나 RPM을 고르고 프로세서 아키텍처와 실행 환경 요구사항을 확인하세요. 파일 확장자만 보고 다른 배포판에 설치하거나 의존성 문제를 해결하려고 시스템 핵심 라이브러리를 교체하지 마세요. 그래픽 인터페이스가 실행되지 않으면 터미널에서 실행해 의존성 오류를 확인하세요.

설치 후 구독을 가져오고 설정을 활성화한 뒤 노드를 선택하는 과정은 다른 데스크톱 플랫폼과 비슷합니다. 다만 시스템 프록시 설정이 모든 데스크톱 환경과 앱에 적용되는 것은 아닙니다. 브라우저, 터미널, 패키지 관리자는 서로 다른 프록시 설정을 사용할 수 있습니다. 먼저 코어가 로컬 포트에서 수신 대기 중인지 확인하고 필요한 프로그램에 프록시를 설정하세요. 데스크톱 설정이 성공했다고 모든 프로세스의 트래픽이 처리되는 것은 아닙니다.

데스크톱이 없는 환경에서는 설정과 실행 디렉터리부터 준비하세요

서버나 라우터에서는 mihomo 코어를 직접 실행할 수 있습니다. 시스템 아키텍처에 맞는 바이너리를 선택하고 압축을 풀어 직접 관리하는 실행 파일 디렉터리에 넣으세요. 아래 예제에서는 프로그램을 /usr/local/bin/mihomo에, 설정을 /etc/mihomo/config.yaml에 둡니다. 예제 경로일 뿐이며 다른 소프트웨어가 사용 중인 디렉터리를 덮어쓸 필요는 없습니다.

전용 서비스 계정과 작업 디렉터리를 먼저 만든 다음 기존 설정을 배치하고 설정 파일의 읽기 권한을 제한하세요. 아래 명령은 해당 도구가 제공되는 일반적인 Linux 시스템에서 사용할 수 있습니다. 실행하기 전에 계정이 이미 있는지 확인하세요. 설정에서 참조하는 규칙 모음, 데이터베이스, 상대 경로도 작업 디렉터리를 기준으로 권한을 확인해야 합니다. 주 설정 파일만 읽을 수 있게 하고 의존 파일을 확인하지 않으면 안 됩니다.

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -o mihomo -g mihomo -m 0750 /etc/mihomo
sudo install -o mihomo -g mihomo -m 0640 ./config.yaml /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo

테스트 명령이 성공했다는 것은 설정을 파싱하고 검사할 수 있다는 뜻일 뿐 노드가 사용 가능하다는 보장은 없습니다. 처음 실행할 때 설정이 참조하는 리소스를 가져와야 할 수도 있습니다. 제한된 네트워크나 디렉터리 쓰기 권한이 이 과정에 영향을 줄 수 있습니다. 파싱 성공을 배포 완료로 간주하지 마세요. 이후 프로세스, 수신 포트, 실제 요청을 확인하고 데이터베이스 리소스 오류와 노드 오류를 구분해야 합니다.

systemd로 일반 프록시 서비스를 관리하세요

다음 서비스 유닛은 TUN을 활성화하거나 추가 네트워크 관리 권한을 부여하지 않는 로컬 일반 프록시 수신용입니다. 내용을 /etc/systemd/system/mihomo.service로 저장하고 실행 경로가 실제 위치와 일치하는지 확인하세요. 배포판에서 systemd를 사용하지 않는다면 해당 시스템의 기본 서비스 관리 방식을 이용하세요. 명령을 억지로 그대로 적용하지 마세요.

[Unit]
Description=mihomo local proxy
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
UMask=0077

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
sudo journalctl -u mihomo -b --no-pager -n 80

네트워크가 준비됐다고 외부 구독 주소에 접속할 수 있다는 뜻은 아닙니다. 서비스 시작 시 리소스를 가져오지 못하면 로그를 확인하고 리소스 관리 방식에 따라 처리하세요. 무한 재시작만으로 해결하려 하지 마세요. 설정을 수정하기 전에 정상 작동하던 사본을 보관하고 먼저 테스트한 뒤 재시작하세요. 재시작이 반복되면 서비스를 중지하고 설정을 수정한 다음 다시 시작해 상위 서버에 실패 요청을 계속 보내지 않도록 하세요.

터미널 프록시, 원격 연결, TUN 권한

일회성 터미널 작업에는 현재 셸에 프록시 환경 변수를 설정할 수 있습니다. 다음 예제에서 혼합 포트는 7890이며 이 변수들을 읽는 프로그램에만 적용되고 시스템 라우팅은 자동으로 바뀌지 않습니다. 로컬 서비스를 불필요하게 프록시로 보내지 않도록 예외 목록을 설정하세요. SOCKS와 원격 DNS를 지원하는지는 해당 도구의 문서를 확인하세요.

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
curl -I https://example.com

# 현재 터미널의 임시 설정 해제
unset http_proxy https_proxy no_proxy

SSH로 서버를 관리할 때는 라우팅을 변경하기 전에 두 번째 관리 세션을 유지하세요. TUN을 사용하려면 가상 네트워크 장치에 접근하고 필요한 네트워크 관리 권한을 부여해야 하므로 위의 낮은 권한 서비스 유닛으로는 해당 작업을 수행할 수 없습니다. 시스템과 클라이언트 구현에 맞춰 권한을 별도로 설계하고 모든 서비스를 root로 바꾸지 마세요. 원격 서버에서는 SSH 복귀 경로와 관리 네트워크의 우회 경로도 먼저 계획해야 합니다.

기본적으로 로컬에서만 사용할 경우 수신 주소를 루프백 범위로 유지하고 외부 제어 인터페이스를 열지 마세요. 로컬 네트워크에 프록시를 제공하려면 수신 주소, 인증, 방화벽을 함께 확인해야 합니다. ‘로컬 네트워크 허용’만 켜면 되는 것이 아닙니다. 추가 배포 방법은 Linux 헤드리스 환경 및 systemd 가이드를 참고하세요. 일반 프록시가 안정적으로 작동하는 것을 확인한 뒤 TUN이나 원격 관리 요구사항을 하나씩 추가하세요.

자주 묻는 설정 문제: 구독, 규칙, TUN, DNS

구독 업데이트 실패: 요청 오류와 파싱 오류를 구분하세요

업데이트에 실패하면 먼저 설정 파일을 요청해 가져왔는지 확인하세요. 시간 초과는 현재 네트워크, 접속 경로, 서버 응답 문제일 가능성이 있습니다. 인증 오류가 발생하면 구독 유효 기간과 주소를 확인하세요. 웹페이지가 반환되면 로그인 페이지, 인증 페이지, 오류 안내일 수 있습니다. 주소를 바로 변환 서비스에 보내지 마세요. 변환으로 만료된 서비스를 복구할 수 없으며 비공개 구독이 추가 처리 업체에 노출될 수 있습니다.

다운로드는 성공했지만 파싱에 실패하면 콘텐츠 형식, 들여쓰기, 코어가 지원하는 필드를 확인하세요. 클라이언트가 마지막으로 성공한 설정을 캐시할 수 있으므로 ‘아직 연결 가능하다’고 해서 이번 업데이트가 적용됐다는 뜻은 아닙니다. 오류가 난 줄 주변의 민감 정보를 삭제해 보관하고 클라이언트의 지원 범위와 대조하세요. 프록시를 통해 구독을 업데이트해야 한다면 먼저 기존의 정상 설정으로 연결되는지 확인하세요. 업데이트해야 인터넷에 연결되는 순환 상태를 피할 수 있습니다.

규칙과 덮어쓰기: 순서대로 적용하고 출처별로 관리하세요

규칙은 보통 위에서 아래 순서로 확인하며 먼저 일치한 규칙의 정책이 적용됩니다. 마지막의 MATCH는 나머지 연결을 처리합니다. 아래 예제는 규칙 구조만 보여 주며 설정에 PROXY라는 정책 그룹이 이미 있어야 합니다. 도메인 규칙과 대상 IP 규칙은 조건이 다릅니다. 도메인 연결에 IP 규칙이 적용됐다면 도메인 인식과 주소 해석 과정을 추가로 확인하세요.

mode: rule
mixed-port: 7890
allow-lan: false

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

수동 규칙을 기본 처리 규칙 뒤에 작성하지 마세요. 구독을 새로고침하면 직접 수정한 내용이 덮어써질 수 있습니다. 지속적으로 수정해야 한다면 클라이언트가 지원하는 덮어쓰기, 병합, 규칙 확장 기능을 사용하고 병합된 최종 설정을 확인하세요. 정책 이름은 공백과 대소문자까지 완전히 일치해야 합니다. 다른 사람의 설정에서 그룹명만 복사하고 해당 그룹을 만들지 않는 것은 설정 불러오기 실패의 흔한 원인입니다.

TUN 모드: 권한, 라우팅, 순환 확인

TUN을 켜자마자 실패하면 권한, 서비스, 가상 장치를 확인하세요. 켠 뒤 기기 전체가 인터넷에 연결되지 않으면 기본 경로, DNS, 노드 출구를 살펴보세요. 자동 라우팅에서는 프록시 코어의 출구가 다시 TUN으로 전달되지 않도록 해야 합니다. 그렇지 않으면 순환이 발생할 수 있습니다. 데스크톱 클라이언트가 관련 처리를 하는 경우가 많으므로 기본 설정을 직접 바꾸기 전에 인터페이스가 생성한 라우팅 설정과 충돌하지 않는지 확인하세요.

다음은 mihomo의 TUN 필드 예제이며 모든 클라이언트에 그대로 붙여 넣을 수 있는 것은 아닙니다. 활성화하기 전에 플랫폼 권한을 준비해야 합니다. DNS 가로채기 범위는 시스템, 라우팅, 구현 방식에 따라 달라집니다. 회사 내부망, 다른 VPN, 원격 유지 관리 환경에서는 먼저 제외 경로를 계획하세요. 자동 라우팅이 모든 네트워크에 적합한 기본 설정이라고 생각해서는 안 됩니다.

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

DNS: 주소 해석 경로와 프록시 경로를 따로 확인하세요

DNS는 도메인을 주소로 변환하고 규칙은 연결이 적용받을 정책을 결정합니다. 서로 관련은 있지만 같은 계층은 아닙니다. 도메인 해석에 실패했다면 노드를 바꿔도 해결되지 않을 수 있습니다. 해석은 정상이지만 연결이 실패해도 DNS를 바꿔야 하는 것은 아닙니다. 먼저 로그에서 주소를 가져왔는지 확인하고 연결에 어떤 규칙과 정책이 적용됐는지 살펴보세요. 브라우저에서 암호화 DNS를 사용 중이라면 클라이언트가 사용하도록 설정한 해석 경로를 우회하는지도 확인하세요.

nameserver는 일반적인 상위 DNS 서버를 지정하고 fallback은 필터 조건과 함께 후보 결과의 사용 여부를 결정합니다. fake-ip는 합성 주소를 이용해 도메인 매핑을 유지합니다. IP 주소 형식의 상위 DNS 서버를 사용하면 서버 도메인을 먼저 해석해야 하는 문제를 피할 수 있지만 모든 네트워크에 적합하다는 뜻은 아닙니다. 다음은 구조 예제이며 실제 접속 가능 여부와 개인정보 보호 요구사항은 직접 검토해야 합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - localhost

해석 모드를 바꾸면 시스템과 앱에 이전 캐시가 남을 수 있고 기존 연결이 이전 주소를 계속 사용할 수도 있습니다. 먼저 테스트 대상 앱의 기존 연결을 닫은 뒤 플랫폼에 맞게 캐시를 비우거나 트래픽 처리 연결을 다시 설정하세요. 여러 필드를 연달아 함께 바꾸지 마세요. DNS 가로채기가 모든 암호화 DNS를 차단한다는 뜻은 아닙니다. 전체 필드 관계는 Clash DNS 설정 자세히 알아보기를 참고하세요.

자동 시작 및 복구: 세 가지 상태를 구분하세요

자동 시작에서는 인터페이스 실행, 코어 작동, 프록시 연결 처리를 각각 확인해야 합니다. 백그라운드 서비스만 실행되고 인터페이스는 열리지 않을 수 있으며, 인터페이스가 실행돼도 설정이 활성화되지 않았을 수 있습니다. 재부팅 후 로그 시간, 현재 설정, 수신 포트를 확인하고 시스템 프록시나 VPN 상태도 점검하세요. 시작 시 네트워크 인증이 완료되지 않았거나 사용자 폴더의 잠금이 풀리지 않은 경우, 이전 클라이언트가 포트를 선점한 경우에는 시작할 때만 실패할 수 있습니다.

변경할 때마다 수정한 필드, 변경 전 값, 테스트 네트워크, 결과를 간단히 기록하세요. 연결이 끊기면 새로 추가한 트래픽 처리 방식을 먼저 끄고 이전 설정을 복구한 다음 단계별로 확인하세요. 공개적으로 도움을 요청할 때는 민감 정보를 삭제한 로그와 최소 재현 절차만 제공하세요. 노드 선택이 궁금하다면 노드 지역·프로토콜·속도 테스트 비교 가이드를 참고하세요. 한 번의 테스트 결과만으로 설정 전체를 삭제하지 마세요.