왜 Ubuntu와 systemd인가

Clash Linux 환경에서 많은 사람이 GUI 클라이언트 대신 mihomo(예전 이름 Clash Meta)나 유사한 헤드리스(headless) 코어를 직접 돌립니다. 서버에는 화면이 없고, 데스크톱이라도 백그라운드에서 항상 같은 포트를 열어 두고 싶을 때가 많기 때문입니다. Ubuntu는 패키지와 문서 예제가 풍부하고, systemd로 부팅 자동 시작과 프로세스 재시작 정책을 표준 방식으로 걸 수 있습니다.

이 튜토리얼은 “법적으로 허용된 네트워크 범위 안에서” 사설망 테스트·원격 개발·개인 학습 목적의 프록시를 쓰는 독자를 가정합니다. 직장이나 학교 장비의 보안 정책을 위반하지 않는 범위에서만 적용하세요.

준비: 버전 확인과 기본 개념

먼저 아키텍처가 맞는 바이너리를 골라야 합니다. 대부분의 최신 PC는 amd64, ARM 보드는 arm64에 해당합니다. 터미널에서 uname -m으로 확인할 수 있습니다. 방화벽(ufw 등)을 쓰고 있다면, 로컬 루프백(127.0.0.1)의 mixed 포트는 기본적으로 막지 않지만, 이후 TUN이나 transparency proxy를 켜면 정책을 다시 볼 필요가 있습니다. TUN 계열은 OS가 가상 인터페이스와 라우팅 테이블을 다루는 단계라 권한 이슈가 잘 붙습니다. 심화 내용은 TUN·DNS 가이드를 함께 읽으면 전체 그림이 맞습니다.

바이너리 배치와 실행 권한

공식 배포 정책에 맞는 경로에서 코어 바이너리를 내려받아 /usr/local/bin/mihomo처럼 PATH에 들어 있는 위치에 두는 방식이 관리하기 쉽습니다. 홈 디렉터리만 쓰고 싶다면 ~/bin/mihomo에 두고 로그인 셸의 PATH에 추가해도 됩니다. 퍼미션은 실행 가능하도록 chmod +x를 잊지 마세요.

이 문서는 실행 파일의 정확한 다운로드 URL을 적지 않습니다. 배포 페이지의 서명·체크섬을 확인한 뒤 신뢰할 수 있는 출처에서만 받으세요. 클라이언트 패키지를 한곳에서 받으려면 아래 정리 단계를 마친 후 사이트 다운로드 페이지와 병행하는 편이 안전합니다.

구성 디렉터리와 최소 config.yaml

일반적으로 사용자별 설정은 ~/.config/mihomo/config.yaml에 둡니다. 디렉터리가 없으면 만들고, 최소한 port나 mixed-port, mode, log-level, 그리고 프록시·프로바이더·규칙이 들어가는 뼈대가 필요합니다. 처음에는 구독이 들어 있는 원격 프로필 전체를 그대로 쓰기보다, 제공자가 준 구독 URL을 proxy-providers로 넣고 자동 갱신 주기를 잡는 패턴이 흔합니다.

구독 링크 형식·갱신 주기·Base64와 YAML 차이는 구독 관리 실전 가이드에서 다루는 내용과 직결됩니다. 코어가 기동될 때 원격 구독을 당겨 오지 못하면 빈 프록시 목록으로 시작하거나 바로 종료할 수 있으므로, 터미널에서 curl -I로 URL이 살아 있는지 먼저 확인해 보는 것이 좋습니다.

수동 실행으로 동작 검증

systemd에 넘기기 전에 터미널에서 한 번 띄워 보세요. 

mihomo -d ~/.config/mihomo

로그에 설정 파싱 오류가 없고, mixed 포트가 열리면 브라우저나 curl로 http://127.0.0.1:포트 환경변수를 지정해 테스트할 수 있습니다. 여기서 실패하면 유닛 파일만 바꿔도 해결되지 않으므로, YAML 들여쓰기·인코딩(UTF-8)·잘못된 rule 참조부터 고칩니다.

systemd 서비스 유닛 작성

시스템 전역으로 돌리려면 /etc/systemd/system/mihomo.service에 유닛을 만들고, 사용자 홈 아래 설정을 쓰는 경우 User=와 Group=을 명시해 소유권 혼선을 막습니다. 홈 디렉터리 경로는 틸드(~) 대신 절대 경로로 쓰는 것이 안전합니다. 

[Unit]
Description=mihomo Clash-compatible daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=여기에_리눅스_사용자명
Group=여기에_기본_그룹
ExecStart=/usr/local/bin/mihomo -d /home/여기에_리눅스_사용자명/.config/mihomo
Restart=on-failure
RestartSec=3
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

편집 후 sudo systemctl daemon-reload를 실행하고, sudo systemctl enable --now mihomo.service로 지금 기동 + 부팅 자동 시작을 동시에 걸 수 있습니다. 상태는 systemctl status mihomo, 로그는 journalctl -u mihomo -e로 봅니다.

user 단위로 돌리고 싶을 때

데스크톱 세션에서만 필요하다면 systemctl --user 영역에 같은 내용의 유닛을 두고 linger(loginctl enable-linger 사용자명)를 켜서 로그인 전에도 사용자 서비스가 살아 있게 할 수 있습니다. 서버 헤드리스 환경에서는 시스템 유닛이 단순한 경우가 많습니다.

권한: CAP, TUN, 바인딩 포트

1024 미만 포트에 바인딩하거나 TUN 디바이스를 만들려면 추가 권한이 필요할 수 있습니다. setcap cap_net_bind_service=+ep는 특정 바이너리에만 신중히 적용해야 하며, 보안 정책에 따라 아예 허용되지 않을 수도 있습니다. TUN 경로는 보통 root 또는 net_admin 관련 capability와 연관되므로, 코어 로그에 operation not permitted류가 보이면 이 절을 의심합니다.

애플리케이션 프록시만 쓰고 시스템 라우팅을 건드리지 않는 구성이라면 TUN 없이도 충분한 경우가 많습니다. 반대로 “모든 앱이 일관되게 탄다”가 목표면 TUN 쪽 설정을 공식 문서 예시에 맞춰 점검해야 합니다. 문서 허브의 키워드로 DNS·스택 옵션을 대조해 보세요.

구독 반영과 자동 갱신 흐름

systemd는 코어를 재시작해 줄 뿐, 구독 내용 자체는 YAML의 proxy-providers·rule-providers 설정과 코어의 스케줄에 따라 갱신됩니다. 주기가 너무 짧으면 제공자 측에서 차단될 수 있고, 너무 길면 노드 교체 후에도 느린 서버만 잡는 시간이 길어집니다. 실패가 반복되면 유닛이 짧은 간격으로 재시작하는 악순환이 생기지 않도록, 로그 레벨을 잠시 올려 원인 HTTP 코드를 확인하는 것이 좋습니다.

“설정은 됐는데 트래픽이 안 탄다” 점검

① 애플리케이션이 실제로 환경 변수 ALL_PROXY·HTTP_PROXY를 읽는지, ② 데스크톱 세션의 전역 프록시 설정과 충돌하지 않는지, ③ DNS가 코어 밖에서 직접 빠져 나가 Rule 매칭이 깨지지 않는지 순서로 봅니다. dig·resolvectl로 실제 질의 경로를 확인하면 “브라우저만 이상하다”는 증상을 빠르게 분리할 수 있습니다.

서버에서 아웃바운드만 프록시한다면 라우팅 테이블을 크게 바꿀 필요가 없지만, 게이트웨이 역할을 동시에 맡기면 IP 포워딩·iptables/nftables·정책 라우팅이 얽히기 쉬우므로 범위를 문서화해 두는 것이 안전합니다.

서비스 운영 시 습관

설정 파일과 구독 URL에는 접근 토큰이 섞여 있는 경우가 많습니다. 백업은 암호화된 매체에 두고, 불필요한 world-readable 권한을 피하세요. 유닛을 수정할 때마다 daemon-reload를 빠뜨리면 변경이 반영되지 않습니다. 업그레이드 후 바이너리를 교체했다면 한 번 수동 실행으로 ABI·권한 오류를 확인한 다음 서비스를 재시작합니다.

Clash·mihomo는 네트워크 제어 도구일 뿐이며, 불법적인 우회·제3자 서비스 약관 위반·기밀 침해 목적으로 사용해서는 안 됩니다.

정리

Ubuntu에서 Clash Linux 스택을 “매번 터미널을 열지 않고” 굴리려면, 검증된 수동 기동을 먼저 확보하고 systemd로 동일 인자를 고정하는 절차가 가장 덜 돌아갑니다. 구독 가져오기와 규칙은 YAML 한 곳에서 관리되고, 부팅 후에도 동일한 포트와 정책이 이어지므로 데스크톱·경량 서버 모두 일관된 경험을 만들 수 있습니다. 같은 구독을 다른 OS에서도 쓰는 사용자에게는 Windows·macOS·Android 튜토리얼과 짝을 이루어 두면 기기를 바꿔도 설정 습관을 유지하기 쉽습니다.

다른 헤드리스 도구들과 비교했을 때, Clash 계열은 규칙 기반 분기와 구독 중심 워크플로가 한 파일에 정리되는 경우가 많아 운영 부담이 상대적으로 낮은 편입니다. 초기에는 설정 표면적이 넓어 보일 수 있지만, 한 번 디렉터리 구조와 systemd 유닛을 잡아 두면 이후 변경은 대부분 YAML과 재시작 한 번으로 끝납니다.

→ Clash 공식 클라이언트 무료 다운로드 — 여러 플랫폼용 빌드를 한곳에서 받아 Ubuntu에서 구성한 흐름과 맞춰 보시면, 데스크톱과 모바일을 오갈 때도 같은 패턴을 유지하기 쉽습니다.