Linux에 Clash 설치하기: 데스크톱 클라이언트와 CLI systemd 서비스 구축

두 경로 중 어떻게 선택할까

시작하기 전에 먼저 확실히 해둘 것이 있습니다. Linux에서 "Clash 설치"는 단일한 작업이 아니라, 먼저 자신이 어떤 환경에 있는지 판단해야 하는 문제입니다. 데스크톱 버전 Linux(Ubuntu Desktop, Fedora Workstation, 각종 Linux Mint 계열 등)에는 창 관리자와 시스템 트레이가 있어 GUI 클라이언트를 설치하는 것이 적합하며, 일상적인 노드 전환이나 트래픽 확인도 클릭으로 처리할 수 있습니다. 서버 버전 Linux(클라우드 호스트, NAS, 홈 게이트웨이)는 보통 SSH 연결만 있고 데스크톱 환경이 없으므로, 순수 CLI 형태의 코어 프로그램과 프로세스 관리 도구를 이용해 프록시를 백그라운드에서 상시 구동시켜야 합니다.

두 경로에서 사용하는 소프트웨어 형태는 완전히 다릅니다. 데스크톱 경로에서는 Tauri 프레임워크로 패키징된 GUI 클라이언트인 Clash Verge Rev를 사용하며, 내부에 mihomo 코어가 통합되어 있어 구독 관리, 규칙 편집, 트래픽 그래프의 시각적 인터페이스를 제공합니다. CLI 경로에서는 mihomo 코어 실행 파일을 바로 구동합니다. GUI가 없으므로 모든 것을 설정 파일과 터미널 명령으로 처리하고, systemd로 프로세스 생명주기를 관리해 기기 재시작 후에도 자동으로 다시 기동되도록 합니다.

데스크톱 환경: Clash Verge Rev의 deb 패키지 설치

Clash Verge Rev 공식 배포판에는 Debian/Ubuntu 계열 배포판을 위한 .deb 설치 패키지가 제공되며, 현재 데스크톱 Linux에서 가장 진입 장벽이 낮은 설치 방법입니다. 의존성을 수동으로 설정할 필요 없이 더블클릭이나 dpkg로 설치하면 됩니다. 아래는 전체 절차입니다.

1단계: 해당 아키텍처의 설치 패키지 다운로드

Linux 데스크톱은 대부분 x86_64(즉 amd64) 아키텍처이며, 일부 ARM 기기(일부 국산 노트북, Raspberry Pi 데스크톱 세트 등)는 aarch64 아키텍처 패키지를 선택해야 합니다. 아키텍처 확인은 다음 명령으로 할 수 있습니다:

uname -m
# 출력이 x86_64 → amd64 패키지 선택
# 출력이 aarch64 → arm64 패키지 선택

2단계: dpkg로 설치하고 의존성 처리

다운로드한 deb 패키지를 로컬 디렉터리에 두고 설치 명령을 실행합니다. deb 패키지 자체는 의존성을 자동으로 가져오지 않으므로, 의존성 누락 오류가 표시되면 이어서 apt로 보완하면 됩니다:

sudo dpkg -i clash-verge-rev_*.deb
# 의존성 오류가 발생하면 아래 명령으로 자동 복구
sudo apt --fix-broken install

설치가 끝나면 애플리케이션 메뉴에 앱이 나타나고, 시스템 프록시 설정과 가상 네트워크 카드 권한 요청을 처리하는 사용자 수준의 백그라운드 보조 프로세스도 함께 등록됩니다. 처음 실행할 때 GUI 형태의 비밀번호 인증 창이 뜨는 경우가 많은데, 이는 TUN 모드를 켜려면 가상 네트워크 인터페이스를 만들어야 하고 이 작업에는 root 권한이 필요하기 때문입니다. 이는 정상적인 절차이며 설치 오류가 아닙니다.

3단계: 자동 시작 설정

Clash Verge Rev의 설정 패널에는 "부팅 시 자동 시작" 스위치가 있으며, 이를 켜면 프로그램이 데스크톱 환경의 자동 시작 메커니즘(~/.config/autostart/ 아래 .desktop 파일 규격을 따름)을 통해 사용자 로그인 시 자동으로 실행됩니다. 스위치가 작동하지 않으면 해당 디렉터리에 desktop 파일이 생성되었는지 직접 확인할 수 있습니다:

ls ~/.config/autostart/ | grep -i clash

생성되지 않았다면 앱 설치 디렉터리에서 desktop 파일을 이 경로로 복사하거나, 설정 패널에서 자동 시작 스위치를 껐다가 다시 켜보면 대부분의 경우 등록 절차가 다시 트리거됩니다.

다른 배포판의 설치 방법

Debian 계열이 아닌 배포판은 각자 다른 방식을 사용합니다:

• RPM 기반 배포판(Fedora, openSUSE): 공식 배포판에서도 .rpm 형식을 제공하며, sudo rpm -i나 sudo dnf install로 로컬 파일을 지정해 설치하면 됩니다.
• Arch 계열 배포판: 커뮤니티에서 관리하는 AUR 패키지를 통해 yay나 paru 같은 AUR 헬퍼 도구로 검색해 설치할 수 있으며, 의존성은 자동으로 해결됩니다.
• 기타 배포판 또는 설치 없이 사용해야 하는 경우: 공식적으로 범용 AppImage 형식도 제공합니다. 다운로드 후 실행 권한을 부여하면 바로 실행되며, 시스템 디렉터리에 기록되지 않아 임시 테스트나 권한이 제한된 환경에 적합합니다.

서버 환경: mihomo 코어 + systemd 구축

서버에는 데스크톱 환경이 없으므로 GUI 클라이언트를 설치할 필요도 없고 설치할 수도 없습니다. mihomo 코어(Clash Meta 프로젝트의 후속작)를 직접 배포하는 것이 더 합리적인 방법입니다. 코어 자체는 단일 실행 파일이며 리소스 사용량이 매우 낮고, systemd로 관리하면 기기 재시작 후에도 사람의 개입 없이 프록시 서비스가 자동으로 복구됩니다.

1단계: 설정 디렉터리 구성

배포 전에 먼저 디렉터리 구조를 계획해두면 설정 파일과 프로그램 본체가 섞이지 않아, 이후 코어 버전을 업그레이드할 때 설정을 잘못 삭제하는 일을 방지할 수 있습니다:

/etc/mihomo/           # 설정 파일 디렉터리
  ├── config.yaml      # 메인 설정 파일
  ├── geoip.dat         # GeoIP 데이터베이스
  └── geosite.dat       # GeoSite 데이터베이스
/usr/local/bin/mihomo   # 코어 실행 파일

코어 실행 파일을 /usr/local/bin 같은 시스템 수준 실행 디렉터리에 두고, 설정 파일은 /etc/mihomo에 별도로 두는 것은 Linux에서 소프트웨어를 배포할 때의 일반적인 관례이며, systemd로 통합 관리하기 편하고 이후 수동으로 설정 문제를 확인할 때도 빠르게 위치를 파악할 수 있습니다.

2단계: 코어 다운로드 및 실행 권한 부여

mkdir -p /etc/mihomo
cd /usr/local/bin
# 해당 아키텍처의 코어 압축 파일을 이미 다운로드하고 압축을 풀어 mihomo 파일을 얻었다고 가정
chmod +x mihomo
mihomo -v   # 정상적으로 실행되고 버전 번호가 출력되는지 확인

서버 아키텍처 확인 역시 uname -m을 사용합니다. 클라우드 호스트는 대부분 x86_64이고, 일부 해외 저가 서비스 제공업체나 ARM 클라우드 인스턴스(일부 경량 애플리케이션 서버 등)는 aarch64이므로 다운로드 전에 반드시 확인해야 합니다. 아키텍처가 일치하지 않는 실행 파일은 실행 시 바로 오류가 발생하며 종료됩니다.

3단계: 설정 파일 준비

구독에서 변환한 YAML 설정 파일을 /etc/mihomo/config.yaml에 배치하고, 그 안의 핵심 필드에 문제가 없는지 확인합니다. 특히 external-controller 항목이 중요한데, 서버 환경에서 이 주소를 열어두고 0.0.0.0에 바인딩하면 코어의 제어 인터페이스를 공용 네트워크에 그대로 노출하는 셈이므로, 반드시 접근 키를 설정하거나 로컬 주소에만 바인딩해야 합니다:

external-controller: 127.0.0.1:9090
secret: "충분히 복잡한 키를 설정하세요"

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

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

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

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

[Install]
WantedBy=multi-user.target

몇 가지 핵심 필드를 짚어보면, -d /etc/mihomo는 코어가 해당 디렉터리의 설정 파일을 읽도록 지정하는 것입니다. Restart=on-failure는 프로세스가 비정상 종료됐을 때 자동으로 재시작하도록 해, 일시적인 네트워크 흔들림 한 번으로 프록시 서비스가 완전히 끊기는 것을 방지합니다. LimitNOFILE은 파일 디스크립터 상한을 높인 것으로, 프록시 서비스가 동시에 많은 연결을 유지해야 하기 때문에 시스템 기본 제한값으로는 고부하 상황에서 연결 실패가 쉽게 발생하기 때문입니다.

5단계: 서비스 활성화 및 시작

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

enable 명령은 부팅 시 자동 시작을 위한 심볼릭 링크를 생성하는 역할을 하며, 이렇게 하면 서버가 재시작된 후에도 별도의 명령 실행 없이 mihomo가 시스템과 함께 자동으로 기동됩니다. status 명령으로 현재 실행 상태를 확인하며, active (running) 줄이 정상적으로 나오는지가 핵심입니다.

권한 요점과 실행 검증

Linux 환경에서 프록시를 배포할 때 가장 자주 걸려 넘어지는 부분이 권한 문제이므로, 여기서 따로 정리합니다.

TUN 모드의 권한 요구사항

설정 파일에서 tun.enable: true를 켰다면, 코어는 가상 네트워크 인터페이스를 생성하고 라우팅 테이블을 수정해야 하며, 이 작업은 Linux에서 반드시 CAP_NET_ADMIN 권한이 필요합니다. root 권한으로 systemd 서비스를 실행하는 것이 가장 간단한 해결 방법입니다(위 서비스 유닛의 User=root처럼). 다만 보안상의 이유로 프록시 프로세스를 root 권한으로 상시 구동하고 싶지 않다면, setcap 명령으로 실행 파일에만 개별적으로 권한을 부여한 뒤 일반 사용자 권한으로 실행할 수도 있습니다:

sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo

권한 부여 후 서비스 유닛의 User=root를 프록시 서비스용으로 별도로 생성한 일반 사용자로 변경해 권한 범위를 한층 더 좁히는 것이, 서버 보안 실무에서 더 권장되는 방식입니다.

설정 디렉터리의 읽기/쓰기 권한

일반 사용자로 서비스를 실행한다면 설정 디렉터리에 해당 사용자의 읽기 권한을 부여해야 합니다. 그렇지 않으면 코어가 설정 파일을 읽지 못해 바로 종료됩니다:

sudo chown -R clash-user:clash-user /etc/mihomo

프록시가 정상 작동하는지 검증

서비스가 시작된 후, 먼저 포트가 정상적으로 리스닝되고 있는지 확인합니다:

sudo ss -tlnp | grep mihomo

그다음 프록시를 경유한 요청을 명령줄로 직접 보내 출구 IP가 바뀌었는지 검증합니다:

curl -x http://127.0.0.1:7890 https://api.ip.sb/ip

반환된 IP가 서버 자체 주소가 아니라 노드의 출구 주소라면, 프록시 경로가 정상적으로 작동하고 있다는 의미입니다. 데스크톱 환경에서 Clash Verge Rev를 사용한다면 클라이언트 안의 연결 상태와 지연 테스트 결과만 확인하면 되며, curl로 직접 검증할 필요는 없습니다.

일상 유지 관리 권장 사항

두 경로 모두 배포가 끝난 뒤에는 일상 유지 관리의 중점이 약간 다르므로 각각 정리합니다.

데스크톱 클라이언트 쪽: Clash Verge Rev는 구독 자동 업데이트 기능이 내장되어 있어 설정에서 업데이트 주기를 지정할 수 있으며, 매번 구독 링크를 수동으로 다시 가져올 필요가 없습니다. 여러 구독 소스를 전환해서 쓰는 경우, 각 설정 파일에 한눈에 알아볼 수 있는 이름을 붙여두면 실수로 만료된 구독으로 전환하는 일을 줄일 수 있습니다.

CLI 서비스 쪽: 설정 파일을 업데이트한 뒤 전체 서비스를 재시작할 필요는 없습니다. mihomo는 RESTful API를 통한 핫 리로드를 지원하며, 아니면 systemctl restart mihomo로 서비스를 재시작해 바로 적용할 수도 있습니다. 특히 커스텀 규칙이 많은 경우, 설정 디렉터리를 정기적으로 백업해두는 것이 좋습니다. 한 번의 실수로 설정을 덮어쓰면 규칙이 전부 사라질 수 있습니다.

또한 어느 경로를 택하든 GeoIP와 GeoSite 데이터베이스는 정기적으로 업데이트하는 것을 권장합니다. 데이터베이스가 오래되면 트래픽 분기 규칙이 오판을 일으켜 "프록시를 거쳐야 할 도메인이 거치지 않고, 직결해야 할 주소가 오히려 프록시를 거치는" 상황이 발생할 수 있습니다. 구체적인 업데이트 방법과 점검 절차는 데이터베이스 업데이트 관련 기술 노트를 참고하세요.

두 경로 비교 정리