Linux Clash: CLI·TUN·systemd 투명 프록시 가이드

서버 운영자·백엔드 개발자·보안 연구자 등 CLI 환경을 매일 쓰는 Linux 사용자에게는 “브라우저만 프록시”로는 부족한 경우가 많습니다. Docker 데몬, apt, git, curl, 일부 GUI가 아닌 도구까지 동일한 규칙으로 묶으려면 TUN 기반 투명 프록시가 사실상 표준에 가깝습니다. Windows·macOS·모바일용 그래픽 클라이언트 가이드는 이미 정리되어 있지만, 베어메탈 Linux에서 Clash 계열 코어를 명령줄로 깔끔하게 올리는 방법은 여전히 검색 수요가 높고 문서 밀도는 낮은 편입니다.

이 글에서는 2026년 기준으로 커뮤니티에서 널리 쓰이는 Mihomo(구 Clash Meta) 단일 바이너리를 예로 들어, Ubuntu·Debian 계열에서 설치 → 설정 디렉터리 구성 → TUN 활성화 → systemd 자동 기동까지 한 흐름으로 설명합니다. 배포판마다 패키지 이름이 조금씩 다를 수 있으므로, 공통적으로 통하는 “공식/프리빌드 바이너리 + 설정 파일” 경로를 기준으로 잡았습니다. 규칙 문법을 더 깊게 다루고 싶다면 Clash 프록시 규칙 심층 분석 글과 함께 보시면 구성이 수월합니다.

1. 왜 Linux에서는 TUN이 중요한가

HTTP HTTP_PROXY 환경 변수만으로는 전부 커버되지 않습니다. Go·Rust 기반 CLI, 일부 게임 런처, 시스템 서비스는 프록시 환경 변수를 무시하거나 DNS를 먼저 직접 조회합니다. TUN 디바이스를 켜면 커널 라우팅 단계에서 트래픽이 Clash 쪽으로 들어오므로, 애플리케이션별 설정 없이 “전역에 가깝게” 규칙 기반 분기를 기대할 수 있습니다. 대신 커널 모듈·라우팅 테이블·DNS(fake-ip 등)와의 상호작용을 이해해야 하고, 권한(CAP_NET_ADMIN 등)도 맞춰야 합니다.

반대로 말하면, 서버 한 대에서 SSH만 쓰고 특정 포트만 터널링하면 되는 상황이라면 TUN 없이 SOCKS5·HTTP 포트만 열어도 충분할 수 있습니다. 본 가이드는 데스크톱·개발 워크스테이션·소프트 라우터에 가까운 “전역 트래픽 제어”가 목표인 경우에 최적화되어 있습니다.

2. 사전 준비: 아키텍처·권한·커널

먼저 CPU 아키텍처를 확인합니다. 대부분의 클라우드·PC는 amd64, 라즈베리파이·일부 ARM 서버는 arm64입니다.

uname -m

출력이 x86_64이면 amd64용, aarch64이면 arm64용 바이너리를 받으면 됩니다. TUN을 쓰려면 일반적으로 가상 네트워크 인터페이스를 올릴 수 있는 권한이 필요합니다. systemd 유닛에서 CapabilityBoundingSet과 AmbientCapabilities로 CAP_NET_ADMIN을 부여하거나, 테스트 단계에서는 루트로 실행하는 방식이 흔합니다. 보안상 최소 권한 원칙을 지키려면 전용 유저를 만들고 capability만 주는 쪽이 좋습니다.

일부 환경에서는 ip_forward가 꺼져 있으면 라우팅이 꼬일 수 있습니다. 필요 시 다음을 확인합니다(주석은 영문으로 유지).

# sysctl net.ipv4.ip_forward

방화벽(ufw, nftables, firewalld)이 활성화되어 있다면 TUN이 추가하는 인터페이스·포워딩 규칙과 충돌하지 않는지 배포판 문서를 함께 참고하세요.

3. Mihomo(Clash Meta) 바이너리 설치

패키지 매니저에 등록된 이름은 배포판마다 다릅니다. 재현성과 최신 프로토콜 지원을 우선한다면, 업스트림에서 제공하는 단일 정적 바이너리를 /usr/local/bin에 두는 방식이 가장 단순합니다. 예시로는 다음과 같은 흐름을 따릅니다(실제 다운로드 URL·파일명은 사용 중인 릴리스 페이지에 맞게 바꾸세요).

바이너리 받기: curl 또는 wget으로 아키텍처에 맞는 압축을 내려받습니다.
검증: 가능하면 체크섬·서명을 확인합니다. 팀 내부 미러를 쓴다면 버전 고정 정책을 문서화해 두는 것이 좋습니다.
설치 위치: sudo install -m 0755 mihomo /usr/local/bin/mihomo처럼 실행 비트를 부여합니다.
동작 확인: mihomo -v로 버전이 출력되는지 봅니다.

// TIP: 설정 디렉터리 통일 운영 편의를 위해 설정 루트를 /etc/mihomo 또는 ~/.config/mihomo 중 한 곳으로 고정해 두세요. 이 글의 systemd 예시는 /etc/mihomo를 가정합니다.

4. 설정 파일·구독·포트

최소한의 config.yaml에는 인바운드(HTTP/SOCKS·혹은 mixed), 아웃바운드(프록시 노드), 규칙, DNS 섹션이 들어갑니다. 구독 URL은 서비스 제공자가 준 Clash 형식 링크를 그대로 proxy-providers에 넣거나, 원본 리스트를 수동으로 파싱해 노드로 정의합니다. 이미 Clash Meta 최종 설정 가이드에서 전체 구조를 익혔다면 여기서는 Linux 경로만 맞추면 됩니다.

로컬 API 포트(예: 9090)와 시크릿을 열어두면 나중에 curl로 트래픽 모드 전환이나 로그 확인이 쉬워집니다. 다만 외부에 노출되지 않도록 127.0.0.1 바인딩과 방화벽을 함께 검토하세요.

5. TUN 투명 프록시 켜기

Mihomo에서 TUN은 설정 파일의 tun 블록으로 켭니다. 대표적인 옵션은 다음과 같은 형태입니다(필드 이름은 사용 중인 버전의 문서와 일치하는지 반드시 확인하세요).

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

stack을 system으로 두면 커널 스택을 활용하고, gvisor 계열을 쓰는 배포도 있습니다. auto-route가 켜지면 기본 게이트웨이 쪽으로 가던 트래픽이 TUN 인터페이스를 경유하도록 라우팅이 조정됩니다. DNS는 fake-ip와 맞물려 도메인 규칙 매칭이 안정적으로 동작하는 경우가 많습니다. 반면 잘못된 DNS 설정은 “사이트는 뜨는데 느리다” 또는 “일부 앱만 실패”로 이어지므로, dns 블록을 규칙 글에서 설명한 순서와 함께 점검하는 것이 좋습니다.

// WARNING: SSH 세션 끊김 원격 서버에서 라우팅을 실험할 때는 본인 세션의 SSH 연결이 끊길 수 있습니다. 콘솔·IPMI·별도 관리 경로를 확보한 뒤 진행하거나, 테스트 전에 iptables/nft 백업과 롤백 절차를 준비하세요.

서비스를 기동한 뒤 ip route, ip addr로 TUN 인터페이스가 올라왔는지, curl로 대상 사이트가 기대한 노드를 타는지 확인합니다. 문제가 나면 먼저 코어 로그 레벨을 올려 DNS·라우팅 메시지를 읽는 것이 빠릅니다.

6. systemd로 부팅 시 자동 실행

수동으로 mihomo -d /etc/mihomo를 실행하는 것은 재부팅마다 잊기 쉽습니다. systemd 유닛을 등록하면 부팅 후 자동 기동·재시작 정책을 한곳에서 관리할 수 있습니다. 아래는 개념 예시입니다(파일 경로·유저 이름은 환경에 맞게 수정).

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

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

[Install]
WantedBy=multi-user.target

유닛 파일을 /etc/systemd/system/mihomo.service에 저장한 뒤 sudo systemctl daemon-reload, sudo systemctl enable --now mihomo.service 순으로 활성화합니다. 상태는 systemctl status mihomo, 로그는 journalctl -u mihomo -f로 추적합니다. 전용 유저로 돌리려면 User=·Group=과 함께 데이터 디렉터리 권한을 맞추고, capability는 그 유저에 맞게 조정해야 합니다.

7. 자주 겪는 문제와 점검 순서

TUN을 켰는데 인터넷이 아예 안 된다면, 우선 유닛이 정상 기동했는지와 코어 로그에 라우팅 오류가 없는지 봅니다. 그다음 DNS가 루프에 빠지지 않았는지, 다른 VPN·컨테이너 네트워크와 충돌하지 않는지 확인합니다. 특정 사이트만 느리다면 규칙 모드가 Global로 고정돼 있지 않은지, 국내·CDN 도메인이 불필요하게 해외 노드를 타고 있지 않은지 점검합니다.

업데이트 후 바이너리만 갈았는데 동작이 이상하다면 설정 스키마 변경을 의심합니다. 릴리스 노트에서 tun·dns 필드 변경 여부를 확인하고, 필요하면 설정을 버전에 맞게 마이그레이션합니다. 팀 단위로 운영한다면 구성 파일을 Git으로 관리하고 태그별로 롤백할 수 있게 두는 것이 안전합니다.

8. 정리: CLI 위에서의 일관된 네트워크

Linux에서 Clash 계열을 쓰는 핵심은 “예쁜 UI”보다 재현 가능한 설치·가능한 한 최소 권한·명확한 실패 로그입니다. TUN과 systemd를 한 번 제대로 잡아 두면, 데스크톱 세션에 관계없이 동일한 네트워크 정책을 유지하기 쉽고, 서버·워크스테이션 모두에서 비슷한 스크립트로 배포할 수 있습니다. 그래픽 클라이언트가 필요한 macOS·Windows 환경은 각각 전용 튜토리얼을 참고하시고, 모바일은 Android 가이드와 연결해 이해하면 전체 그림이 맞춰집니다.

바이너리 설치·구독 구성·규칙 튜닝을 마쳤다면, 팀 표준으로 쓸 Clash Pro 같은 패키지도 검토해 볼 만합니다. 사전에 최적화된 규칙과 프로필이 포함되어 있으면 초기 트러블슈팅 시간을 크게 줄일 수 있습니다. 다른 플랫폼용 클라이언트는 다운로드 페이지에서 한 번에 확인할 수 있습니다.

→ Clash를 무료로 받고, Linux를 포함한 여러 환경에서 일관된 프록시 경험을 시작해 보세요