어떤 검색이 이 페이지로 들어오나요
Arch·EndeavourOS·Manjaro 사용자는 Clash Verge Rev AUR, yay clash verge, paru 설치, Arch 프록시 클라이언트, AppImage Verge처럼 영문 패키지명과 한글을 섞어 검색합니다. 요구는 동일합니다. 그래픽 패널로 Meta·Mihomo 코어를 감싼 뒤 구독을 동기화하고, 운영체제 시스템 프록시 필드에 값을 맞추거나 TUN으로 전역 경로를 잡습니다. 처음에는 Rule 모드와 노드 그룹 이름만 이해해도 되고, 순서는 전제 점검 → AUR 또는 AppImage → 첫 실행 → 구독 → 시스템 프록시 → (선택) TUN으로 기억하면 “앱은 정상인데 브라우저만 직통”일 때 역추적이 빨라집니다.
회사 단말은 보안 에이전트가 로컬 포트를 막는 경우가 있어 개인 장비와 증상이 다를 수 있습니다. 또한 Arch는 패키지가 최신에 가깝게 올라오므로 glibc·webkitgtk 같은 의존성 메시지가 Ubuntu 문서와 다르게 보일 수 있는데, 그때는 콘솔 출력과 pacman 제안을 그대로 따라가는 편이 안전합니다.
왜 Arch에서는 경로가 Ubuntu와 다를까요
Ubuntu·Debian은 보통 공식 .deb를 내려받아 apt install ./로 올리는 흐름이 중심입니다. 반면 Arch 공식 저장소에는 Clash Verge Rev가 없을 수 있어 커뮤니티가 올린 AUR의 PKGBUILD를 yay나 paru가 받아 빌드·설치하는 패턴이 일반적입니다. 이름은 시기에 따라 clash-verge-rev-bin처럼 -bin 접미가 붙은 프리빌드 패키지가 있을 수도 있고, 소스에서 빌드하는 변형이 있을 수도 있으니 yay -Ss clash verge로 목록을 보고 설명을 읽은 뒤 고르는 습관이 필요합니다.
AppImage는 pacman 트리 밖에서 단일 파일로 시험하기 좋아 듀얼부트·임시 계정에 부담이 적습니다. 반면 메뉴 통합·업데이트 알림은 AUR 쪽이 편한 경우가 많습니다. 둘 다 합법적인 출처인지, 릴리스 페이지가 동일 프로젝트인지 먼저 확인하세요.
설치 전에 확인할 것
uname -m로 x86_64와 aarch64를 구분합니다. AUR에서 소스 빌드를 할 계획이면 base-devel 메타 패키지와 git이 필요한 경우가 많습니다. yay를 처음 깐다면 공식 가이드에 따라 일반 사용자로 클론·빌드하는 흐름을 권장합니다. paru도 유사합니다.
TUN을 곧바로 켤 생각이라면 /dev/net/tun 존재 여부와 커널 모듈 메시지를 한 번 보고, nftables·iptables-nft·ufw 등 로컬 방화벽이 루프백·컨트롤러 포트를 막지 않는지 확인합니다. 다만 첫 연결은 시스템 프록시만으로도 검증 가능한 경우가 많아, 문제 범위를 줄이려면 프록시부터 맞춘 뒤 TUN으로 넘어가는 편이 디버깅에 유리합니다.
안내: 패키지 이름이 비슷한 다른 포크와 섞이지 않도록 다운로드 허브나 공식 GitHub 릴리스 한 곳을 기준으로 고정하는 습관이 좋습니다.
1yay·paru로 AUR에서 설치하기
이미 yay나 paru가 있다면 검색으로 후보 패키지를 고릅니다. 전형적으로는 -S에 패키지 이름을 넣으면 의존성을 묻고 빌드를 진행합니다. 빌드 로그에 gpg·키링 관련 경고가 나오면 공식 위키의 키 신뢰 절차를 따릅니다. 프리빌드 아카이브를 풀어 쓰는 -bin 계열이 있으면 시간이 절약되지만, PKGBUILD 변경 사항은 반드시 짧게라도 읽습니다.
# Search available AUR packages (example)
yay -Ss clash verge
# Install chosen package name from search results; example placeholder:
# yay -S clash-verge-rev-bin
위 마지막 줄은 예시일 뿐 실제 패키지 이름은 검색 결과를 따르세요. 설치가 끝나면 pacman -Ql로 바이너리·.desktop 파일 경로를 확인하거나 앱 런처에서 Clash Verge Rev를 찾습니다. KDE·GNOME 모두 메뉴 등록이 되어 있으면 이후 단계가 수월합니다.
Manjaro는 pamac 그래픽 도구로 AUR을 켠 뒤 동일 패키지를 고를 수도 있습니다. 이 경우에도 출처 설명란을 읽고, 빌드 실패 시 콘솔 로그를 저장해 두면 재시도에 도움이 됩니다.
2AppImage로 받아 실행하기
GitHub Releases에서 AppImage 자산을 내려받은 뒤 실행 비트를 부여합니다. 파일 관리자 속성이나 chmod +x를 사용합니다. 더블클릭 무반응이면 터미널에서 직접 실행해 FUSE·샌드박스 관련 메시지를 읽습니다. Arch에는 필요한 사용자 공간 라이브러리를 pacman으로 맞추는 식으로 처리하는 경우가 많습니다.
# Example only; replace with real filename from releases
chmod +x ./Clash.Verge-*--linux.AppImage
./Clash.Verge-*-linux.AppImage실행 파일은 로컬 디스크에 두고, 원격 파일시스템 위에 두면 잠금·지연 문제가 커질 수 있습니다. 버전 교체 시 이전 파일 이름에 날짜를 붙여 보관하면 롤백이 쉽습니다.
3첫 실행·트레이·Wayland
GNOME·KDE Plasma 모두 기본 세션이 Wayland인 경우가 많습니다. 레거시 시스템 트레이에 의존하는 UI는 상단 패널에 안 보일 수 있어 메인 창에서 코어 상태·모드를 확인하는 습관이 필요합니다. 자동 시작 옵션이 있다면 로그인 후 한 번 수동 실행한 뒤 재부팅 테스트를 권장합니다.
pkexec·polkit 창이 뜨는 구성이라면 비밀번호 입력 타이밍과 정책을 확인합니다. 방화벽을 켠 환경에서는 로컬 API·mixed 포트가 막혀 패널만 비정상으로 보일 수 있으니 잠시 프로파일을 바꿔 재현을 나눠 보세요.
4구독 가져오기와 새로 고침
공급자 대시보드에서 복사한 구독 URL을 프로필 입력란에 붙여 넣습니다. 끝 공백·줄바꿈 때문에 토큰이 깨지면 HTTP 403처럼 보일 수 있어 메모장에 한 번 정리하는 방법이 안전합니다. 자동 갱신 주기는 너무 짧으면 속도 제한에 걸리기 쉬우니 기본값에서 시작합니다.
로그 분해는 구독 403·시간 초과 글과 함께 보는 것이 좋습니다. 갱신 주기만 따로 튜닝하려면 자동 새로 고침 간격 글도 참고하세요. 여러 프로필을 두었다면 활성 표시가 어느 것인지 항상 확인합니다.
5시스템 프록시와 (선택) TUN
코어가 떠 있는데도 브라우저만 직통이면 운영체제 프록시 필드가 비었을 가능성이 큽니다. 패널이 제시하는 HTTP·HTTPS·필요 시 SOCKS와 mixed-port 안내를 설정 → 네트워크 → 프록시에 글자 단위로 맞춥니다. Rule 모드에서 테스트 사이트가 DIRECT로 빠지면 출구 IP가 그대로일 수 있으니 잠깐 Global로 바꿔 경로를 분리 검증한 뒤 규칙 모드로 돌아옵니다.
터미널·Docker·flatpak 등이 환경 변수를 따로 쓰면 UI만으로는 부족할 수 있습니다. 그때 TUN이나 스크립트형 프록시를 검토합니다. 절차는 TUN 가이드와 TUN 스택·gVisor 글을 교차 확인하세요. 커널 업데이트 직후 모듈 메시지가 바뀌면 한동안 이전과 증상이 달라질 수 있습니다.
엔데버OS·만자로에서 달라질 수 있는 점
EndeavourOS는 순정 Arch에 가깝게 유지되는 경우가 많아 본문 순서와 거의 같습니다. Manjaro는 스테이블 브랜치가 Arch보다 패키지를 늦게 따라가거나, 전용 설정 도구(mS 등)와 커널 빌드를 함께 쓰는 경우가 있어 그래픽·커널 모듈 경고가 추가로 나올 수 있습니다. 그럴 때도 핵심은 콘솔 로그를 기준으로 의존성을 채우고, 프록시 값이 OS 설정과 패널 안내에서 일치하는지 보는 것입니다.
설치 직후 검증 체크리스트
- 프로세스 목록에서 코어 바이너리가 기대한 사용자 권한으로 떠 있는지 확인합니다.
- 프로필 새로 고침 시각이 최근인지, 노드 목록에 지연 값이 채워지는지 확인합니다.
- 데스크톱 환경의 프록시 필드와 패널 안내가 일치하는지, 비공개 창에서 출구 IP가 바뀌는지 확인합니다.
- TUN을 켰다면
ip route·DNS 결과가 의도와 맞는지 한 번 훑습니다.
준수: 소속 기관의 보안 규정과 서비스 약관을 지키세요. 업무 장비에서는 IT 허가 없이 프록시 소프트웨어를 설치하지 마십시오.
자주 묻는 짧은 질문
AUR와 AppImage 중 무엇부터 시도할까요?
메뉴·pacman 트리와 함께 두고 싶으면 AUR, 이동식으로만 쓰려면 AppImage가 부담이 적은 경우가 많습니다. 같은 구독으로 한쪽만 성공시켜도 충분합니다.
yay와 paru 중 어느 쪽이 맞나요?
둘 다 널리 쓰이는 헬퍼입니다. 이미 익숙한 쪽을 고르고, 빌드 정책은 각 프로젝트 문서를 따릅니다. 중요한 것은 PKGBUILD 출처를 짧게라도 확인하는 습관입니다.
구독이 403이면 Arch 설치가 잘못됐나요?
대부분 링크·토큰 이슈입니다. 브라우저에서 URL을 열어 보고 로그의 HTTP 코드와 비교하세요.
바로 TUN을 켜도 될까요?
시스템 프록시가 먼저 안정적인지 본 뒤 단계적으로 켜는 것을 권장합니다. 절차는 TUN 가이드를 참고합니다.
문서 허브
규칙·DNS·로그가 겹치기 시작하면 Clash 설정 허브를 북마크해 두세요. 윈도와 비교해 읽을 글이 필요하면 Windows Verge 설치도 함께 두면 검색 경로가 짧아집니다.
마치며
Arch 계열에서 Clash Verge Rev를 쓰려면 공식 저장소가 아닌 경로(AUR·AppImage)를 전제로 패키지 이름·의존성 메시지를 바로잡고, 구독 가져오기와 시스템 프록시를 같은 세션에서 확인하는 것이 핵심입니다. 예전 셸 스크립트 조합이나 단일 코어만 띄우는 방식은 업데이트마다 깨지기 쉬웠고, Verge 계열은 UI에서 코어 상태와 규칙 전환을 한 화면에 묶어 줍니다. 그래도 롤링은 커널·데스크톱 스택이 자주 바뀌므로 “패널만 초록”에 속지 않도록 OS 쪽 프록시 값을 함께 보는 습관이 필요합니다.
순수 systemd·컨테이너 위주 Mihomo 운영은 편집·배포 부담이 크고 실수 시 복구 시간도 깁니다. GUI가 있는 Clash 제품군은 규칙 전환과 로그 확인을 클릭 몇 번으로 줄여 주어 일상 데스크톱에는 부담이 적습니다. 아직 써 보지 않았다면 Clash 무료 다운로드에서 리눅스용 패키지를 고른 뒤, 위 순서대로 첫 프록시까지 연결해 보세요.