왜 Linux에서는 Mihomo를 직접 실행할까

Windows·macOS용 Clash Verge Rev 글은 많지만, VPS나 홈 서버에는 화면이 없는 경우가 흔합니다. 이때 Mihomo(Clash Meta 계열)는 익숙한 Clash YAML을 그대로 가져와 명령줄에서 구동할 수 있어 자동화에 유리합니다. 여기에 systemd를 쓰면 프로세스 감시, 부팅 후 자동 실행, journalctl로 로그를 한곳에서 보는 운영 패턴이 완성됩니다.

구독 URL에서 설정 파일을 만드는 단계가 아직이라면 먼저구독 가져오기 튜토리얼을 읽고 돌아오면 전체 흐름이 빨라집니다.

nohup이나 screen으로 억지로 띄우는 방식도 가능하지만, 재시작 정책과 부팅 순서를 systemd에 맡기면 운영 기록이 훨씬 명확해집니다. 컨테이너 표준을 쓰는 팀이라면 동일한 바이너리를 이미지에 넣을 수도 있지만, 호스트 네트워킹·방화벽·로컬 인증서 저장소와 바로 연결하려면 지금처럼 네이티브 유닛이 가장 단순한 경우가 많습니다.

배포판·아키텍처 정리

이 글은 systemd를 쓰는 Debian/Ubuntu, Fedora, Arch 계열을 기준으로 설명합니다. init이 다르더라도 본질은 동일합니다.

릴리스 자산은 CPU와 맞아야 합니다. 일반 PC·클라우드 VM은 amd64, 라즈베리파이·ARM 인스턴스는 arm64가 흔합니다. uname -m으로 확인하세요.

CI 이미지를 빌드할 때는 런타임 아키텍처와 빌드 아키텍처를 혼동하기 쉽습니다. 릴리스 노트를 읽고 YAML 호환성 변화가 없는지 확인한 뒤 스테이징에서 먼저 올리면 운영 중단을 줄일 수 있습니다.

다운로드, 권한, 설치 경로

GitHub Releases에서 Linux용 아카이브를 받아 mihomo 실행 파일을 꺼낸 뒤 고정 경로에 둡니다.

  • 전역 사용: /usr/local/bin/mihomo
  • 단일 사용자: ~/.local/bin/mihomo (PATH 포함)
  • 반드시 chmod +x
  • 운영 환경이라면 공개된 체크섬으로 무결성 확인 권장

Mihomo가 어떤 프로토콜을 더 지원하는지 개념을 잡으려면코어 업그레이드 가이드를 함께 보세요.

바이너리 경로를 자주 바꾼다면 심볼릭 링크를 고정하고 systemd의 ExecStart는 링크를 가리키게 두는 편이 업그레이드를 단순화합니다. 여러 버전을 보관해야 한다면 /opt/mihomo/버전/mihomo처럼 디렉터리를 나누고 링크만 교체하는 패턴도 자주 쓰입니다.

설정 디렉터리와 가져오기 방식

mihomo -d 경로로 디렉터리를 지정하고, 그 안에 config.yaml을 둡니다. 예: 개인 계정은 ~/.config/mihomo, 공용 게이트웨이는 /etc/mihomo.

구성 방법은 세 가지가 대표적입니다. 공급자가 준 완성 YAML을 저장하거나, proxy-providers로 원격 구독을 당겨오거나, 다른 클라이언트에서보낸 호환 파일을 복사합니다. 이후 mixed-port, external-controller 포트가 기존 데몬과 겹치지 않는지 확인하세요.

TUN 투명 프록시는 권한·라우팅 이슈가 붙습니다. 먼저 HTTP/SOCKS 상시 실행을 안정화한 다음TUN 모드 가이드로 확장하는 편이 안전합니다.

DNS 스택이 복잡한 환경에서는 설정의 dns 블록이 예상과 다르게 동작할 수 있습니다. 문제가 생기면 잠시 로그 레벨을 올려 쿼리 경로를 확인하고, 끝나면 반드시 원래 값으로 돌려 디스크 사용과 민감 로그 노출을 막으세요.

포그라운드 테스트

systemd에 넣기 전에 터미널에서 직접 실행합니다.

mihomo -d ~/.config/mihomo

YAML 오류나 포트 충돌은 여기서 바로 드러납니다. 정상이라면 Ctrl+C로 종료하고 동일 인자를 서비스 유닛에 옮깁니다.

systemd 사용자 서비스

~/.config/systemd/user/mihomo.service 예시는 다음과 같습니다. 홈 경로는 본인 계정에 맞게 바꿉니다.

[Unit]
Description=Mihomo (Clash) proxy daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /home/사용자명/.config/mihomo
Restart=on-failure
RestartSec=3
LimitNOFILE=65536

[Install]
WantedBy=default.target

systemctl --user daemon-reload 후 enable --now 합니다. SSH 서버에서 로그아웃 뒤에도 사용자 서비스를 살리려면 sudo loginctl enable-linger 사용자명이 필요할 수 있습니다.

systemd 시스템 서비스

/etc/systemd/system/mihomo.service에 시스템 경로를 넣고 sudo systemctl enable --now mihomo로 켭니다. 비밀 노드 정보가 들어가므로 디렉터리 권한을 제한하세요.

검증: API, 포트, 로그

external-controller가 127.0.0.1:9090이면 curl http://127.0.0.1:9090/version으로 버전 JSON을 확인합니다. 리스닝 포트는 ss -tlnp 등으로 점검합니다.

로그는 사용자 유닛이면 journalctl --user -u mihomo.service -f, 시스템 유닛이면 sudo journalctl -u mihomo.service -f입니다. 디버그 로그는 디스크와 민감 정보에 유의하세요.

컨트롤러를 루프백 밖으로 노출해야 한다면(권장하지 않음) 리버스 프록시 인증이나 방화벽으로 반드시 보호하세요. 로컬 점검만 한다면 curl로 프록시 그룹 이름이 애플리케이션 설정과 일치하는지 빠르게 확인할 수 있습니다.

보안·업데이트 습관

꼭 필요하지 않으면 root로 상시 실행하지 말고, 설정 파일 권한을 최소화합니다. 업데이트는 서비스 중지 → 바이너리 교체 → 시작 순서를 지키면 반쯤 쓴 실행 파일 문제를 피할 수 있습니다. 작동하던 YAML 스냅샷을 남기면 롤백이 빨라집니다.

여러 대를 관리한다면 구성 관리 도구로 YAML을 렌더링하고, 변경 전후에 API 헬스 체크 스크립트를 돌리면 회귀를 빨리 잡을 수 있습니다. 실험적인 규칙 프로바이더를 켜기 전에도 백업 습관이 가장 값싼 보험입니다.

자주 막히는 지점

포트 사용 중

YAML의 포트를 바꾸거나 충돌 프로세스를 종료합니다.

실행 거부·포맷 오류

아키텍처 불일치나 실행 비트 누락이 흔한 원인입니다.

SELinux 차단

audit2why로 이유를 보고 정책을 조정합니다.

그래도 원인이 안 보이면문제 해결 가이드에서 DNS·구독 쪽을 의심해 보세요.

GUI가 더 편할 때

서버에는 CLI+systemd가 잘 맞고, 데스크톱에서는 노드 전환 UI가 생산성을 올려 줍니다. Clash Verge Rev는 최신 Mihomo 코어를 포함해 같은 생태계를 유지한 채 클릭 운영이 가능합니다.

역할을 나눠 쓰면 오래 편합니다. 공식 빌드를 받아 직접 비교해 보세요.→ Clash를 무료로 다운로드하고 차이를 경험해 보세요