Clash Linux 배포 두 가지 방법: 데스크톱 클라이언트 설치와 mihomo 명령줄 실행

Linux 배포를 왜 두 가지 경로로 나눠서 봐야 할까

Windows와 macOS의 Clash 클라이언트는 기본적으로 "설치 파일 다운로드 → 더블클릭 설치 → 그래픽 화면에서 설정"이라는 고정된 흐름을 따르며, 차이는 주로 시스템 권한 팝업 정도에서 나타납니다. Linux는 다릅니다. 생태계 자체가 나뉘어 있기 때문입니다. 데스크톱 배포판(Ubuntu, Debian, Fedora 데스크톱 버전 등)은 윈도우 시스템과 시스템 트레이가 있어 그래픽 클라이언트를 실행할 수 있지만, 클라우드 서버·NAS·라우터·Docker 컨테이너처럼 그래픽 환경이 없는 곳은 디스플레이 서버 자체가 존재하지 않아 GTK나 Webview에 의존하는 클라이언트는 아예 실행되지 않습니다.

이 차이가 두 배포 경로가 완전히 다른 사용 시나리오를 겨냥하게 만듭니다. 그래픽 클라이언트인 Clash Verge Rev는 노드를 자주 전환하고 트래픽을 확인하고 규칙을 조정해야 하는 일상 업무·개발 디버깅용 데스크톱 시나리오를 위한 것으로, 직관적인 조작을 지향합니다. 반면 systemd와 결합한 mihomo 코어는 장시간 상시 구동되는 서버 시나리오를 위한 것으로, 부팅 시 자동 시작, 충돌 시 자동 재시작, 무인 운영을 목표로 하며 그래픽 상호작용이 필요하지도, 적합하지도 않습니다. 어떤 경로를 택할지 정하기 전에 먼저 자신의 시스템에 그래픽 환경이 있는지 확인하는 것이 첫 단계입니다.

경로 1: deb 패키지로 Clash Verge Rev 설치 (데스크톱 환경)

Clash Verge Rev는 현재 Linux 데스크톱에서 유지보수가 활발하고 완성도가 높은 그래픽 클라이언트 선택지로, Tauri 프레임워크 기반으로 만들어져 초기 Electron 방식보다 리소스 사용량이 적습니다. Ubuntu / Debian 계열 배포판을 예로 들면, 공식에서 배포하는 .deb 설치 패키지를 사용하는 것이 권장되며 절차는 다음과 같습니다.

1단계: 시스템 의존성 확인

Tauri 앱은 화면 렌더링을 위해 시스템의 WebKitGTK 구성 요소에 의존합니다. 대부분의 데스크톱 배포판에는 기본적으로 설치되어 있지만, 경량 설치나 최소화 이미지에는 빠져 있을 수 있습니다. 설치 전에 수동으로 보완해 두는 것을 권장합니다.

sudo apt update
sudo apt install -y libwebkit2gtk-4.1-0 libgtk-3-0 libayatana-appindicator3-1

2단계: deb 패키지 설치

해당 아키텍처(amd64 또는 arm64)의 설치 패키지를 내려받은 뒤, dpkg -i가 아니라 apt install로 설치하세요. 전자는 의존성을 자동으로 처리해 주지만, 후자는 실패했을 때 수동으로 의존성을 채워야 합니다.

cd ~/Downloads
sudo apt install ./clash-verge-rev_amd64.deb

설치가 완료되면 애플리케이션 메뉴에서 Clash Verge Rev 아이콘을 찾을 수 있습니다. 처음 실행 시 네트워크 설정 쓰기 권한을 요청하는 안내가 나오면 그대로 승인하면 됩니다.

3단계: 구독 가져오기 및 프록시 검증

실행 후 클라이언트의 구독 관리 화면에 구독 링크를 붙여넣어 불러온 다음, 프록시 화면으로 이동해 노드를 선택합니다. 시스템 프록시나 TUN 모드를 켠 뒤 아래 명령으로 트래픽이 실제로 프록시 출구를 통해 나가는지 확인할 수 있습니다.

curl -s https://ipapi.co/json/

반환 결과의 위치 정보 필드가 노드가 위치한 지역으로 바뀌었다면 프록시 연결이 정상 작동한다는 뜻입니다. 만약 명령줄 도구가 프록시를 거치지 않는다면(명령줄 프록시와 브라우저 프록시는 서로 다른 시스템 설정 항목을 사용합니다), http_proxy와 https_proxy 환경 변수를 추가로 설정하거나, 클라이언트에서 TUN 모드를 켜서 전체 네트워크 계층 트래픽을 한 번에 처리하도록 하면 도구마다 따로 설정할 필요가 없습니다.

데스크톱 경로에서 자주 발생하는 의존성 문제

경로 2: mihomo 코어 + systemd 상시 실행 (GUI 없는 환경)

서버, NAS, 컨테이너 등 그래픽 환경이 없는 곳에는 그래픽 클라이언트를 설치할 수 없습니다. 이런 경우 보통 mihomo(Clash Meta 프로젝트를 이어받은 코어 구현체) 바이너리를 직접 실행하고, systemd로 생명 주기를 관리해 부팅 시 자동 시작과 비정상 종료 후 자동 재시작을 구현합니다.

1단계: 코어 바이너리 내려받아 배치

시스템 아키텍처에 맞는 mihomo 바이너리를 내려받아 압축을 풀고, 시스템 실행 경로에 옮긴 뒤 실행 권한을 부여합니다.

tar -zxvf mihomo-linux-amd64.tar.gz
sudo mv mihomo /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo

2단계: 설정 디렉터리와 설정 파일 준비

설정 파일은 /etc/mihomo/ 아래에 모아 두는 것을 권장합니다. systemd 서비스가 경로를 일관되게 읽을 수 있고, 이후 여러 설정을 관리할 때도 편리합니다.

sudo mkdir -p /etc/mihomo
sudo cp config.yaml /etc/mihomo/config.yaml

설정 파일에서 mixed-port(혼합 프록시 포트)와 external-controller(외부 제어 API 주소) 두 필드가 GUI 없는 환경에서의 사용 방식에 맞는지 확인해야 합니다. 그래픽 화면으로 트래픽을 보거나 노드를 전환할 수 없으므로, 보통 external-controller를 켜서 브라우저로 접속하는 서드파티 패널(예: metacubexd)과 함께 원격으로 노드를 관리합니다.

mixed-port: 7890
external-controller: 0.0.0.0:9090
secret: "접속 비밀번호를 설정하세요"

3단계: systemd 서비스 유닛 작성

새 서비스 파일 /etc/systemd/system/mihomo.service를 만들고 아래 내용을 작성합니다.

[Unit]
Description=mihomo Daemon
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW

[Install]
WantedBy=multi-user.target

여기서 -d /etc/mihomo는 해당 디렉터리를 작업 디렉터리로 삼아 설정을 읽는다는 뜻이고, Restart=on-failure는 코어 프로세스가 비정상 종료됐을 때 systemd가 자동으로 다시 실행하도록 보장합니다. CAP_NET_ADMIN과 CAP_NET_RAW 두 능력(capability)은 TUN 모드로 네트워크 계층 트래픽을 처리하는 데 필요한 권한으로, 프로세스를 완전히 root 권한으로 실행하지 않아도 요구 사항을 충족할 수 있어 상대적으로 더 안전합니다.

4단계: 서비스 활성화 및 상태 확인

sudo systemctl daemon-reload
sudo systemctl enable mihomo
sudo systemctl start mihomo
sudo systemctl status mihomo

enable 명령으로 부팅 시 자동 시작을 등록하고, status 명령으로 프로세스가 active (running) 상태인지 확인합니다. 상태가 실패로 표시되면 먼저 상세 로그를 확인해 문제를 파악하세요.

journalctl -u mihomo -n 50 --no-pager

실행 실패의 흔한 원인은 설정 파일 필드 형식 오류, 포트가 다른 프로세스에 이미 점유된 경우, 또는 TUN 모드에 필요한 네트워크 권한이 부족한 경우에 몰려 있습니다. 로그에는 대개 구체적인 오류 줄 번호나 필드명이 표시되므로 안내에 따라 하나씩 수정하면 됩니다.

GUI 없는 환경에서 노드와 규칙을 관리하는 방법

창이 없다고 해서 무작정 방치해야 하는 것은 아닙니다. 흔히 쓰는 관리 방식은 다음과 같으며, 익숙한 정도에 따라 조합해서 사용할 수 있습니다.

• 서드파티 웹 패널: external-controller를 켜면 같은 네트워크 안에서 브라우저로 해당 주소에 접속해 오픈소스 웹 패널과 함께 노드 전환, 지연 테스트, 규칙 확인 등을 수행할 수 있으며, 체감은 그래픽 클라이언트와 비슷합니다.
• curl로 제어 API 호출: mihomo의 외부 제어 인터페이스는 본질적으로 REST API이므로 curl로 직접 요청을 보내 현재 프록시 그룹 상태를 조회하거나 노드를 전환할 수 있어 자동화 스크립트에 넣기 좋습니다.
• 설정 파일을 직접 수정하고 서비스 재시작: 규칙이나 프록시 그룹 조정은 YAML 파일을 직접 고친 뒤 systemctl restart mihomo로 적용하면 되며, 변경 빈도가 낮은 고정된 환경에 적합합니다.

구독 갱신 측면에서는 설정 파일에 구독 링크가 적혀 있다면 cron 정기 작업과 함께 주기적으로 갱신을 받아온 뒤 서비스를 자동으로 재시작해 노드 정보가 오래되는 것을 막을 수 있습니다. 다만 자동 업데이트 스크립트는 반드시 형식 검증을 먼저 거쳐야 하며, 손상된 설정 파일을 그대로 덮어써서 서비스 재시작이 실패하는 상황을 피해야 합니다.

두 경로 중 무엇을 선택할까

평소 사용 환경이 개인 노트북이나 데스크톱 워크스테이션이고 창과 트레이 아이콘이 보인다면, 그래픽 클라이언트 경로를 바로 선택하는 것이 가장 진입 장벽이 낮고 대부분의 사용 습관에도 잘 맞습니다. systemd 명령을 외울 필요도 없습니다.

클라우드 서버, 가정용 NAS, 라우터 커스텀 펌웨어, Docker 컨테이너 같은 환경이라면 애초에 그래픽 인터페이스를 실행할 조건이 없으므로 mihomo 코어와 systemd 조합밖에 선택지가 없습니다. 설정 유지와 충돌 복구는 시스템 서비스에 맡기고, 원격 웹 패널로 일상적인 노드 관리를 처리하는 것이 현재 GUI 없는 환경에서 가장 안정적인 방법입니다.

두 경로는 서로 배타적이지 않습니다. 같은 사용자가 서로 다른 기기에서 병행해서 쓸 수도 있습니다. 업무용 노트북에는 그래픽 클라이언트를, 집에서 상시 구동하는 서버에는 mihomo와 systemd를 올리고, 두 쪽이 같은 구독을 공유하되 실행 형태만 다르게 두는 방식입니다.