왜 터미널만으로 쓸 때 systemd인가요?

nohup이나 screen으로도 백그라운드 실행은 가능하지만, 크래시 시 자동 재시작·부팅 후 자동 기동·표준 로그 수집까지 묶어 주는 쪽이 운영에 유리합니다. systemd는 대부분의 현대 배포판에 기본 포함되어 있고, 서비스 단위로 의존 관계(After=network-online.target 등)를 명시하기도 쉽습니다.

Clash 계열에서 서버에 많이 쓰는 구현체는 Meta 코어(공식 저장소명 mihomo)입니다. Windows·macOS용 GUI 글에서 다룬 것과 같이 최신 프로토콜과 규칙 기능을 유지하려면 Meta 빌드를 쓰는 편이 낫습니다. 개념 정리는 코어 업그레이드 가이드를 참고하면 됩니다.

역할 구분 본문은 «바이너리 + YAML + systemd»에 초점을 맞춥니다. 규칙·정책 그룹 설계는 YAML 규칙 분기 가이드와 함께 보시면 설정 파일을 다듬기 수월합니다.

디렉터리와 권한 준비

관습적으로 바이너리는 /usr/local/bin/mihomo처럼 PATH에 두거나, 업데이트를 쉽게 하려면 /opt/mihomo/mihomo 한 곳에 모아 둡니다. 설정은 /etc/mihomo/config.yaml 또는 전용 사용자 홈 아래 ~/.config/mihomo/config.yaml 등으로 통일해 두면 백업·버전 관리가 편합니다.

리슨 포트(mixed-port, port, tproxy 등)는 방화벽(ufw, firewalld, 클라우드 보안 그룹)과 겹치지 않게 미리 정합니다. 1024 미만 포트에 바인드하면 cap_net_bind_service나 root 실행 대신 포트 포워딩을 쓰는 편이 안전합니다.

바이너리 받기

아키텍처에 맞는 릴리스를 고릅니다. 예를 들어 x86_64 서버면 linux-amd64, ARM VPS면 linux-arm64입니다. 압축을 풀고 실행 비트를 줍니다.

# Example: install under /opt/mihomo (adjust paths to your layout)
sudo mkdir -p /opt/mihomo
sudo tar xzf mihomo-linux-amd64-*.gz -C /opt/mihomo
sudo chmod +x /opt/mihomo/mihomo

구성 검증만 하려면 한 번 대화형으로 실행해 봅니다. -d는 설정 디렉터리, -f는 설정 파일 경로입니다.

# Dry run: check config loads (stop with Ctrl+C after confirming)
sudo /opt/mihomo/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
보안 설정 파일에 구독 URL·토큰이 들어갑니다. chmod 600 등으로 다른 사용자 읽기를 막고, 공유 서버에서는 전용 계정으로만 서비스를 돌리세요.

systemd 유닛 작성하기

전용 사용자 mihomo를 만들고 홈·설정 소유권을 맡기면 root로 장시간 돌리는 것보다 낫습니다. 아래는 예시 유닛입니다. 배포판에 따라 User 생성·파일 경로만 바꿔 쓰면 됩니다.

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

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/opt/mihomo/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=3
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Restart=on-failure는 설정 오류로 즉시 종료될 때도 짧은 간격으로 재시도하므로, 배포 직후에는 journalctl을 열어 두고 YAML을 고치는 편이 좋습니다. 무한 재시작 루프가 싫다면 잠시 Restart=no로 두고 수동으로 systemctl start할 수도 있습니다.

등록과 자동 시작

  1. sudo systemctl daemon-reload로 유닛을 읽습니다.
  2. sudo systemctl enable --now mihomo.service로 지금 시작하고 부팅 시 자동 시작을 켭니다.
  3. systemctl status mihomo로 active (running)인지 확인합니다.

TUN 모드나 특정 capability가 필요하면 배포판 문서에 맞게 AmbientCapabilities·CapabilityBoundingSet을 추가합니다. 단순 HTTP/SOCKS 인바운드만 쓰면 위 최소 예시로도 충분한 경우가 많습니다.

로그 보는 법: journalctl과 설정 쪽

systemd로 띄우면 표준 출력·에러가 저널에 쌓입니다. 가장 먼저 쓰는 명령은 다음과 같습니다.

# Follow live logs for the service
sudo journalctl -u mihomo -f

# Last boot only, with priority
sudo journalctl -u mihomo -b --no-pager

YAML 파싱 오류·포트 점유·DNS 실패 등은 보통 여기에 한 줄 이상으로 남습니다. 시간대가 헷갈리면 journalctl 출력의 타임스탬프를 기준으로 재현해 보면 됩니다.

설정 파일 안의 로그 레벨

루트에 log-level(예: info, debug)를 두면 코어가 더 자세히 찍습니다. 장애 재현 단계에서만 debug로 올렸다가 평소에는 info 이하로 돌려 디스크·저널 부하를 줄입니다. 파일로 남기고 싶다면 Meta가 지원하는 로그 관련 키(버전별로 문서 확인)를 쓰되, 로테이션(logrotate)을 잊지 마세요.

외부 컨트롤러·API

원격에서 규칙을 바꾸려면 external-controller를 켜고 방화벽으로 접속을 제한합니다. 이 포트가 열려 있으면 인증 없이 노출되지 않았는지 반드시 확인하세요. 운영 편의와 공격 면적은 트레이드오프입니다.

자주 나는 증상과 점검 순서

아래는 헤드리스 환경에서 로그와 함께 자주 마주치는 패턴입니다. 위에서 아래로 좁히면 시간을 줄일 수 있습니다.

증상·메시지 가능한 원인 확인
서비스가 failed, 즉시 종료 YAML 문법 오류, 잘못된 경로 journalctl -u mihomo -e에서 에러 줄 확인, -d·-f 경로 재검토
bind: address already in use 포트 중복 ss -lntp로 점유 프로세스 확인, YAML 포트 변경
실행 파일 오류·Exec format error 아키텍처 불일치 uname -m와 릴리스 이름(amd64/arm64) 대조
노드는 살아 있는데 로컬 트래픽이 안 감 클라이언트가 프록시 주소를 안 씀 LAN의 다른 기기는 서버 IP:포트로 수동 설정, 방화벽 허용 확인
간헐적 끊김 OOM, 파일 디스크립터 한도 dmesg, LimitNOFILE 상향, 메모리 모니터링

문제가 mihomo 바깥(커널 모듈, nftables, Docker 네트워크)까지 확장되면 동일 호스트에서 다른 프록시나 방화벽 규칙과 충돌하는지 함께 봐야 합니다. 변경 후에는 systemctl restart mihomo로 설정을 다시 읽게 하는 것이 일반적입니다.

데스크톱 클라이언트와의 차이 PC용 앱은 트레이·자동 업데이트가 있지만 서버는 직접 바이너리를 갈아 끼우는 경우가 많습니다. 릴리스 노트를 보고 호환되는 YAML 키인지 확인한 뒤 재시작하세요.

마무리

GUI 없는 Linux에서 Clash Meta를 쓰는 핵심은 «한 번 띄우고 잊지 않기»입니다. systemd로 프로세스 생명주기를 맡기고, 문제가 생기면 저널 로그과 설정의 로그 레벨로 원인을 좁히면, Windows나 macOS 글에서 다룬 코어 이야기와도 맥락이 이어집니다. 반대로 규칙만 복잡하게 쌓아 두고 프록시 포트가 실제로 열려 있지 않으면 증상은 같아도 원인은 전혀 다를 수 있으니, 항상 status와 journalctl부터 확인하는 습관이 좋습니다.

PC나 모바일에서 패키지로 제공되는 클라이언트는 설치·업데이트가 단순한 편이라, 서버에서 고생한 설정을 로컬로 옮겨 비교 실험하기에도 유리합니다. 배포 방식은 다르지만 동일한 Meta 코어를 쓰면 동작 차이를 줄일 수 있습니다.

→ Clash 무료 다운로드 — Windows·macOS·Android 등에서 GUI로 구독과 규칙을 다루며, 서버에서 만든 YAML과도 맞춰 쓰기 좋습니다.

추가로 DNS·분기 설계를 다듬고 싶다면 기술 칼럼의 다른 튜토리얼을 이어서 읽어 보세요.