1. Add Server / Subscribe: 서버 추가 및 구독 가져오기
먼저 보유한 정보의 종류를 확인하세요. 서버 목록을 갱신하는 전체 링크가 있다면 구독으로 가져옵니다. 서버 주소, 포트, 프로토콜, 인증 정보를 개별적으로 받았다면 서버를 하나씩 추가합니다. 두 방법 모두 Home에서 시작합니다. 구독 링크를 서버 주소 입력란에 넣거나, 서버 정보만 담긴 텍스트를 구독 링크로 제출하지 마세요.
구독 링크가 있는 경우: Subscribe 선택
Shadowrocket을 열고 Home으로 이동한 다음 오른쪽 위의 추가 버튼을 눌러 Add Server로 이동합니다. Type에서 Subscribe를 선택하고 전체 구독 링크를 URL에 입력합니다. Remarks에는 ‘개인 구독’처럼 알아보기 쉬운 이름을 입력하세요. 이름은 기기에서 구분하기 위한 것으로 링크를 수정하거나 서버 자체를 변경하지 않습니다. 저장하기 전에 링크의 시작 부분, 경로, 쿼리 매개변수가 모두 있는지 확인하세요. 특히 물음표 뒤의 내용을 빠뜨리지 않도록 주의합니다.
저장한 뒤 Home으로 돌아와 구독 요청이 완료될 때까지 기다린 다음 해당 그룹에 서버 항목이 표시되는지 확인합니다. 구독 이름만 표시되고 그룹에 항목이 없다면 가져오기가 성공한 것이 아닙니다. 업데이트가 진행 중인지, 요청 실패 메시지가 표시되는지 확인한 뒤 원본 정보를 살펴보세요. 일부 구독 주소는 브라우저에서 일반 웹페이지가 아닌 텍스트나 인코딩된 문자열로 표시될 수 있습니다. 페이지가 일반적인 웹 형식이 아니라는 이유만으로 링크가 잘못되었다고 판단하지 마세요.
메시지나 문서로 정보를 전달받았다면 복사할 때 줄 끝의 공백, 줄바꿈, 한국어 문장 부호, 잘린 끝부분의 매개변수에 유의하세요. 구독 링크에는 접속 자격 증명이 포함되는 경우가 많으므로 전체 주소를 공개 스크린샷, 게시물 댓글, 테스트 기록에 올리지 마세요. 구독 유효성을 확인하려면 같은 구독을 반복해서 만들지 말고 기존 서비스 경로를 통해 상태를 확인하세요.
서버 정보가 있는 경우: 프로토콜에 따라 항목별 입력
마찬가지로 Add Server로 이동해 Type에서 제공된 정보에 명시된 프로토콜을 선택한 다음 서버 주소, 포트, 인증 정보를 입력합니다. 프로토콜마다 필요한 항목이 다릅니다. 비밀번호, 식별자, 전송 방식, TLS 관련 설정은 서로 대신 사용할 수 없습니다. 먼저 원본 정보를 빠짐없이 입력하고, 익숙하지 않은 항목이 있다고 비워 두거나 다른 서버의 설정을 그대로 입력하지 마세요.
일반적으로 서버 주소 입력란에는 제공된 호스트 이름이나 IP 주소만 입력합니다. 포트는 해당 포트 입력란에 입력하고 경로가 포함된 전체 웹 주소를 붙여 넣지 마세요. 가져올 수 있는 서버 링크가 있거나 QR 코드로 정보를 받았다면 앱의 해당 가져오기 기능이나 Scan QR Code를 사용할 수도 있습니다. 가져온 뒤에는 이름만 확인하지 말고 항목을 열어 프로토콜, 주소, 포트를 확인하세요.
저장하고 Home으로 돌아온 다음 사용할 서버를 선택하고 현재 선택 표시를 확인합니다. 목록에 항목이 여러 개 있다고 해서 여러 서버가 동시에 요청을 처리하는 것은 아닙니다. 처음 테스트할 때는 하나만 선택하고 이름을 기록해 두세요. 이후 테스트와 접속도 같은 항목을 기준으로 진행합니다. 이 단계에서는 On Demand를 켜지 마세요. 자동 연결 조건이 수동 확인을 방해할 수 있습니다.
2. Global Routing: 연결 방식 선택
서버를 가져온 다음에는 요청을 처리할 방식을 정합니다. Home에서 Global Routing을 열어 현재 선택을 확인하세요. 세 가지 방식은 Config, Proxy, Direct입니다. 이 설정은 라우팅 방식을 바꾸며 서버 비밀번호를 수정하거나 유효하지 않은 구독을 복구하지는 않습니다.
Config: 현재 설정에 따라 정책 적용
Config는 현재 활성화된 설정의 규칙에 따라 요청을 처리합니다. Config로 이동해 실제로 활성화된 파일을 확인한 다음 파일에 포함된 규칙과 정책을 살펴보세요. 서버 구독을 가져왔다는 이유만으로 모든 대상에 예상한 라우팅 규칙이 적용된다고 볼 수는 없습니다. 서버 목록과 규칙 설정은 서로 다른 역할을 하므로 각각 확인해야 합니다.
규칙을 확인할 때는 매칭 조건, 순서, 마지막 처리 방식을 살펴보세요. DOMAIN-SUFFIX는 도메인 접미사 매칭에, IP-CIDR은 주소 대역 매칭에 사용됩니다. FINAL은 앞선 규칙에 매칭되지 않을 때 적용되는 정책을 뜻합니다. 아래 내용은 규칙 문법의 예시일 뿐, 그대로 가져와야 하는 완성된 설정이 아닙니다. example.com은 예시 도메인이며 실제 테스트 대상이 아닙니다.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYPROXY와 DIRECT는 정책 키워드이며 서버 이름이 아닙니다. PROXY는 프록시 정책으로 처리하고, DIRECT는 직접 연결합니다. 규칙이나 정책 그룹에 다른 설정이 지정되어 있다면 실제 선택 항목도 확인해야 합니다. 규칙 한 줄이 있다는 이유만으로 요청이 반드시 해당 규칙에 매칭된다고 단정하지 마세요. 앞선 규칙, 현재 활성화된 파일, 요청에 사용된 도메인 모두 결과에 영향을 줄 수 있습니다.
Proxy: 프록시 연결 경로를 별도로 확인
Proxy는 해당 트래픽을 현재 프록시 정책으로 보냅니다. 처음 문제를 확인할 때 잠시 이 방식을 사용하면 서버가 작동하는지와 규칙이 예상대로 적용되는지를 구분해 볼 수 있습니다. 모든 앱의 동작을 일괄적으로 보장하는 것은 아닙니다. 시스템 트래픽 범위, 현재 네트워크, 대상 서비스 상태도 접속에 영향을 줍니다. 테스트를 마친 뒤 규칙에 따른 라우팅이 필요하면 Config로 다시 전환하세요.
Direct: 직접 접속 기준 확인
Direct는 직접 연결 방식이므로 프록시 연결이 작동한다는 증거로 사용할 수 없습니다. 현재 네트워크에서 대상에 직접 접속할 수 있는지 비교할 때 적합합니다. Direct로 바꾼 뒤 페이지가 열린다면 해당 시점에 직접 접속이 가능했다는 뜻일 뿐 서버 매개변수가 올바르다는 의미는 아닙니다. 다음 연결을 시작하기 전에 Global Routing을 다시 확인해 테스트용 설정을 최종 설정으로 착각하지 않도록 하세요.
3. Home: 연결 시작 및 시스템 승인
Home으로 돌아와 현재 서버, Global Routing, 현재 네트워크를 순서대로 확인합니다. 처음에는 네트워크를 바꾸지 말고 같은 Wi-Fi에서 테스트를 마친 다음 셀룰러 네트워크를 별도로 테스트하는 것이 좋습니다. 서버를 선택하기 전에 연결을 반복해서 켜고 끄거나 서버, 네트워크, 규칙 파일을 한꺼번에 바꾸지 마세요. 문제가 발생했을 때 원인을 파악하기 어려워집니다.
Home 상단의 연결 스위치를 켭니다. 처음 연결할 때 시스템에서 VPN 구성을 추가하라는 메시지가 표시될 수 있습니다. 이는 앱이 시스템 네트워크 연결을 설정하는 데 필요한 승인 절차입니다. 팝업에 표시된 앱 이름과 설명을 읽고 현재 작업으로 인해 표시된 것인지 확인한 후 시스템 안내에 따라 승인 및 본인 인증을 완료하세요. 승인은 시스템 화면에서 진행합니다. 기기 잠금 정보나 Apple 계정 자격 증명을 서버 항목에 입력할 필요는 없습니다.
Shadowrocket으로 돌아온 뒤 스위치와 연결 상태가 유지되는지 확인합니다. 스위치가 곧바로 꺼지면 시스템 승인을 취소했는지, 처리할 알림이 남아 있는지, 다른 VPN 구성이 사용 중인지 먼저 확인하세요. 시스템 Settings에서 관련 VPN 상태를 확인한 뒤 앱으로 돌아와 다시 시도할 수 있습니다. 스위치를 켜 두기 위해 용도를 모르는 시스템 구성을 임의로 삭제하지 마세요.
연결 상태가 설정되었다는 것은 시스템 연결 통로가 시작되었다는 뜻일 뿐, 선택한 서버로 모든 대상에 접속할 수 있다는 의미는 아닙니다. 비밀번호, 포트, 전송 매개변수가 잘못되면 실제 요청은 여전히 실패할 수 있습니다. 따라서 승인 후에는 상태 표시만으로 판단하지 말고 다음 절의 테스트를 바로 진행하세요. iPhone과 iPad의 상태 표시는 기기와 시스템 화면에 따라 다를 수 있으므로 앱과 시스템에 표시되는 연결 상태를 함께 확인하세요.
이번 테스트를 마치려면 Home에서 연결 스위치를 끄고 시스템 연결이 종료되었는지 확인합니다. 이후 자동으로 다시 연결되면 On Demand가 켜져 있는지 확인하세요. 처음 수동 연결 절차를 마칠 때까지 자동 연결 조건을 테스트에서 제외하면 ‘연결을 끈 직후 다시 연결되는’ 현상을 잘못 판단할 가능성을 줄일 수 있습니다.
4. Connectivity Test: 연결 작동 여부 확인
확인은 세 단계로 나뉩니다. 서버 테스트에 결과가 나오는지, 시스템 연결이 설정되었는지, 실제 요청이 예상한 정책으로 처리되는지를 각각 확인합니다. 서로 다른 질문에 답하므로 한 가지 결과로 다른 항목을 대신 확인할 수는 없습니다. 먼저 Home에서 Connectivity Test를 사용해 선택한 서버를 테스트하고 결과가 안정될 때까지 기다린 다음 실제 접속을 시도하세요. 테스트 중에 서버 항목을 바꾸면서 이전 결과를 다른 서버의 결과로 착각하지 않도록 주의합니다.
Connectivity Test 결과는 테스트 방식과 대상에 따라 달라집니다. 숫자 값이 표시되더라도 해당 테스트에 응답이 있었다는 뜻일 뿐, 모든 웹사이트와 앱 요청이 작동한다는 의미는 아닙니다. timeout도 현재 테스트 방식과 대상을 함께 고려해야 하며, 한 번의 결과만으로 모든 서버가 작동하지 않는다고 판단할 수는 없습니다. 처음에는 현재 선택된 항목을 중심으로 확인해 목록 전체의 결과를 혼동하지 않도록 하세요.
그다음 브라우저를 열어 현재 네트워크에서 정상적으로 열리는 것으로 알고 있는 페이지에 접속한 뒤, 정책을 확인하려는 대상에도 접속합니다. 요청을 새로 보내고 이미 열려 있는 페이지나 캐시된 내용만 확인하지 마세요. ‘대상, 네트워크, 서버, Global Routing 방식’을 기록하면 ‘된다’ 또는 ‘안 된다’만 적는 것보다 다음 단계의 문제 해결에 도움이 됩니다.
Config를 사용한다면 앱의 Data에서 확인할 수 있는 연결 기록을 살펴보고 방금 보낸 요청의 대상, 규칙, 정책을 확인할 수 있습니다. 기록마다 확인할 수 있는 정보가 다를 수 있으므로 정책 세부 정보가 보이지 않더라도 임의로 추측하지 마세요. 현재 설정이 실제로 사용되고 있는지, DIRECT, PROXY 또는 설정에 지정된 다른 정책이 의도에 맞게 적용되었는지 확인하는 것이 중요합니다.
Proxy에서는 접속되지만 Config에서 예상대로 작동하지 않는다면 서버 인증 정보를 바로 바꾸지 말고 Config로 돌아가 규칙 순서와 정책 선택을 확인하세요. 두 방식에서 모두 실패하고 Direct에서는 비교 페이지가 열린다면 서버와 연결 경로를 계속 확인합니다. 이 비교로 원인 범위를 좁힐 수는 있지만 구체적인 대상과 오류 기록을 함께 살펴봐야 결론을 내릴 수 있습니다.
5. 자주 발생하는 문제: 순서대로 원인 확인
가장 먼저 실패한 단계부터 확인하세요. 목록이 비어 있으면 가져오기 문제를 먼저 해결합니다. 항목은 있지만 테스트에 실패하면 서버 매개변수를 확인합니다. 연결은 되었지만 일부 대상에서만 문제가 생기면 규칙과 대상 접속을 확인합니다. 원본 설정과 기존 항목을 보관하고 한 번에 한 항목만 변경한 뒤 다시 테스트하고 결과를 기록하세요. 연달아 삭제하거나 다시 가져오고 규칙을 바꾸면 하나였던 문제도 확인하기 어려워질 수 있습니다.
구독 저장 후 목록이 비어 있음
먼저 Subscribe 항목으로 돌아가 URL 전체가 입력되어 있는지 확인하고 계정 페이지나 안내 페이지가 아닌 구독 주소를 복사했는지 살펴보세요. 업데이트가 완료되었는지, 현재 네트워크에서 해당 주소에 요청을 보낼 수 있는지 확인한 다음 기존 서비스 경로를 통해 구독 상태와 내용이 유효한지 확인합니다. 업데이트에서 오류나 빈 내용이 반환되었다면 같은 링크를 다시 추가해도 대개 해결되지 않습니다. 요청 단계에서 발생한 문제인지 내용 해석 단계에서 발생한 문제인지 먼저 확인하세요.
업데이트 전에 사용할 수 있는 항목이 있었다면 기존 정보를 보관하고 목록을 다시 가져오려고 여러 항목을 한꺼번에 삭제하지 마세요. 수동 업데이트 후, 네트워크 전환 후, 앱을 다시 연 후 중 언제 문제가 발생했는지 기록하면 업데이트 시점과 관련이 있는지 판단하는 데 도움이 됩니다. 자세한 확인 순서는 구독 업데이트 후 서버 목록이 비어 있을 때 확인할 순서를 참고하세요.
Connectivity Test에 timeout 표시
먼저 테스트 대상이 현재 선택된 서버인지 확인한 다음 주소, 포트, 프로토콜, 인증, 전송 매개변수를 하나씩 점검합니다. 기기의 날짜와 시간이 정확한지도 확인하세요. 특히 TLS나 시간 기반 인증을 사용하는 경우 시스템 시간이 잘못되면 실패할 수 있습니다. 다른 네트워크에서도 다시 테스트해 현재 네트워크 문제와 서버 문제를 구분하되, 네트워크를 바꾼 뒤에도 같은 서버와 테스트 대상을 유지하세요.
추측으로 포트를 계속 바꾸거나 인증을 끄거나 TLS 설정을 수정하지 마세요. 매개변수는 보유한 서버 정보를 기준으로 하고 서비스 상태는 기존 서비스 경로를 통해 확인해야 합니다. 더 자세한 기록 방법은 서버 timeout 및 연결 실패 문제 해결을 참고해 순서대로 결과를 기록하세요.
연결은 되었지만 웹페이지가 열리지 않음
먼저 원래 네트워크에서 비교 페이지에 접속할 수 있는지 확인해 Wi-Fi 로그인이 완료되지 않았거나 셀룰러 데이터가 연결되지 않은 기본 문제를 제외합니다. 그런 다음 Global Routing을 확인하세요. Direct라면 요청이 프록시 정책에 따라 처리될 것으로 기대하면 안 됩니다. Config라면 현재 활성화된 파일과 매칭된 정책을 확인합니다. 도메인 조회와 관련된 오류가 명확히 확인된 경우에만 DNS 설정을 살펴보세요. 서버, 규칙, DNS를 동시에 바꾸지 마세요.
특정 대상 하나만 실패한다면 다른 정상 작동이 확인된 대상으로 비교하고 해당 요청 기록을 살펴보세요. 대상 서비스 자체의 문제, 규칙 매칭 오류, 서버 접속 제한, 인증 실패는 각각 다른 결과를 낼 수 있으므로 모두 ‘앱이 연결되지 않음’으로 단정할 수 없습니다. 특정 앱에서만 문제가 생기면 해당 앱에서 네트워크 요청을 새로 보내고, 기존 연결이나 캐시 때문에 결과 확인이 늦어질 수 있다는 점에 유의하세요.
설정 변경 후 결과를 구분하기 어려움
최근에 명확히 기록해 둔 상태로 돌아가세요. 기존 서버와 Global Routing, 설정 파일을 복원하고 이번에 추가한 On Demand 조건을 끈 뒤 확인 단계부터 다시 테스트합니다. 일시적인 성공을 설정이 안정되었다는 증거로 보지 마세요. 같은 조건에서 반복 확인한 다음 네트워크를 바꿨을 때의 결과도 각각 살펴보세요.
문제 해결 기록에는 시간, 네트워크 유형, 서버의 로컬 이름, 연결 방식, 오류 현상만 남기면 됩니다. 다른 사람에게 문제를 설명하기 전 구독 전체 링크, 비밀번호, 키, 기타 인증 정보를 가리세요. 설정 일부를 공유할 때도 해당 정보가 포함되어 있는지 먼저 확인해야 합니다. 구매, 스토어에서 앱 받기, 기기 변경 후 복원 절차를 다시 확인하려면 설치 안내를 참고하세요. 앱을 구하는 문제와 기존 서버 연결 문제를 혼동하지 마세요.