Ubuntu 24.04에서 Clash Verge 설치: 구독 가져오기와 systemd로 부팅·로그인 후 자동 실행

① 왜 Ubuntu 24.04와 Clash Verge인가요?

2026년 기준으로도 Linux 데스크톱 검색은 Ubuntu와 특정 LTS 버전 이름이 함께 붙는 경우가 많습니다. Ubuntu 24.04는 장기 지원·패키지 기본값·Wayland 전환이 한꺼번에 정리된 세대라, “설치 스크립트가 옛날 22.04만 가정한다”는 식의 마찰이 줄어듭니다. Clash Verge(커뮤니티에서 자주 언급되는 Clash Verge Rev 포함)는 그래픽으로 프로필을 고르고 코어를 띄우기 쉬운 클라이언트라, 터미널만으로 config.yaml을 만지기 싫은 사용자에게 맞습니다. 전체 생태계 그림은 2026년 Clash 생태계 글에서 한 번 잡아 두면, 레거시 앱과의 차이를 가늠하기 쉽습니다.

이번 주제의 핵심은 “설치와 구독”에 더해 매번 손으로 실행하지 않기입니다. Linux에서는 세션 자동 시작(.desktop)과 systemd 사용자 유닛이 대표적인 두 갈래인데, 그래픽 앱은 전자가 더 잘 맞는 경우가 많고, 후자는 로그인 전후·재시작 정책을 명확히 쓰고 싶을 때 유리합니다. 아래에서는 둘 다 예시로 적어 두되, 본인 환경에 맞는 한 가지를 먼저 고정하는 것을 권장합니다.

② 설치 전 점검: 권한·배포 형식·보안 소프트

Ubuntu 24.04에서 서드파티 GUI 앱은 AppImage, .deb, 혹은 배포자가 안내하는 압축 해제형 바이너리로 제공되는 경우가 많습니다. 어떤 형식이든 공통으로 확인할 것은 실행 권한과 경로입니다. AppImage는 chmod +x 후 실행하고, 패키지 설치형은 메뉴에 등록되는지·실행 파일 경로가 어디인지 한 번 확인해 두면 이후 systemd의 ExecStart=를 쓸 때 편합니다.

UFW 같은 방화벽은 기본적으로 “막아 두되 로컬 루프백은 허용”에 가깝지만, 기업 보안 에이전트나 추가 필터가 있으면 로컬 프록시 포트를 이상 징후로 분류하기도 합니다. “앱은 뜨는데 전부 안 붙는다”면 방화벽·보안 모듈의 예외를 의심합니다. 오픈소스 GitHub 저장소는 라이선스·이슈·기여 방식을 확인하는 용도로 두고, 실제 설치 패키지를 받는 주 경로는 사이트 안내를 따르는 편이 버전 혼선이 적습니다. 같은 맥락에서 클라이언트 패키지를 한곳에서 정리해 두면 재설치·자동 시작 경로를 잃어버릴 확률도 줄어듭니다.

③ Clash Verge 설치: Ubuntu 24.04에서의 일반적인 순서

빌드마다 메뉴 이름이 조금 다를 수 있으나 큰 줄기는 같습니다. 배포 형식에 맞춰 앱을 설치한 뒤 한 번 실행해 의존 라이브러리 경고가 없는지 봅니다. Wayland 세션에서 창이 뜨지 않거나 트레이 아이콘이 안 보이면, 데스크톱 환경(GNOME·KDE 등)별로 “트레이 확장”이나 “백그라운드 실행 허용” 설정을 확인합니다. 설치 직후에는 아직 구독이 없어도 앱 셸이 뜨는지·로그에 치명적 오류가 없는지만 보면 됩니다.

터미널에 익숙하다면 설치 위치를 which나 패키지 관리자로 확인해 메모해 두세요. 이후 systemd 사용자 서비스를 만들 때 이 경로가 그대로 들어갑니다. 반대로 AppImage를 홈 디렉터리 깊숙이 두고 나중에 옮기면 유닛 파일을 같이 고쳐야 하므로, 고정된 디렉터리(예: ~/Applications 또는 /opt에 심볼릭 링크)를 쓰는 편이 운영이 단순합니다.

④ 구독(Subscription) URL로 프로필 가져오기

앱을 연 뒤 프로필·Profiles 화면에서 URL로 가져오기·새 구독에 들어가 공급자가 준 구독 주소를 붙여 넣습니다. 복사 과정에서 앞뒤 공백·줄바꿈이 섞이면 실패하는 경우가 많으니, 텍스트 편집기에 한 번 붙여 넣어 정리한 뒤 다시 복사하는 습관이 좋습니다.

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

⑤ Linux에서 연결 방식: 시스템 프록시와 TUN을 어떻게 고를까요?

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

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

⑥ 로그인할 때 자동 실행: XDG 자동 시작(.desktop)

그래픽 클라이언트를 “그냥 켜지게”만 하고 싶다면 자동 시작(Autostart)이 가장 직관적입니다. GNOME을 예로 들면, 앱이 설치 과정에서 ~/.config/autostart/에 .desktop 파일을 만들어 주기도 하고, 사용자가 수동으로 복사해 넣기도 합니다. 핵심 필드는 Exec=에 실제 실행 파일의 전체 경로를 넣는 것과, 필요 시 Hidden=false, X-GNOME-Autostart-enabled=true 같은 항목을 맞추는 것입니다.

AppImage라면 Exec=에 AppImage 경로를 그대로 쓰고, 경우에 따라 %F 같은 인자는 빌드 안내를 따릅니다. 이 방식은 그래픽 세션이 올라온 뒤 사용자 환경 변수를 그대로 물려받기 쉬워, Wayland·DISPLAY 이슈가 systemd 백그라운드 서비스보다 적은 편입니다. 다만 “전원을 켜자마자 로그인 화면만 있고 사용자 세션이 없을 때”까지 코어를 띄워야 한다면 다음 절의 systemd 논의로 넘어가야 합니다.

⑦ systemd 사용자 유닛으로 자동 실행 맞추기

systemd의 사용자 모드(systemctl --user)는 “로그인한 사용자 단위로 서비스를 관리”합니다. 그래픽 앱을 유닛으로 올릴 때는 세션 그래픽이 준비된 뒤 실행되도록 의존 관계를 두는 편이 안전합니다. 빌드·환경마다 최적 값이 달라서, 아래 예시는 출발점으로만 보고 실제 경로·환경 변수는 본인 PC에 맞게 바꿉니다.

~/.config/systemd/user/clash-verge.service 같은 파일을 만들고, ExecStart=에 설치된 바이너리 전체 경로를 넣습니다. 그 다음 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는 반드시 실제 경로로 바꿉니다. Wayland·X11 혼용 환경에서는 창 시스템 변수가 필요한 빌드도 있어, 자동 시작이 .desktop에서는 되는데 systemd에서만 실패한다면 환경 전달 문제를 우선 의심합니다. “사용자 로그인 없이도 항상 떠 있어야 한다”는 요구는 linger(loginctl enable-linger 사용자명) 같은 주제와 엮이므로, 가정이 다르면 보안·권한 모델을 다시 점검해야 합니다.

⑧ 설치·자동 시작 후에도 안 될 때: 순서대로 점검

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

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

⑨ 정리: Ubuntu 24.04에서는 “설치·구독·연결 방식·자동 시작”을 한 세트로

Ubuntu 24.04에서 Clash Verge를 쓸 때의 핵심은 구독만 넣었다고 끝이 아니라는 것입니다. 시스템 프록시와 TUN 중 무엇을 켰는지에 따라 어떤 앱이 잡히는지가 달라지고, 자동 시작은 .desktop이 단순할 때가 많지만 systemd 사용자 유닛이 재시작 정책·로그 측면에서 유리할 때도 있습니다. 노드 지연은 정상인데 웹만 안 열리면 DNS·규칙·프록시 적용 여부를 의심하는 순서가 실전에서 가장 빠릅니다.

상용 VPN 앱과 비교해 Clash 계열은 처음 설정이 길어 보일 수 있지만, 한 번 구조를 잡아 두면 구독과 규칙을 같은 방식으로 여러 기기에 가져갈 수 있다는 장점이 있습니다. 데스크톱뿐 아니라 휴대 기기까지 묶어 보고 싶다면 Clash 입문 튜토리얼에서 전체 흐름을 잡아 두면 이후 트러블슈팅이 쉬워집니다. 최신 클라이언트와 설치 경로를 한곳에서 정리해 두면 버전 혼선도 줄어듭니다. → Clash를 무료로 내려받고, Linux 데스크톱에서도 규칙 기반 프록시를 안정적으로 써 보세요.