Ubuntu에 Clash Meta 설치·systemd 자동 기동: deb부터 부팅까지 (2026)

1. 왜 데스크톱·서버에서 코어 단독을 쓰나

Windows·macOS·Android에는 그래픽이 붙은 Clash 클라이언트가 많지만, Ubuntu에서는 백그라운드 데몬과 웹 UI·시스템 프록시만 연결하는 구성이 흔합니다. 특히 서버나 헤드리스 환경에서는 브라우저 확장 대신 코어 + systemd가 가장 단순한 운영 단위가 됩니다. Clash란 무엇인가에서 말하는 것처럼 규칙·DNS·아웃바운드는 모두 config.yaml 중심으로 움직이므로, 이 문서는 그 파일을 어디에 두고 어떤 사용자로 띄울지까지 포함합니다.

또한 Clash Meta는 기능 집합이 넓어서, 구독·규칙·TUN 등을 같은 코어로 처리할 수 있습니다. 이후 고급 라우팅 가이드에서 규칙 우선순위를 다룰 때도, 지금 만든 systemd 유닛은 그대로 재사용할 수 있습니다. 반대로 말하면, 유닛이 불안정하면 로그·재시작 정책부터 점검하는 것이 맞습니다.

2. 사전 준비: Ubuntu 버전·sudo·네트워크

권장은 지원 기간이 남은 LTS입니다. 배포판이 오래되면 glibc·libc 요구사항과 맞지 않는 바이너리가 있을 수 있습니다. 터미널에서 lsb_release -a로 버전을 확인하고, 커널·헤더가 TUN·iptables·nft와 맞는지도 나중에 한 번씩 봅니다. sudo 권한이 있는 계정으로 진행하며, 전용 시스템 사용자(예: mihomo)를 만들어 코어를 돌리는 방식이 권한 분리를 쉽게 합니다.

네트워크는 부팅 직후에도 이름 해석이 되는지가 중요합니다. systemd에서 After=network-online.target을 쓰면 대부분의 환경에서 순서가 맞지만, DNS만 늦게 올라오는 환경에서는 첫 기동이 실패했다가 재시작으로 복구되는 패턴이 나올 수 있습니다. 그래서 Restart=on-failure와 짧은 RestartSec을 함께 두는 편이 실무적으로 유리합니다.

3. deb 설치와 바이너리·버전 확인

Clash Meta 계열 코어는 종종 .deb 패키지로 릴리스됩니다. 파일을 받은 뒤에는 sudo apt install ./패키지명.deb 또는 sudo dpkg -i 패키지명.deb 후 의존성 오류가 나면 sudo apt -f install로 맞춥니다. 설치가 끝나면 which mihomo 또는 배포판이 넣은 경로(예: /usr/bin/mihomo)를 확인하고, mihomo -v로 버전을 확인합니다. 이름이 clash-meta인 경우도 있으니 패키지 설명을 함께 보는 것이 좋습니다.

오픈 소스 빌드 산출물과 라이선스는 상위 프로젝트 저장소에서 확인할 수 있습니다. 다만 설치 패키지로 받는 일반 사용자의 경로는 이 사이트의 다운로드 페이지를 우선 참고하는 것이 일관됩니다. GitHub 릴리스는 소스·변경 이력 확인용으로 두고, 본문의 deb 설치 예는 로컬에 받은 파일이 있다는 가정입니다.

4. 설정 디렉터리와 config.yaml

흔한 패턴은 /etc/mihomo 또는 홈 아래 ~/.config/mihomo입니다. 시스템 전역으로 서비스하려면 /etc 쪽에 두고, 특정 사용자만 쓰면 홈 기준으로 두는 식입니다. 디렉터리 소유자는 서비스를 실행할 사용자와 반드시 일치해야 하며, 여기에 config.yaml과 구독 캐시·DB 파일이 생깁니다. 구독 가져오기 설정을 이미 알고 있다면, 같은 URL을 이 파일에 넣어 갱신하면 됩니다.

최소한 mixed-port나 port, external-controller 등 외부에서 접근할 포트를 열어두면 웹 패널·REST로 상태를 확인하기 쉽습니다. 방화벽(ufw)을 쓰는 경우에는 해당 포트를 허용 목록에 넣거나, 로컬 전용이라면 127.0.0.1에만 바인딩하는 설정을 검토합니다. 설정 문법 오류는 기동 시 바로 실패하므로, 다음 단계에서 포그라운드 실행으로 한 번 검증합니다.

5. 수동 기동으로 동작 확인

systemd에 넣기 전에 터미널에서 sudo -u 전용사용자 mihomo -d /경로/설정폴더 형태로 띄워 봅니다. 정상적으로 리스닝 포트가 열리는지 ss -lntp로 확인하고, curl로 로컬 프록시를 경유해 테스트합니다. 오류 메시지가 YAML 파싱이면 config.yaml의 들여쓰기·따옴표를 먼저 고치고, 권한이면 디렉터리 소유자와 chmod를 확인합니다.

TUN 모드나 특정 capability가 필요한 빌드라면, 수동 실행에서도 같은 오류가 재현됩니다. 이 경우 setcap이나 별도 래퍼가 필요한지 배포 문서를 따릅니다. 데스크톱에서만 쓰고 시스템 프록시만 맞추는 경우에는 TUN 없이도 충분한 경우가 많습니다.

6. systemd 유닛 파일 작성

아래는 예시입니다. User·Group·ExecStart·WorkingDirectory는 환경에 맞게 바꿉니다. 파일은 /etc/systemd/system/mihomo.service에 두고, 코멘트는 영어로만 적습니다.

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

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/path/to/config
ExecStart=/usr/bin/mihomo -d /path/to/config
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

Restart=always를 쓰면 설정 실패로도 무한 재시작되는 경우가 있어, on-failure가 무난 편입니다. 필요하면 Environment=으로 추가 환경 변수를 넣고, 여러 인스턴스를 띄울 때는 유닛 이름과 포트를 분리합니다.

7. enable·부팅 자동 시작·재시작 정책

유닛을 저장한 뒤 sudo systemctl daemon-reload를 실행하고, sudo systemctl enable --now mihomo.service로 지금 시작 + 부팅 시 자동 실행을 동시에 걸 수 있습니다. 상태는 systemctl status mihomo로 보고, 재부팅 후에도 active (running)인지 확인합니다. 실패 시 systemctl status의 최근 로그 한 줄이 원인 분류에 큰 도움이 됩니다.

크래시 후 재시작은 위 예시의 Restart=on-failure와 RestartSec 조합이 담당합니다. OOM이나 시그널로 죽었을 때도 정책에 따라 다시 올라오므로, 장애가 반복되면 정책 그룹·노드 쪽과 분리해 원인을 봅니다. 코어 문제인지 네트워크·DNS 문제인지 로그로 나누는 습관이 중요합니다.

8. journalctl 로그와 흔한 문제

서비스 로그는 journalctl -u mihomo.service -e로 따라가면 됩니다. 실시간으로 보려면 -f를 붙입니다. 흔한 원인은 설정 경로 오타, 디렉터리 권한, 포트 충돌, DNS 루프입니다. 포트가 이미 다른 프로세스에 잡혀 있으면 ss -lntp로 PID를 찾고, 필요하면 설정에서 포트를 바꿉니다.

TUN을 쓰는 경우 CAP_NET_ADMIN 등이 필요할 수 있어, 배포본이 권장하는 방식을 따릅니다. 방화벽이나 Docker와 함께 쓸 때는 FORWARD·iptables/nft 규칙이 충돌하지 않는지도 점검합니다. 문제가 재현 가능한 한 줄 오류로 좁혀지면 그때부터는 설정 파일의 특정 섹션을 의심하면 됩니다.

9. 데스크톱·서비스 프록시 연동 메모

GNOME 등에서는 시스템 프록시에 127.0.0.1:포트를 넣거나, 환경 변수 http_proxy·https_proxy를 셸 프로필에 설정합니다. 브라우저만 별도로 쓰려면 확장 프록시 또는 PAC를 쓰고, 터미널 도구는 앞의 환경 변수가 잡히는지 확인합니다. 서버에서는 특정 데몬만 프록시를 타게 하려면 서비스 유닛에 Environment를 넣는 방식이 깔끔합니다.

반대로 모든 트래픽을 TUN으로 보내는 구성은 데스크톱에서 편하지만, 충돌이나 스플릿이 필요하면 규칙·라우팅을 더 세밀하게 써야 합니다. 이 글의 범위는 코어 기동·systemd까지이며, 라우팅 세부는 프로젝트 문서와 위의 규칙 가이드를 이어가면 됩니다.

10. 권한·업데이트·보안 습관

external-controller에 비밀번호를 두고, 외부에 노출하지 않습니다. 구독 URL·노드 정보가 들어 있는 파일은 백업 권한도 제한하고, 공유 PC에서는 디렉터리 암호화나 별도 계정을 고려합니다. 코어는 릴리스가 나올 때마다 변경 로그를 보고, deb를 다시 설치하거나 바이너리만 교체하는 방식으로 올립니다. systemd 유닛은 그대로 두고 systemctl restart mihomo만 하면 됩니다.

마지막으로, 자동 기동·재시작은 가용성을 높이지만 잘못된 설정을 숨기지는 않습니다. 장애가 반복되면 journalctl과 코어 로그를 먼저 확보하고, 규칙·DNS·노드 순으로 좁히는 것이 좋습니다. 이렇게 정리해 두면 Ubuntu·Clash Meta·systemd 조합이 재현 가능한 운영 절차로 남습니다.