Linux에 Clash 클라이언트 설치하기: 데스크톱 GUI 및 명령줄 배포 방법

데스크톱 클라이언트와 명령줄 코어 선택

Linux에서 Clash를 배포하는 방법은 보통 두 가지입니다. 데스크톱 클라이언트는 GNOME, KDE Plasma, Xfce 같은 그래픽 환경의 워크스테이션에 적합합니다. GUI에서 구독을 가져오고, 프록시 그룹을 전환하고, 연결 기록을 확인하며, 트레이 메뉴로 시스템 프록시를 제어할 수 있습니다. mihomo 명령줄 코어는 서버, 소프트 라우터, 개발 컨테이너 호스트, 그리고 systemd로 프로세스를 통합 관리하려는 사용자에게 적합합니다.

mihomo는 Clash 설정 체계와 호환되면서 기능을 계속 확장하는 코어입니다. 일반적인 Clash 규칙, 프록시 그룹, 프록시 노드, DNS 및 TUN 설정은 코어가 실행하고, 데스크톱 클라이언트는 그 위에 설정 관리 화면을 제공합니다. 두 가지를 반드시 동시에 실행해야 하는 별도의 프록시 계층은 아닙니다. 대부분의 데스크톱 클라이언트는 이미 코어를 포함하거나 관리하므로, 시스템 수준의 mihomo를 추가로 실행하면 포트 점유, 컨트롤 포트 충돌 또는 시스템 프록시의 반복 전환이 발생하기 쉽습니다.

Linux 데스크톱 클라이언트 설치

다운로드하기 전에 프로세서 아키텍처를 확인하세요. 터미널에서 uname -m을 실행하면 일반적으로 x86_64, aarch64 또는 arm64가 표시됩니다. 설치 패키지의 amd64와 x64는 대개 x86_64에 해당하고, arm64는 64비트 ARM에 해당합니다. 아키텍처가 맞지 않으면 프로그램은 보통 클라이언트 화면으로 진입하지 않고 바이너리 파일을 실행할 수 없다는 오류를 바로 표시합니다.

데스크톱 배포판에서 흔히 사용하는 설치 형식은 AppImage, DEB 및 RPM입니다. 클라이언트를 선택할 때는 현재 유지 관리 상태, 지원하는 코어 유형, 설정 저장 위치, Linux 시스템 프록시 및 TUN 관리 지원 여부를 우선 확인하세요. 클라이언트마다 구독 오버라이드, 코어 업데이트 및 권한 상승 방식이 다르므로, 마이그레이션할 때 GUI 옵션이 완전히 같다고 가정해서는 안 됩니다.

AppImage 실행 방법

AppImage는 기존 패키지 설치 절차가 필요하지 않습니다. 현재 아키텍처에 맞는 파일을 다운로드한 뒤 실행 권한을 추가하고 터미널에서 실행하세요. 아래 명령의 파일명은 실제로 다운로드한 파일명으로 바꿔야 합니다.

mkdir -p "$HOME/Applications"
mv "$HOME/Downloads/클라이언트 파일.AppImage" "$HOME/Applications/"
chmod +x "$HOME/Applications/클라이언트 파일.AppImage"
"$HOME/Applications/클라이언트 파일.AppImage"

더블클릭해도 반응이 없으면 터미널에서 한 번 실행하여 오류 출력을 확인하세요. 일부 배포판은 FUSE 호환 구성 요소가 필요하며, 최신 AppImage 중에는 자체적으로 지원하는 압축 해제 모드로 실행할 수 있는 것도 있습니다. 단순히 아이콘이 나타나지 않는다는 이유만으로 설치 실패라고 판단하지 마세요. 윈도 시스템, 트레이 확장 기능 및 데스크톱 바로가기 캐시가 표시 여부에 영향을 줄 수 있습니다.

DEB 및 RPM 설치 방법

Debian, Ubuntu 및 파생 시스템에서는 APT로 로컬 DEB 패키지를 설치할 수 있습니다. APT는 패키지가 선언한 의존성도 함께 처리합니다.

cd "$HOME/Downloads"
sudo apt install ./클라이언트 파일.deb

Fedora, Rocky Linux 등 RPM 패키지를 사용하는 시스템에서는 DNF로 로컬 파일을 설치할 수 있습니다.

cd "$HOME/Downloads"
sudo dnf install ./클라이언트 파일.rpm

설치가 끝나면 애플리케이션 메뉴에서 클라이언트를 실행하세요. 처음 실행할 때는 먼저 코어 상태를 확인한 다음 구독 또는 로컬 YAML 설정을 가져오세요. 클라이언트에 시스템 프록시 설정 옵션이 있다면 이는 보통 현재 데스크톱 세션의 프록시 설정만 변경하며, 모든 프로세스를 투명하게 가로채는 기능과는 다릅니다. 터미널 프로그램, 컨테이너 및 시스템 서비스로 실행되는 소프트웨어가 데스크톱 프록시를 읽는지는 각각 확인해야 합니다.

mihomo 명령줄 코어 배포

명령줄 배포의 핵심은 실행 파일, 작업 디렉터리 및 설정 파일이라는 세 가지 요소입니다. 실행 파일은 /usr/local/bin/mihomo에, 시스템 수준 설정은 /etc/mihomo/에 두는 것을 권장합니다. 이렇게 하면 프로그램 업데이트와 설정 관리를 분리할 수 있고, systemd에서도 고정된 경로로 실행하기 쉽습니다.

신뢰할 수 있는 릴리스 채널에서 아키텍처에 맞는 압축 파일을 받아 압축을 푼 뒤 바이너리 파일 이름을 mihomo로 변경하세요. 파일의 압축을 현재 디렉터리에 풀었다고 가정하면 다음을 실행할 수 있습니다.

sudo install -m 0755 mihomo /usr/local/bin/mihomo
/usr/local/bin/mihomo -v
sudo install -d -m 0750 /etc/mihomo

mihomo -v는 코어 버전과 빌드 정보를 출력해야 합니다. Exec format error가 나타나면 대개 다운로드한 아키텍처가 잘못된 경우입니다. 실행 권한이 없다는 메시지가 표시되면 파일 모드와 파일 시스템이 noexec 마운트 옵션을 사용하는지 확인하세요.

처음 배포할 때는 복잡한 DNS, 스크립트 및 TUN 규칙을 바로 추가하지 마세요. 먼저 파싱 가능한 기본 설정으로 포트와 노드가 작동하는지 확인한 뒤 고급 설정을 하나씩 추가하세요. mihomo는 -d로 작업 디렉터리를 지정할 수 있으며, 해당 디렉터리의 config.yaml이 기본 설정으로 로드됩니다.

sudo /usr/local/bin/mihomo -d /etc/mihomo

포그라운드 실행은 초기 점검에 적합합니다. 터미널에 설정 파싱, 리스닝 포트, 프록시 연결 및 규칙 매칭 정보가 계속 표시됩니다. 설정으로 정상 시작되는 것을 확인한 뒤 문서 후반부에 따라 systemd 서비스를 생성하세요. 그래야 서비스가 반복 재시작되면서 최초 오류가 가려지는 일을 피할 수 있습니다.

설정 디렉터리, 구독 파일 및 기본 포트

가장 단순한 디렉터리에는 /etc/mihomo/config.yaml만 포함됩니다. GeoIP, 규칙 세트 또는 기타 외부 리소스를 활성화하면 작업 디렉터리에 데이터베이스, 캐시 및 다운로드 파일이 추가될 수 있습니다. 서비스를 실행하는 사용자는 설정을 읽을 수 있어야 하며, 업데이트가 필요한 캐시 위치에는 쓰기 권한이 있어야 합니다. 설정에 구독 인증 정보나 컨트롤 인터페이스 키가 포함되어 있다면 디렉터리와 파일 권한을 제한하세요.

sudo install -m 0640 config.yaml /etc/mihomo/config.yaml
sudo chmod 0750 /etc/mihomo
sudo ls -la /etc/mihomo

로컬 테스트용 기본 설정에는 혼합 프록시 포트, LAN 접근 허용 여부, 실행 모드 및 컨트롤 인터페이스를 포함할 수 있습니다. 아래 예시는 구조만 보여 주며, 프록시 노드와 규칙은 실제로 작동하는 Clash 또는 Mihomo 설정에서 가져와야 합니다.

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: true

external-controller: 127.0.0.1:9090
secret: "무작위로 충분히 긴 컨트롤 키를 설정하세요"

proxies: []
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,PROXY

mixed-port는 HTTP와 SOCKS5 연결을 동시에 허용하므로 브라우저, 터미널 도구 및 개발 소프트웨어가 하나의 포트를 함께 사용할 수 있습니다. allow-lan: false는 우선 로컬 시스템에서만 사용하도록 제한한다는 뜻입니다. bind-address를 와일드카드 주소로 작성했더라도 LAN 접근을 허용하지 않았다면 공유 설정이 완료된 것으로 보아서는 안 됩니다.

external-controller는 컨트롤 인터페이스이며 일반 프록시 포트가 아닙니다. 로컬에서만 관리한다면 127.0.0.1에 바인딩하고 컨트롤 키를 설정해야 합니다. 원격 관리가 꼭 필요하다면 방화벽, 신뢰할 수 있는 네트워크 범위 및 접근 인증도 함께 계획해야 하며, 컨트롤 포트를 신뢰할 수 없는 네트워크에 그대로 노출해서는 안 됩니다.

구독을 가져올 때 백업 파일을 유지하세요

그래픽 클라이언트는 보통 구독 URL, 업데이트 주기 및 로컬 설정 사본을 자체적으로 관리합니다. 명령줄 배포에서는 누가 업데이트를 담당하는지 명확히 해야 합니다. 제어된 스크립트로 설정을 가져와 임시 파일로 저장하고, 코어를 호출해 설정을 검사한 다음 현재 사용 중인 파일과 교체할 수 있습니다. 다운로드에 실패했을 때 기존 config.yaml을 바로 덮어쓰지 마세요. 빈 응답이나 인증 만료 한 번으로 다음 서비스 재시작이 실패할 수 있습니다.

구독 주소에는 대개 접근 인증 정보가 포함되므로 다른 사용자가 읽을 수 있는 셸 기록, 서비스 로그 또는 공개 스크립트에 직접 남기지 않는 것이 좋습니다. 더 안전한 방법은 권한이 제한된 환경 파일에 인증 정보를 저장하고, 업데이트 작업이 해당 파일만 읽도록 하며, 업데이트 결과의 접근 권한도 제한하는 것입니다. 구독 제공자가 Clash YAML이 아닌 일반 노드 목록을 출력한다면 먼저 호환 형식으로 변환해야 합니다. 임의의 텍스트를 그대로 mihomo 설정으로 실행할 수는 없습니다.

systemd 서비스 및 부팅 시 자동 시작 설정

기본 설정 검증을 통과했다면 /etc/systemd/system/mihomo.service를 생성할 수 있습니다. 아래 서비스 유닛은 시스템 수준 프로세스로 실행되며, TUN 기능에 필요할 수 있는 네트워크 관리 권한을 남겨 둡니다. HTTP 또는 SOCKS 포트만 사용한다면 설정 요구 사항을 확인한 뒤 권한 범위를 줄이세요.

[Unit]
Description=Mihomo proxy service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

저장한 뒤 systemd 설정을 다시 불러오고 서비스를 시작한 다음 부팅 시 자동 시작으로 설정하세요.

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo --no-pager

이번 부팅에서 시작된 로그는 다음 명령으로 확인할 수 있습니다.

sudo journalctl -u mihomo -b --no-pager
sudo journalctl -u mihomo -f

Restart=on-failure는 비정상 종료 때만 재시작하므로 설정 파싱 및 실행 오류를 확인하는 데 적합합니다. 서비스가 계속 재시작되면 먼저 systemctl stop mihomo를 실행한 뒤 같은 설정 디렉터리를 사용해 포그라운드로 시작하여 첫 번째 오류를 찾으세요. 흔한 원인으로는 YAML 들여쓰기 오류, 이미 사용 중인 리스닝 포트, 규칙에서 참조한 프록시 그룹 누락, 설정 디렉터리 권한 부족, TUN 장치 또는 네트워크 권한 부족이 있습니다.

데스크톱 시스템 프록시, 터미널 및 TUN 모드 연결

코어가 실행 중이라고 해서 모든 트래픽이 자동으로 프록시를 통과하는 것은 아닙니다. mixed-port: 7890만 설정한 경우 애플리케이션이 해당 포트에 직접 연결해야 합니다. 데스크톱 환경에서는 HTTP, HTTPS 및 SOCKS 프록시를 127.0.0.1:7890로 지정할 수 있고, 터미널 프로그램은 필요에 따라 환경 변수를 설정할 수 있습니다.

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5h://127.0.0.1:7890"

socks5h는 도메인 이름 해석도 SOCKS 프록시 측에서 처리한다는 뜻이지만, 실제 지원 여부는 애플리케이션에 따라 다릅니다. 환경 변수는 현재 셸과 그 하위 프로세스에만 적용됩니다. sudo, systemd 서비스, 컨테이너 또는 그래픽 런처를 사용할 때 변수가 상속되지 않을 수 있으므로 해당 실행 환경에서 별도로 설정해야 합니다.

TUN 모드의 역할과 전제 조건

TUN 모드는 가상 네트워크 인터페이스를 통해 수동으로 프록시를 설정하기 어려운 더 많은 트래픽을 가로채며, 데스크톱 애플리케이션, 명령줄 도구 및 일부 게임 연결을 통합 처리해야 할 때 유용합니다. Linux의 /dev/net/tun 장치, 라우팅 규칙 및 적절한 네트워크 관리 권한이 필요합니다. 컨테이너, 최소화된 커널 또는 제한된 가상 머신에서는 TUN 장치가 열려 있지 않을 수 있으므로 설정 문법이 올바르더라도 인터페이스를 만들 수 없습니다.

일반적인 설정은 기존 DNS 구성이 정상적으로 작동하는지 확인한 뒤 활성화합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true

auto-route는 라우팅을 자동으로 설정하고, auto-detect-interface는 기본 출구 인터페이스를 식별합니다. auto-redirect의 실제 지원 범위와 동작은 Linux 네트워크 환경, 커널 기능 및 mihomo 버전에 따라 달라집니다. 시스템에서 Docker, Podman, VPN, NetworkManager 사용자 지정 라우팅 또는 여러 네트워크 카드를 함께 사용한다면 라우팅 우선순위와 방화벽 규칙을 확인하세요. 컨테이너 네트워크, 내부망 주소 또는 프록시 서버 자체 연결이 실수로 다시 TUN으로 전달되지 않도록 해야 합니다.

TUN을 활성화한 뒤 도메인 이름을 해석할 수 없다면 노드만 반복해서 전환하지 마세요. DNS 리스닝, 상위 DNS 연결 가능 여부, 규칙의 DNS 정책, 가상 인터페이스 라우팅, 그리고 시스템이 다른 로컬 해석 서비스로 계속 요청을 보내는지를 각각 확인해야 합니다. DNS와 TUN을 동시에 크게 변경하면 진단이 어려워지므로 먼저 포트 프록시를 확인하고, 그다음 DNS를 활성화한 뒤 마지막으로 TUN을 추가하는 것이 좋습니다.

시작 점검과 일반적인 문제 진단

배포가 끝난 뒤에는 웹 페이지가 열리는지부터 판단하지 말고 프로세스에서 외부 방향으로 순서대로 확인해야 합니다. 첫째 서비스 실행 여부를 확인하고, 둘째 포트가 리스닝 상태인지 확인하고, 셋째 명시적 프록시로 요청을 보내고, 넷째 규칙 매칭 및 노드 연결 로그를 확인한 다음, 마지막으로 시스템 프록시나 TUN을 활성화하세요.

systemctl is-active mihomo
ss -lntup | grep -E '7890|9090'
curl --proxy http://127.0.0.1:7890 https://example.com/
journalctl -u mihomo -n 100 --no-pager

7890이 리스닝되지 않는다면 먼저 설정 파싱과 포트 충돌을 확인하세요. ss -lntup으로 포트를 점유한 프로세스를 찾을 수 있습니다. 포트는 존재하지만 요청이 실패한다면 로그에서 DNS 실패, 연결 시간 초과, 인증 오류 또는 사용 가능한 프록시 없음 중 무엇인지 확인하세요. 프록시 그룹에 노드가 표시된다고 해서 해당 노드에 반드시 연결되는 것은 아니므로 최종 판단은 연결 로그와 실제 요청 결과를 기준으로 해야 합니다.

데스크톱 클라이언트는 실행되지만 트래픽을 가로채지 못하는 경우

• 창이 열려 있는지만 보지 말고 클라이언트 코어가 실행 중인지 확인하세요.
• 현재 설정이 활성화되어 있고 프록시 그룹이 만료되었거나 사용할 수 없는 노드를 가리키지 않는지 확인하세요.
• 데스크톱 시스템 프록시가 정상적으로 적용되었는지, 대상 애플리케이션이 시스템 프록시를 따르는지 확인하세요.
• TUN을 사용한다면 권한 상승 절차가 완료되었는지, 가상 인터페이스가 존재하는지, 다른 VPN이 라우팅을 덮어쓰지 않았는지 확인하세요.
• 여러 프로그램이 프록시와 라우팅을 동시에 변경하지 않도록 다른 프록시 클라이언트를 종료하세요.

서비스가 시작 직후 종료되는 경우

journalctl -u mihomo -b로 이번 부팅 로그를 읽고 가장 먼저 나타난 오류를 중점적으로 확인하세요. YAML은 공백으로 들여쓰기하므로 Tab 문자, 잘못된 계층 또는 제대로 인용하지 않은 특수 문자 때문에 파싱에 실패할 수 있습니다. 규칙이 존재하지 않는 프록시 그룹을 가리키는 경우에도 코어가 설정 로드를 거부할 수 있습니다. 수정한 뒤에는 먼저 터미널에서 포그라운드로 실행하여 오류가 없는지 확인하고 systemd 서비스를 다시 시작하세요.

LAN 장치가 연결되지 않는 경우

프록시를 공유하려면 네 가지 조건을 모두 충족해야 합니다. 설정에서 LAN 접근을 허용해야 하고, 서비스가 LAN에서 접근 가능한 주소에 리스닝해야 하며, 호스트 방화벽에서 해당 TCP 또는 UDP 포트를 허용해야 하고, 클라이언트에는 127.0.0.1이 아닌 Linux 호스트의 LAN 주소를 입력해야 합니다. 무선 네트워크에서 클라이언트 격리가 활성화되어 있지 않은지도 확인하세요. 포트를 개방하기 전에는 신뢰할 수 있는 네트워크 대역으로 제한하고 프록시 포트를 공용 네트워크 인터페이스에 노출하지 않도록 해야 합니다.

Linux 배포 완료 후 유지 관리 목록

1. 현재 코어의 출처, 버전, 아키텍처 및 실행 파일 경로를 기록하세요.
2. 설정 디렉터리 권한을 제한하고 구독 인증 정보와 컨트롤 인터페이스 키를 안전하게 보관하세요.
3. 예정된 프록시, DNS 및 컨트롤 포트를 점유하는 인스턴스가 하나뿐인지 확인하세요.
4. 설정 업데이트를 위해 임시 파일과 롤백 사본을 보관하고, 검증이 끝난 뒤 교체하세요.
5. 업그레이드 전에 설정 호환성 변경 사항을 확인하고, 업그레이드 후 시작 로그와 규칙 매칭을 확인하세요.
6. TUN을 사용할 때 추가 라우팅, 방화벽 규칙 및 VPN·컨테이너 네트워크와의 관계를 기록하세요.
7. 데스크톱 클라이언트를 더 이상 사용하지 않을 때는 시스템 프록시 설정도 함께 복원하여 잘못된 포트가 남지 않도록 하세요.

데스크톱 클라이언트에서는 현재 배포판에 맞고 계속 유지 관리되는 GUI를 선택하고 시스템 프록시와 TUN의 차이를 이해하는 것이 중요합니다. 명령줄 배포에서는 고정 디렉터리를 사용하고 설정을 먼저 검증한 다음 systemd에 관리를 맡기는 것이 핵심입니다. 바이너리 파일, 설정 파싱, 포트 리스닝, 명시적 프록시, 시스템 트래픽 가로채기 순서로 확인하면 대부분의 Linux 설치 문제를 명확한 단계로 좁힐 수 있습니다.