어떤 독자를 위한 글인가

클라우드 VPS나 사내 배스천처럼 그래픽 데스크톱이 없는 리눅스에 SSH만으로 접속해, Clash Meta(일명 Mihomo) 코어를 24시간 데몬처럼 돌리고 싶은 경우를 가정합니다. 검색 의도는 대개 「Clash Meta Linux」,「systemd 자동 시작」,「헤드리스 프록시」,「Mihomo 서버 배포」처럼 묶입니다. Windows 11·macOS·Android용 그래픽 클라이언트 가이드와 달리, 이 문서는 무GUI 서버에서의 운영 절차—바이너리 배치, 설정 파일 위치, systemd 유닛, journalctl 로그, 재시작 정책—에 초점을 둡니다.

로컬 PC에서 규칙·DNS를 다루는 흐름은 Fake-IP·DNS 가이드와 맞물리지만, 서버에서는 우선 「코어가 죽지 않고 뜨는가」「재부팅 후에도 같은 경로로 올라오는가」「로그를 어디서 읽는가」가 먼저입니다. 아래 순서는 배포판 차이를 줄이기 위해 단일 정적 바이너리 + 전용 홈 디렉터리 패턴을 권장합니다.

디렉터리와 권한 설계

패키지 매니저에 의존하지 않고, /opt/mihomo 또는 /etc/mihomo 아래에 실행 파일·런타임 데이터·구독 캐시를 모으면 백업과 업그레이드가 단순해집니다. 예시로 전용 사용자 clashmeta를 만들고 홈을 /var/lib/mihomo로 두는 구성을 설명합니다. 실제 경로는 조직 표준에 맞춰 바꿉니다.

# Create a dedicated system user (no login shell).
sudo useradd --system --home /var/lib/mihomo --shell /usr/sbin/nologin clashmeta || true
sudo mkdir -p /opt/mihomo /var/lib/mihomo
sudo chown -R clashmeta:clashmeta /opt/mihomo /var/lib/mihomo

실행 파일 이름은 릴리스에 따라 mihomo 또는 clash-meta로 다를 수 있으니, 다운로드한 아카이브의 실제 바이너리 이름을 확인합니다. 업스트림 릴리스 페이지에서 아키텍처에 맞는 압축 파일을 고른 뒤, 검증용 체크섬이 제공되면 함께 대조하는 습관이 좋습니다. 버전 갱신 절차는 Clash Meta 업그레이드 가이드의 사고 방지 팁과 조합하면 안전합니다.

바이너리 배치와 최소 실행 테스트

바이너리를 /opt/mihomo/mihomo에 두고 실행 비트를 부여합니다. 설정 파일은 /etc/mihomo/config.yaml처럼 읽기 전용 트리에 두고, 런타임이 쓰는 GeoSite 캐시·DB 파일은 /var/lib/mihomo로 보내는 편이 권한 분리에 유리합니다. config.yaml 안의 external-ui 경로를 쓰지 않는다면 웹 자산은 생략해도 됩니다.

# Place binary then smoke-test as the service user.
sudo install -o clashmeta -g clashmeta -m 0755 ./mihomo /opt/mihomo/mihomo
sudo -u clashmeta /opt/mihomo/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml -t

-t는 설정 검증 모드로, 문법 오류를 조기에 잡습니다. 통과했다면 동일 인자로 포그라운드 실행을 잠시 걸어 포트 리슨과 규칙 로딩을 눈으로 확인한 뒤, 다음 절차의 systemd 유닛으로 넘어갑니다. 구독 URL을 아직 넣지 않았다면 구독 가져오기 가이드에서 프로필을 정리한 뒤 이어가면 재시도 비용이 줄어듭니다.

systemd 유닛 작성

서비스 파일은 /etc/systemd/system/mihomo.service에 둡니다. 핵심은 User·Group 고정, WorkingDirectory, ExecStart 인자, 그리고 실패 시 재시작 정책입니다. Restart=on-failure는 비정상 종료에 반응하고, Restart=always는 의도적 중지와의 구분이 필요하니 운영 정책에 맞게 고릅니다. 아래는 on-failure를 기본으로 한 예시입니다.

# /etc/systemd/system/mihomo.service
[Unit]
Description=Mihomo (Clash Meta) proxy core
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=clashmeta
Group=clashmeta
WorkingDirectory=/var/lib/mihomo
ExecStart=/opt/mihomo/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=3
LimitNOFILE=1048576
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

AmbientCapabilities는 1024 미만 포트에 바인딩해야 할 때만 필요합니다. 사용하지 않으면 줄 전체를 삭제합니다. TUN 모드처럼 커널 모듈·특권이 더 필요한 구성은 배포판·커널 옵션에 따라 달라지므로, 본문에서는 HTTP·SOCKS 인바운드 위주의 전형적인 헤드리스 프록시 전제를 둡니다. TUN을 서버에 직접 얹는 경우에는 별도의 네트워크 설계 검토가 선행되어야 합니다.

ℹ️
참고: external-controller를 켤 때는 127.0.0.1에만 바인딩하고, 원격에서 REST API가 필요하면 SSH 터널이나 리버스 프록시로 앞단 인증을 두는 편이 안전합니다. 불특정 다수에게 열어 두면 구독·노드 정보가 그대로 노출될 수 있습니다.

등록·기동·부팅 자동 시작

유닛을 저장한 뒤 데몬 리로드와 즉시 기동, 그리고 부팅 시 자동 시작을 한 번에 적용합니다.

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

status 출력에서 active (running)이 보이면 1차 성공입니다. 이후 sudo reboot으로 실제 부팅 자동 시작을 검증합니다. 클라우드 이미지는 첫 부팅에 네트워크 준비가 늦는 경우가 있어, After=network-online.target을 두면 레이스가 줄어듭니다. 여전히 간헐 실패한다면 유닛에 ExecStartPre=/bin/sleep 2 같은 완충을 잠시 넣어 원인을 분리할 수 있습니다.

journalctl로 로그 읽기

데스크톱 클라이언트의 GUI 로그 대신, 서버에서는 systemd 저널이 1차 관측 창구입니다. 최근 200줄을 보려면 다음과 같습니다.

sudo journalctl -u mihomo.service -n 200 --no-pager
sudo journalctl -u mihomo.service -f

코어 자체의 파일 로그를 config.yaml의 log-level과 경로 지시로 나누어 쓰고 싶다면, 로그 디렉터리만 /var/lib/mihomo/logs처럼 고정해 로테이션 정책(logrotate 또는 내장 옵션)을 추가합니다. 장애 대응 시에는 저널 타임스탬프와 코어 로그의 트랜잭션 ID를 맞춰 적어 두면 재현이 빨라집니다.

방화벽과 인바운드

다른 서버나 컨테이너가 이 VPS의 mixed-port를 업스트림 프록시로 쓰려면, 퍼블릭 인터페이스에 포트가 열려 있는지와 ufw·firewalld·클라우드 보안 그룹이 일치하는지 확인합니다. 사설망 전용이라면 보안 그룹에서 소스 IP 대역을 제한하는 것이 기본입니다. 리눅스 서버 운영에서 가장 흔한 실수는 「코어는 떴는데 방화벽만 막아 클라이언트가 타임아웃」인 경우입니다.

업그레이드·롤백 습관

바이너리 교체 전에 systemctl stop mihomo로 유닛을 내리고, 이전 바이너리를 mihomo.bak으로 보관합니다. 새 파일을 올린 뒤 -t 검증과 짧은 포그라운드 실행을 거쳐 문제가 없으면 다시 start합니다. 자동화하려면 Ansible 등으로 동일 절차를 스크립트화하되, 구독 URL·시크릿은 비밀 저장소에서만 주입합니다.

데스크톱 클라이언트와 무엇이 다른가

GUI 클라이언트는 시스템 프록시 토글·트레이 아이콘·원클릭 업데이트를 제공하지만, 헤드리스 배포에서는 운영자가 직접 systemctl·journalctl·구성 파일 편집을 갖습니다. 대신 동일한 Clash Meta 규칙 문법을 그대로 쓸 수 있어, 로컬에서 검증한 config.yaml을 서버로 옮기는 워크플로가 단순합니다. 문법·기능 차이를 줄이려면 코어 버전을 로컬 테스트 환경과 맞추는 것이 좋습니다.

운영 체크리스트

  1. 전용 사용자·홈 디렉터리·설정 경로가 문서화돼 있는가.
  2. systemctl is-enabled mihomo가 enabled인가.
  3. 재부팅 후에도 자동 기동되는가.
  4. journalctl에 반복되는 오류 스택이 없는가.
  5. external-controller·인바운드 포트가 최소 권한으로 노출돼 있는가.
  6. 업그레이드 시 중지·검증·시작 순서가 문서에 고정돼 있는가.
⚠️
주의: 회사 네트워크나 클라우드 계약에 따라 프록시 계층을 추가하는 것이 금지될 수 있습니다. 정책을 확인한 뒤 허용된 범위에서만 구성하세요.

맺음말

Clash Meta Linux 헤드리스 배포의 핵심은, GUI가 아니라 systemd가 제공하는 가시성—상태, 재시작, 부팅 순서—을 최대한 활용하는 것입니다. Mihomo 서버로 고정 IP VPS를 프록시 허브로 쓰는 경우에도, 로그와 설정 경로를 팀원이 즉시 찾을 수 있게 정리해 두면 장애 대응 시간이 줄어듭니다. 규칙·DNS 튜닝은 로컬에서 먼저 검증하고 서버에는 안정판만 올리는 흐름이 가장 비용이 적습니다.

개인용 노트북·워크스테이션에서 그래픽 클라이언트를 쓰려면 패키지 형태와 자동 업데이트 채널이 중요합니다. 설치 파일은 릴리스 탭만 고집하기보다 Clash 공식 다운로드 페이지를 기준으로 삼는 편이 안전합니다. → Clash를 무료로 내려받아 로컬과 서버 구성을 나란히 맞춰 보세요.