Ubuntu 22.04에서 Clash(Mihomo) 설치와
systemd 상주·부팅 자동 실행·재시작

1. 왜 Linux에서는 systemd로 Clash를 감싸는가

Clash Linux 환경에서 사용자 세션에만 프로세스를 띄우면 SSH 세션이 끊기거나 데스크톱을 로그아웃할 때 함께 내려갑니다. 서버나 24시간 상주가 필요한 워크스테이션에서는 systemd 사용자 유닛보다 시스템 유닛(/etc/systemd/system/)으로 두는 편이 재부팅 후에도 동일하게 복구됩니다. 또한 Restart=on-failure나 Restart=always를 조합하면 코어가 OOM·네트워크 흔들림으로 죽었을 때 자동으로 다시 올릴 수 있어, “밤새 두었는데 아침에만 꺼져 있다”는 상황을 줄입니다.

Mihomo는 Clash Meta 계열 코어로, 구독·규칙·DNS·TUN 등 최신 기능을 한 실행 파일에서 다룹니다. 배포판별 패키지 이름이 제각각이므로, 본문은 공식 사이트에서 내려받은 Linux용 아티팩트를 고정 경로에 두고 실행하는 흐름을 기준으로 합니다. GUI가 필요하면 동일한 코어를 바라보는 데스크톱 앱을 별도로 쓰면 되고, Android용 Clash Meta 글에서 다룬 구독·규칙 개념과도 이어집니다. 전역 개념은 설정 문서와 함께 보시면 좋습니다.

2. 전제·준비물(Ubuntu 22.04)

예시는 Ubuntu 22.04 LTS(Jammy)의 최소 설치 또는 서버 이미지를 가정합니다. sudo 권한이 있어야 하며, 방화벽으로 ufw를 쓰는 경우 나중에 혼합 포트(HTTP/SOCKS)와 외부 컨트롤러 포트를 허용 목록에 넣어야 합니다. 커널이 오래된 환경에서는 TUN·iptables·nft 관련 모듈이 다를 수 있으므로, 본문은 “프록시 포트만 로컬에서 검증”하는 단계까지를 우선순위로 둡니다.

필요 패키지는 배포판에 따라 다르지만, 바이너리 실행·권한 조정·편집을 위해 curl 또는 wget, vim/nano 정도면 충분합니다. SELinux는 Ubuntu 기본이 아니므로 여기서는 다루지 않으며, 엔터프라이즈 정책이 있는 경우 보안팀 가이드를 따르세요.

3. 디렉터리·바이너리·전용 사용자

관례적으로 /opt/mihomo 또는 /usr/local/bin에 실행 파일을 두고, 설정은 /etc/mihomo 아래에 config.yaml·GeoSite.dat 등을 모읍니다. root로 장시간 돌리기보다 전용 시스템 사용자(예: mihomo)를 만들고 홈이 아닌 설정 디렉터리만 읽기·쓰기 가능하게 두면 권한 범위를 줄일 수 있습니다.

사용자·디렉터리 예시

아래는 개념 예시이며, 실제 그룹 ID·경로는 환경에 맞게 조정합니다. 바이너리 파일명은 릴리스에 따라 mihomo 또는 clash-meta 등으로 달라질 수 있습니다.

sudo useradd --system --home /var/lib/mihomo --shell /usr/sbin/nologin mihomo
sudo mkdir -p /etc/mihomo /var/lib/mihomo
sudo chown -R mihomo:mihomo /etc/mihomo /var/lib/mihomo
sudo install -m 0755 /path/to/mihomo /usr/local/bin/mihomo

설치 단계에서 바이너리를 어디서 받을지는 조직 정책에 따릅니다. 일상적인 클라이언트 설치 패키지는 공식 다운로드 페이지를 우선 참고하고, Linux 헤드리스용 코어는 릴리스 페이지에서 아키텍처에 맞는 파일을 고르는 방식이 일반적입니다. 오픈 소스 저장소는 라이선스·빌드 확인용으로 두고, 운영 서버의 실행 파일 출처는 항상 기록해 두세요.

4. 최소 config.yaml 잡기

동작 확인을 위해 mixed-port(HTTP·SOCKS 공통)와 external-controller(REST API)만 명확히 두는 것이 좋습니다. secret을 비워 두면 누구나 API를 호출할 수 있으므로, 로컬 루프백에서만 쓰거나 반드시 문자열 시크릿을 넣으세요. DNS·규칙·프록시 그룹은 기존 프로필을 그대로 가져오되, 포트 충돌이 없는지 ss -tulpn으로 먼저 확인합니다.

# /etc/mihomo/config.yaml — example skeleton (adjust to your profile)
mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "change-me"
log-level: info

실제 운영에서는 구독 URL·rule-providers·DNS 등이 훨씬 길어집니다. YAML 들여쓰기가 한 칸이라도 어긋나면 코어가 기동에 실패하므로, 편집 후에는 가능하면 mihomo -t -d /etc/mihomo 형태의 테스트 모드(지원하는 경우)나 직접 한 번 실행해 오류 메시지를 확인합니다.

5. systemd 유닛 파일 작성

/etc/systemd/system/mihomo.service에 유닛을 만듭니다. User·Group을 앞에서 만든 계정으로 맞추고, ExecStart에 설정 디렉터리 인자(-d 또는 해당 바이너리의 관례)를 넣습니다. 재시작 정책은 Restart=on-failure로 두고 짧은 RestartSec를 주면 일시적 오류에 강해집니다. 부팅 순서상 네트워크가 올라온 뒤에 뜨게 하려면 After=network-online.target을 함께 쓰는 경우가 많습니다.

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

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

LimitNOFILE은 동시 연결이 많은 경우에 유용합니다. Capability가 필요한 TUN 모드 등을 쓰면 AmbientCapabilities나 별도 권한 설정이 추가될 수 있으니, 해당 기능을 켤 때 공식 문서의 Linux 섹션을 확인하세요.

6. daemon-reload·enable·start

유닛을 저장한 뒤에는 반드시 데몬 리로드를 한 번 수행합니다. 그다음 부팅 시 자동 시작을 원하면 enable, 지금 즉시 띄우려면 start를 씁니다. 상태는 systemctl status mihomo로 확인하고, Active: active (running)이면 정상입니다. 실패 시 같은 출력에 exit code와 최근 로그 힌트가 붙습니다.

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

설정을 고친 뒤에는 sudo systemctl restart mihomo로 재시작합니다. 무중단이 꼭 필요하면 API로 리로드하는 방법을 쓰는 빌드도 있으나, 초기 구축 단계에서는 재시작으로 충분한 경우가 많습니다.

7. 포트·외부 컨트롤러 검증

설치가 끝났다면 리스닝 포트부터 확인합니다. ss -tulpn | grep mihomo 또는 lsof -i -P -n | grep mihomo로 mixed-port와 API가 기대한 주소에 붙었는지 봅니다. 로컬에서 curl -s http://127.0.0.1:9090/version처럼(포트·경로는 설정에 맞게) 버전 정보가 오면 API가 살아 있는 것입니다. 브라우저 대신 curl을 쓰면 스크립트에 넣기도 쉽습니다.

같은 머신의 브라우저나 다른 앱에 HTTP 프록시로 127.0.0.1:7890(예시)을 지정해 접속을 시험해 보세요. 안 되면 방화벽보다 먼저 코어 로그에 규칙 매칭·DNS 오류가 없는지 보는 것이 빠릅니다. Clash 계열은 로그에 어떤 정책에 걸렸는지 남기는 경우가 많아, “포트는 열렸는데 트래픽만 안 간다”는 상황을 분리하기 좋습니다.

8. 권한·방화벽·파일 소유권

/etc/mihomo 안의 구독 URL·토큰이 들어 있는 파일은 전용 사용자만 읽을 수 있게 퍼미션을 제한하세요. 웹 서버나 다른 데몬과 사용자를 공유하면 설정이 노출될 수 있습니다. ufw를 사용 중이라면 기본 정책이 deny incoming인지 확인하고, LAN에 프록시 포트를 열어야 한다면 최소 대역만 허용합니다.

컨테이너 안에서 동일 구성을 돌릴 때는 호스트의 systemd가 아니라 컨테이너 오케스트레이터의 재시작 정책을 쓰게 됩니다. 개념은 같습니다. “프로세스가 죽으면 다시 올린다”는 운영 요구는 플랫폼만 다를 뿐입니다.

9. journalctl로 로그 보기

systemd로 관리하면 표준 출력·에러가 저널에 남습니다. journalctl -u mihomo -e로 따라가거나, journalctl -u mihomo --since "10 min ago"로 범위를 좁힐 수 있습니다. 코어 자체 로그 파일 경로를 config.yaml에 지정했다면 그 파일과 저널을 함께 보면 타임라인이 맞습니다.

업데이트 직후 갑자기 기동 실패하면 바이너리·GLIBC 버전 불일치, 잘못된 아키텍처 다운로드, YAML 문법 오류가 흔한 원인입니다. 메시지에 permission denied가 보이면 소유권·ReadWritePaths·AppArmor 프로필(배포판에 따라)을 의심합니다.

10. 증상별 빠른 점검 표

아래는 Clash Linux·Ubuntu 22.04·systemd 조합에서 자주 보는 패턴입니다. 실제 키워드·포트는 프로필에 맞게 바꾸면 됩니다.

GUI가 있는 다른 OS와 병행할 때는 동일 Mihomo 규칙을 쓰더라도 경로·포트만 통일하면 혼선이 줄어듭니다. Windows TUN·라우팅 글은 트래픽 경로가 OS마다 다르다는 점을 상기시켜 줍니다.

11. 요약

Ubuntu 22.04에서 Clash Linux 스택을 쓸 때는 코어 바이너리·config.yaml·전용 사용자·systemd 유닛을 한 세트로 보는 것이 수월합니다. 부팅 자동 실행은 enable, 비정상 종료 대응은 Restart= 계열로, 검증은 포트·API·저널 로그로 나누면 현장 대응이 빨라집니다. 규칙 기반 프록시는 로그만 확보되면 원인 추적이 비교적 명확해, 상시 가동 서버에도 잘 맞습니다.

데스크톱에서 그래픽 클라이언트를 쓰는 경우에도 동일한 설치·업데이트 습관을 유지하려면 공식 다운로드 페이지를 북마크해 두는 편이 안전합니다. 소스 코드와 이슈 트래커는 신뢰·기여 목적으로 참고하고, 일상적인 패키지 수령 경로는 사이트 정책에 맞추는 것이 혼선이 적습니다.

오픈 소스 생태계에서 빌드 산출물이 여러 갈래로 퍼져 있어, 팀 단위로는 “어떤 채널을 표준으로 할지”만 정해도 운영 비용이 크게 줄어듭니다. systemd 한 벌로 Mihomo를 감싸 두면 SSH만 있는 서버에서도 명령줄 기준으로 동일한 절차를 문서화하기 좋습니다.

→ Clash를 무료로 다운로드하고, 데스크톱·모바일과 함께 쓸 수 있는 최신 클라이언트로 흐름을 맞춰 보세요