Linux에서 Clash 쓰는 두 가지 방법: 데스크톱 클라이언트 설치와 명령줄 커널 배포

Linux에서 Clash 배포 방법, 무엇을 골라야 할까

엄밀히 말하면 오늘날 "Clash"는 단일 소프트웨어보다는 생태계 전체를 가리키는 말에 가깝습니다. 실제로 돌아가는 엔진은 mihomo(전신은 Clash Meta, 오리지널 Clash 커널은 업데이트가 중단됨)이며, 그 위에 그래픽 인터페이스를 갖춘 데스크톱 클라이언트를 얹을 수도 있고 커널 바이너리를 시스템에 그대로 서비스로 올려 실행할 수도 있습니다. 두 방식의 차이는 "화면 유무"에 그치지 않고 사용 시나리오 자체가 다릅니다.

• 데스크톱 클라이언트 방식: Ubuntu, Fedora, Debian 등 배포판에서 데스크톱 환경(GNOME, KDE 등)을 일상적으로 사용하는 경우에 적합합니다. 그래픽 화면에서 노드 전환, 규칙 로그 확인, TUN 모드 켜고 끄기까지 마우스 클릭으로 처리할 수 있어 진입 장벽이 가장 낮으며, 대표 제품으로 Clash Verge Rev와 FlClash가 있습니다.
• 명령줄 커널 방식: 그래픽 인터페이스가 없는 서버, NAS, 우회 라우터, 클라우드 인스턴스, 또는 그냥 Clash를 부팅 시 자동 실행되는 백그라운드 서비스로 만들고 싶은 경우에 적합합니다. 창을 열어 조작할 필요도 여유도 없이 config.yaml 한 벌과 systemd 유닛 파일로 장기간 상시 구동합니다.

두 방식 모두 같은 mihomo 커널을 사용하므로 규칙 문법과 구독 형식은 완전히 동일합니다. 차이는 "누가 커널을 실행하고 누가 제어판을 노출하는가"뿐입니다. 평소 웹서핑과 장기 상시 구동을 동시에 담당하는 Linux 장비(예를 들어 항상 켜져 있는 미니 PC)라면 두 방식을 모두 설치해 필요에 따라 전환해도 문제없습니다.

데스크톱 클라이언트 방식: Clash Verge Rev와 FlClash 설치 요점

데스크톱 클라이언트 방식에서는 Clash Verge Rev와 FlClash가 현재 Linux 데스크톱에서 활발히 관리되고 오픈소스로 확인 가능한 두 선택지입니다. 둘 다 내부적으로 mihomo 커널을 감싸고 있으며 화면 스타일과 의존성 용량에 약간의 차이가 있습니다.

Clash Verge Rev: 주요 배포판 전부 지원

Clash Verge Rev는 공식적으로 .deb, .rpm, .AppImage 세 가지 패키지 형식을 배포하며, Debian/Ubuntu 계열, Fedora/openSUSE 계열, 그리고 어떤 배포판에서도 실행 가능한 AppImage 범용 형식까지 대체로 커버합니다. 설치 요점은 다음과 같습니다.

1. Debian/Ubuntu 계열은 dpkg -i로 .deb 패키지를 설치하고, 의존성 누락 오류가 나오면 apt --fix-broken install 한 줄로 해결합니다.
2. Fedora/openSUSE 계열은 rpm -i 또는 해당 패키지 관리자로 .rpm 패키지를 설치합니다.
3. 시스템 패키지를 설치하지 않고 잠시 실행만 해보고 싶다면 AppImage 파일에 실행 권한을 준 뒤 더블클릭하거나 명령줄로 실행합니다: chmod +x Clash-Verge-Rev.AppImage && ./Clash-Verge-Rev.AppImage.
4. 처음 실행 시 TUN 모드에 추가 권한이 필요하다는 안내가 뜨면 화면 안내에 따라 sudo 권한으로 보조 프로세스를 한 번 설치합니다. 이후에는 TUN을 켜고 끌 때마다 비밀번호를 입력할 필요가 없습니다.

FlClash: 가볍고 크로스플랫폼인 또 다른 선택

FlClash는 Flutter로 만들어졌으며 마찬가지로 Linux용 .deb과 .AppImage 패키지를 제공합니다. 화면이 더 단순하고 자원 소모도 상대적으로 적어 사양이 낮은 데스크톱이나 가상머신 환경에 적합합니다. 설치 방식은 Clash Verge Rev와 비슷하며, 압축 해제 또는 설치 후 바로 실행하면 됩니다. 처음 실행 시 구독 링크나 로컬 설정 파일을 직접 가져와야 합니다.

둘 다 설치가 끝나면 사용 흐름은 거의 동일합니다: 구독 링크 가져오기 → 프록시 모드 선택(규칙/전역/직결) → 필요 시 TUN 모드로 전체 트래픽 인계 → 노드 목록에서 그룹 전환. 구체적인 화면 조작 절차와 플랫폼 공통 문제 해결 목록은 본 사이트의 최초 설치 설정 관련 글도 참고할 수 있습니다.

명령줄 방식: mihomo 커널을 직접 실행하는 전체 절차

명령줄 방식은 모든 그래픽 인터페이스를 건너뛰고 mihomo 바이너리 자체를 직접 관리합니다. 전체 흐름은 세 단계로 나뉩니다: 해당 아키텍처의 바이너리 다운로드, 설정 파일 준비, 손으로 한 번 실행해 문제없는지 확인.

1단계: 해당 CPU 아키텍처의 바이너리 다운로드

mihomo 공식 배포 페이지는 amd64, arm64, armv7 등 아키텍처별로 나뉘어 있습니다. 먼저 아래 명령으로 자신의 장비 아키텍처를 확인한 뒤 해당 버전을 내려받으세요.

uname -m
# x86_64는 amd64에 대응; aarch64는 arm64에 대응

다운로드한 파일은 보통 .gz 압축 파일이므로 압축을 풀고 실행 권한을 준 뒤, 이후 systemd에서 참조하기 편하도록 고정 디렉터리에 넣어둡니다.

gunzip mihomo-linux-amd64.gz
chmod +x mihomo-linux-amd64
sudo mkdir -p /etc/mihomo
sudo mv mihomo-linux-amd64 /usr/local/bin/mihomo

2단계: 설정 파일 준비

구독에서 변환한 config.yaml을 /etc/mihomo/ 디렉터리에 넣고, 최소한 아래 항목이 자신에게 필요한 값인지 확인합니다.

• port / socks-port: HTTP와 SOCKS5 로컬 프록시 포트.
• allow-lan: 이 장비가 로컬 네트워크 내 다른 기기에 프록시를 제공해야 한다면 true로 설정.
• mode: rule(규칙별 분기), global(전체 프록시) 또는 direct(전체 직결).
• external-controller: 제어판이 대기할 주소, 예를 들어 127.0.0.1:9090, secret 항목과 함께 접속 키를 설정.

3단계: 손으로 한 번 실행해 확인

아직 systemd를 연결하지 말고, 터미널에서 바로 한 번 실행해 설정이 정상적으로 로드되는지, 문법 오류가 없는지 확인합니다.

mihomo -d /etc/mihomo

로그에 규칙 로드 성공, 포트 대기 시작 안내가 나오고 오류가 화면을 채우지 않으면 설정 파일이 정상적으로 사용 가능하다는 뜻이므로 다음 단계인 상시 서비스화로 넘어갈 수 있습니다.

systemd로 mihomo 서비스를 상시 구동하고 연결 확인하기

수동 실행이 확인되면 다음은 mihomo를 부팅 시 자동 실행되고 장애 시 자동 재시작되게 만드는 단계이며, 이 작업은 systemd에 맡기는 것이 가장 편합니다. 유닛 파일을 새로 만듭니다.

sudo nano /etc/systemd/system/mihomo.service

다음 내용을 작성합니다(실제 경로에 맞게 조정):

[Unit]
Description=mihomo Clash kernel service
After=network.target

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

[Install]
WantedBy=multi-user.target

저장 후 다음 명령을 순서대로 실행해 서비스를 활성화하고 시작합니다.

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

systemctl status에서 active (running)이 표시되면 서비스가 상시 구동 중이라는 뜻입니다. 일상적인 문제 해결과 로그 확인에는 다음을 추천합니다.

journalctl -u mihomo -f

연결 상태 확인은 curl로 로컬 프록시 포트를 직접 테스트하면 됩니다.

curl -x socks5h://127.0.0.1:7890 https://www.google.com -I

정상적인 HTTP 상태 라인이 반환되면 프록시 경로가 정상적으로 연결된 것입니다. 현재 적용 중인 노드, 트래픽, 규칙 매칭 상황을 보고 싶다면 브라우저에서 external-controller에 설정한 주소(예: http://127.0.0.1:9090/ui)를 열어 오픈소스 웹 제어판 프로젝트와 함께 확인할 수 있으며, 별도로 데스크톱 클라이언트를 설치할 필요는 없습니다.

두 방식의 구독 업데이트와 일상 유지 관리 차이

방식을 정한 뒤에는 장기적인 유지 관리 방법도 달라지므로 미리 알아두면 시행착오를 줄일 수 있습니다.

데스크톱 클라이언트 방식의 구독 업데이트는 보통 화면에 "구독 업데이트" 버튼이 있고 자동 업데이트 간격도 설정할 수 있습니다. 규칙 세트와 노드 목록이 업데이트되면 즉시 적용되며 클라이언트 자체를 재시작할 필요가 없습니다. 노드 전환, 분기 모드 임시 변경 모두 클릭 한 번으로 처리되므로 자주 조정해야 하는 일상 사용에 적합합니다.

명령줄 커널 방식에는 버튼이 없으므로 구독 업데이트는 보통 정기 작업(crontab)으로 최신 config.yaml을 다시 내려받아 기존 파일을 덮어쓰고 systemctl restart mihomo를 한 번 실행해 새 설정을 적용합니다. 업데이트마다 프로세스를 재시작해 기존 연결을 끊기고 싶지 않다면, mihomo가 제공하는 설정 핫 리로드 인터페이스(external-controller 제어판을 통해 리로드 요청을 보내는 방식)를 연구해 서비스 중단을 피할 수도 있습니다.

어느 방식을 택하든 설정 파일의 규칙 문법은 동일합니다. 같은 config.yaml이 이론적으로는 데스크톱 클라이언트와 명령줄 커널 사이에서 그대로 재사용 가능하며, 다만 데스크톱 클라이언트는 가져올 때 그래픽 그룹화와 패널 설정을 자동으로 한 층 더 씌우는 경우가 많습니다. 데스크톱과 상시 구동 서버를 동시에 관리한다면 같은 규칙 소스를 유지해 두 쪽 설정이 어긋나 생기는 문제 해결 비용을 줄여보는 것도 좋습니다.