이 글은 Linux 그래픽 데스크톱에 Shadowrocket을 설치하는 사용자를 위한 안내입니다. Debian / Ubuntu에서는 보통 deb, Fedora에서는 rpm을 선택하고, 그 밖의 배포판에서는 실행 조건을 충족할 경우 AppImage를 사용할 수 있습니다. 먼저 시스템과 CPU 아키텍처를 확인한 뒤 실제 다운로드 경로를 사용해 설치하세요. 설치 후에는 기존 설정을 가져오고 트래픽이 제대로 전달되는지 확인해야 합니다. 창이 열리는 것만으로 연결이 적용됐다고 판단하면 안 됩니다.
먼저 배포판, 아키텍처, 다운로드 경로 확인
Shadowrocket(Linux 버전) 설치 파일은 사이트의 다운로드 안내에서 받을 수 있습니다. 다운로드 페이지에 표시된 형식과 아키텍처를 기준으로 선택하세요. iPhone / iPad 버전은 App Store에서 $2.99에 한 번 구매하며, 시스템 요구 사항은 App Store 페이지를 기준으로 합니다. Mac(Apple 칩 및 Intel), Windows, Android, Linux 버전은 무료입니다. 앱을 받는 것과 네트워크 서비스는 별개입니다. 이후 사용할 구독은 서비스 제공업체에서 받으세요.
터미널에서 다음 두 명령을 실행하세요. 첫 번째 명령으로 배포판 정보를 확인하고, 특히 ID, ID_LIKE, VERSION_ID를 살펴보세요. 두 번째 명령은 커널이 보고하는 시스템 아키텍처를 확인합니다. 데스크톱 화면만 보고 패키지 형식을 판단하면 안 됩니다. 같은 데스크톱 환경도 여러 배포판에서 실행될 수 있습니다.
cat /etc/os-release
uname -m
배포판과 패키지 관리자
- Debian / Ubuntu
- 일반적으로 deb를 사용하며, apt가 로컬 설치와 의존성을 처리합니다.
- Fedora
- 일반적으로 rpm을 사용하며, dnf가 로컬 설치와 의존성을 처리합니다.
- 그 밖의 배포판
- 먼저 다운로드 페이지에서 지원 범위를 확인하세요. AppImage도 실행 환경 조건이 있습니다.
rpm은 패키지 형식일 뿐, rpm을 사용하는 모든 시스템이 dnf를 쓰는 것은 아닙니다.
CPU 아키텍처 확인
- x86_64
- 일반적으로 다운로드 항목의 x64 또는 amd64에 해당합니다.
- aarch64
- 일반적으로 다운로드 항목의 arm64에 해당합니다.
- 그 밖의 아키텍처
- 먼저 다운로드 페이지에 해당 빌드가 있는지 확인하고, 다른 아키텍처용 패키지를 억지로 설치하지 마세요.
아키텍처 이름은 표기 방식이 다를 수 있으므로 다운로드 페이지의 안내를 기준으로 하세요.
파일 확장자를 바꿔 형식을 변환하지 마세요. deb를 rpm으로 바꿔도 패키지 구조는 달라지지 않습니다. 아래 명령은 설치 파일명을 미리 가정하지 않으며 와일드카드로 여러 파일을 한꺼번에 설치하지도 않습니다. Bash 터미널에서 단계별로 실행하고, 안내가 나오면 다운로드한 파일의 실제 경로를 입력하세요. 경로 앞뒤에 따옴표를 붙이지 않아도 되며, 경로에 공백이 있어도 그대로 입력하면 됩니다.
Debian / Ubuntu: apt로 로컬 deb 설치
먼저 파일 다운로드가 완료됐는지 확인한 뒤 다음 명령을 실행하세요. read -r은 실제 경로를 입력받고, realpath -e는 파일이 있는지 확인한 다음 절대 경로로 변환해 apt에 전달합니다. 현재 작업 디렉터리에 의존하지 않고 파일명을 소프트웨어 저장소의 패키지 이름으로 잘못 처리하는 일도 방지합니다.
read -r -p "다운로드한 deb 파일의 실제 경로를 입력하세요: " pkg
if [ -f "$pkg" ]; then
pkg=$(realpath -e -- "$pkg") && sudo apt install "$pkg"
else
printf '%s\n' "파일을 찾을 수 없습니다. 경로를 확인한 뒤 다시 시도하세요."
fi
- 권한: 시스템에 설치할 때
sudo를 사용합니다. 암호를 입력할 때 터미널에 문자가 표시되지 않는 것은 정상입니다. - 의존성: apt는 현재 활성화된 소프트웨어 저장소에서 의존성을 확인합니다. 따라서 로컬 패키지 설치에도 인터넷 연결이 필요할 수 있습니다.
- 확인: 설치 계획을 읽어보세요. 시스템 구성 요소를 대량으로 제거하거나 패키지를 다운그레이드하는 경우, 또는 아키텍처가 맞지 않는 경우에는 먼저 취소하고 원인을 확인하세요.
- 경로: 로컬 상대 경로를 사용할 때는
./같은 경로 표시가 필요합니다. 위 명령은 절대 경로를 사용해 혼동을 피합니다.
의존성을 찾을 수 없다는 메시지가 나오면 먼저 배포판과 패키지 요구 사항이 맞는지 확인한 다음 sudo apt update를 실행해 저장소 인덱스를 새로 고치고 다시 시도하세요. 인덱스를 갱신해도 호환되지 않는 패키지가 호환되는 것은 아닙니다. 다른 패키지 관리 프로세스가 잠금을 사용 중이라는 메시지가 나오면 시스템 업데이트가 끝날 때까지 기다리세요. 잠금 파일을 바로 삭제하지 마세요.
Fedora: dnf로 로컬 rpm 설치
dnf를 사용하는 시스템에서는 로컬 rpm 파일을 설치 인수로 바로 지정할 수 있습니다. dnf가 설치 작업을 처리하고 의존성 해결을 시도합니다. 의존성 오류를 피하려고 의존성을 무시하는 방식으로 설치하지 마세요. 설치 기록은 남아도 프로그램이 실행되지 않을 수 있습니다.
read -r -p "다운로드한 rpm 파일의 실제 경로를 입력하세요: " pkg
if [ -f "$pkg" ]; then
pkg=$(realpath -e -- "$pkg") && sudo dnf install "$pkg"
else
printf '%s\n' "파일을 찾을 수 없습니다. 경로를 확인한 뒤 다시 시도하세요."
fi
- 터미널에 표시된 패키지 아키텍처를 확인하고
uname -m결과와 일치하는지 살펴보세요. - 의존성과 작업 요약을 확인해 중요한 데스크톱 구성 요소가 의도치 않게 제거되지 않는지 살펴보세요.
- 설치가 끝나면 데스크톱 앱 메뉴에서 Shadowrocket을 검색해 실행하세요.
- 의존성 또는 신뢰 관련 오류가 발생하면 전체 메시지를 보관하고 다운로드 출처와 배포판 요구 사항을 다시 확인하세요. 시스템 검증 기능을 꺼서 해결하지 마세요.
dnf를 사용하는 것이 일반적이지 않은 다른 rpm 배포판도 있으며, 의존성 조건이 같다고 볼 수도 없습니다. 확장자가 같다는 이유만으로 Fedora 명령을 그대로 사용하지 마세요. 해당 배포판의 패키지 관리 방식을 따르고 다운로드 페이지의 호환 안내를 먼저 확인하세요. 지원되는 시스템용 빌드가 없다면 AppImage의 실행 조건을 검토하세요.
AppImage: 실행 권한을 설정하고 일반 사용자로 실행
AppImage는 보통 단일 파일로 배포되므로 deb나 rpm처럼 시스템 패키지 데이터베이스에 등록할 필요가 없습니다. 그렇다고 시스템 환경과 무관하게 실행되는 것은 아닙니다. CPU 아키텍처, 그래픽 세션, 기본 런타임 라이브러리, 일부 빌드에 필요한 FUSE가 실행에 영향을 줄 수 있습니다. 사용자가 읽고 실행할 수 있는 로컬 디렉터리에 파일을 둔 뒤 작업하는 것이 좋습니다.
read -r -p "다운로드한 AppImage 파일의 실제 경로를 입력하세요: " app
if [ -f "$app" ]; then
app=$(realpath -e -- "$app") && chmod +x -- "$app" && "$app"
else
printf '%s\n' "파일을 찾을 수 없습니다. 경로를 확인한 뒤 다시 시도하세요."
fi
chmod +x는 파일에 실행 권한을 부여하는 명령이며, 의존성을 설치하거나 CPU 아키텍처를 변경하지 않습니다. &&로 명령을 연결하면 권한 설정에 실패했을 때 다음 실행 단계로 넘어가지 않습니다. 평소 실행할 때 파일 앞에 sudo를 붙이지 마세요. 사용자 설정이 관리자 디렉터리에 저장되어 일반 사용자로 접근하지 못할 수 있습니다.
- Permission denied: 파일의 실행 권한과 상위 디렉터리 접근 권한을 확인하고, 파일이 있는 파티션이
noexec옵션으로 마운트됐는지 살펴보세요. 실행 가능한 사용자 로컬 디렉터리로 옮긴 뒤 다시 시도하세요. - Exec format error: 먼저 아키텍처가 맞는지, 파일이 온전히 다운로드됐는지 확인하세요. 권한만 반복해서 바꾸지 마세요.
- FUSE 누락이 명시된 경우: 현재 배포판의 문서에 따라 호환 구성 요소를 설치하세요. 특정 시스템의 패키지 이름을 모든 배포판에 그대로 적용하지 마세요.
- GLIBC 요구 조건을 충족하지 않는 경우: 시스템 지원 범위를 확인하고 지원되는 시스템이나 호환 빌드를 사용하세요. 시스템 핵심 라이브러리를 수동으로 교체하지 마세요.
터미널에서 실행하면 오류 메시지를 확인할 수 있습니다. 더블 클릭해도 창이 열리지 않으면 먼저 위 방법으로 실행해 메시지를 살펴보세요. AppImage가 데스크톱 바로 가기를 자동으로 만드는지는 연동 방식에 따라 다릅니다. 앱 메뉴에 표시되지 않아도 실행에 실패한 것은 아니며, 파일은 원래 위치에 그대로 두어야 합니다.
처음 실행할 때: 설정을 마친 뒤 트래픽 전달 확인
앱 설치가 끝나면 ‘앱 실행’, ‘설정 유효성’, ‘트래픽이 프록시를 통과하는지’를 각각 확인해야 합니다. Linux의 데스크톱 프록시 설정과 앱 자체의 네트워크 동작은 완전히 같지 않습니다. 브라우저는 데스크톱 프록시 설정을 따르더라도 일부 터미널 프로그램은 따르지 않을 수 있습니다. Home에 연결 상태가 표시된다는 이유만으로 모든 프로세스가 같은 경로를 사용한다고 판단하지 마세요.
-
앱 실행
앱 메뉴 또는 AppImage 파일에서 Shadowrocket을 실행한 뒤 Home 화면이 정상적으로 표시되는지 확인하세요. 화면이 열리지 않으면 구독을 바꾸기보다 설치 오류나 런타임 라이브러리 문제를 먼저 해결하세요.
-
설정 가져오기
서비스 제공업체에서 받은 구독을 Config의 Subscribe 항목에서 추가하세요. 서버 정보를 한 개씩 입력하려면 Home → Add Server에서 해당 Type을 선택해 입력합니다. 구독을 가져오는 방법과 개별 서버 정보를 입력하는 방법은 용도가 다릅니다.
-
정책 확인
Home에서 서버를 선택하고 Global Routing의 현재 모드를 확인하세요. Config를 사용한다면 활성 구성과 규칙에서 참조하는 정책이 실제로 존재하는지도 Config에서 확인해야 합니다.
-
트래픽 전달 확인
연결을 켠 뒤 같은 브라우저에서 같은 테스트 주소에 접속하고 클라이언트 연결 기록을 확인하세요. 브라우저에는 기록이 있지만 터미널에는 없다면 설치 파일을 원인으로 단정하지 말고 터미널 프로그램의 프록시 설정을 확인하세요.
터미널 프로그램에 로컬 프록시 주소를 입력해야 한다면 실제 설정에서 수신 주소, 포트, 프로토콜을 확인하세요. 포트 번호를 추측하거나 HTTP 프록시 포트를 SOCKS5로 사용하지 마세요. 이 기기에서만 사용할 경우 수신 주소는 보통 루프백 주소로 설정하는 것이 LAN에 공개하는 것보다 적절합니다. 문제 해결을 위해 수신 범위를 함부로 넓히지 마세요.
Global Routing: 모드에 따라 규칙 문제와 연결 문제 구분
아래에서 비교하는 것은 설치 패키지 형식이 아니라 Shadowrocket 자체의 Global Routing 모드입니다. 이 모드는 클라이언트로 들어온 트래픽의 처리 방식을 정하며, 모든 Linux 프로그램이 데스크톱 프록시를 자동으로 따르게 하지는 않습니다. 테스트할 때는 설정을 한 번에 하나씩만 바꾸고 변경 전후의 접속 결과를 기록하세요.
Config
권장활성 구성의 규칙과 정책에 따라 요청을 처리합니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 IP 주소 대역을, GEOIP는 IP 주소의 지역 정보를 기준으로 매칭합니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다.
적합한 경우: 유효한 규칙 설정을 일상적으로 사용하는 경우
Proxy
클라이언트로 들어온 요청을 현재 프록시 정책으로 보냅니다. 규칙 분기의 영향을 줄여 테스트할 때 사용할 수 있습니다. Proxy에서는 연결되지만 Config에서는 되지 않는다면 Config에서 규칙 순서와 정책 참조를 확인하세요.
적합한 경우: 서버와 프록시 경로를 일시적으로 확인할 때
Direct
클라이언트로 들어온 요청을 직접 연결로 처리합니다. 같은 네트워크에서 비교할 때 유용하지만 결과는 현재 네트워크 상태에 따라 달라집니다. 직접 연결 결과만으로 서버 설정이 올바르다고 단정할 수는 없습니다.
적합한 경우: 로컬 네트워크와 프록시 경로의 차이를 비교할 때
Scene은 설정된 장면에 따라 해당 동작을 적용하는 기능이며, 항상 ‘모든 트래픽 프록시’로 작동하는 스위치가 아닙니다. 아직 장면을 만들지 않았다면 Config, Proxy, Direct 중 하나를 명확히 선택해 기본 동작부터 확인하세요. 자동 연결은 수동 연결을 확인한 뒤 설정해야 자동 동작이 문제 해결을 방해하지 않습니다.
설치·업데이트·삭제 관련 자주 묻는 질문
설치는 완료됐는데 창이 열리지 않아요.
먼저 사용 가능한 그래픽 데스크톱 세션이 있는지 확인하세요. AppImage는 실제 경로를 사용해 터미널에서 실행하고 오류 메시지를 확인합니다. deb / rpm을 설치했다면 패키지 관리자 작업이 완료됐는지 확인한 다음 데스크톱 메뉴에서 실행하세요. 명령줄만 사용할 수 있는 원격 세션은 로컬 그래픽 데스크톱과 다릅니다.
새 설치 파일을 다운로드한 뒤 기존 파일 위에 바로 덮어써도 되나요?
먼저 Config에서 활성 구성을 백업하고 기존 구독 정보도 안전하게 보관하세요. deb / rpm은 같은 패키지 관리자를 사용해 새 로컬 패키지를 설치하고 업그레이드는 패키지 관리자에 맡기세요. AppImage는 기존 프로세스를 종료한 다음 새 파일을 저장하고 실행 권한을 설정한 뒤 실행해 확인하세요.
세 가지 형식을 모두 설치해야 하나요?
대개 한 가지 형식만 있으면 충분합니다. 앱이 여러 개 설치되어 있으면 메뉴 항목이 중복되어 어떤 앱이 실행 중인지 헷갈릴 수 있습니다. 형식을 바꾸기 전에 앱을 종료하고 설정을 백업하세요. 기존 설치 방식에 따라 이전 앱을 제거하고, 시스템 패키지 관리 디렉터리의 파일을 직접 삭제하지 마세요.
삭제할 때 어떤 패키지 이름을 사용해야 하나요?
다운로드 파일명만 보고 패키지 이름을 추측하지 마세요. deb는 dpkg-deb -f "$pkg" Package, rpm은 rpm -qp --queryformat '%{NAME}\n' "$pkg"로 패키지 이름을 확인할 수 있습니다. 변수에는 보관해 둔 해당 설치 파일의 경로가 들어 있어야 합니다. 확인한 패키지 이름을 시스템 소프트웨어 관리자에서 찾아 제거하세요.
창은 정상적으로 열리지만 구독 업데이트 시간이 초과돼요.
설치 문제와 네트워크 문제를 구분하세요. 시스템 시간이 정확하고 네트워크를 사용할 수 있는지 확인한 뒤 서비스 제공업체에서 받은 링크가 온전히 입력됐는지 살펴보세요. 업데이트 중 발생한 오류 메시지를 기록하세요. 로그를 공유하기 전에 링크에 포함된 token, 서버 인증 정보 등 민감한 내용은 삭제하세요.
AppImage를 제거하려면 보통 프로그램을 종료한 뒤 해당 파일을 삭제하면 됩니다. 별도로 데스크톱 바로 가기를 만들었다면 직접 만든 바로 가기 파일도 정리해야 합니다. 어떤 형식이든 프로그램 제거와 사용자 설정 삭제가 항상 한 번에 이뤄지는 것은 아닙니다. 재설치하거나 다른 기기로 옮길 계획이라면 먼저 백업이 제대로 됐는지 확인한 뒤 사용자 데이터를 삭제할지 결정하세요.