Shadowrocket 사용 안내

1. 서버 추가 또는 구독 가져오기

먼저 보유한 정보의 종류를 확인하고 해당 메뉴를 선택합니다. 구독 주소는 보통 서버 목록을 가져오고 업데이트하는 데 사용합니다. 서버 공유 링크는 하나의 연결 정보를 담고 있으며, 주소·포트·비밀번호처럼 개별 항목으로 받은 정보는 직접 입력해야 합니다. 웹 주소 모양이 비슷해도 용도는 다를 수 있습니다. 계정 관리 페이지나 안내 페이지는 구독 주소를 대신할 수 없습니다.

기존 구독: Subscribe 사용

Shadowrocket을 열고 Config 페이지에서 Subscribe를 찾습니다. 구독 관련 메뉴에 기존 구독 주소를 입력하고 화면 안내에 따라 가져오기를 확인하세요. 주소를 복사할 때는 물음표 뒤의 쿼리 매개변수를 포함해 전체 내용을 유지해야 합니다. 앞뒤에 공백이나 줄바꿈, 한글 문장 부호가 붙지 않았는지도 확인하세요. 주소에 포함된 인증 정보는 민감한 정보이므로 공개 댓글에 올리지 말고, 문제를 보여주기 위해 전체 링크를 공개하지 마세요.

제출한 뒤 오류 메시지가 표시되는지 확인하고 Home으로 돌아가 SERVER 영역을 살펴봅니다. 목록에 선택 가능한 서버가 실제로 표시되어야 가져오기가 완료된 것입니다. 입력 창이 닫힌 것만으로 성공 여부를 판단하지 마세요. 기존 구독에서 업데이트를 지원한다면 다음 업데이트 때 원격 정보를 다시 가져옵니다. 구독 내용에 따라 서버 이름, 개수, 매개변수가 바뀔 수 있으며 직접 수정한 항목도 업데이트 후 확인해야 합니다.

구독 주소와 전체 구성 파일 주소는 서로 다른 정보입니다. 구독 주소는 주로 서버 정보를 관리하는 데 쓰이며, 구성 파일에는 규칙이나 도메인 매핑 같은 설정이 포함될 수 있습니다. 가져온 뒤 구성 항목만 보이고 서버가 없다면 먼저 정보의 용도를 확인하세요. 같은 주소를 여러 메뉴에 반복해서 붙여넣지 마세요.

기존 서버 정보 입력: Add Server 사용

Home으로 돌아가 항목 추가 버튼을 누른 다음 Add Server를 엽니다. 보유한 정보에 맞는 프로토콜을 선택하고 서버 주소, 포트, 인증 정보를 입력하세요. 프로토콜에 따라 입력 항목이 달라집니다. 두 프로토콜 모두 비밀번호나 UUID를 사용한다고 해서 같은 설정으로 취급하면 안 됩니다.

예를 들어 Shadowsocks는 암호화 방식과 비밀번호를 확인해야 합니다. VMess와 VLESS는 정보에 기재된 UUID와 관련 항목을 확인하고, Trojan은 비밀번호와 TLS 설정을 함께 살펴봅니다. 전송 방식, TLS, 서버 이름, 경로 등 추가 매개변수도 하나씩 대조하세요. 제공된 정보에 없는 항목을 임의로 채우지 말고, 인증서 확인을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 확인이 끝나면 저장하고 SERVER로 돌아가 해당 항목을 선택합니다.

기존 공유 링크 또는 QR 코드

서버 공유 링크라면 앱의 클립보드 가져오기 기능을 사용할 수 있습니다. QR 코드라면 Scan QR Code를 선택하고 시스템 안내에 따라 카메라 접근을 허용하세요. 스캔하거나 인식한 뒤에도 프로토콜, 주소, 포트를 확인해야 합니다. 가져오기에 성공했다는 것은 앱이 내용을 인식했다는 뜻일 뿐, 원격 서버까지 검증되었다는 의미는 아닙니다. QR 코드에도 비밀번호나 인증 정보가 포함될 수 있으므로 원본 링크와 같은 수준으로 안전하게 보관하세요.

이 단계에서는 Home에 명확한 서버 항목이 표시되고 사용할 항목이 선택되어 있어야 합니다. 확인을 마친 뒤 트래픽 처리 방식을 설정하세요. 메뉴와 형식의 차이는 구독 가져오기 메뉴 안내에서, 각 항목의 의미는 용어 설명에서 확인할 수 있습니다.

2. Global Routing 선택

Home에서 Global Routing을 누릅니다. 여기서 트래픽 처리 방식을 정합니다. 앞 단계에서 서버를 선택하는 것과는 별개의 설정입니다. 서버를 선택했다고 모든 연결이 그 서버를 거치는 것은 아닙니다. 반대로 프록시 모드를 선택해도 서버 정보가 잘못되어 있으면 연결할 수 없습니다.

구성(Config): 현재 규칙에 따라 처리

구성(Config)은 규칙이 설정된 구성을 평소에 사용할 때 적합합니다. 앱은 현재 구성의 규칙에 따라 연결 경로를 정하며 PROXY, DIRECT, REJECT 등의 정책을 적용할 수 있습니다. 따라서 같은 연결 세션에서도 도메인에 따라 처리 결과가 다를 수 있으며, 규칙에 따른 정상 동작일 수 있습니다. 이 모드를 선택하기 전에 Config에서 현재 적용 중인 구성을 확인하세요. 파일이 목록에 있다는 것만으로는 적용 여부를 알 수 없습니다.

처음 설정할 때 규칙을 작성할 필요는 없습니다. 현재 구성의 출처와 내용이 확실하지 않다면 서버 연결부터 확인한 뒤 이 구성을 사용할지 결정하세요. 규칙의 매칭 순서와 기본 정책, 구문은 규칙 및 구성 참고에서 확인할 수 있습니다. 첫 연결 단계에서 함께 수정할 필요는 없습니다.

프록시(Proxy): 규칙의 영향을 먼저 분리

프록시(Proxy)는 첫 연결 확인이나 비교 점검에 사용할 수 있습니다. 일반적으로 앱이 처리하는 연결을 프록시로 전달하므로 ‘서버 자체에 연결할 수 없는 문제’와 ‘규칙이 연결 경로를 바꾼 문제’를 구분하는 데 도움이 됩니다. 서버 품질 테스트를 대신하지 않으며 모든 대상에 접속할 수 있다고 보장하지도 않습니다. 시스템 차원의 트래픽 예외나 앱 자체의 연결 방식도 실제 결과에 영향을 줄 수 있습니다.

직접 연결(Direct): 대상에 바로 연결

직접 연결(Direct)은 선택한 프록시 서버를 거치지 않고 대상에 바로 연결합니다. 서버가 정상인지 확인하는 중에 이 모드를 계속 사용하면 웹 페이지가 열려도 프록시 연결이 작동한다는 증거가 되지 않습니다. 이 모드로 바꾸더라도 Home의 연결 스위치가 꺼지는 것은 아닙니다. 라우팅 선택과 시스템 연결 상태는 별도로 확인하세요.

처음 설정할 때는 Proxy를 선택하고 같은 서버로 다음 단계를 확인하세요. 작동을 확인한 뒤 Config로 바꾸어 평소 규칙이 어떻게 적용되는지 살펴봅니다. 모드를 바꿀 때마다 새로 접속해 브라우저에 남은 기존 연결이 결과에 영향을 주지 않도록 하세요.

3. 스위치 켜기 및 승인

Home으로 돌아가 SERVER에서 선택한 항목과 현재 Global Routing 모드를 다시 확인한 다음 연결 스위치를 켭니다. 연결 전에는 Not Connected 등의 상태가 표시될 수 있습니다. 스위치를 켠 뒤 상태가 바뀌는지, 곧바로 연결이 끊기는지 확인하세요. 시스템 확인 창을 처리하기 전에 스위치를 연속으로 켜고 끄지 마세요.

처음 사용할 때 Shadowrocket에서 VPN 구성을 추가하도록 요청하는 시스템 안내가 표시될 수 있습니다. 이 안내는 앱이 시스템 네트워크 구성을 생성하도록 허용하는 절차이며, 앱을 다시 구매하라는 뜻도 서버 정보를 대신 입력해 준다는 뜻도 아닙니다. 방금 실행한 Shadowrocket이 요청한 것인지 확인하고 시스템 안내에 따라 허용한 뒤 기기 암호나 본인 인증을 완료하세요. 인증은 기기의 시스템 화면에서 진행하고, 기기 암호를 서버 입력 양식이나 웹 페이지에 입력하지 마세요.

이전에 안내를 취소했다면 앱으로 돌아가 다시 연결을 시도하고 실제로 표시되는 안내에 따라 진행하세요. 시스템 설정에서 VPN을 검색해 Shadowrocket의 구성 상태를 확인할 수도 있습니다. 진행하기 전에 기기가 조직의 관리를 받는지, 관련 제한이 있는지 확인하세요. 관리 제한이 명확하다면 기기 관리 정책에 따라 처리하고, 정체를 알 수 없는 시스템 구성을 계속 삭제하지 마세요.

승인을 마친 뒤 Home으로 돌아가 연결 상태를 확인합니다. 시스템에 VPN이 연결된 것으로 표시되면 기기의 네트워크 트래픽 처리가 시작된 것입니다. 그렇다고 원격 서버, DNS, 대상 웹사이트가 모두 정상이라는 뜻은 아닙니다. 다음으로 실제 접속을 확인해야 합니다. 스위치를 켜자마자 꺼진다면 바로 재설치하기보다 시스템 안내와 앱의 오류 메시지를 먼저 기록하세요.

첫 연결을 확인하는 동안에는 On Demand 설정을 그대로 두세요. 자동 연결 조건과 수동 스위치를 혼동하지 않도록 하기 위해서입니다. 스위치를 끈 뒤에도 연결이 자동으로 다시 설정된다면 On Demand가 활성화되어 있는지와 작동 조건을 확인하세요. 수동 연결이 안정적으로 완료된 뒤 사용 목적에 맞게 자동 연결을 설정합니다.

4. 연결이 실제로 작동하는지 확인

확인은 세 단계로 나뉩니다. 서버 테스트 통과 여부, 시스템 연결 유지 여부, 대상 요청의 정상 처리 여부입니다. 서로 관련은 있지만 어느 하나가 다른 항목을 대신하지는 않습니다. 각 단계의 결과를 따로 기록하면 막연히 ‘연결이 안 된다’고 설명하는 것보다 원인을 찾기 쉽습니다.

먼저 Connectivity Test 확인

Home에서 Connectivity Test를 실행하고 현재 서버의 테스트 결과를 확인합니다. 테스트 방식과 대상에 따라 결과가 달라지므로 한 번 성공했다고 모든 웹사이트가 정상인 것은 아니며, 한 번 시간 초과가 발생했다고 모든 연결을 사용할 수 없는 것도 아닙니다. 서버가 여러 개라면 테스트 결과가 어느 항목에 해당하는지, 실제로 선택된 항목은 무엇인지 확인하세요.

테스트 수치만으로 결론을 내리지 마세요. 테스트 요청의 경로와 대상은 실제 서비스 요청과 다를 수 있습니다. 계속 실패한다면 그때 매개변수, 현재 네트워크, 원격 서버 상태를 확인하세요. 한 번의 테스트 결과를 개선하려고 DNS, TLS, 프로토콜, 라우팅 모드를 한꺼번에 바꾸면 결과를 비교하기 어렵습니다.

새 요청으로 실제 접속 확인

연결을 켠 상태로 브라우저를 열고 평소 사용하며 정상 응답을 확인한 HTTPS 페이지에 새로 접속하세요. 기존 탭을 새로고침하면 캐시가 표시될 수 있으므로 새 요청을 보내고 페이지 내용이 실제로 로드되는지 확인하는 편이 좋습니다. 몇 개의 서로 다른 대상으로 교차 확인하되, 한 웹사이트의 실패만으로 전체 연결을 판단하지 마세요.

브라우저에서는 접속되지만 특정 앱에 문제가 있다면 앱에 기존 연결이 남아 있는지, 로그인·권한·서비스 상태에 문제가 있는지 먼저 살펴보세요. 해당 앱을 다시 연 뒤 결과를 비교합니다. 확인하기 전부터 계정 오류, 대상 서비스 점검, 웹페이지 자체의 오류를 Shadowrocket 문제로 단정하지 마세요.

마지막으로 규칙 처리 결과 확인

Proxy에서 정상 작동을 확인한 뒤 Config로 전환하고 같은 대상에 다시 접속합니다. 더 자세히 확인하려면 Data에서 확인 가능한 연결 정보를 살펴보고 대상 도메인, 일치한 규칙, 정책을 함께 검토해 연결 경로를 판단하세요. 트래픽이 늘었다는 사실만으로 요청이 선택한 서버를 거쳤다고 단정할 수는 없습니다. 기록만으로 판단하기 어렵다면 ‘아직 확인되지 않음’으로 남기고 추측을 검증 결과처럼 취급하지 마세요.

Proxy에서는 정상인데 Config에서 문제가 생긴다면 서버 매개변수보다 현재 구성, 규칙, DNS를 중점적으로 확인해야 합니다. 정상 작동하는 서버 설정은 유지하고 규칙 참고에서 해당 규칙을 살펴보세요. 모든 단계를 처음부터 다시 설정할 필요는 없습니다.

5. 실패한 단계별로 확인

먼저 어느 단계에서 멈췄는지 확인합니다. 가져온 내용이 없음, 서버는 있지만 테스트 실패, 시스템 승인 실패, 연결은 유지되지만 대상에 접속할 수 없음 중 어디에 해당하나요? 한 번에 하나의 항목만 바꾸고 테스트 결과를 기록하세요. 개선되지 않으면 원래 설정으로 되돌린 뒤 다음 항목을 확인합니다. 이렇게 하면 검증된 설정을 유지하면서 관련 문제 안내를 이어서 확인할 수 있습니다.

가져온 뒤 서버가 표시되지 않음

입력한 것이 구독 주소인지, 단일 서버 공유 링크인지, 구성 파일 주소인지 다시 확인하고 정보 유형에 맞는 메뉴를 사용했는지 살펴보세요. 메신저에서 링크가 잘리지 않았는지, 쿼리 매개변수가 빠지지 않았는지, 인증 정보가 유효한지도 확인합니다. 업데이트 결과로 로그인 페이지나 오류 안내가 반환된다면 주소가 열리더라도 앱에서 인식할 수 있는 구독 내용이 반환된 것은 아닙니다.

현재 네트워크에서 구독 내용을 가져올 수 있는지, 기존 구독을 제공하는 관리 페이지에서 상태를 갱신해야 하는지도 확인하세요. 반환된 오류를 먼저 살펴보고 같은 주소를 계속 추가하지 마세요. 같은 항목이 여러 개 생겨 구분하기 어려워질 수 있습니다. 문제를 외부에 설명할 때는 오류 유형만 남기고 전체 구독 주소와 인증 정보를 숨기세요.

서버는 있지만 테스트가 계속 실패함

서버 주소, 포트, 프로토콜 유형부터 확인한 다음 비밀번호, UUID, 암호화 방식 등의 인증 정보를 살펴보고 마지막으로 TLS, 서버 이름, 전송 매개변수를 확인합니다. 숫자 포트를 잘못 입력하지 않았는지, 비밀번호 앞뒤에 공백이 붙지 않았는지, 경로를 빠뜨리지 않았는지 특히 주의하세요. 항목 이름만 확인하지 말고 실제 값이 보유한 서버 정보와 일치하는지 대조해야 합니다.

본인이 사용할 수 있는 다른 네트워크에서도 같은 테스트를 반복해 현재 Wi-Fi나 셀룰러 네트워크의 영향인지 확인할 수 있습니다. 네트워크를 바꾸기 전에 기기의 데이터 사용 설정을 살펴보세요. 서로 다른 네트워크에서도 같은 항목의 테스트가 실패한다면 결과를 기록해 기존 서비스 제공자에게 서버 상태와 정보를 확인하세요. 인증 오류를 해결하려고 모드만 계속 바꾸지 마세요.

연결은 켜져 있지만 페이지가 열리지 않음

먼저 Direct 모드가 선택되어 있지 않은지 확인한 뒤 같은 대상을 Proxy와 Config에서 각각 확인합니다. Config에서만 실패한다면 현재 적용 중인 구성에 예상하지 못한 REJECT, 적절하지 않은 DIRECT, 잘못된 기본 정책이 있는지 살펴보세요. 두 모드에서 모두 실패한다면 규칙만 수정하지 말고 서버, DNS, 대상 사이트 상태도 확인하세요.

인증서 오류가 발생하면 먼저 기기 시간, 서버 이름, TLS 매개변수를 확인하고 인증서 확인을 건너뛰는 설정을 기본 해결책으로 사용하지 마세요. 일부 도메인만 실패한다면 해당 도메인과 발생 시각을 기록한 뒤 관련 연결 정보를 살펴보세요. 모든 구성을 지울 필요는 없습니다. DNS 변경은 도메인 해석 결과에 영향을 줄 수 있지만, 오류 근거를 확인하고 조정해야 합니다. 여러 설정을 무작정 추가하지 마세요.

다음 문제 해결을 위해 필요한 정보 기록

다음 네 가지를 기록해 두세요. 실패한 단계, 당시의 Global Routing 모드, 앱에 표시된 오류 원문, 네트워크나 모드를 바꾼 뒤의 변화입니다. 비밀번호, UUID, 전체 구독 링크, 인증 정보가 담긴 QR 코드는 기록에 포함하지 마세요. 추가 도움을 요청하기 전에 스위치 색깔만 설명하지 말고 어느 단계에서 성공하고 실패했는지 정리해 두세요.

첫 연결을 마친 뒤에는 기존 구독을 관리하고 현재 서버와 구성을 확인하며 이상 변화를 살펴보면 됩니다. 연결 및 가져오기에 관한 다른 사례는 자주 묻는 질문을, On Demand와 FINAL 같은 용어는 용어 설명을 참고하세요. 구성 세부 사항은 규칙 참고에서 확인할 수 있습니다. 이 페이지의 완료 기준은 기존 서버에 연결할 수 있고 실제 요청으로 작동 여부를 확인했으며 문제가 생겼을 때 어디서부터 점검할지 아는 것입니다.