Shadowrocket Linux 설치 가이드: deb·rpm·AppImage 선택과 apt·dnf 명령어

1. Linux 설치 파일 선택: 배포판과 아키텍처 확인

Linux에서는 데스크톱 모양이 아니라 시스템의 패키지 관리 방식에 맞춰 형식을 선택해야 합니다. Ubuntu, Debian 및 같은 패키지 관리 체계를 사용하는 배포판은 보통 deb를 선택하고, Fedora처럼 dnf를 사용하는 시스템은 rpm을 선택합니다. 앱 파일을 별도로 보관하고 싶다면 AppImage가 현재 시스템 환경에 맞는지 확인하세요. rpm은 파일 형식일 뿐, rpm을 사용하는 모든 배포판에서 dnf를 쓰는 것은 아닙니다.

1. 시스템 확인

   터미널을 열고 cat /etc/os-release를 실행해 ID와 ID_LIKE를 확인하세요. 파일 관리자나 데스크톱 테마로 판단하지 말고, 배포판 공식 안내에서 패키지 관리자를 확인하는 것이 좋습니다.

2. 아키텍처 확인

   uname -m을 실행하세요. 일반적으로 x86_64는 64비트 x86, aarch64는 64비트 ARM을 뜻합니다. 다운로드 페이지에 표시된 설치 파일의 아키텍처와 일치해야 합니다.

3. 파일 받기

   다운로드 페이지의 Linux 섹션에서 시스템에 맞는 파일을 선택하세요. 일치하는 아키텍처가 없다면 확장자를 바꾸거나 권한을 반복해서 부여해 실행하려고 하지 마세요.

4. 작업 디렉터리 준비

   파일 관리자에서 다운로드한 파일이 있는 폴더를 열고 해당 위치에서 터미널을 실행하세요. 아래 명령어는 모두 파일이 있는 디렉터리에서 실행합니다. 경로에 공백이 있다면 디렉터리 이동 시 전체 경로를 따옴표로 묶으세요.

cat /etc/os-release
uname -m
pwd
ls -lh

Linux에서 uname -m은 시스템 아키텍처만 보여 주며, 특정 AppImage의 모든 실행 의존성이 충족되는지는 확인할 수 없습니다. deb 패키지의 amd64는 보통 시스템 출력의 x86_64와 같은 아키텍처를 뜻합니다. 이름이 다르다고 파일 형식을 변환할 필요는 없습니다. 다운로드 페이지의 표시와 패키지 내부 정보를 함께 확인하세요.

2. Debian / Ubuntu: apt로 로컬 deb 설치

Debian과 Ubuntu에서 로컬 deb를 설치할 때는 apt install ./파일명.deb를 사용해 패키지 관리자가 의존성도 함께 처리하도록 하세요. 파일 관리자에서 방금 다운로드한 deb의 이름을 shadowrocket.deb로 바꾸고, 현재 디렉터리에 설치할 파일만 있는지 확인한 뒤 아래 명령어를 실행합니다. 이름 변경은 입력을 편하게 하기 위한 것으로, 패키지 내부 이름이나 아키텍처에는 영향을 주지 않습니다.

dpkg-deb -f ./shadowrocket.deb Package Architecture
sudo apt update
sudo apt install ./shadowrocket.deb

Debian 계열에서 첫 번째 줄은 패키지의 이름과 아키텍처를 확인하며 설치하지 않습니다. 두 번째 줄은 설정된 소프트웨어 저장소의 색인을 갱신하고, 세 번째 줄은 현재 디렉터리의 로컬 파일을 설치합니다. ./를 임의로 생략하면 apt가 다운로드한 파일 대신 패키지 이름으로 검색할 수 있습니다. sudo 비밀번호를 입력할 때 터미널에 문자가 표시되지 않는 것은 정상입니다.

• 파일을 찾을 수 없다는 메시지가 표시됨: 먼저 pwd와 ls -lh를 실행해 터미널의 현재 디렉터리, 대소문자, 실제 확장자를 확인하세요. 웹 주소를 로컬 파일 인수로 입력하지 마세요.
• 의존성을 충족할 수 없다는 메시지가 표시됨: 누락된 의존성의 이름과 버전 조건을 기록하고 시스템 버전 및 소프트웨어 저장소가 맞는지 확인하세요. 설치를 위해 다른 배포판의 저장소를 섞어 추가하지 마세요.
• 아키텍처가 일치하지 않는다는 메시지가 표시됨: dpkg-deb 출력과 시스템 아키텍처를 비교해 올바른 파일을 다시 선택하세요. 실행 권한을 설정해도 아키텍처 문제는 해결되지 않습니다.
• 잠금이 사용 중이라는 메시지가 표시됨: 시스템 업데이트 프로그램이나 다른 apt 프로세스가 실행 중인지 확인하고 완료될 때까지 기다리세요. 잠금 파일을 직접 삭제하지 마세요.

3. Fedora: dnf로 로컬 rpm 설치

Fedora에서는 dnf로 로컬에 다운로드한 rpm을 설치할 수 있습니다. 다운로드한 파일의 이름을 로컬에서 shadowrocket.rpm으로 바꾸고 파일이 있는 디렉터리로 이동한 다음, 패키지 정보를 확인하고 설치하세요. dnf를 사용하지 않는 다른 rpm 기반 시스템에서는 해당 배포판의 패키지 관리 절차를 따르세요. Fedora 명령어를 그대로 사용하지 마세요.

rpm -qp --queryformat '%{NAME} %{ARCH}\n' ./shadowrocket.rpm
sudo dnf install ./shadowrocket.rpm

Fedora에서 rpm -qp는 아직 설치되지 않은 패키지 파일의 내부 이름과 아키텍처를 조회합니다. dnf install은 설치와 의존성 해결을 담당합니다. 확인 목록이 표시되면 설치·업그레이드·삭제될 항목을 먼저 확인한 뒤 진행 여부를 결정하세요. 예상과 달리 많은 항목이 삭제될 예정이라면 중단하고 시스템 호환성을 확인하세요.

Fedora에서 다운로드 실패, 의존성 충돌, 서명 관련 안내는 각각 구분해 확인해야 합니다. 의존성 다운로드에 실패하면 시스템 저장소와 네트워크를 점검하세요. 의존성 충돌이 발생하면 관련 패키지 이름과 조건을 확인하세요. 출처나 서명 관련 메시지가 표시되면 파일이 사이트 다운로드 페이지에서 받은 것인지와 시스템 정책을 확인하고, 검사를 건너뛰는 방법을 일반적인 설치 절차로 사용하지 마세요.

4. AppImage: 실행 권한을 설정하고 터미널에서 실행

Linux의 AppImage는 apt나 dnf로 설치하지 않지만, 프로세서 아키텍처·시스템 라이브러리·마운트 방식·데스크톱 환경의 영향을 받습니다. ‘설치 불필요’는 파일을 보관해 실행할 수 있다는 뜻이지, 모든 배포판에서 바로 실행된다는 뜻은 아닙니다. 다운로드한 파일의 이름을 로컬에서 Shadowrocket.AppImage로 바꾸고, 현재 사용자가 쓰기 권한을 가지고 프로그램 실행이 허용된 디렉터리에 두세요.

ls -l ./Shadowrocket.AppImage
chmod u+x ./Shadowrocket.AppImage
./Shadowrocket.AppImage

AppImage에서는 chmod u+x로 파일 소유자에게 실행 권한을 부여할 수 있습니다. 이는 chmod +x를 대상 사용자로 한정한 명령입니다. 명령어 앞의 ./는 현재 디렉터리에 있는 파일을 실행한다는 뜻입니다. 파일명만 입력하면 터미널은 보통 PATH에 지정된 디렉터리만 검색합니다. 처음에는 터미널에서 실행하면 더블 클릭으로 확인하기 어려운 오류 메시지를 볼 수 있습니다.

이동식 디스크나 공유 디렉터리에 둔 AppImage는 ls -l에서 실행 가능으로 표시되더라도 마운트 정책에 의해 실행이 차단될 수 있습니다. 파일을 홈 디렉터리 아래의 실행 가능한 위치로 옮긴 뒤 다시 시도해 보세요. 다운로드 디렉터리 전체 권한을 재귀적으로 변경하거나, 모든 사용자에게 쓰기 권한을 주거나, 시스템 보안 기능을 끄는 방식으로 오류 원인을 찾으려 하지 마세요.

5. 첫 실행: 설치 성공과 연결 상태 구분

Linux에서 Shadowrocket 창이 열렸다면 앱이 실행된 것입니다. 이것만으로 프록시 연결까지 사용할 수 있다고 판단할 수는 없습니다. 이후 설정은 사용자가 이미 보유한 서비스와 구독을 전제로 합니다. 사이트에서는 노드나 구독을 제공·판매·추천하지 않습니다. 기존 설정을 먼저 가져온 다음 Home의 연결 상태와 Global Routing을 확인하세요. 설정이 비어 있다면 설치 파일을 반복해서 다시 설치하지 마세요.

1. 설치한 앱은 데스크톱 앱 목록에서 열고, AppImage는 저장한 파일을 실행하세요. 시스템 권한 요청이 표시되면 사용 목적을 확인한 후 필요한 작업에 맞게 허용하세요.
2. Config에서 현재 사용 중인 설정과 사용자가 보유한 구독의 가져오기 결과를 확인하세요. 예시 주소 https://example.com/sub?token=xxxx는 형식을 설명하기 위한 것이며, 실제로 사용할 수 있는 구독이 아닙니다.
3. Home으로 돌아가 SERVER 목록과 선택 항목, Global Routing을 확인하세요. 연결 스위치가 계속 Not Connected로 표시되면 먼저 연결 상태를 점검하세요.
4. 설정을 확인하고 연결을 수립한 다음 Connectivity Test로 결과를 확인하세요. 테스트 시간 초과가 deb, rpm 또는 AppImage 설치 실패를 뜻하는 것은 아닙니다. 테스트 대상, 네트워크, 설정을 계속 확인하세요.

Global Routing을 제공하는 화면에서 Config, Proxy, Direct, Scene은 라우팅 방식이지 설치 파일 형식이 아닙니다. 아래 비교는 앱이 연결을 처리하는 범위에만 해당합니다. 시스템 트래픽이 앱으로 전달되는지는 실제 트래픽 처리 방식과 권한에도 달려 있습니다. 처음 확인할 때는 테스트 대상을 하나로 고정하고 설정을 한 번에 하나씩만 변경하세요. 모드, DNS, 구독을 동시에 바꾸면 원인을 찾기 어려워집니다.

화면에 Scene이 표시된다면 해당 장면의 설정부터 확인한 뒤 실제 동작을 판단하세요. Scene을 고정된 전역 프록시나 직접 연결 모드로 간주하지 마세요. Linux 빌드에 따라 화면 구성이 다르면 현재 앱에 표시되는 이름을 기준으로 하세요. 시스템 연결 권한, 앱 라우팅, 서버 연결 상태는 각각 따로 확인해야 합니다.

6. 업데이트 및 문제 기록: 설정을 보존하고 재설치 반복 피하기

Linux에서 업데이트하기 전에 필요한 설정 자료를 먼저 보관하세요. 특히 구독 출처, 직접 입력한 서버 매개변수, 규칙 파일을 확인해야 합니다. 설치 형식이 다르면 데이터 디렉터리도 같을 것이라고 가정하지 말고, 앱 파일을 삭제하면 설정이 모두 삭제된다고 생각하지 마세요. token, 비밀번호, 개인 키가 포함된 내용은 별도로 보호하고 공개 문제 기록에 첨부하지 마세요.

• deb 업데이트: 다운로드 페이지에서 적합한 파일을 받은 뒤 로컬 deb 설치 명령어를 실행하세요. 파일명으로 업데이트 여부를 추측하지 말고 패키지 관리자에서 패키지 버전을 확인하세요.
• rpm 업데이트: 로컬 rpm도 dnf로 처리하고 트랜잭션 요약을 확인하세요. 충돌이 발생하면 오류 메시지를 원문 그대로 기록하고 시스템 파일을 강제로 덮어쓰지 마세요.
• AppImage 업데이트: 실행 중인 인스턴스를 먼저 종료하고 설정을 보관한 다음 파일을 교체하세요. 새 파일의 실행 권한을 다시 확인해야 하며, 데스크톱 바로 가기의 대상 경로도 수정해야 할 수 있습니다.
• 창이 중복되거나 이전 프로그램이 실행됨: deb, rpm, AppImage의 실행 항목이 동시에 남아 있는지 확인하세요. 현재 실행 중인 파일이 무엇인지 먼저 확인한 뒤 사용할 설치 방식을 결정하세요.

Linux 설치 문제를 점검할 때는 ‘파일 일치 여부 → 패키지 관리자 또는 실행 권한 → 앱 실행 → 설정 및 연결’ 순서를 따르세요. 첫 단계에서 문제가 발생한 경우에만 설치 파일을 다시 선택하면 됩니다. 창이 정상적으로 열리면 앱 설정과 네트워크 진단을 우선 확인하고, 반복적인 삭제와 재설치로 실제 문제를 덮지 마세요.