Arch Linux에 Clash Meta 설치: systemd 자동 기동과 mixed-port 첫 설정 (2026)

1. 롤링·AUR에서 달라지는 설치 감각

Arch 계열은 패키지가 최신에 가깝게 움직이고, 공식 저장소에 없는 소프트웨어는 AUR의 PKGBUILD를 사용자가 빌드해 설치하는 흐름이 일반적입니다. Clash Meta·mihomo도 배포 방식에 따라 패키지 이름·의존성·바이너리 경로가 바뀔 수 있으므로, 글 하나에 고정된 yay -S 패키지명만 외우기보다 AUR 페이지를 직접 확인하고 pacman -Ql로 실제 설치 경로를 찍는 습관이 안전합니다. Clash가 무엇인지 이미 정리되어 있다면, 여기서는 “코어를 어디에 두고 어떤 사용자로 띄울지”에 집중하면 됩니다.

데스크톱 사용자에게는 GUI 클라이언트를 쓰는 선택지도 있지만, 본문은 코어 + systemd 조합을 전제로 합니다. 서버·헤드리스·또는 규칙을 직접 파일로 관리하고 싶을 때 재현성이 좋고, 이후 라우팅·규칙 가이드로 확장하기도 쉽습니다. Manjaro는 기본적으로 Arch와 같은 생태계를 공유하지만, 미러·그래픽 설치기·배포 주기가 조금 다를 수 있어 버전만 한 번 확인하면 충분합니다.

2. 사전 준비: pacman·base-devel·네트워크

AUR 빌드를 직접 하려면 base-devel 메타 패키지와 서명 검증에 필요한 도구가 갖춰져 있어야 합니다. sudo pacman -S --needed base-devel git 정도를 기본값으로 두고, yay나 paru 같은 AUR 헬퍼는 공식 저장소가 아니므로 설치 방법은 프로젝트 문서를 따릅니다. 헬퍼를 쓰지 않을 경우 PKGBUILD를 받아 makepkg -si로 빌드하는 전통적인 방식도 동일하게 통합니다.

네트워크는 부팅 직후 DNS가 안정적인지가 systemd 자동 기동의 성패를 가릅니다. systemd-networkd·NetworkManager·iwd 중 무엇을 쓰든, 유닛의 After=를 네트워크 온라인 타깃에 맞추는 패턴은 Fedora·Ubuntu 글과 같습니다. 다만 Arch는 사용자가 최소 설치에서 시작하는 경우가 많아, 방화벽(nftables·ufw 등)을 별도로 올렸다면 로컬 루프백 프록시 포트가 막히지 않았는지도 함께 봅니다.

3. 설치: AUR·yay/paru와 수동 바이너리

AUR에서 mihomo·clash-meta 계열 패키지를 검색해 유지 상태가 괜찮은 PKGBUILD를 고릅니다. 헬퍼 사용 시에도 소스 URL·체크섬·라이선스를 한 번 훑는 것이 좋습니다. 빌드가 끝나면 which mihomo 또는 which clash-meta로 실제 실행 파일을 확인하고, mihomo -v로 버전을 출력해 봅니다. 패키지가 /usr/bin에 바이너리를 넣는지, 사용자 영역에 두는지는 PKGBUILD마다 다릅니다.

AUR을 쓰기 어렵거나 특정 버전을 고정하려면, 공식 릴리스에서 받은 바이너리를 /usr/local/bin 등에 두고 실행 권한만 주는 방법도 흔합니다. 이 경우 업데이트는 압축을 덮어쓴 뒤 서비스만 재시작하면 됩니다. 클라이언트 설치 패키지를 찾는 일반 사용자에게는 사이트의 다운로드 페이지를 먼저 보는 것이 다른 플랫폼과 안내가 일치합니다. GitHub는 소스·이슈·릴리스 노트 확인용으로 두고, 본문의 Arch 코어 설치는 로컬 정책에 맞는 경로를 택했다는 가정입니다.

4. config.yaml·mixed-port·구독 연결

데스크톱 단일 사용자라면 ~/.config/mihomo 또는 패키지가 안내하는 경로에 config.yaml을 두는 패턴이 많습니다. 시스템 전역 서비스로 띄울 때는 /etc/mihomo 등으로 옮기고 디렉터리 소유자를 서비스 사용자와 맞춥니다. mixed-port는 HTTP와 SOCKS를 한 포트에서 받는 설정으로, 브라우저·CLI 도구가 같은 주소(127.0.0.1와 포트 번호)를 바라보게 만들기 좋습니다. 최소 구성에서는 mixed-port, external-controller, secret(또는 동등한 인증), proxies·proxy-groups·rules 흐름을 갖춥니다.

구독 URL은 구독 가져오기에서 설명하는 것과 같이 proxy-providers나 노드 목록으로 넣습니다. Arch는 롤링이라 TLS·루트 인증서가 비교적 최신인 편이지만, 구독 서버의 인증서 체인 문제가 있으면 코어 로그에 명확히 남습니다. external-controller를 외부 인터페이스에 바인딩하지 말고, 관리 API에는 비밀번호·ACL을 반드시 걸어 두세요.

5. 수동 기동으로 리스닝·curl 검증

systemd에 넣기 전에 터미널에서 mihomo -d ~/.config/mihomo처럼 설정 디렉터리를 지정해 포그라운드로 실행해 봅니다. 정상이라면 ss -lntp에 mixed-port가 보이고, curl -x http://127.0.0.1:포트 https://example.com로 우회가 되는지 확인합니다. YAML 들여쓰기 오류나 권한 문제는 이 단계에서 바로 드러나므로, 로그 한 화면을 남겨 두면 이후 장애 대응이 빨라집니다.

TUN 모드나 특정 capability가 필요한 빌드라면 수동 실행에서도 같은 메시지가 재현됩니다. 데스크톱에서 시스템 프록시 + mixed-port만 쓸 계획이라면 TUN 없이도 많은 앱을 커버할 수 있습니다. 포트가 이미 점유 중이면 ss로 충돌 프로세스를 찾아 번호를 바꿉니다.

6. systemd 사용자 유닛과 linger

로그인한 데스크톱 사용자만 쓸 코어라면 사용자 유닛이 권한 분리에 유리합니다. 예시 유닛은 홈 경로와 바이너리 위치를 환경에 맞게 바꿉니다. 주석은 영어로만 적습니다.

# ~/.config/systemd/user/mihomo.service
[Unit]
Description=mihomo (Clash Meta) user service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/.config/mihomo
ExecStart=/usr/bin/mihomo -d %h/.config/mihomo
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576

[Install]
WantedBy=default.target

저장 후 systemctl --user daemon-reload, systemctl --user enable --now mihomo.service 순으로 활성화합니다. 로그인 전·무인 부팅 후에도 사용자 서비스를 올리려면 root가 loginctl enable-linger 사용자명을 실행해 linger를 켜야 합니다. 그렇지 않으면 세션이 없을 때 사용자 유닛이 멈추는 것이 정상 동작입니다.

Restart=always는 설정 오류로 인한 무한 재시작 루프를 만들 수 있어, 실무에서는 on-failure와 짧은 RestartSec 조합을 선호하는 경우가 많습니다. 여러 인스턴스를 띄울 때는 유닛 파일 이름과 설정 디렉터리·포트를 쌍으로 나눕니다.

7. 시스템 전역 유닛을 쓰는 경우

여러 사용자가 같은 호스트에서 공유하거나, 부팅 직후 시스템 레벨에서 코어를 띄워야 한다면 /etc/systemd/system/mihomo.service에 시스템 유닛을 두고 전용 시스템 사용자(User=·Group=)를 지정합니다. 설정 디렉터리 소유권을 그 사용자에게 맞추고, sudo systemctl enable --now mihomo.service로 걸면 됩니다. Ubuntu·Fedora 글의 예시와 구조는 동일하고, Arch에서 달라지는 점은 패키지가 놓는 바이너리 경로와 선택한 네트워크 스택뿐인 경우가 많습니다.

보안 측면에서 root로 코어를 실행하면 편해 보일 수 있지만, 설정 유출 시 피해 범위가 커집니다. 가능하면 전용 계정과 최소 권한을 유지하고, 관리 API와 구독 파일 접근을 제한하세요.

8. journalctl과 흔한 오류

사용자 유닛은 journalctl --user -u mihomo.service -e로, 시스템 유닛은 sudo journalctl -u mihomo.service -e로 추적합니다. 흔한 원인은 설정 경로 오타, 홈 디렉터리 권한, 포트 충돌, DNS 순환입니다. YAML 검증을 건너뛰지 말고, 첫 장애 시점의 로그 한 블록을 저장해 두면 원인 분기가 빨라집니다.

롤링 업데이트 직후 라이브러리 불일치로 바이너리가 깨진 경우도 드물지 않으므로, pacman -Syu 후 증상이 나오면 부분 업그레이드 여부를 확인합니다. TUN·netfilter를 쓰는 빌드는 capability 요구사항을 배포 문서와 맞춥니다.

9. 데스크톱·환경 변수 프록시

GNOME·KDE 등에서는 시스템 프록시 설정에 127.0.0.1과 mixed-port 번호를 넣습니다. 터미널 도구는 http_proxy·https_proxy 환경 변수로 같은 포트를 가리키게 할 수 있습니다. Wayland·Flatpak 앱은 전역 설정을 무시하는 경우가 있어, 앱별 프록시 옵션이나 래퍼를 추가로 봅니다.

서버에서 특정 데몬만 프록시를 타게 하려면 해당 서비스 유닛에 Environment=를 넣는 방식이 깔끔합니다. 본문 범위는 코어 기동·systemd·mixed-port까지이며, 세밀한 도메인 분기는 규칙 파일과 DNS 설정에서 이어가면 됩니다.

10. pacman 업데이트와 운영 습관

롤링 배포는 pacman -Syu로 주기적으로 전체를 올리는 것이 안전합니다. AUR 패키지는 헬퍼의 동기화 명령으로 재빌드하고, 수동 바이너리면 릴리스 노트를 보고 교체한 뒤 systemctl --user restart mihomo 또는 sudo systemctl restart mihomo만 수행하면 됩니다. 유닛 파일 자체는 자주 바꾸지 않아도 되고, 변경 시에만 daemon-reload를 잊지 않으면 됩니다.

자동 기동은 가용성을 높이지만 잘못된 규칙·노드를 숨기지는 않습니다. 장애가 반복되면 저널과 코어 로그를 먼저 확보하고, DNS·정책 그룹·업스트림 순으로 좁힙니다. 이렇게 정리해 두면 Arch·Manjaro에서도 Clash Meta·systemd·mixed-port 조합이 재현 가능한 운영 절차로 남습니다.