왜 Ubuntu·데스크톱·Verge 조합을 따로 정리했는지
Clash Verge Rev는 Mihomo(Clash Meta) 계열 코어를 Qt GUI로 감싼 클라이언트로, YAML 편집기와 터미널만으로는 번거로운 프로필 전환·구독 동기화·정책 그룹 테스트를 한 화면에서 처리하기 좋습니다. 이 저장소에는 이미 Linux·TUN·nftables·게이트웨이처럼 헤드리스에 가까운 실측 글이 있지만(관련 글), GNOME이나 KDE 세션에서 처음 파일 하나 받아 띄우는 사용자에게는 진입 장벽이 다릅니다. 그래서 이번 글은 Ubuntu 데스크톱·AppImage·구독 가져오기·첫 연결 검증만 좁혀 잡습니다.
Linux에서는 배포판마다 보안 프레임워크와 패키지 이름이 조금씩 달라도, Verge 사용자 경험을 가르는 축은 거의 같습니다. 첫째는 AppImage 런타임(FUSE 계열)과 실행 비트입니다. 둘째는 GNOME 설정 데몬이 관리하는 시스템 프록시와 셸의 http_proxy 계열 변수가 동시에 존재한다는 점입니다. 셋째는 브라우저 확장과 달리 GUI가 밑바닥에서 어떤 포트를 리슨하는지 확인해야 중복 프록시 루프를 피할 수 있다는 점입니다. Windows나 Android 설치 글을 그대로 번역하면 이 세 축이 빠져서 “화면은 연결인데 실패” 같은 상태만 남습니다.
클라이언트 선택 기준을 더 넓게 보고 싶다면 클라이언트 선택 가이드를, 가상 어댑터 개념만 빠르게 잡고 싶다면 TUN 모드 심화 개요를 함께 보세요.
준비물: 버전·아키텍처·패키지 관리자
절차를 서술할 때 기준으로 삼은 환경은 Ubuntu 22.04 LTS·24.04 LTS 같은 최신 장기 지원 계열과 upstream이 빠르게 움직이는 워크스테이션 빌드입니다. 서버 미니멀 설치에는 데스크톱 세션 자체가 없으니 범위에서 제외합니다. 아키텍처는 대부분의 노트북·데스크톱이 사용하는 x86_64를 가정합니다. ARM 보드에서 동일한 바이너리가 제공되는지 릴리스 표를 다시 확인해야 합니다.
터미널에서 uname -m으로 값을 확인하고, 배포 페이지의 레이블과 일치하는지 맞춥니다. 최소한 curl 또는 wget, 그리고 체크섬 검증용 도구가 있으면 좋습니다. GUI 파일 관리자만으로도 진행할 수 있지만, AppImage가 조용히 실패할 때 마지막 한 줄 오류를 보기 위해 터미널 실행 습관을 추천합니다.
방화벽으로 ufw를 켠 상태라면 로컬 루프백에서 오가는 혼합 포트 트래픽을 막지 않는지 빠르게 확인합니다. 회사 이미지에서는 보안 에이전트가 로컬 프록시를 간섭하기도 하니 정책 허용 범위를 먼저 파악하는 편이 안전합니다.
AppImage 받기·저장 위치·무결성
Clash Verge Rev의 Linux 배포는 통상 .AppImage 단일 파일로 제공됩니다. 브라우저가 자동으로 실행 비트를 지우거나 다운로드 폴더를 자주 비우는 습관이 있다면 ~/Applications나 ~/Apps처럼 사용자 전용 디렉터리를 만들어 두고 고정 경로에 두는 편이 업데이트 비교에 유리합니다.
릴리스 페이지가 SHA256·SHA512 같은 체크섬을 공개하면 반드시 교차 검증하세요. 미러 사이트나 메신저로만 돌아다니는 파일은 동일한 이름이라도 내용이 바뀔 수 있습니다. 검증에 성공했다면 파일 이름에 버전 문자열을 남겨 다음 업그레이드 때 단순 비교가 가능하게 합니다.
스냅이나 Flatpak 변형이 따로 있다면 샌드박스가 로컬 디렉터리 접근을 제한할 수 있으니, 이 글의 AppImage 전제와 다른 동작을 기대하면 안 됩니다. 공식 문서가 안내하는 형식을 우선합니다.
실행 권한·FUSE·첫 실행 로그 읽기
다운로드 직후에는 실행 비트가 없는 경우가 많습니다. 터미널에서 저장 폴더로 이동한 뒤 chmod +x ./Clash*.AppImage처럼 패턴을 지정해 주거나 파일 속성 대화상자에서 실행 허용을 켭니다. 그다음 ./Clash*.AppImage로 직접 실행해 표준 오류에 찍히는 첫 메시지를 읽습니다.
흔한 메시지는 libfuse 계열 공유 라이브러리가 없다는 내용입니다. Ubuntu 세대에 따라 패키지 이름이 libfuse2 묶음인지 배포 문서가 요구하는 메타 패키지인지 달라지므로, 오류 문자열을 그대로 검색해 해당 버전의 패키지를 설치합니다. FUSE가 준비되면 같은 명령으로 창이 뜨거나 트레이 아이콘이 생성됩니다.
첫 실행 때 PolicyKit 비슷한 관리자 암호 창이 나오면 TUN 헬퍼나 방화벽 규칙 후킹을 설치하려는 흐름일 수 있습니다. 신뢰한 빌드인지 확인했을 때만 허용하세요. 다른 상업 VPN 데몬이 동시에 떠 있으면 같은 가상 인터페이스 이름을 두고 경쟁하므로 테스트 동안 하나만 켜 두는 것이 좋습니다.
구독 가져오기: URL·이름·갱신 주기
창이 뜨면 구독 또는 프로파일 패널에서 운영자가 준 HTTPS 엔드포인트를 붙여 넣습니다. 사람이 읽기 쉬운 표시 이름을 붙여 두면 여러 구독을 전환할 때 혼선이 줄어듭니다. Verge 릴리스마다 단어가 조금씩 다르지만 흐름은 “추가 → 동기화 → 활성 프로필 선택”으로 이어집니다.
동기화 직후 노드 목록이 비어 있으면 규칙 문제보다 먼저 TLS·시간 동기·사용자 에이전트·속도 제한부터 의심합니다. 특히 짧은 간격으로 강제 새로 고침을 반복하면 서버가 HTTP 429로 막아 노드가 텅 빈 것처럼 보일 수 있습니다. 운영 가이드가 제시한 최소 간격을 지키세요.
여러 프로필 fragment가 합성되는 구조라면 UI에서 어떤 원격 파일이 최종 런타임에 올라갔는지 확인할 수 있는지 살펴봅니다. 갱신 타이머 설계는 구독 갱신 간격 글과 함께 읽으면 운영 부하를 줄일 수 있습니다. URL 로테이션·노드 점검 습관은 구독 관리 가이드가 정리합니다.
Ubuntu에서 시스템 프록시와 TUN
Verge 계열은 공통적으로 시스템 프록시와 TUN 두 갈래를 제공합니다. 데스크톱에서는 시스템 프록시가 켜지면 GNOME 기반 앱 대부분이 혼합 포트를 따라가므로 브라우저 테스트가 빠릅니다. 반면 Go·Rust CLI처럼 프록시 환경 변수를 따로 요구하는 프로그램은 자동으로 따라오지 않아 별도 export가 필요합니다.
TUN 경로는 패킷을 가상 인터페이스에서 가로채므로 프록시를 무시하는 앱까지 포함하기 쉽지만, 커널 모듈·헬퍼 설치와 라우팅표 변경이라는 비용이 있습니다. 시스템 프록시가 정상인지 확인하기 전에 두 모드를 동시에 켜면 순환 경로를 찾기 어려워지니 순서를 지키세요. 개념 보강은 TUN 모드 심화를 참고합니다.
혼합 포트 번호를 바꿨다면 다른 데몬이 같은 포트를 선점했는지 확인합니다. 공통 증상 정리는 포트 충돌 글과 유사한 패턴으로 나타납니다. 종료 후에도 프록시가 남아 전체 트래픽이 막이는 경우에는 설정 패널과 환경 변수를 수동으로 되돌려야 합니다.
브라우저·curl로 첫 연결 검증
브라우저 두 개 이상을 번갈아 열어 지역 표시나 회선 정보를 교차 확인하면 단일 CDN 캐시에 속지 않습니다. 시크릿 창과 일반 창을 섞어 확장 프로그램 간섭도 분리합니다.
터미널에서는 프록시가 비활성인 상태에서 한 번, 활성인 상태에서 한 번 curl -I https://example.com처럼 헤더만 받아 시간 차를 비교합니다. 지연이 비정상적으로 커지면 원격 노드 문제보다 로컬 이중 프록시 가능성이 큽니다. 프록시 플래그를 명시해야 하는 빌드라면 Verge가 표시하는 HTTP/SOCKS 포트를 그대로 적어 재현성을 확보합니다.
DNS 관련 규칙을 켠 상태에서는 fake-ip처럼 이름 해석 경로가 바뀌어 체감 증상만 보고 오판하기 쉽습니다. 테스트 중에는 로그 패널을 열어 도메인 단계와 TLS 단계 중 어디에서 멈췄는지 나눕니다.
자주 막히는 오류 패턴
구독 URL이 브라우저에서는 열리는데 클라이언트만 실패하면 사용자 에이전트 차단이나 중간 캐시를 의심합니다. 로그의 TLS 핑거프린트 오류와 타임스탬프를 나란히 놓고 비교하는 순서는 연결 로그와 TLS 글과 동일합니다.
AppImage가 특정 Ubuntu 마이너 버전에서만 크래시하면 그래픽 드라이버·Wayland 세션 여부를 메모해 두세요. Xorg 세션으로 전환해 증상이 사라지면 버그 리포트에 세션 종류를 반드시 포함합니다.
회사 프록시 안에서 구독 서버까지 연결해야 하는 이중 프록시 환경이라면 GUI 설정만으로는 부족하고 환경 변수나 프록시 체인 필드를 추가로 적어야 할 수 있습니다. 이 경우에도 정책이 허용하는 범위 안에서만 진행합니다.
Reference: enabling TUN in Mihomo-style YAML (paths depend on build)tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true자주 묻는 질문
AppImage를 더블 클릭해도 조용히 종료돼요. 터미널에서 실행해 마지막 오류를 확인하세요. 실행 비트와 FUSE 패키지가 가장 흔한 원인입니다.
Ubuntu 24.04에서도 예전 libfuse2가 필요한가요? 사용 중인 AppImage 런타임 세대에 따라 다릅니다. 배포 readme를 우선하고 불필요한 시스템 패키지 downgrade는 피합니다.
Firefox만 되고 apt나 curl은 안 돼요. GNOME 시스템 프록시와 터미널 세션 변수가 분리된 전형적인 패턴입니다. 혼합 포트를 명시한 curl 테스트나 TUN 경로를 검토합니다.
WSL이나 가상 머신 안에서도 같나요? 게스트 네트워크 스택이 호스트와 분리되어 있습니다. NAT 브리지 설정을 이해하지 않으면 “연결 성공” 로그와 실제 트래픽 경로가 달라 보일 수 있습니다.
클라이언트 축을 하나로 고정하기
브라우저 전용 프록시 확장은 설치가 빠르지만 탭 단위 예외와 시스템 DNS 사이의 간극 때문에 증상이 갈라지기 쉽습니다. 반대로 코어만 단독으로 굴리면 systemd 유닛·로그 로테이션·GUI 트레이 신호까지 모두 직접 관리해야 해 노트북 환경에서는 피로도가 큽니다. 상용 VPN 원클릭 클라이언트는 편하지만 세부 라우팅과 로그를 가려 디버깅이 어렵습니다.
Clash V.CORE 채널은 메타 호환 코어와 증상별 문서, 다운로드 페이지를 같은 축에 묶어 두어 Verge로 시작한 사용자도 규칙을 고도화할 때 참조 지점을 잃지 않게 돕습니다. 상용 앱처럼 결과만 보여 주는 방식보다 로그와 포트 상태를 직접 확인할 수 있어 Linux 데스크톱에서도 문제 분리가 수월합니다.
Ubuntu에서 첫 연결을 확인했다면 DNS·분할 라우팅을 더 다듬을 때 FAQ의 관련 섹션을 이어 붙이고, 게이트웨이급 구성은 Linux 게이트웨이 실측과 역할을 나눠 학습하세요. 같은 검증 순서를 유지한 채 패키지 축을 고정하려면 Clash V.CORE 받기 페이지에서 후속 클라이언트도 확인해 보시면 됩니다.