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

준비 사항: 아키텍처, 구독, 트래픽 처리 방식

먼저 클라이언트, 커널, 설정 파일을 구분하세요

클라이언트는 화면, 구독 관리, 시스템 연동과 권한 요청을 담당하고, mihomo 커널은 설정을 해석하고 연결을 만들며 규칙을 적용합니다. 화면이 비슷해도 설정 기능은 다를 수 있습니다. 같은 Clash 설정이라도 특정 커널에서만 지원하는 항목이 포함될 수 있으므로 가져오기 전에 구독 제공자가 안내한 호환 대상을 확인하세요. ClashX는 macOS 생태계의 클라이언트 이름이지 Windows, 모바일, Linux에서 공통으로 사용하는 설치 파일 이름이 아닙니다. 한 플랫폼의 프로그램을 다른 플랫폼에 복사해 실행할 수 없습니다.

일반적인 설정에는 노드 또는 노드 제공자, 정책 그룹, 규칙, DNS 설정이 포함됩니다. 구독 주소는 이 내용을 받아오는 경로일 뿐, 주소의 확장자만으로 형식을 판단할 수는 없습니다. 브라우저에서 링크가 열려도 YAML로 해석할 수 있는 응답이라는 뜻은 아닙니다. 로그인 페이지, 트래픽 만료 안내, 웹 오류 내용이 반환되면 가져오기에 실패할 수 있습니다. 구독 주소에는 접근 정보가 포함될 수 있으므로 비공개 데이터로 취급하고 공개 댓글, 온라인 변환 사이트, 오류 화면에 노출하지 마세요.

시스템 아키텍처와 기존 네트워크 설정 확인

Windows에서는 ‘설정 → 시스템 → 정보’에서 시스템 종류를 확인하고, macOS에서는 ‘이 Mac에 관하여’에서 칩을 확인하세요. Linux에서는 uname -m을 실행하면 됩니다. Apple Silicon과 Intel은 각각 맞는 설치 파일을 선택해야 하며, Linux 패키지 형식은 배포판에 맞아야 합니다. Android 설치 파일도 ARM64, ARM 등 아키텍처가 다르므로 다운로드 페이지의 안내를 따르세요. 파일이 다운로드됐다고 해서 현재 기기에 맞는 것은 아닙니다. 설치 오류가 나면 다시 다운로드하기 전에 아키텍처부터 확인하세요.

시작하기 전에 기존 프록시, VPN, DNS, 네트워크 필터링 프로그램 설정을 기록해 두세요. 회사 기기는 관리 정책에 따라 프록시나 인증서가 강제 지정될 수 있습니다. 권한 문제가 있으면 기기 관리자에게 문의하고 시스템 설정을 반복해서 덮어쓰지 마세요. 처음 문제를 확인할 때는 트래픽을 처리하는 클라이언트를 하나만 실행해 여러 프로그램이 시스템 프록시나 기본 경로를 동시에 바꾸지 않도록 하세요. 업무용 VPN을 계속 사용해야 한다면 함께 사용할 수 있는지 먼저 확인한 뒤 테스트 순서를 정하세요.

반복 가능한 첫 연결 절차 만들기

먼저 클라이언트를 설치하고 정상적으로 한 번 실행한 뒤 구독을 가져오세요. 설정이 선택되어 있고 정책 그룹에 사용할 수 있는 구성원이 있는지 확인한 다음, 규칙 모드에서 노드 하나를 지정하고 마지막으로 시스템 프록시나 모바일 연결을 켭니다. 각 단계를 마칠 때마다 로그와 화면을 확인하고 포트, DNS, 라우팅, 규칙을 한꺼번에 바꾸지 마세요. 첫 테스트에 실패해도 설정은 그대로 두고 구독 가져오기, 커널 시작, 수신 대기, 외부 연결 중 어느 단계에서 문제가 생겼는지 먼저 확인하세요.

테스트 대상은 최소 두 가지로 나누세요. 하나는 직접 연결되어야 하는 사이트, 다른 하나는 프록시를 사용해야 하는 사이트입니다. 브라우저에서 열어 보는 것은 시작점일 뿐이므로 연결 목록에서 실제 적용된 정책도 확인해야 합니다. 캐시된 페이지, 기존 연결 재사용, 브라우저의 보안 DNS 때문에 한 번 접속한 결과가 실제 상태와 다를 수 있습니다. 기본 테스트를 마친 뒤 자동 업데이트, 시작 프로그램 등록, TUN을 켜면 문제가 생겼을 때 되돌릴 기준이 분명해집니다. 기기를 옮길 때는 기존 설정 사본과 사용자 규칙 기록도 함께 보관하세요.

Windows: 설치, 시스템 프록시, TUN

설치 파일을 선택하고 첫 실행하기

Windows에서는 Clash Plus를 우선 추천합니다. 데스크톱 기능을 비교하려면 Clash Verge Rev, FlClash, Clash Nyanpasu를 차례로 확인하세요. Clash for Windows는 개발이 중단된 보관용 클라이언트이므로 새로 설치할 때는 권장하지 않습니다. Windows 설치 파일에서 시스템 종류에 맞는 파일을 선택하세요. 기존 클라이언트를 교체하기 전에 설정을 저장하면 이전 과정에서 구독과 로컬 규칙이 사라지는 일을 막을 수 있습니다.

설치 프로그램을 실행할 때 권한 안내를 확인하고, 설치가 끝나면 먼저 일반 사용자로 시작하세요. 클라이언트 화면이 열려도 포트 충돌, 설정 오류, 보안 정책 때문에 커널이 실행되지 않을 수 있으므로 커널 로그를 확인해야 합니다. 서비스 구성 요소나 가상 네트워크 어댑터가 필요할 때만 클라이언트가 제공하는 설치 절차에 따라 관리자 권한을 요청하세요. 일상적인 작업을 모두 관리자 계정으로 할 필요는 없습니다. 조직에서 관리하는 기기는 네트워크 서비스 설치가 제한될 수 있으며, 이는 구독 내용과 무관합니다.

구독을 가져온 뒤 선택 상태 확인

‘설정’, ‘구독’ 또는 비슷한 메뉴에서 원격 설정을 추가하고 전체 주소를 붙여 넣은 뒤 업데이트하세요. 설정 항목이 나타나면 현재 설정으로 지정하고 정책 그룹에서 사용할 노드를 선택합니다. 구독을 추가하기만 하고 현재 설정으로 바꾸지 않으면 이전 파일이 계속 실행될 수 있습니다. 정책 그룹이 비어 있다면 시스템 프록시를 반복해서 켜고 끄는 대신 구독 응답과 파싱 로그를 먼저 확인하세요.

Clash for Windows에서 옮길 때 구독 주소와 직접 추가한 규칙은 보존할 수 있지만, 새 클라이언트의 전체 앱 데이터 폴더를 그대로 덮어쓰지는 마세요. 이전 버전의 화면 설정, 서비스 경로, 확장 스크립트는 호환되지 않을 수 있습니다. 새 클라이언트에서 원본 구독을 가져와 기본 연결을 확인한 다음 덮어쓰기 설정을 하나씩 복원하세요. 이전 스크립트 문법이나 커널 전용 항목이 포함되어 있다면 새 클라이언트의 설정 검사 결과를 기준으로 판단하세요.

시스템 프록시를 확인한 뒤 앱별 차이 점검

먼저 규칙 모드를 유지한 상태로 클라이언트의 시스템 프록시를 켜세요. Windows의 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 수동 프록시 주소와 포트가 클라이언트의 로컬 수신 주소를 가리키는지 확인합니다. 브라우저에서 연결되는 것을 확인한 뒤 개발 도구나 다른 앱도 테스트하세요. 일부 앱은 자체 프록시 설정을 사용하고, 백그라운드 서비스는 WinHTTP 설정을 읽을 수 있습니다. 데스크톱 시스템 프록시를 켰다고 모든 앱의 경로가 자동으로 바뀌는 것은 아닙니다.

명령줄에서 수신 프록시를 지정해 연결을 확인할 수 있습니다. 아래 명령은 로컬 HTTP 프록시 경로만 테스트하며, 대상 사이트가 노드를 경유하는지는 설정 규칙에 따라 결정됩니다. PowerShell에서 curl.exe를 사용하면 일부 구형 환경에서 같은 이름의 명령 별칭으로 매개변수가 달라지는 일을 피할 수 있습니다. 클라이언트 포트가 7890이 아니라면 명령에 지정한 포트도 함께 변경하세요.

curl.exe -I --proxy http://127.0.0.1:7890 https://example.com

연결이 거부되면 클라이언트 실행 여부, 포트 일치 여부, 수신 대기 성공 여부부터 확인하세요. 로컬 연결은 되지만 원격 응답이 시간 초과되면 정책 그룹, 노드, DNS를 확인합니다. 일부 환경에서는 UWP 앱에 루프백 제한이 있을 수 있으므로 클라이언트가 관련 관리 기능을 제공하는지 확인하세요. 모든 앱을 한꺼번에 허용하는 것은 일반적인 해결 방법이 아닙니다. 꼭 필요한 앱만 별도로 설정하고 나중에 되돌릴 수 있도록 변경 내용을 기록하세요.

TUN, 자동 시작, 종료 후 설정 복구

게임, 자체 네트워크 스택을 사용하는 프로그램, 시스템 프록시를 따르지 않는 앱에는 TUN을 고려할 수 있습니다. 먼저 클라이언트 안내에 따라 서비스를 설치한 다음 강화 모드를 켜고 가상 네트워크 어댑터와 라우팅이 만들어졌는지 확인하세요. TUN으로 대상 앱의 트래픽을 처리할 수 있다면 스위치를 더 켜기 위해 다른 프록시 도구를 겹쳐 쓸 필요는 없습니다. 켠 뒤 로컬 프린터, LAN 서비스, 회사 네트워크에 문제가 생기면 사설 네트워크 대역 제외 규칙과 기존 VPN 경로를 확인하세요.

시작 프로그램 등록과 커널 실행은 별개의 단계입니다. 로그인 후 화면이 나타나도 서비스가 준비된 것은 아니며, 서비스가 준비되어도 구독이 로드되거나 프록시가 다시 켜졌다는 뜻은 아닙니다. 재부팅 후에는 이 순서대로 하나씩 확인하세요. 클라이언트를 종료하기 전에 시스템 프록시를 끄세요. 프로그램이 비정상 종료된 뒤 웹에 연결되지 않으면 시스템 프록시 설정에서 남은 항목을 지우고 직접 연결을 테스트하세요. 시작 문제는 시작 프로그램 관련 질문과 답변을, 클라이언트 비교는 Windows 클라이언트 비교를 확인하세요.

macOS: 칩 아키텍처, 네트워크 권한, 메뉴 막대

칩에 맞는 클라이언트 선택 및 설정 이전

macOS에서는 Clash Plus를 우선 추천하며 Clash Verge Rev나 FlClash도 선택할 수 있습니다. ClashX Meta는 개발이 중단되었습니다. 보관된 설치 파일은 특정 호환성이 필요한 구형 환경에만 적합하며, 새로운 기능 지원의 기준으로 삼을 수 없습니다. ‘이 Mac에 관하여’에서 Apple 칩인지 Intel인지 확인한 뒤 macOS 다운로드에서 해당 아키텍처용 파일을 선택하세요. 출시 연도만으로 판단하지 마세요. 같은 해에 판매된 기기라도 칩이 다를 수 있습니다.

디스크 이미지 파일을 열고 앱을 ‘응용 프로그램’ 폴더로 드래그한 뒤 해당 폴더에서 실행하세요. 이미지 안에 있는 복사본을 계속 실행하는 상황을 피할 수 있습니다. 기존 프로그램을 교체하기 전에 클라이언트를 정상 종료하세요. 파일이 사용 중이라는 안내가 나오면 메뉴 막대 프로세스가 종료되었는지도 확인합니다. 처음 실행할 때 보안 경고가 표시되면 파일 출처부터 확인한 뒤 시스템에서 안내하는 검토 절차를 따르세요. 앱 하나를 실행하기 위해 기기의 보안 기능 전체를 끄지 마세요.

구독 가져오기와 메뉴 막대 상태 확인

클라이언트의 설정 메뉴에서 구독을 추가하거나 로컬 YAML 파일을 가져오세요. 저장 후 해당 설정을 선택하고 정책 그룹에서 현재 사용하는 구성원을 확인합니다. 메뉴 막대의 규칙, 전역, 직접 연결은 보통 라우팅 모드를 뜻하며, 노드 이름은 정책 그룹에서 선택하는 항목입니다. 두 가지는 서로 대체할 수 없습니다. 규칙 모드를 선택해도 규칙에서 참조하는 정책 그룹에 올바른 구성원이 있는지 확인해야 합니다. 그렇지 않으면 화면은 정상처럼 보여도 트래픽이 준비되지 않은 외부 연결 경로로 갈 수 있습니다.

ClashX 또는 ClashX Meta에서 다른 클라이언트로 옮길 때는 먼저 구독을 가져온 다음 직접 관리하는 규칙 조각을 이전하세요. 메뉴 막대 설정, 단축키, 보조 서비스, 로컬 스크립트는 앱에 종속되므로 폴더 전체를 덮어쓰지 않는 편이 좋습니다. 원격 설정을 업데이트하면 직접 수정한 내용이 덮어써질 수도 있습니다. 계속 사용할 사용자 규칙은 클라이언트가 지원하는 덮어쓰기 또는 병합 메뉴에 넣고, 편집 화면만 보지 말고 최종 적용된 설정을 확인하세요.

시스템 프록시, 보조 서비스, 네트워크 위치

시스템 프록시를 켠 뒤 ‘시스템 설정 → 네트워크 → 현재 네트워크 서비스 → 세부사항 → 프록시’에서 HTTP와 HTTPS 프록시를 확인하세요. macOS 버전에 따라 메뉴 이름은 조금씩 다를 수 있습니다. 목록에 남아 있는 미사용 네트워크가 아니라 현재 연결된 Wi-Fi 또는 이더넷 서비스를 확인해야 합니다. 네트워크 어댑터를 바꾸거나 도킹 스테이션을 연결하거나 네트워크 위치를 전환한 뒤에는 프록시가 현재 서비스에 계속 적용되는지 다시 확인하세요.

터미널에서 시스템 프록시 상태를 확인할 수 있습니다. 출력된 활성화 상태, 서버, 포트가 클라이언트와 일치해야 합니다. 이 명령은 상태만 조회하며 시스템 설정을 변경하지 않습니다. 프록시가 켜져 있는데도 브라우저 연결 기록이 없다면 브라우저가 자체 프록시 확장 프로그램을 사용하는지, 로컬 주소나 특정 도메인을 우회하는 예외 목록이 있는지 확인하세요.

scutil --proxy
curl -I --proxy http://127.0.0.1:7890 https://example.com

TUN이나 네트워크 보조 서비스를 처음 켤 때 시스템에서 권한을 요청하고 기기의 관리자 암호를 요구할 수 있습니다. 클라이언트에서 작업을 시작한 다음 시스템 안내가 현재 앱의 요청인지 확인하세요. 서비스 설치에 실패하면 앱 경로, 시스템 권한, 로그부터 확인하고 같은 서비스를 여러 앱 복사본에 반복 설치하지 마세요. 메뉴 막대 아이콘이 보인다고 보조 서비스가 실행 중인 것은 아닙니다. 연결 화면과 시작 로그를 확인해야 합니다.

절전 모드 해제, 터미널 도구, 로컬 개발

Mac이 절전 모드에서 깨어나거나 Wi-Fi에서 핫스팟으로 전환되면 기존 연결이 끊길 수 있습니다. 먼저 설정을 다시 불러오거나 연결을 재설정한 뒤 노드를 바꿔야 하는지 판단하세요. TUN을 켰을 때만 문제가 생긴다면 시스템 프록시로 잠시 되돌려 구독 문제와 가상 네트워크 어댑터·라우팅 문제를 구분할 수 있습니다. 클라이언트를 종료해도 직접 연결되지 않으면 현재 네트워크 서비스에 수동 프록시가 남아 있는지, 다른 VPN이 연결된 상태인지 확인하세요.

터미널 도구는 그래픽 인터페이스의 시스템 프록시 설정을 완전히 이어받지 않는 경우가 많습니다. 필요하면 현재 터미널에서 환경 변수를 설정해 임시로 테스트한 뒤 shell 설정 파일에 저장할지 결정하세요. NO_PROXY에 로컬 개발 주소를 넣으면 로컬 서비스가 프록시로 우회되지 않습니다. 의미를 모르는 넓은 범위의 도메인을 우회 목록에 추가하지 마세요. Git, 패키지 관리자, 컨테이너에도 별도 설정이 있을 수 있으므로 시스템 스위치를 계속 바꾸기보다 각각 확인하는 편이 효과적입니다.

Android: 설치 권한, VPN 인터페이스, 백그라운드 실행

아키텍처 선택과 앱 데이터 보존

Android에서는 Clash Plus를 우선 추천하며 Clash Meta for Android, FlClash, Surfboard도 선택할 수 있습니다. 클라이언트마다 구독 형식, 규칙 문법, 확장 항목 지원이 다릅니다. 특히 mihomo 전용 복잡한 설정이 모든 클라이언트에서 통한다고 가정하지 마세요. Android 설치 파일 안내에서 아키텍처와 설정 호환성을 확인한 뒤 다운로드하세요.

로컬 설치 파일을 설치할 때 시스템에서 브라우저나 파일 관리 앱에 알 수 없는 앱 설치 권한을 요청할 수 있습니다. 실제로 사용하는 출처에만 임시로 권한을 허용하세요. 설치 파일을 해석하지 못하면 다운로드가 완료되었는지, 아키텍처가 맞는지, 시스템 요구 사항을 충족하는지 먼저 확인합니다. 업데이트 중 서명이 다르다는 안내가 나오더라도 바로 삭제하지 마세요. 기존 앱의 출처를 확인하고 내보낼 수 있는 설정과 로컬 규칙을 먼저 저장한 뒤 이전 여부를 결정하세요. 앱을 삭제하면 앱 데이터도 함께 사라지는 경우가 많습니다.

구독 가져오기와 첫 VPN 권한 승인

구독 주소를 설정 메뉴에 붙여 넣고 다운로드가 끝나면 해당 설정을 선택하세요. 일부 클라이언트는 구독을 먼저 추가한 뒤 별도로 업데이트해야 합니다. 제목이 표시되는 것만으로 노드를 가져온 것은 아닙니다. 가져오기에 실패하면 현재 네트워크에서 구독 서버에 접속할 수 있는지 확인하세요. 구독 주소에 프록시가 필요하다면 신뢰할 수 있는 다른 네트워크나 구독 제공자가 안내한 가져오기 방법을 사용하세요. 비공개 링크를 공개 변환 서비스에 보내지 마세요.

정책 그룹과 노드를 선택한 뒤 연결을 시작하면 Android에 VPN 권한 안내가 표시됩니다. 방금 설치한 클라이언트에서 요청한 것이 맞는지 확인하고 허용한 다음, 시스템 VPN 표시와 클라이언트 연결 상태를 확인하세요. 이 인터페이스는 트래픽을 로컬 클라이언트로 전달하는 데 사용되며 모든 트래픽이 원격 노드를 거친다는 뜻은 아닙니다. 규칙에 따라 일부 연결은 직접 연결될 수 있습니다. 시작에 실패하면 권한을 거부했는지 먼저 확인하고 다른 VPN, 네트워크 필터, 방화벽 앱이 인터페이스를 점유하는지도 살펴보세요.

앱별 라우팅과 시스템 네트워크 설정

일부 앱만 처리하려면 클라이언트의 앱별 트래픽 설정을 사용하고 현재 모드가 ‘선택한 앱만’인지 ‘선택한 앱 제외’인지 먼저 확인하세요. 두 모드는 의미가 반대라 같은 목록을 사용해도 결과가 완전히 달라집니다. 변경 후 VPN 연결을 다시 만들어야 할 수 있으며 기존 연결은 즉시 경로가 바뀌지 않을 수도 있습니다. 테스트할 때는 대상 앱을 완전히 종료한 뒤 다시 열고 연결 기록에서 트래픽이 클라이언트에 전달되었는지 확인하세요.

Android의 비공개 DNS, 브라우저 보안 DNS, 클라이언트 DNS가 동시에 작동할 수 있습니다. 도메인 조회에 문제가 생기면 기존 설정을 기록한 뒤 하나씩 바꿔 테스트하고 여러 계층을 한꺼번에 수정하지 마세요. IP 주소로는 연결되지만 도메인으로 접속할 수 없다면 DNS 경로를 중점적으로 확인하세요. 모든 요청이 시간 초과된다면 노드와 라우팅도 점검해야 합니다. 웹페이지가 열리지 않는다는 이유만으로 DNS 문제라고 단정할 수 없습니다. 회사 업무 프로필의 앱은 별도의 정책을 적용받을 수도 있습니다.

화면 잠금 후 연결 끊김, 네트워크 전환, 배터리 설정

앱을 사용할 때는 정상인데 화면을 잠근 뒤 연결이 끊긴다면 배터리 최적화, 백그라운드 활동, 자동 시작 권한부터 확인하세요. 제조사마다 배터리, 앱 관리, 보안 센터 등 메뉴 위치가 다르므로 관련 기능을 찾아보면 됩니다. 먼저 클라이언트에 필요한 백그라운드 실행만 허용하고 화면을 잠근 상태에서 테스트하세요. 모든 앱의 절전 제한을 해제할 필요는 없습니다. 일부 시스템에서 상시 알림은 포그라운드 서비스 상태를 알리는 역할을 합니다. 알림을 숨긴 뒤 연결이 불안정해지면 기본 설정으로 되돌려 비교하세요.

Wi-Fi에서 모바일 데이터로 전환하면 기존 연결을 다시 만들어야 할 수 있습니다. 클라이언트에 연결됨으로 표시되는지만 보지 말고 새 요청이 실제로 연결되는지 확인하세요. 먼저 연결을 중지했다가 다시 시작한 뒤 같은 대상을 테스트하면 됩니다. 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS, IPv6, 접속 제한을 중점적으로 살펴보세요. 노드 목록의 단일 테스트 결과를 모든 앱이 사용할 수 있다는 보장으로 보아서는 안 됩니다.

일반적으로 한 대의 휴대전화에서 여러 일반 VPN 앱이 같은 사용자 네트워크를 동시에 처리할 수는 없습니다. 광고 차단, 방화벽, 회사 VPN과 충돌하면 스위치를 빠르게 번갈아 누르기보다 용도에 맞는 처리 앱을 선택하세요. TV가 휴대전화나 컴퓨터의 프록시를 사용하게 하려면 핫스팟 격리, 수신 주소, 방화벽도 확인해야 합니다. 휴대전화에서 VPN을 켰다고 핫스팟에 연결된 기기의 트래픽까지 자동으로 프록시 처리되는 것은 아닙니다. LAN 공유 방법은 혼합 포트 및 LAN 연결 안내에서 확인하세요.

iOS: Clash Plus, 설정 가져오기, 네트워크 확장

앱 스토어에서 설치하고 설정 출처 확인

iPhone과 iPad에서는 Clash Plus를 우선 추천합니다. App Store의 Clash Plus 페이지에서 설치할 수 있으며 제품 정보는 공식 사이트 clashplus.io에서 확인할 수 있습니다. 이 사이트의 iOS 다운로드 안내에도 같은 링크가 정리되어 있습니다. 설치 후 클라이언트를 열고 시스템 권한 안내를 읽은 다음 구독을 가져오세요. 구독 서비스의 웹 양식에 Apple 계정 정보나 기기 암호를 입력하지 마세요.

iOS 클라이언트는 데스크톱 클라이언트와 화면 구성, 네트워크 확장 기능, 설정 호환 범위가 다를 수 있습니다. 데스크톱에서 사용하던 구독이 있다면 제공자가 현재 클라이언트를 지원하는지 먼저 확인하세요. 특히 스크립트, 외부 리소스, 커널 전용 항목을 살펴보세요. 설정 이름이 같아도 해석 방식까지 완전히 같은 것은 아닙니다. 서비스에서 여러 구독 형식을 제공한다면 알 수 없는 변환 링크를 하나씩 시도하기보다 현재 클라이언트에 맞는 형식을 선택하세요.

설정 가져오기, 정책 선택, 연결 권한 승인

클라이언트의 설정 또는 구독 메뉴에서 주소를 추가하고 업데이트한 뒤 해당 설정을 선택하세요. 정책 그룹에서 구성원을 확인하고 먼저 노드 하나를 직접 선택해 기본 연결을 테스트합니다. 연결이 확인된 뒤 자동 선택 같은 정책을 사용하세요. 자동 정책은 테스트 주소와 간격, 후보 구성원에 따라 결과가 달라집니다. 한 번의 테스트는 해당 테스트 대상의 응답만 보여 줄 뿐 동영상, 업무 시스템, 다른 서비스에서도 같은 수준으로 사용할 수 있다는 뜻은 아닙니다.

처음 연결을 시작하면 iOS에서 VPN 구성을 추가할지 묻습니다. 시스템 안내에 따라 기기 인증을 완료하세요. 권한을 허용한 뒤에는 클라이언트로 돌아가 연결이 실제로 시작되었는지 확인해야 합니다. 이 VPN 구성은 로컬 네트워크 확장 기능을 위한 것이며 구독 계정이나 노드 정보를 대신하지 않습니다. 시스템에서 VPN 구성을 실수로 삭제했다면 보통 클라이언트에서 권한 요청을 다시 시작하면 됩니다. 구독을 다시 구매하거나 전체 네트워크 설정을 초기화할 필요는 없습니다.

테스트할 때는 먼저 Safari에서 직접 연결되어야 하는 사이트를 연 다음 프록시가 필요한 사이트를 여세요. 이후 클라이언트의 연결 목록이나 로그에서 규칙이 예상대로 적용되었는지 확인합니다. 브라우저에 이미 열린 페이지는 캐시된 내용일 수 있고, 앱은 기존 연결을 재사용할 수도 있습니다. 정책을 바꾼 뒤에는 새 요청을 보내세요. 시스템 상태 막대의 표시만으로 현재 연결이 선택한 노드를 거치는지 판단할 수 없습니다.

시스템 제한과 연결 충돌 이해하기

iOS 연결은 대개 네트워크 확장으로 처리하므로 데스크톱처럼 ‘시스템 프록시와 TUN’을 모두 켜는 절차를 그대로 따를 필요는 없습니다. 클라이언트마다 용어가 다를 수 있으니 현재 화면의 설명을 기준으로 하세요. Wi-Fi에 HTTP 프록시를 직접 입력하는 것은 별도의 경로로, 해당 설정을 사용하는 트래픽에만 적용되며 모바일 데이터 연결을 대신할 수도 없습니다. 기본 테스트에서는 네트워크 확장과 수동 Wi-Fi 프록시를 겹치지 말고 한 가지 트래픽 처리 경로만 사용하세요.

기기에 다른 VPN, 콘텐츠 필터, 조직 관리 설정이 있으면 연결이 다른 설정으로 대체되거나 차단될 수 있고 네트워크가 바뀐 뒤 다른 설정이 다시 적용될 수도 있습니다. 시스템 ‘설정’에서 VPN을 검색해 현재 연결된 앱을 확인하세요. 조직에서 관리하는 기기라면 관리자에게 먼저 문의하고 업무용 설정을 직접 삭제하지 마세요. 시스템의 전용 프록시 기능, 브라우저 개인정보 보호 기능, 앱 내 네트워크 설정도 접속 경로를 바꿀 수 있으므로 문제를 확인할 때 각각의 상태를 기록하세요.

네트워크 전환, 업데이트, 배터리 소모 확인

집 Wi-Fi에서 셀룰러 네트워크로 전환한 뒤에는 먼저 새 요청이 성공하는지 확인하고 필요할 때 연결을 다시 만드세요. 호텔이나 공용 Wi-Fi에서만 실패한다면 네트워크 로그인 인증을 먼저 완료해야 할 수 있습니다. 이때 클라이언트를 잠시 끄고 네트워크 접속 인증을 마친 다음 다시 연결해 테스트하세요. 공용 네트워크 인증 페이지가 열리지 않으면 구독 노드를 계속 바꾸기보다 시스템 네트워크 설정에 수동 프록시가 남아 있는지 확인하세요.

구독은 안정적인 네트워크에서 업데이트하고 완료 후 현재 정책 그룹이 유효한 구성원을 참조하는지 확인하세요. 노드가 삭제되거나 이름이 바뀌면 직접 선택했던 구성원이 더는 유효하지 않을 수 있으므로 다시 선택해야 합니다. 업데이트에 실패했다고 사용 중인 이전 설정을 바로 삭제할 필요는 없습니다. 현재 연결은 유지하면서 응답 형식과 서비스 상태를 확인하세요. 자세한 절차는 구독 업데이트 실패 항목별 확인을 참고하세요. 링크 유효성과 YAML 확인 방법은 모바일에도 적용됩니다.

VPN 표시가 계속 나온다는 이유만으로 배터리 소모를 판단할 수는 없습니다. 비슷한 사용 환경에서 시스템 배터리 기록을 비교하고 연결 실패가 잦은지, 테스트 간격이 지나치게 짧은지, 로그가 반복해서 쌓이는지 확인하세요. 먼저 클라이언트의 기본 테스트 주기로 되돌리고 필요하지 않은 상세 로그를 끈 다음 상태를 살펴보세요. LAN 기기 검색에 문제가 있으면 로컬 네트워크 분기와 앱 권한도 확인해야 합니다. 프린터 하나에 연결하려고 모든 트래픽을 장시간 전역 프록시로 바꾸지 마세요.

Linux: 데스크톱 클라이언트와 systemd 실행

데스크톱 설치 전 패키지 형식과 아키텍처 확인

Linux 데스크톱에서는 Clash Verge Rev를 권장하며 FlClash도 선택할 수 있습니다. Linux 다운로드에서 배포판에 맞는 패키지를 선택하세요. Debian·Ubuntu 계열은 보통 DEB를, RPM 기반 배포판은 해당 형식을 사용합니다. 먼저 uname -m을 실행해 아키텍처를 확인한 뒤 다운로드 페이지에서 실제 제공하는 파일을 살펴보세요. 패키지 형식과 프로세서 아키텍처를 혼동하지 말고, 데스크톱용으로 맞지 않는 패키지를 서버에 강제로 설치하지 마세요.

의존성 관리와 나중에 제거하기 쉽도록 배포판의 패키지 관리자를 우선 사용하세요. 실행 후 구독을 가져오고 현재 설정과 정책 그룹을 선택한 다음 시스템 프록시를 켭니다. GNOME, KDE, 터미널 앱은 프록시를 사용하는 방식이 다릅니다. 데스크톱 브라우저가 연결된다고 명령줄도 설정된 것은 아닙니다. TUN이 필요하면 클라이언트 안내에 따라 서비스와 권한을 설정하고 그래픽 환경 전체를 root로 장시간 실행하지 마세요. 그래픽 구성 요소가 없는 서버에서는 커널을 직접 실행하세요.

헤드리스 실행 전 설정을 직접 검증

서버나 라우터에서는 커널 다운로드에서 아키텍처에 맞는 mihomo를 선택할 수 있습니다. 압축을 풀고 실제 실행 파일을 /usr/local/bin/mihomo에 설치한 뒤 별도의 설정 디렉터리를 준비하세요. 아래 절차는 실행 파일이 해당 경로에 설치되었다고 가정합니다. 압축 파일 자체를 실행 경로로 복사하지 마세요. 설정에서 상대 경로를 사용하는 규칙 세트나 노드 제공자를 지정했다면 해당 리소스가 올바른 작업 디렉터리에 있는지도 확인해야 합니다.

기존의 완전한 설정을 /etc/mihomo/config.yaml에 저장하고 읽기 권한을 제한한 뒤 설정을 테스트하세요. 테스트를 통과하면 한 번은 포그라운드로 실행해 수신 대기, DNS, 외부 연결 로그를 확인합니다. 기본값으로 로컬 인터페이스만 수신하도록 두고 정상 작동을 확인한 뒤 다른 기기에서 접근하도록 설정하세요. 커널만 실행한다고 터미널, 브라우저, 시스템 서비스에 프록시가 자동 설정되지는 않습니다. 서버에서 ‘프로세스는 정상인데 요청은 계속 직접 연결되는’ 흔한 이유입니다.

sudo install -d -m 700 /etc/mihomo
sudo chmod 600 /etc/mihomo/config.yaml
sudo /usr/local/bin/mihomo -t -d /etc/mihomo
sudo /usr/local/bin/mihomo -d /etc/mihomo

별도 사용자 계정으로 systemd에 등록

포그라운드 테스트가 끝나면 프로세스를 먼저 중지한 뒤 서비스를 설정하세요. 같은 포트를 두 인스턴스가 점유하는 일을 방지할 수 있습니다. 아래 예시는 systemd와 해당 사용자 관리 명령을 지원하는 배포판용이며, 로컬 프록시 서비스만 설정하고 TUN은 포함하지 않습니다. 전용 사용자를 만들고 디렉터리 소유권을 해당 사용자에게 지정하세요. 설정 디렉터리에 쓰기 권한이 필요하더라도 서비스 사용자에게만 부여해야 합니다. 다른 배포판에서는 이에 해당하는 시스템 계정 생성 방법을 사용하세요.

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo chown -R mihomo:mihomo /etc/mihomo

다음 내용을 /etc/systemd/system/mihomo.service에 저장하세요. 서비스는 고정된 설정 디렉터리를 사용하고 프로세스가 실패하면 다시 시작하며 네트워크 대상이 준비될 때까지 기다립니다. 네트워크가 준비되어도 구독 서버에 반드시 연결된다는 뜻은 아니므로 원격 리소스는 별도로 확인해야 합니다. 예시에서는 네트워크 관리 권한을 부여하지 않았습니다. 설정에서 TUN을 사용한다면 먼저 끄거나 배포 환경에 맞게 최소 권한으로 별도 구성하세요.

[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
UMask=0077
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

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

수신 상태, 환경 변수, 접근 범위 확인

ss -lntp로 7890 포트가 수신 중인지 확인한 다음 프록시를 명시해 요청을 테스트하세요. 서비스가 시작 직후 종료되면 먼저 설정을 테스트하고 로그에서 경로 권한과 포트 오류를 확인합니다. 서비스 사용자가 설정을 읽지 못하더라도 모든 사용자에게 읽기 권한을 열어 해결하지 마세요. 소유권과 디렉터리 권한을 바로잡으세요. 설정을 변경한 뒤 먼저 테스트하고 sudo systemctl restart mihomo를 실행하면 문법 오류로 기존 서비스가 중단되는 일을 막을 수 있습니다.

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

환경 변수는 현재 셸과 하위 프로세스에만 적용되며 이미 실행 중인 systemd 서비스로 자동 전달되지 않습니다. 컨테이너에서 127.0.0.1은 컨테이너 자체를 가리키므로 호스트 주소로 사용할 수 없습니다. 컨테이너 간 또는 LAN 접근이 필요하다면 수신 인터페이스, 허용 네트워크 대역, 방화벽 규칙을 명확하게 지정하세요. 외부 제어 인터페이스를 인터넷에 직접 공개하지 마세요. 원격 관리는 보호된 관리 경로를 사용하세요. 전체 배포 방법은 Linux 데스크톱 및 헤드리스 실행 안내를 확인하세요.

자주 묻는 설정 문제: 포트, 규칙, DNS, 복구

혼합 포트와 LAN 수신 설정

mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. 7890은 자주 쓰이는 기본값일 뿐 반드시 고정해야 하는 값은 아닙니다. 포트를 바꾸면 시스템 프록시, 터미널 환경 변수, 앱 내부 설정, LAN 기기에도 같은 포트를 적용해야 합니다. 아래 내용은 기존 설정에 추가하는 기본 매개변수 예시로, 노드와 정책 그룹은 포함하지 않으며 완전한 구독을 대신할 수 없습니다. 클라이언트에서 설정 덮어쓰기를 사용한다면 해당 메뉴에서 수정하고 최종 적용된 값을 확인하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

이 기기에서만 사용할 때는 LAN 연결을 끈 상태로 유지하세요. 휴대전화나 TV와 공유해야 할 때만 LAN 접근을 켜고 수신 주소, 방화벽, 기기 간 격리 설정을 확인합니다. 다른 기기에는 컴퓨터의 LAN 주소를 입력해야 하며 127.0.0.1을 입력하면 안 됩니다. 신뢰할 수 있는 네트워크 대역만 허용해 외부 네트워크에서 프록시에 접근하지 못하게 하세요. allow-lan과 제어 패널 인터페이스는 별도 설정입니다. 프록시 포트를 공개한다고 제어 인터페이스까지 열어야 하는 것은 아닙니다.

규칙 순서, 덮어쓰기, 정책 참조

규칙은 보통 위에서 아래 순서로 검사되며 처음 일치한 규칙이 연결 경로를 결정합니다. 특정 도메인 규칙은 기본 규칙보다 앞에 두고 MATCH는 일반적으로 마지막에 배치합니다. 아래 예시는 완전한 설정에 Proxy라는 정책 그룹이 이미 있다고 가정합니다. 대소문자와 이름이 정확히 일치해야 합니다. 규칙을 추가한 뒤 설정을 다시 불러오고 새 연결의 적용 기록을 확인하세요. 기존 연결에는 이전 정책이 계속 적용될 수 있습니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,adservice,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

구독을 업데이트한 뒤 규칙이 사라진다면 원격 설정 파일을 직접 편집했을 가능성이 큽니다. 클라이언트가 지원하는 덮어쓰기 또는 병합 기능을 사용하고 규칙이 삽입되는 위치도 확인하세요. YAML 들여쓰기에는 공백을 사용하고 탭은 넣지 마세요. 콜론 등 특수 문자가 포함된 문자열은 올바르게 따옴표로 감싸야 합니다. 오류가 표시된 줄이 실제 원인인 것은 아닙니다. 바로 앞 줄에서 목록 기호나 들여쓰기 단계가 빠져도 파싱 오류가 발생할 수 있습니다. 규칙 문법과 정책 참조가 모두 정상인지 확인한 뒤 네트워크 문제를 점검하세요.

DNS 오류와 인증서 오류 구분

DNS는 도메인을 어떤 주소로 변환할지 결정하고, 라우팅 규칙은 연결을 어떤 경로로 내보낼지 결정합니다. 서로 영향을 주지만 같은 기능은 아닙니다. 일부 도메인에서 문제가 생기면 로그에서 DNS 조회 실패, 규칙 적용, 연결 생성 과정을 함께 확인하세요. fake-ip 모드는 트래픽 식별에 합성 주소를 사용하므로 조회 결과가 공용 DNS와 다르다는 이유만으로 오류라고 볼 수는 없습니다. DNS 모드를 바꾼 뒤에는 시스템이나 앱에 캐시가 남을 수 있으니 연결을 새로 만든 다음 다시 테스트하세요.

HTTPS 인증서 경고가 뜨면 시스템 시간, 대상 도메인, 인증서 발급자, 네트워크 차단 설정부터 확인하세요. ‘인증서 오류 무시’를 복구 방법으로 사용하지 마세요. 특정 노드에서만 문제가 생기면 해당 노드 사용을 중지하고 신뢰할 수 있는 경로로 테스트하세요. 직접 연결에서도 경고가 뜬다면 기기와 현재 네트워크를 확인해야 합니다. 자세한 분기별 대응은 HTTPS 인증서 오류 해결을 참고하세요. 기기의 포트를 계속 바꾸며 인증서 문제를 숨기지 마세요.

로그 수집과 설정 되돌리기 순서

문제를 확인할 때 운영체제, 클라이언트 이름, 현재 모드, 트래픽 처리 방식, 오류 발생 시각을 기록하고 해당 시간대의 로그를 보관하세요. 로그에는 도메인, 구독 주소, 계정 정보가 포함될 수 있으므로 공유 전에 민감한 내용을 삭제해야 합니다. 먼저 문제를 한 번 재현한 뒤 변수를 하나씩 바꾸세요. TUN을 잠시 끄고 시스템 프록시만 유지해 테스트하면 라우팅 문제와 노드 연결 문제를 구분할 수 있습니다. 프록시를 명시한 요청으로 로컬 수신 경로도 확인할 수 있습니다.

직접 연결로 되돌릴 때는 먼저 시스템 프록시와 TUN을 끄고 클라이언트를 정상 종료한 다음 시스템에 프록시, VPN, 수동 DNS가 남아 있는지 확인하세요. 처음부터 모든 네트워크 설정을 초기화하면 문제 단서와 업무용 네트워크 설정을 잃을 수 있습니다. 더 궁금한 점은 구독 관련 질문과 답변을 확인하세요. 연결을 처음부터 다시 설정하려면 빠른 시작 가이드의 순서대로 진행하면 됩니다.