Linux Mihomo TUN·systemd 설치: 데스크톱 분할 완전 가이드 (2026)

왜 Linux에서는 Mihomo 코어인가

서버나 개발용 워크스테이션에서는 종종 단일 바이너리와 YAML 프로필만으로 전체 스택을 운영하고 싶습니다. Mihomo는 Clash Meta 계열 코어로, 다중 아웃바운드·Rule Provider·스크립트 확장을 한 프로세스에서 다룰 수 있습니다. 데스크톱 배포판마다 패키지 이름이 다르지만, 공식 릴리스 아키텍처에 맞는 실행 파일 하나를 받아 /usr/local/bin 등에 두는 방식이 가장 예측 가능합니다. GUI 없이도 systemd와 로그만으로 장애를 추적할 수 있다는 점이 서버 운영자에게 유리합니다.

브라우저만 프록시하고 터미널은 직행으로 두면 git·curl·컨테이너 레지스트리 접속이 엇갈립니다. TUN 모드는 커널 레벨에서 트래픽을 코어로 보내기 때문에, 애플리케이션이 HTTP 프록시 환경 변수를 무시해도 동일한 정책을 적용하기 쉽습니다. 물론 권한 요구와 다른 VPN 도구와의 충돌 가능성은 감수해야 하므로, 아래 사전 조건을 먼저 읽는 것이 좋습니다.

사전 조건: 커널·권한·충돌

TUN을 쓰려면 일반적으로 루트 권한 또는 CAP_NET_ADMIN이 필요합니다. 배포판에 따라 tun 모듈이 이미 로드되어 있거나, 컨테이너·보안 프로파일이 가상 인터페이스 생성을 막을 수 있습니다. SELinux·AppArmor를 켠 상태라면 바이너리 경로와 프로필에 예외를 추가해야 할 수 있습니다. 또한 NetworkManager·systemd-resolved·dnsmasq가 DNS를 잡고 있으면 Meta의 FakeIP·DoH 설정과 충돌하므로, 한 번에 하나의 “DNS 책임자”를 정하는 것이 안전합니다.

동시에 WireGuard·기업 VPN·Docker의 사용자 정의 브리지가 같은 라우팅 테이블을 건드리면 루프나 끊김이 납니다. 운영 원칙은 전역 트래픽 후킹 도구는 한 번에 하나입니다. 설치 전에 기존 프록시 데몬을 중지하고, 방화벽(nftables/iptables) 규칙이 자동으로 덮어쓰이지 않는지 확인하세요.

바이너리 배치와 디렉터리 구조

일반적인 구성은 다음과 같습니다. 홈 디렉터리에 사용자 권한만으로 쓰려면 경로를 조정하면 됩니다.

• 실행 파일: 예) /usr/local/bin/mihomo
• 구성 파일: 예) /etc/mihomo/config.yaml
• 작업 디렉터리: 예) /var/lib/mihomo (캐시·GEOIP·다운로드 규칙)

릴리스 아카이브를 풀고 실행 권한을 부여한 뒤, mihomo -v로 버전을 확인합니다. 아직 프로필이 없다면 최소한의 port·mixed-port·빈 proxies 섹션만 넣고 문법 오류가 없는지 검증하세요. 구독 URL이 V2Ray 원문이라면 Subconverter 가이드를 참고해 Clash 형식으로 바꿉니다.

프로필 기본: 모드와 인바운드

일상 사용에서는 mode: rule을 기본으로 두고, GLOBAL·DIRECT 전환은 장애 시에만 씁니다. mixed-port를 열면 HTTP와 SOCKS가 한 포트에서 처리되어 브라우저 수동 프록시 설정이나 일부 앱의 SOCKS 지정에 쓸 수 있습니다. 그러나 “모든 앱이 자동으로 따라오게” 하려면 다음 절의 TUN이 핵심입니다. 로그 레벨은 처음에는 info로 두고 안정화 후 warning으로 낮추는 편이 디스크와 CPU에 유리합니다.

TUN 섹션: 스택·auto-route·인터페이스

Meta 문법에서 TUN은 보통 tun: 블록 아래에 enable: true, stack: system 또는 gvisor, auto-route: true, auto-detect-interface: true 조합으로 시작합니다. 배포판·커널에 따라 system 스택이 더 자연스럽거나, 반대로 gvisor가 안정적인 경우도 있으니 한쪽에서 이상 증상이 나오면 다른 쪽을 시험합니다. 인터페이스 이름은 기본값(예: Meta)을 쓰거나 운영 정책에 맞게 바꿉니다.

DNS가 순환 참조를 일으키면 “연결은 되는데 이름만 안 풀린다”는 패턴이 나옵니다. TUN과 함께 쓸 때는 dns 섹션에서 enhanced-mode·업스트림 서버·nameserver-policy를 프로필 일관성 있게 맞추고, 필요하면 DNS 유출 방지 가이드의 순서를 밟으세요. 여기서 한 번 정리해 두면 브라우저·쉘·시스템 서비스가 같은 해석 경로를 공유합니다.

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  # strict-route: true  # policy routing conflicts: test before enable

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query

systemd 유닛: 부팅 시 자동 기동

서비스 사용자는 보안상 전용 계정을 쓰는 것이 좋지만, TUN 생성 권한 때문에 User=root로 두는 예도 흔합니다. 대안으로는 CapabilityBoundingSet=CAP_NET_ADMIN과 AmbientCapabilities=CAP_NET_ADMIN을 조합해 비루트 사용자에게 최소 권한만 주는 방식이 있습니다. 유닛 파일은 /etc/systemd/system/mihomo.service에 두고 systemctl daemon-reload 후 enable --now로 등록합니다.

After=network-online.target를 지정하면 부팅 직후 DNS가 아직 준비되지 않은 상태에서 코어가 먼저 뜨는 일을 줄일 수 있습니다. 작업 디렉터리는 WorkingDirectory로 고정하고, 구성 경로는 ExecStart 인자로 명시하면 업그레이드 시 혼선이 적습니다. 실패 시 journalctl -u mihomo -e로 원인을 확인하세요.

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

[Service]
Type=simple
WorkingDirectory=/var/lib/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

데스크톱: 브라우저·터미널·GUI 앱

TUN이 켜지면 대부분의 TCP·UDP 세션이 규칙 엔진을 거칩니다. 그럼에도 일부 Electron 앱은 자체 인증서 저장소를 쓰거나 로컬 루프백을 우회하려 하므로, 이상 징후가 있으면 해당 앱만 DIRECT 규칙으로 빼는 식의 예외를 둡니다. Wayland·X11과 무관하게 동작한다는 점이 서버형 워크플로에 유리합니다.

프록시 환경 변수(http_proxy 등)를 쉘 프로필에 넣는 방식은 TUN과 병행할 수 있지만, 이중 경로로 혼동이 생기기 쉽습니다. 통일된 정책을 원하면 TUN + Rule만으로 끝내고, 환경 변수는 비우거나 주석 처리한 상태에서 테스트해 보세요. 개발 도구 중 npm·pip·git만 예외적으로 미러를 쓰고 싶다면 규칙에서 도메인 단위로 분기하는 편이 장기적으로 깔끔합니다.

기본 분할: 국내 직결·해외 프록시

geosite·GEOIP 기반 규칙 세트를 쓰면 “국내 사이트는 DIRECT, 나머지는 선택 그룹” 같은 패턴을 빠르게 구성할 수 있습니다. Rule Provider URL을 쓸 경우 주기적 업데이트와 실패 시 동작을 설정 파일에 명시해 두세요. 세트가 커질수록 메모리 사용량이 늘므로, 경량 서버에서는 최소 규칙부터 시작해 점진적으로 확장하는 것이 좋습니다.

세트 선택과 커스터마이징 전략은 ACL4SSR과 Loyalsoldier 비교 글과 연결해 읽으면 유지 보수 관점에서 도움이 됩니다. Linux에서도 규칙 파일의 문법은 동일하므로, 다른 플랫폼에서 검증된 프로필을 그대로 가져올 수 있습니다.

트러블슈팅 점검 순서

1. TUN이 안 생김: 권한·모듈·보안 프로필을 확인하고, 다른 VPN을 끈 뒤 재시도합니다.
2. 인터넷 전체 단절: 라우팅 테이블·기본 게이트웨이·auto-route 설정을 점검하고, 임시로 TUN을 끄고 복구합니다.
3. DNS만 실패: FakeIP·로컬 DNS 리스너·systemd-resolved 충돌 여부를 순서대로 확인합니다.
4. 느리거나 불안정: 노드 그룹·프로토콜·MTU를 바꾸고, 로그에 재전송·타임아웃 패턴이 없는지 봅니다.

한 가지 변수만 바꾼 뒤 다시 측정하는 습관이 가장 빠릅니다. 프로필 전체를 동시에 손대면 어느 층에서 깨졌는지 찾기 어렵습니다.

문서 허브와 함께 보기

전체 설정 항목의 지도를 보고 싶다면 문서·설정 허브의 링크를 참고하세요. 코어만 쓰는 구성에서도 개념(모드, 그룹, Rule Provider)은 GUI 클라이언트와 동일합니다.

정리

Linux에서 Mihomo를 “쓸 만한” 상태로 만들려면 재현 가능한 경로에 바이너리와 프로필을 고정하고, TUN으로 트래픽을 한 코어에 모은 뒤, systemd로 생명주기를 관리하는 세 단계가 축입니다. 여기에 DNS와 분할 규칙만 일관되게 맞추면 브라우저와 터미널이 서로 다른 우회 경로를 타는 문제를 크게 줄일 수 있습니다. Windows·macOS용 GUI에 익숙한 사용자라도, 서버나 CLI 중심 환경에서는 이 패턴이 유지 보수 비용을 가장 낮춥니다.

다른 도구 여러 개를 겹치기보다 한 코어와 한 프로필에 규칙을 모아 로그로 행동을 확인하는 편이 장기적으로 안정적입니다. Meta 계열은 그런 운영 방식과 잘 맞습니다.

→ Clash를 무료로 내려받고, Linux를 포함한 각 플랫폼에서 매끄러운 프록시 경험을 시작해 보세요