Arch Linux에서 Clash Verge 설치: AUR과 systemd --user로 첫 구독·자동 시작

① 왜 Arch에서는 Ubuntu·Fedora 튜토리얼을 그대로 쓰면 안 되나요?

Arch Linux는 패키지 세트가 매일 조금씩 움직이는 롤링 모델이라, 특정 LTS 버전 번호에 묶인 설명문과 잘 안 맞을 수 있습니다. 더 중요한 차이는 그래픽용 서드파티 클라이언트가 배포판 공식 저장소에 없을 때가 많다는 점입니다. Ubuntu에서는 .deb나 AppImage 안내가 흔하고, Fedora에서는 COPR·RPM 이야기가 나오지만, Arch에서는 커뮤니티가 관리하는 AUR(Arch User Repository)와 이를 설치해 주는 yay·paru 같은 AUR 헬퍼가 사실상의 표준에 가깝습니다.

그래서 검색 결과에서 sudo apt install이나 sudo dnf install만 보이면 그대로 따라 하기보다, “지금 내 배포판의 패키지 관리자는 무엇인가”를 먼저 확인하는 것이 안전합니다. Clash Verge 계열 이름도 저장소마다 clash-verge·clash-verge-bin·clash-verge-rev처럼 조금씩 다를 수 있으니, AUR 웹 페이지에서 최신 패키지 이름과 의존성 설명을 한 번 읽고 들어가는 습관이 좋습니다. 전체 생태계 맥락은 2026년 Clash 생태계 글과 함께 보면 레거시 앱과의 차이를 정리하기 쉽습니다.

② 준비: base-devel, AUR 헬퍼, 그리고 “빌드”에 대한 기대치

AUR의 많은 패키지는 미리 빌드된 바이너리가 아니라 PKGBUILD 스크립트를 받아 로컬에서 makepkg로 조립하는 형태입니다. 그래서 공식 위키에서 권장하듯 base-devel 메타 패키지(컴파일 도구 모음)가 갖춰져 있어야 합니다. 이미 yay나 paru를 쓰고 있다면 다음 단계로 넘어가고, 없다면 위키의 최신 안내에 따라 헬퍼를 설치합니다. 헬퍼마다 명령 스위치가 조금 다르지만, “검색 → PKGBUILD 확인 → 빌드·설치”라는 큰 줄기는 같습니다.

보안 측면에서는 AUR 패키지를 맹신하지 말고, 유지보수 상태·코멘트·소스 URL을 훑는 것이 기본입니다. Clash Verge는 그래픽 셸이므로 빌드가 실패하면 대개 의존 라이브러리 버전이나 Rust 체인 문제인데, 이때는 패키지 페이지의 최근 업데이트와 이슈를 먼저 확인합니다. 오픈소스 GitHub 저장소는 라이선스·버그 리포트를 보는 용도로 두고, 설치 패키지를 받는 주 경로는 배포판 커뮤니티 관행에 맞추는 편이 재현성이 높습니다. 동시에 클라이언트 설치 파일을 한곳에서 정리해 두려면 사이트의 다운로드 페이지를 함께 참고하는 것도 방법입니다.

③ AUR에서 Clash Verge 설치: 검색부터 첫 실행까지

터미널에서 헬퍼의 검색 명령으로 verge나 clash-verge를 찾아 후보 목록을 봅니다. 이름이 비슷한 패키지가 여러 개일 수 있으니, 설명에 “Rev”나 특정 코어 이름이 붙어 있는지 확인합니다. 선택한 뒤 빌드가 끝나면 데스크톱 메뉴에 등록되는지, 실행 파일이 /usr/bin 아래에 생겼는지, 아니면 /opt 계열에 깔렸는지 한 번 확인합니다. 이 경로는 나중에 systemd 사용자 유닛의 ExecStart=에 그대로 들어갑니다.

첫 실행에서는 Wayland·X11 세션 모두에서 창이 뜨는지, 시스템 트레이 아이콘이 보이는지 정도만 보면 됩니다. GNOME은 트레이 확장이 필요할 수 있고, KDE Plasma는 비교적 수월한 편입니다. 아직 구독을 넣지 않았어도 앱 셸과 로그에 치명적 오류가 없는지 확인하는 단계로 충분합니다. 빌드 산출물이 사용자 홈 아래에만 깔리는 형태라면, 이후 업데이트 때 경로가 바뀌지 않게 고정 디렉터리에 두는 편이 운영에 유리합니다.

④ 구독 URL로 프로필 가져오기: Arch에서도 동일한 UX

앱을 연 뒤 프로필·Profiles 화면에서 URL로 가져오기에 공급자가 준 구독 주소를 붙여 넣습니다. 복사 과정에서 앞뒤 공백이나 줄바꿈이 섞이면 실패하는 경우가 많으니, 메모장에 한 번 붙여 넣어 정리한 뒤 다시 복사하는 습관이 좋습니다. 가져온 뒤에는 갱신을 눌러 노드 목록이 채워졌는지 확인합니다.

갱신이 안 되거나 목록이 비면 만료·요청 제한·User-Agent 요구 등을 의심합니다. 이런 증상은 OS를 가리지 않으므로 구독 링크 FAQ를 같이 보시면 원인 분기가 빨라집니다. 프로필이 여러 개일 때는 현재 활성 프로필이 무엇인지 꼭 확인하세요. 잘못된 프로필이 선택되어 있으면 규칙은 있는데 노드 풀이 비어 보이는 일이 생깁니다.

⑤ 연결 방식: 시스템 프록시와 TUN, 그리고 DNS

Linux 데스크톱에서도 축은 두 가지입니다. 시스템 프록시는 데스크톱 환경 설정에 HTTP/HTTPS/SOCKS 엔드포인트를 반영하는 방식이고, TUN은 가상 인터페이스 뒤에서 트래픽을 넓게 잡는 방식입니다. 브라우저는 시스템 프록시를 잘 따르지만, 터미널·일부 런처는 환경 변수나 자체 설정 때문에 빗나갈 수 있습니다.

“노드 지연은 뜨는데 웹만 안 열린다”는 질문은 DNS·규칙·실제로 프록시가 켜졌는지로 갈립니다. TUN을 켠 상태에서 DNS가 꼬이면 프로필의 fake-ip·DoH 설정을 함께 봐야 합니다. 개념을 더 깊게 잡고 싶다면 TUN 모드 심화 글의 점검 순서를 참고하면 Arch에서도 진단이 수월합니다. 프록시 그룹 구조가 헷리리면 프록시 그룹 가이드로 맞춥니다.

⑥ 로그인 후 자동 실행: XDG 자동 시작(.desktop)과의 선택

그래픽 앱을 “그냥 켜지게”만 하고 싶다면 자동 시작(Autostart)이 가장 직관적입니다. ~/.config/autostart/에 .desktop 파일을 두고 Exec=에 실행 파일 전체 경로를 적습니다. 이 방식은 그래픽 세션이 올라온 뒤 사용자 환경 변수를 그대로 물려받기 쉬워, Wayland·DISPLAY 이슈가 systemd 백그라운드 서비스보다 적은 편입니다.

반대로 재시작 정책·로그를 journalctl --user 한 줄로 보고 싶다면 사용자 유닛이 유리합니다. Fedora 글에서 다룬 SELinux나 firewalld 같은 축은 Arch 기본 설치에는 없지만, 방화벽 도구를 따로 올렸다면 로컬 프록시 포트 예외를 같은 식으로 점검하면 됩니다.

⑦ systemd --user로 Clash Verge 올리기: 유닛 파일 예시

systemctl --user는 “로그인한 사용자 단위”로 서비스를 관리합니다. 그래픽 앱을 유닛으로 올릴 때는 그래픽 세션이 준비된 뒤 실행되도록 의존 관계를 두는 편이 안전합니다. 빌드·데스크톱 환경마다 최적 값이 달라 아래는 출발점이며, ExecStart=는 반드시 실제 바이너리 경로로 바꿉니다.

~/.config/systemd/user/clash-verge.service를 만든 뒤 systemctl --user daemon-reload, systemctl --user enable --now clash-verge.service 순으로 활성화합니다. 실패하면 journalctl --user -u clash-verge.service -e로 “DISPLAY 없음”, “실행 파일 없음”, “권한 거부”를 빠르게 갈라 봅니다.

[Unit]
Description=Clash Verge (user graphical session)
After=graphical-session-pre.target

[Service]
Type=simple
ExecStart=/usr/bin/clash-verge
Restart=on-failure

[Install]
WantedBy=default.target

위 예시의 ExecStart는 패키지가 설치한 실제 경로로 교체해야 합니다. .desktop 자동 시작에서는 되는데 systemd --user에서만 실패한다면 환경 변수 전달 문제를 우선 의심합니다. “사용자 로그인 없이도 항상 떠 있어야 한다”는 요구는 linger(loginctl enable-linger)와 보안 모델을 다시 검토해야 하는 영역입니다.

⑧ pacman 업데이트 이후: 모듈 드라이버·커널과 TUN

Arch는 커널·모듈이 자주 갱신되므로, TUN을 켠 구성이라면 업데이트 직후에만 터널이 깨지는 패턴도 있습니다. 이때는 재부팅 한 번으로 복구되는지, 아니면 서드파티 모듈을 다시 빌드해야 하는지를 구분합니다. 그래픽 스택(Mesa·NVIDIA 등)과 무관해 보여도, 사실은 네임스페이스·권한 캡슐화가 바뀌어 클라이언트가 TUN 디바이스를 못 여는 경우도 있으니 로그를 먼저 봅니다.

롤링 특유의 “어제까지 되던 게 오늘 안 된다”는 상황에서 뉴스와 포럼을 확인하는 것도 Arch 사용자 경험의 일부입니다. 프록시 앱만의 문제인지, 시스템 업데이트와의 상관인지를 가르는 습관이 장기적으로 시간을 아껴 줍니다.

⑨ 트러블슈팅 체크리스트: 한 번에 하나씩

아래는 한 번에 여러 가설을 섞지 말고 위에서부터 밟는 순서입니다.

1. 클라이언트에서 코어 실행·시스템 프록시/TUN 스위치가 실제로 켜져 있는지 확인합니다.
2. 브라우저·터미널이 시스템 프록시를 따르는지, 수동 프록시가 예전 값으로 남아 있지 않은지 확인합니다.
3. 다른 VPN·가상 어댑터가 동시에 켜져 있으면 충돌합니다. 한쪽을 끄고 다시 시도합니다.
4. 프록시 그룹이 빈 그룹을 가리키거나, 규칙 모드에서 의도치 않게 DIRECT로 빠지는 도메인이 없는지 확인합니다.
5. DNS가 로컬에서 깨지면 “사이트만 안 열린다”로 보입니다. 프로필의 DNS·fake-ip·fallback을 공급자 문서에 맞게 두었는지 확인합니다.
6. 자동 시작이 중복이면 프로세스가 두 개 떠서 포트가 겹칠 수 있습니다. ps로 중복 실행 여부를 확인합니다.

⑩ 정리: Arch에서는 AUR·사용자 systemd·구독을 한 세트로

Arch Linux에서 Clash Verge를 쓸 때의 핵심은 다른 배포판 튜토리얼의 패키지 관리자 명령을 그대로 가져오지 않는 것과, 구독만 넣었다고 끝이 아니라는 것입니다. AUR과 yay·paru로 설치 경로를 명확히 한 뒤, systemd --user로 자동 실행을 맞추면 재시작 정책과 로그 측면에서 운영이 단순해집니다. 반대로 그래픽 세션 변수 때문에 고생한다면 .desktop 자동 시작이 더 나은 선택일 수 있습니다.

상용 VPN 앱과 비교해 Clash 계열은 처음 설정이 길어 보일 수 있지만, 한 번 구조를 잡아 두면 구독과 규칙을 같은 방식으로 여러 기기에 가져갈 수 있다는 장점이 있습니다. 전체 흐름을 한 번에 잡고 싶다면 Clash 입문 튜토리얼을 함께 보시고, 데스크톱 설치와 경로 정리는 다운로드 페이지에서 맞춰 보세요. 규칙 기반 프록시를 안정적으로 쓰려면 클라이언트뿐 아니라 DNS·분류 순서를 같은 축으로 맞추는 것이 중요합니다. → Clash를 무료로 내려받고, Arch 데스크톱에서도 롤링 환경에 맞게 첫 설정을 마쳐 보세요.