Linux에 Mihomo 설치 및 부팅 시 자동 실행:
systemd 서비스와 최소 YAML

1 Linux에서 Mihomo를 쓰는 이유

많은 개발자와 운영자가 클라우드 VPS나 데스크톱 Linux에서 일합니다. Windows·macOS에는 GUI 클라이언트가 풍부하지만, Linux에서는 리소스 사용이 적고 스크립트로 자동화·무인 운영이 가능한 방식을 선호하는 경우가 많습니다. 프록시 코어를 시스템 서비스로 백그라운드에서 돌리고 규칙으로 분기하면 git·curl·컨테이너 이미지 pull 등 필요할 때만 노드를 타고 나머지는 직접 연결하도록 만들 수 있습니다.

Mihomo(Clash.Meta)는 활발히 유지보수되는 Clash 계열 구현체로, 문법이 대부분의 Clash 튜토리얼과 호환되며 최신 전송 프로토콜과 고급 기능을 지원합니다. systemd로 프로세스를 관리하면 부팅 시 자동 시작, 비정상 종료 후 자동 재시작이 가능하고 표준 출력을 로그 파일로 남겨 서버에서 원인 분석하기 쉽습니다. SSH만 있는 환경은 물론, WSL이나 물리 머신에 로컬 프록시 포트를 상주시키는 개발 환경에도 잘 맞습니다.

구독 링크가 네이티브 YAML이 아니라면, 사이트의 구독 변환 가이드를 참고해 Mihomo가 읽을 수 있는 조각으로 바꾼 뒤, 아래 템플릿과 합치면 됩니다.

Fedora·RHEL 계열도 systemd가 기본이라 절차는 동일합니다. SELinux를 켠 환경에서는 Mihomo 바이너리와 /etc/mihomo에 대한 컨텍스트가 읽기·쓰기를 허용하는지 확인하세요. 권한 거부로 서비스가 바로 실패할 수 있습니다. 방화벽은 로컬 전용이면 API와 mixed 포트를 127.0.0.1에만 바인딩하고 allow-lan은 false로 두는 것이 안전합니다. LAN이나 관리망에 열어야 한다면 UFW·firewalld·클라우드 보안 그룹으로 출발지 IP를 화이트리스트해 제어 API가 전체 인터넷에 노출되지 않게 하세요.

2 다운로드와 바이너리 설치

CPU 아키텍처를 먼저 확인하세요. 대부분의 클라우드 인스턴스는 amd64, 라즈베리 파이·일부 ARM VPS는 arm64입니다. 터미널에서 uname -m을 실행해 x86_64이면 amd64 패키지에 해당합니다.

디렉터리 만들기

실행 파일은 /usr/local/bin, 설정은 /etc/mihomo, 로그는 /var/log/mihomo에 두면 권한과 백업 관리가 단순합니다.

sudo mkdir -p /etc/mihomo
sudo mkdir -p /var/log/mihomo

릴리스 바이너리 받기

Mihomo 공식 GitHub Releases에서 플랫폼에 맞는 압축 파일을 받습니다(아래 버전 번호는 최신으로 바꾸세요).

# Example: amd64 (replace URL with latest release)
wget https://github.com/MetaCubeX/Mihomo/releases/download/v1.18.0/mihomo-linux-amd64-v1.18.0.gz

gunzip mihomo-linux-amd64-v1.18.0.gz
sudo mv mihomo-linux-amd64-v1.18.0 /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo

3 최소 YAML 설정(Clash 호환)

Mihomo는 설정 디렉터리의 config.yaml을 읽습니다. 아래 템플릿은 mixed 포트(HTTP·SOCKS5), 패널·스크립트용 외부 API, 기본 DNS를 포함하며, 규칙은「중국 본토 IP는 직접, 나머지는 PROXY 그룹」 예시입니다. 실제 노드를 proxies에 넣고 이름을 proxy-groups의 PROXY 목록에 추가해야 합니다.

# External controller (dashboard / REST API)
external-controller: 127.0.0.1:9090
secret: "change-to-strong-password"

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://8.8.8.8/dns-query
    - https://1.1.1.1/dns-query

proxies: []
#  - name: "my-node"
#    type: ss
#    server: example.com
#    port: 443
#    cipher: aes-256-gcm
#    password: "secret"

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

파일을 /etc/mihomo/config.yaml로 저장한 뒤 YAML 들여쓰기는 공백만 사용하고 Tab을 섞지 마세요. LAN의 다른 기기가 이 머신의 프록시를 쓰려면 allow-lan을 true로 바꾸고 방화벽으로 신뢰 구간만 열어 주세요.

DNS 프라이버시와 유출 방지를 강화하려면 Meta 커널 DNS·FakeIP 가이드를 참고해 dns 블록을 환경에 맞게 조정하세요.

systemd에 넘기기 전 검증

서비스 등록 전에 설정 문법을 한 번 점검하면 재시작 루프를 줄일 수 있습니다.

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

테스트가 통과한 뒤 유닛 파일을 작성하세요. YAML을 고칠 때마다 sudo systemctl restart mihomo로 다시 읽히게 할 수 있습니다.

4 systemd 서비스 구성

유닛 파일을 만들어 네트워크가 준비된 뒤 Mihomo를 기동하고, 프로세스가 종료되면 자동으로 다시 띄우게 합니다.

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

아래 내용을 입력합니다(-d는 설정 디렉터리).

[Unit]
Description=Mihomo Daemon (Clash.Meta compatible)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=always
RestartSec=5
StandardOutput=append:/var/log/mihomo/output.log
StandardError=append:/var/log/mihomo/error.log

[Install]
WantedBy=multi-user.target

5 자주 쓰는 서비스 명령

유닛 파일이나 설정을 바꾼 뒤에는 다음 순서로 적용합니다.

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

상태가 active (running)이면 데몬이 정상입니다. config.yaml을 수정했다면 sudo systemctl restart mihomo로 반영하세요. 오류 추적은 /var/log/mihomo/error.log와 journalctl -u mihomo -f를 병행하면 편합니다.

6 시스템과 터미널 프록시

Mihomo가 mixed-port에서 수신해도 앱은 환경 변수나 자체 프록시 설정을 쓰지 않으면 자동으로 프록시를 타지 않습니다.

현재 셸에만 임시 적용

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"

로그인 스크립트에 영구 반영(해당 사용자만)

위 변수들을 ~/.bashrc 또는 ~/.zshrc 끝에 추가하고 필요하면 ALL_PROXY도 넣은 뒤 source ~/.zshrc 등으로 다시 읽습니다.

간단한 확인

curl -I https://www.google.com

노드와 규칙이 맞으면 HTTP/2 200 응답이 돌아오는 경우가 많습니다. 계속 타임아웃이면 서비스 상태·로컬 포트 충돌·규칙이 대상을 PROXY로 보내는지 순서대로 확인하세요.

환경 변수 없이 전체 트래픽을 넘기려면 Mihomo의 TUN 모드를 검토할 수 있고, GUI가 필요하면 Clash Verge Rev TUN 가이드를 참고해 병행할 수 있습니다.

방화벽과 보안 그룹

다른 장치에서 이 호스트의 mixed 포트를 쓰려면 allow-lan: true와 함께 Ubuntu에서는 sudo ufw allow 7890/tcp처럼 포트를 열고, 클라우드 콘솔 보안 그룹에서도 동일하게 허용해야 합니다. API 포트는 공인망에 직접 노출하지 말고 SSH 터널이나 제한된 관리망에서만 쓰는 것이 좋습니다.

7 문제 해결

• 서비스가 시작되지 않음: journalctl -u mihomo -n 80 --no-pager로 로그를 봅니다. YAML 문법 오류, proxies가 비어 있는데 존재하지 않는 노드로 보내는 경우, 포트 충돌이 흔한 원인입니다.
• 로컬 포트는 열리나 외부로 안 나감: proxy-groups에 실제 노드 이름이 들어 있는지, 구독·수동 노드가 연결 가능한지 확인하세요.
• 원격에서 대시보드 필요: API를 0.0.0.0에 바인딩했다면 방화벽으로 출발지 IP를 제한하세요(예: ufw allow from YOUR_OFFICE_IP to any port 9090). 인터넷 전체에 열지 마세요.
• DNS 이상: dns.listen과 같은 포트를 다른 데몬이 쓰고 있지 않은지 확인하고, 충돌이면 포트를 바꾼 뒤 시스템이나 TUN 환경에 맞게 전달 설정을 맞춥니다.
• HTTPS만 실패: curl -x http://127.0.0.1:7890 -I https://example.com으로 프록시 포트 자체를 먼저 검증한 다음 규칙이 트래픽을 PROXY로 보내는지 점검합니다.

8 정리

Linux에 Mihomo를 올리고 systemd로 관리하는 방식은 프록시를 한 번 «인프라»처럼 깔아 두는 실용적인 접근입니다. 백그라운드 상주·부팅 자동 시작·로그 추적이 한 번에 되며 서버와 개발용 워크스테이션 모두에 맞습니다. YAML 구조가 Clash 계열과 같아 학습 부담도 적습니다.

브라우저 확장만 쓰는 것과 달리, 로컬이나 VPS의 규칙 엔진이 CLI·스크립트 트래픽까지 같은 정책으로 묶어 줍니다. 데스크톱에서 GUI로 구독을 관리하고 TUN을 한 번에 켜고 싶다면 사이트 다운로드 페이지에서 클라이언트를 고르고, 이 글의 CLI 구성과 역할을 나눠 쓸 수 있습니다. 다른 도구에 비해 Clash/Mihomo 생태계는 규칙과 구독 흐름이 통일되어 있어 운영 감각을 옮기기 쉽습니다.

Clash를 무료로 내려받고 안정적인 크로스 플랫폼 프록시를 경험해 보세요 →