Shadowrocket 서버 추가, 규칙 기반 라우팅 및 연결 확인

준비 확인: 입력 정보가 완전한지 먼저 확인

처음 조작하기 전에 보유한 정보를 두 종류로 나눕니다. 첫 번째는 단일 서버 정보로, 일반적으로 프로토콜 유형, 서버 주소, 포트와 인증 필드가 포함됩니다. 일부 프로토콜에는 전송 방식, TLS, SNI, Public Key, Private Key 또는 기타 매개변수가 추가될 수 있습니다. 두 번째는 서비스 제공자가 제공하는 구독 링크로, 여러 서버 기록을 한 번에 가져오고 업데이트하는 데 사용됩니다. 두 종류 중 한 가지 방식만 선택해 가져오면 되며 중복으로 추가할 필요는 없습니다.

Shadowrocket을 연 뒤 먼저 Home에 머뭅니다. 이 화면에서 현재 서버를 확인하고 연결 대상을 선택하며 Global Routing을 설정하고 연결 스위치를 제어합니다. 하단의 Config에서는 규칙 Config를 관리하고, Data에서는 연결로 생성된 데이터를 확인하며, Settings에는 DNS, On Demand, Log 등 클라이언트 설정이 있습니다. 먼저 이러한 진입점을 익혀 두면 이후 화면을 잘못 찾아가는 일을 줄일 수 있습니다.

기기에 Shadowrocket이 없다면 먼저 사이트의 App Store 다운로드 안내에서 제품 페이지를 확인합니다. 개발자명은 Shadow Launch Technology Limited이고 앱 ID는 932747118이어야 합니다. iPhone, iPad 및 App Store 호환성 항목에 표시된 기타 Apple 기기의 시스템 요구 사항은 App Store 페이지 표기를 따릅니다. 이 튜토리얼에서는 이어서 iPhone과 iPad의 기본 조작만 설명합니다.

서버 추가 또는 기존 구독 가져오기

Home에서 Add Server로 이동합니다. 보유한 정보에 따라 경로를 선택합니다. 명확한 서버 필드가 있다면 수동 추가를 사용하고, 구독 링크가 있다면 Subscribe로 이동합니다. 어느 경로를 완료하든 Home으로 돌아가 서버 항목이 표시되는지 확인한 뒤 Global Routing을 설정합니다.

경로 1: Add Server에서 수동 입력

Add Server에서 먼저 보유한 정보와 일치하는 프로토콜 유형을 선택합니다. 예를 들어 Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard 또는 Hysteria2를 선택할 수 있습니다. 프로토콜 이름은 유형을 선택하는 진입점일 뿐 서로 대체할 수 없습니다. 선택한 뒤 원본 정보에 따라 서버 주소, 포트 및 인증 필드를 하나씩 입력합니다. 화면에 추가 필드가 표시되더라도 서비스 제공자가 해당 값을 명확히 제공한 경우에만 입력합니다.

입력할 때 자주 발생하는 세 가지 문제에 특히 주의합니다. 첫째, 서버 주소 앞뒤에 공백을 넣지 말고 설명 문구까지 함께 복사하지 않습니다. 둘째, 포트는 포트 필드에 입력하며 주소와 같은 칸에 쓰지 않습니다. 셋째, 대소문자를 구분하는 인증 정보는 원문 그대로 유지합니다. 완료 후 저장하고 Home으로 돌아가 SERVER 목록에서 추가한 항목을 찾아 선택합니다. 현재 선택된 서버는 일반적으로 목록에서 상태가 다르게 표시됩니다.

보유한 정보가 QR 코드로 저장되어 있다면 해당 진입점에서 Scan QR Code를 사용할 수 있습니다. 스캔하기 전에 QR 코드가 실제로 보유한 서버 정보에서 생성된 것인지 확인합니다. 인식이 완료된 뒤에도 항목을 열어 프로토콜 유형과 주요 필드를 확인해 QR 코드 정보가 만료된 상태로 다음 단계로 넘어가지 않도록 합니다. 클라이언트 요구 사항에 맞는 Cloud JSON이 있다면 Import from Cloud JSON을 사용할 수 있으며, 가져온 뒤에도 Home으로 돌아가 항목을 확인해야 합니다.

경로 2: Subscribe로 가져오기

Add Server에서 Subscribe로 이동해 구독을 식별하기 쉬운 이름으로 지정한 다음 기존 구독 링크를 붙여넣고 저장합니다. 저장 후 업데이트를 실행하고 Shadowrocket의 파싱이 끝날 때까지 기다립니다. 업데이트가 성공하면 Home의 서버 목록에 해당 구독에서 가져온 항목이 표시됩니다. 목록에 변화가 없더라도 같은 구독을 반복해서 만들지 말고, 먼저 기존 구독 기록을 열어 링크가 완전한지 확인하고 업데이트 과정에 오류 메시지가 표시되었는지 살펴봅니다.

구독은 서버 기록을 업데이트하는 방식이며 연결이 이미 활성화되었다는 뜻은 아닙니다. 가져온 뒤에도 Home에서 특정 서버를 선택하고 Global Routing과 연결 스위치를 설정해야 합니다. 이후 구독 내용이 변경되면 같은 링크를 새로 만들지 말고 기존 구독 기록을 업데이트합니다. 이렇게 하면 중복 항목을 줄이고 현재 사용하는 정보 그룹을 쉽게 파악할 수 있습니다.

이 단계의 완료 기준은 간단합니다. Home으로 돌아왔을 때 직접 보유한 정보에서 생성된 서버 항목이 하나 이상 표시되고 선택할 수 있어야 합니다. Add Server 저장 후 항목이 없거나 Subscribe 업데이트 후 목록이 비어 있다면 문제는 아직 가져오기 단계에 있으므로 먼저 DNS나 Config를 조정할 필요가 없습니다.

Global Routing 방식 선택

서버 항목을 준비한 후 Home으로 돌아가 Global Routing을 찾습니다. 여기서 트래픽에 적용할 기본 처리 방식을 결정합니다. Shadowrocket에서 자주 사용하는 세 가지 방식은 구성 Config, 프록시 Proxy, 직접 연결 Direct입니다. 각각의 역할이 다르므로 선택하기 전에 이번 작업이 서버 자체를 확인하기 위한 것인지, 규칙에 따라 장기적으로 사용하기 위한 것인지 먼저 정해야 합니다.

처음 조작하는 경우 먼저 Proxy로 기본 연결을 확인하는 것이 좋습니다. 현재 서버가 작동하는 것을 확인한 뒤 Config로 전환해 규칙 기반 라우팅이 예상대로 이루어지는지 확인합니다. 이렇게 하면 “서버 자체에 연결할 수 없음”과 “Config 규칙이 예상대로 매칭되지 않음”을 두 가지 문제로 나누어 더 명확하게 점검할 수 있습니다.

Config를 선택하기 전에 하단의 Config를 열어 사용할 Config 파일이 실제로 선택되어 있는지 확인합니다. Config 파일이 비어 있거나 선택되지 않았거나 규칙 내용이 사용 목적과 맞지 않으면 요청 경로가 예상과 달라질 수 있습니다. 규칙은 일반적으로 순서대로 매칭되므로 더 구체적인 규칙을 적절한 위치에 배치하고, 최종적으로 매칭되지 않은 요청은 FINAL 등의 규칙으로 처리합니다. 규칙 문법과 DNS 조합 방식은 다양하므로 Settings 설정 안내서에서 계속 확인할 수 있습니다.

연결 스위치 활성화 및 시스템 권한 승인

Home에 머문 상태에서 현재 서버 이름과 Global Routing을 다시 확인한 다음 연결 스위치를 켭니다. 기기에서 처음 연결을 설정할 때 시스템은 VPN 구성 추가를 허용하도록 요청합니다. iOS 또는 iPadOS에 표시되는 안내를 확인하고 기기에서 요구하는 인증 방식으로 작업을 완료합니다. 시스템 권한 승인이 완료되지 않으면 Shadowrocket은 해당 시스템 네트워크 구성을 설정할 수 없습니다.

권한 승인 후 Shadowrocket으로 돌아가 연결 상태가 안정될 때까지 기다립니다. 스위치를 켠 직후 서버, Config 및 Global Routing을 연속해서 바꾸지 않습니다. 여러 항목을 동시에 변경하면 실패 원인을 판단하기 어려워집니다. 상태가 곧바로 연결 안 됨으로 돌아가면 당시 선택한 서버와 방식을 기록한 뒤 다음 절차에서 확인합니다. 스위치 색상만으로 모든 네트워크 단계가 정상이라고 판단하지 않습니다.

이전에 권한을 승인했더라도 시스템 설정이 변경되면 권한을 다시 확인해야 할 수 있습니다. 먼저 연결 스위치를 끄고 몇 초 기다린 뒤 다시 켭니다. 그래도 연결이 유지되지 않으면 기기에서 현재 Wi-Fi 또는 셀룰러 네트워크를 사용할 수 있는지 확인합니다. Shadowrocket은 정상적인 로컬 네트워크 위에서 연결을 설정하므로 로컬 네트워크 자체에 접속할 수 없다면 Global Routing을 바꾸는 것만으로는 기본 연결 문제가 해결되지 않습니다.

연결이 설정된 직후에는 On Demand를 활성화하지 않는 것이 좋습니다. On Demand는 조건에 따라 자동으로 연결을 실행하므로 수동 절차가 정상임을 확인한 뒤 설정하는 것이 적합합니다. 처음 점검할 때는 수동 스위치를 유지해야 각 작업이 언제 발생했는지 명확히 알 수 있습니다. On Demand를 계속 사용하려면 기본 절차를 완료한 뒤 Settings에서 설정하고 On Demand 설정 안내를 참고합니다.

Connectivity Test로 결과 확인

연결 스위치를 켠 상태에서 먼저 Home의 상태가 안정되었는지 확인한 다음 현재 서버에서 Connectivity Test를 실행합니다. 서버 항목의 작업 메뉴에서 같은 기능을 찾을 수 있습니다. 현재 화면 구성상 관련 메뉴 안에 있더라도 영어 화면 용어인 Connectivity Test를 기준으로 찾습니다. 테스트는 서버 관련 연결 단계를 확인하지만 한 번의 테스트 결과가 실제 접속 확인을 대신하지는 않습니다.

이어서 원래 접속하려던 페이지나 앱을 열고 정상적으로 로드되는지 확인합니다. 그다음 Shadowrocket으로 돌아가 Data에 새로운 연결 기록이 표시되는지 확인합니다. Config를 사용하는 경우 요청이 최종적으로 어떤 규칙에 매칭되었고 PROXY 또는 DIRECT 중 무엇을 사용했는지도 살펴봅니다. 연결 기록은 보이지만 페이지 로드가 완료되지 않는다면 시스템 스위치는 작동한 것이며, 문제는 서버 응답, DNS, 규칙 정책 또는 대상 서비스 계층에 있을 수 있습니다.

더 자세한 근거가 필요하면 Settings에서 Log 관련 항목을 확인합니다. Log는 도메인 확인, 규칙 매칭, 연결 설정 및 오류 메시지를 파악하는 데 유용하지만 도메인과 서버 주소 등 실행 정보가 포함될 수 있으므로 다른 사람에게 전달하기 전에 내용을 확인합니다. 점검이 끝난 뒤 실제 필요에 따라 로그 설정을 조정하며, 일상적으로 가장 상세한 기록 수준을 계속 유지할 필요는 없습니다.

특정 상태 하나만 보지 말고 다음 순서로 결과를 판단하는 것이 좋습니다:

1. Home에서 예상한 서버가 선택되어 있고 연결 스위치가 켜져 있습니다.
2. Global Routing이 테스트 목적에 맞으며 서버를 확인할 때 Direct가 아닙니다.
3. Connectivity Test가 해당 점검을 완료하거나 원인 파악에 사용할 수 있는 명확한 안내를 표시합니다.
4. 실제 페이지가 로드되고 Data에서 새로운 연결 기록을 확인할 수 있습니다.
5. Config를 사용할 때 규칙 매칭 결과가 PROXY 및 DIRECT의 예상과 일치합니다.

Proxy에서는 정상적으로 접속되지만 Config에서 문제가 발생한다면 서버 자체는 기본 확인을 통과했을 가능성이 높으므로 Config 파일, 규칙 순서, 정책 이름 및 DNS를 중점적으로 확인합니다. 반대로 Proxy에서도 테스트를 완료하지 못한다면 서버 필드, 로컬 네트워크 및 구독 상태를 먼저 확인하고 규칙을 서둘러 다시 작성하지 않습니다.

주요 오류 원인: 단계별 점검

연결 스위치가 유지되지 않거나, 테스트가 실패하거나, 페이지가 계속 로드되거나, 일부 도메인만 사용할 수 없는 등 서로 다른 문제가 비슷하게 나타날 수 있습니다. 효과적으로 처리하려면 가장 바깥 단계부터 시작해 한 번에 하나의 변수만 바꾸고 변경 후 같은 확인 절차를 다시 실행합니다. 아래 순서는 처음 사용할 때 자주 겪는 단계를 다룹니다.

1. Home에 서버 항목이 표시되지 않음

먼저 Add Server로 돌아가 저장이 완료되었는지 확인합니다. 수동 입력이라면 프로토콜 유형, 서버 주소 및 포트가 모두 저장되었는지 확인합니다. Subscribe로 가져왔다면 기존 구독 기록을 열어 업데이트를 실행하고 파싱 안내가 표시되는지 확인합니다. 같은 이름의 기록을 여러 개 연속해서 만들지 않습니다. 구독 링크 만료, 인증 정보 변경 또는 서비스 상태 문제는 해당 정보를 제공한 서비스 제공자가 확인해야 합니다.

2. 서버는 보이지만 연결 스위치가 유지되지 않음

먼저 기기의 로컬 네트워크를 사용할 수 있는지 확인한 다음 시스템 권한 승인이 완료되었는지 점검합니다. 스위치를 끄고 연결 상태가 완전히 종료될 때까지 기다린 뒤 다시 켜며 빠르게 연속해서 누르지 않습니다. 네트워크를 바꾼 뒤 현상이 달라진다면 Wi-Fi와 셀룰러 네트워크에서 각각 결과를 기록합니다. 이어서 현재 서버의 프로토콜, 주소, 포트 및 인증 필드를 확인하고 복사 과정에서 생긴 공백이나 누락에 특히 주의합니다.

3. Connectivity Test 실패

Global Routing을 일시적으로 Proxy로 설정하고 모든 정보가 저장된 것이 확실한 서버를 선택해 다시 테스트합니다. 여러 서버에서 모두 실패한다면 로컬 네트워크, 구독 업데이트 여부 및 공통 필드의 오입력을 먼저 확인합니다. 단일 항목만 실패한다면 해당 항목의 개별 매개변수를 중점적으로 확인합니다. Connectivity Test는 원인 파악 도구이므로 반복해서 누르는 것으로 필드 확인을 대신해서는 안 됩니다.

4. Proxy는 정상이지만 Config에서 접속할 수 없음

Config로 이동해 Config 파일이 선택되어 있는지 확인하고 규칙 정책 이름이 존재하는지 점검합니다. 규칙이 위에서 아래로 매칭될 때 앞쪽의 포괄적인 규칙이 요청을 먼저 처리하면 뒤쪽의 구체적인 규칙이 적용되지 않을 수 있습니다. Data 또는 Log에서 대상 도메인이 DOMAIN, DOMAIN-SUFFIX, GEOIP, IP-CIDR 또는 FINAL 중 어디에 매칭되었는지 확인한 뒤 조정할 규칙을 결정합니다. 한 번에 전체 규칙 그룹을 삭제하지 말아야 수정 전후를 비교하기 쉽습니다.

5. 테스트 결과는 있지만 웹페이지가 열리지 않음

이 경우 DNS를 별도의 단계로 확인해야 합니다. 서버 테스트가 정상이라는 것은 일부 연결 조건이 충족되었다는 뜻일 뿐 도메인 확인까지 완료되었다는 의미는 아닙니다. 모든 도메인에서 실패하는지 특정 도메인만 실패하는지 먼저 확인한 뒤 Log에서 확인 관련 안내를 살펴봅니다. DNS 설정, 원격 확인 및 규칙 사이에는 연관성이 있으므로 구체적인 필드와 점검 순서는 DNS 설정 참고에서 확인할 수 있습니다.

6. 일부 앱은 정상인데 일부 요청은 비정상

Config를 사용한다면 먼저 문제가 발생한 요청이 어떤 정책에 매칭되었는지 확인합니다. 어떤 연결은 DOMAIN-SUFFIX에 매칭되고 다른 연결은 GEOIP 또는 FINAL로 넘어갈 수 있으므로 같은 앱 안에서도 결과가 달라질 수 있습니다. 규칙을 확인한 뒤 해당 정책이 현재 사용 가능한 서버를 가리키는지 점검합니다. Proxy를 사용해도 특정 대상만 비정상이라면 테스트 시간과 Log의 오류 유형을 기록해 대상 서비스 상태와 클라이언트 설정 문제를 구분합니다.

7. 구독 업데이트 후 서버가 변경됨

구독을 업데이트하면 구독 내용에 따라 관련 기록이 새로 반영됩니다. 업데이트 후 Home으로 돌아가 현재 선택된 서버를 다시 확인하고 Connectivity Test를 다시 실행합니다. 기존 항목이 목록에서 사라졌다면 이전 이름을 기준으로 계속 점검하지 않습니다. 유지해야 하는 수동 서버는 별도 항목으로 관리하고 수동 입력 기록과 구독 업데이트 기록을 한 그룹으로 섞지 않습니다.

기본 연결 완료 후 설정 순서

Home의 연결 스위치가 안정적으로 유지되고, Connectivity Test에 명확한 결과가 표시되며, 실제 접속이 정상이고 Config에서 규칙 매칭이 예상과 일치하면 기본 절차가 완료된 것입니다. 이후 필요에 따라 DNS, On Demand, Ping, Log, Widget, iCloud 동기화 및 Proxy 포트 등을 설정합니다. 기본 연결을 확인하기 전에 이러한 항목을 동시에 변경하지 않습니다.

권장하는 후속 순서는 먼저 확인이 끝난 서버 하나를 고정하고 Config 규칙을 확인한 다음 DNS를 점검하는 것입니다. 마지막으로 On Demand 또는 Widget 같은 편의 기능을 활성화합니다. 이렇게 하면 각 단계에서 비교할 기준을 확보할 수 있습니다. 이후 변경으로 연결 문제가 발생하면 이 튜토리얼의 Proxy 확인 단계로 돌아가 서버가 여전히 작동하는지 먼저 판단한 뒤 새로 변경한 설정을 점검합니다.