Ubuntu 24.04 LTS에 Mihomo 설치:
tarball 압축 해제부터 systemd 자동 시작까지

1 왜 Ubuntu 24.04 LTS인가

«Linux에 Mihomo 깔기»만 검색하면 배포판마다 패키지 이름과 초기 도구가 조금씩 달라 처음부터 헷갈리기 쉽습니다. 그중에서도 Ubuntu 24.04 LTS는 클라우드 기본 이미지·데스크톱 채택률이 높고 문서가 많아, 실제 검색과 운영 현장에서 가장 자주 마주치는 기준선입니다. 이 글은 그 버전에 맞춰 바이너리 배포본 압축 해제와 systemd 등록을 한 흐름으로 고정해 두었습니다. 다른 Debian 계열에도 거의 그대로 옮겨갈 수 있지만, 방화벽 예시는 Ubuntu에 기본으로 많이 쓰이는 ufw를 넣었습니다.

범용 안내가 필요하면 동일 사이트의 Linux 전반 Mihomo·systemd 튜토리얼과 함께 보시면 Fedoras나 다른 init 환경까지 확장하기 쉽습니다. 여기서는 검색 의도에 맞게 Ubuntu 24.04 LTS라는 전제를 명시적으로 유지합니다.

2 사전 준비와 아키텍처 확인

최소한 sudo로 관리 명령을 실행할 수 있는 계정이 필요합니다. 새 VPS라면 제공업체 안내에 따라 키 로그인까지 마친 상태에서 진행하세요. 아키텍처는 터미널에서 다음으로 확인합니다.

uname -m

x86_64 출력이면 일반적인 클라우드·PC용 amd64 패키지를 고르면 되고, Apple Silicon 호환 가상머신이나 일부 ARM 서버는 aarch64에 해당하는 arm64 빌드를 받아야 합니다. WSL2에서 Ubuntu 24.04를 쓰는 경우에도 대부분 amd64입니다.

압축 해제와 다운로드에 curl 또는 wget, 그리고 gzip·tar가 필요합니다. 최소 설치 이미지라면 한 번만 패키지 목록을 갱신해 두면 이후 트러블이 줄어듭니다.

sudo apt update
sudo apt install -y curl ca-certificates

3 릴리스 받기: gzip 단일 파일 또는 tarball

배포 방식은 두 가지가 흔합니다. 하나는 .gz로 압축된 단일 실행 파일이고, 다른 하나는 .tar.gz 안에 실행 파일과 메타데이터가 함께 들어 있는 형태입니다. Ubuntu에서는 둘 다 표준 도구만으로 처리할 수 있습니다.

디렉터리 준비

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

실행 파일은 /usr/local/bin에 두면 PATH에 자연스럽게 잡힙니다. 설정은 /etc/mihomo/config.yaml 단일 파일로 시작해 두면 백업과 버전 관리가 단순합니다.

gzip 바이너리 예시(amd64)

cd /tmp
curl -LO https://github.com/MetaCubeX/mihomo/releases/download/v1.19.24/mihomo-linux-amd64-v1.19.24.gz
gunzip -f mihomo-linux-amd64-v1.19.24.gz
sudo mv mihomo-linux-amd64-v1.19.24 /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo
mihomo -v

릴리스 태그는 업데이트됩니다. GitHub Releases에서 mihomo-linux-amd64-…gz 자산 이름을 확인한 뒤 위 줄들의 버전 문자열만 바꾸면 됩니다. mihomo -v가 정상 출력되면 압축 해제와 실행 권한까지 끝난 것입니다.

tar.gz 아카이브를 쓸 때

파일 이름이 mihomo-linux-amd64-……tar.gz 형태라면 같은 디렉터리에서 한 번에 풀고 실행 파일만 골라 옮깁니다.

cd /tmp
curl -LO "REPLACE_WITH_RELEASE_URL/mihomo-linux-amd64-vX.Y.Z.tar.gz"
tar -xzf mihomo-linux-amd64-vX.Y.Z.tar.gz
sudo install -m 0755 mihomo /usr/local/bin/mihomo

압축을 풀었을 때 최상위 폴더 이름이 릴리스마다 다를 수 있으므로, tar -tvf로 안을 먼저 확인한 뒤 실제 바이너리 경로에 맞게 install 대상을 조정하세요. 이렇게 하면 «압축 풀기→권한 부여→PATH에 노출» 절차가 한 줄에서 끝납니다.

4 최소 YAML과 구독 연결(Clash Meta 호환)

Mihomo는 Clash 계열과 같은 규칙·프록시 표현을 주로 따릅니다. 여기서는 로컬 개발과 서버 모두에 무리 없는 mixed 포트, 로컬 전용 외부 컨트롤러, 그리고 proxy-providers로 구독을 주기적으로 가져오는 최소 골격을 제시합니다. 노드 목록이 이미 단일 YAML 파일로 있다면 proxies: 블록에 직접 넣어도 됩니다.

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

external-controller: 127.0.0.1:9090
secret: "replace-with-strong-password"

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

proxy-providers:
  sub:
    type: http
    url: "https://example.com/your-subscription"
    path: ./providers/sub.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - sub

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

url 자리에 실제 구독 주소를 넣고, 제공 형식이 원본 Clash가 아니라면 구독 변환 가이드를 참고해 Mihomo가 읽을 수 있는 프로바이더 출력으로 맞춥니다. 파일을 저장할 때 들여쓰기는 공백만 사용하고 탭을 섞지 마세요.

sudo mihomo -t -d /etc/mihomo

테스트가 통과해야 systemd로 넘어갈 때 재시작 루프를 피할 수 있습니다. DNS 동작을 더 빡세게 맞추려면 Meta DNS·FakeIP 유출 방지 글과 조합하세요.

5 systemd 유닛으로 부팅 자동 시작

Ubuntu는 systemd가 기본이므로 네트워크가 준비된 뒤 Mihomo를 띄우고 실패 시 재시작하는 유닛을 붙이면 운영 부담이 크게 줄어듭니다.

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

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

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

[Install]
WantedBy=multi-user.target

프로덕션에서는 전용 사용자를 만들고 데이터 디렉터리 소유권을 넘기는 편이 더 안전합니다. TUN 모드를 쓰려면 권한 요구가 달라지므로 보안 정책에 맞게 조정하세요.

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

상태가 active (running)이면 성공입니다. 설정을 고칠 때마다 sudo systemctl restart mihomo로 다시 읽히게 할 수 있습니다.

6 UFW, 환경 변수, 간단 검증

기본 예시는 allow-lan: false로 로컬 루프백에만 mixed 포트가 열립니다. 같은 호스트의 브라우저나 CLI가 프록시를 쓰려면 환경 변수를 넣습니다.

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"
curl -I https://www.google.com

LAN의 다른 기기에서 이 우분투 머신으로 들어와 프록시를 쓰려면 allow-lan: true로 바꾼 다음 방화벽으로 출처를 제한해야 합니다. Ubuntu에서는 흔히 다음과 같이 엽니다.

sudo ufw allow from 192.168.0.0/16 to any port 7890 proto tcp
sudo ufw reload

관리망 대역은 실제 공유기 서브넷에 맞게 수정하세요. 외부 컨트롤러 포트를 공인망에 노출하지 말고, 꼭 필요하면 소스 IP 화이트리스트와 강한 secret을 병행합니다.

7 문제 해결

• 서비스 실패: journalctl -u mihomo -n 120 --no-pager와 /var/log/mihomo/error.log를 함께 봅니다. YAML 오류·구독 URL 차단·포트 점유가 흔합니다.
• 프로바이더 파일이 비어 있음: 구독 서버가 특정 User-Agent만 허용하는 경우가 있어 Mihomo 쪽 UA 설정이나 중계 변환이 필요할 수 있습니다.
• DNS만 이상함: dns.listen 포트가 systemd-resolved 등과 겹치면 바인딩에 실패합니다. 포트를 바꾸거나 충돌 주체를 끕니다.
• HTTPS만 안 됨: 먼저 curl -x http://127.0.0.1:7890 -I https://example.com으로 포트 자체를 검증한 뒤 규칙이 트래픽을 PROXY로 보내는지 확인합니다.

8 정리

Ubuntu 24.04 LTS처럼 사용자층이 두꺼운 기준을 잡아 두면 «어디까지 따라오면 되는지»가 분명해져 문서와 검색어가 맞물립니다. tarball 또는 gzip 배포본을 풀어 /usr/local/bin에 고정하고, /etc/mihomo에 최소 YAML을 두며, systemd로 자동 기동까지 한 번에 묶으면 데스크톱 개발용 프록시와 경량 서버 프록시 모두 같은 패턴으로 운영할 수 있습니다.

순수 CLI 구성은 재현성과 서버 무인 운영에 강하지만, 구독 교체·규칙 편집·TUN 전환을 매번 파일과 명령으로 하려면 피로도가 큽니다. 브라우저 확장만으로는 터미널·컨테이너까지 같은 정책을 묶기 어렵고, 일부 폐쇄형 바이너리 클라이언트는 규칙 투명성이나 업데이트 주기에서 불안이 남습니다. 반면 Clash/Mihomo 계열은 YAML 규칙과 프록시 그룹 개념이 플랫폼 간에 통일되어 있어, 방금 구축한 데몬과도 같은 언어로 대화할 수 있습니다.

GUI에서 구독을 끌어오고 창 한 번에 모드를 바꾸고 싶다면 다운로드 페이지의 크로스 플랫폼 클라이언트를 함께 두고, 서버는 이 글의 systemd 패턴으로 유지하는 식으로 역할을 나누면 관리가 한결 편해집니다.