구독 가져오기 → Global Routing 선택 → 연결 권한 설정 → 작동 확인. 먼저 전체 과정을 한 번 완료한 다음 규칙과 Settings를 조정하세요.
아래 안내는 iPhone 및 iPad 기준입니다. 스크린샷은 해당 화면을 보여 주며, 실제 입력 항목은 선택한 프로토콜에 따라 달라질 수 있습니다. 입력할 때는 보유한 설정 정보를 기준으로 삼으세요.
가져오기 방법 하나만 선택하면 됩니다. 같은 정보를 중복으로 추가할 필요는 없습니다.
Shadowrocket을 열고 Home 화면에서 SERVER 그룹 근처의 Add Server를 탭해 추가 화면으로 이동합니다. Type에서 Subscribe를 선택한 다음, 보유한 구독 링크 전체를 해당 URL 항목에 입력하세요. 구독 링크는 서버 항목을 가져오는 주소이지 일반적인 서비스 안내 웹페이지가 아닙니다. 서비스 제공업체에 원본 링크를 확인하고, 브라우저 주소창에 표시된 아무 페이지 주소나 구독 링크로 사용하지 마세요.
붙여넣은 뒤 링크의 처음부터 끝까지 확인하세요. 앞뒤에 공백이 있는지, 따옴표나 한글 설명이 함께 복사되지는 않았는지, 줄바꿈 때문에 내용이 잘리지는 않았는지 살펴봅니다. 구독 링크에는 설정에 접근하기 위한 인증 정보가 포함될 수 있으므로 신뢰할 수 있는 기기에만 저장하고, 공개 스크린샷이나 채팅방, 문제 해결 기록에 올리지 마세요. 입력을 마치고 저장한 다음 Home으로 돌아가 구독 그룹이 표시되는지, 그룹 안에 서버 항목이 있는지 확인합니다.
구독 이름만 보이고 선택할 서버가 없다면 연결 스위치를 켜지 마세요. 이는 보통 구독 주소 저장과 콘텐츠 가져오기 및 파싱이 모두 완료되지 않았다는 의미입니다. 현재 네트워크에서 해당 주소에 접근할 수 있는지, 구독이 유효한지, 응답 내용이 올바른지 확인한 뒤 업데이트하세요. 같은 구독을 반복해서 새로 추가해도 중복 항목만 늘어날 뿐, 가져올 수 없는 주소가 해결되지는 않습니다.
서버 하나의 정보를 받았다면 Add Server로 이동해 자료와 일치하는 Type을 선택한 다음 Host, Port와 해당 프로토콜에 필요한 인증 항목을 입력합니다. 스크린샷의 항목을 기준으로 하면 Password와 Method는 서버 측 설정과 일치해야 합니다. 다른 프로토콜을 선택하면 화면에 표시되는 항목도 달라지므로 이전 프로토콜의 입력 방식을 그대로 적용하지 마세요. Host에는 일반적으로 서버 도메인이나 IP 주소를 입력하며, 임의로 웹페이지 경로를 덧붙이면 안 됩니다.
Port, 암호화 방식, Password, UUID, TLS, SNI 등의 매개변수는 각각 용도가 다릅니다. 현재 Type에서 요구하는 항목만 입력하세요. 항목이 누락된 경우 흔히 쓰이는 값을 추측하지 말고 원본 자료를 다시 확인해야 합니다. QR 코드가 있다면 Scan QR Code로 읽은 뒤 인식된 Type과 매개변수가 올바른지 확인하세요. Import from Cloud JSON은 해당 형식의 자료를 가져올 때 사용하는 기능이며, 임의의 구독 링크를 넣는 공용 입력란이 아닙니다.
저장한 뒤 Home으로 돌아가 새 항목이 예상한 SERVER 그룹에 있는지 확인하고 사용할 서버를 탭해 선택합니다. 이름은 항목을 구분하는 데만 도움이 되며 연결이 유효하다는 뜻은 아닙니다. 여기까지는 정보를 추가하고 선택할 수 있는 상태입니다. 다음 단계에서는 이 정보를 어떤 방식으로 사용할지 정한 뒤 연결을 시작합니다. 프로토콜 항목이 낯설다면 프로토콜 용어집을 참고하세요. 첫 설정부터 모든 프로토콜을 익힐 필요는 없습니다.
모드는 요청을 처리하는 방식을 정하고, 서버 항목은 프록시 연결에 사용할 매개변수를 정합니다.
Home으로 돌아가 Global Routing을 탭하고 현재 선택 항목을 확인합니다. 세 가지 모드는 구성(Config)/프록시(Proxy)/직접 연결(Direct)입니다. Global Routing의 Config와 구성 파일을 관리하는 하단의 Config 화면을 혼동하지 마세요. 전자는 라우팅 모드를 선택하고, 후자는 구성 파일 내용을 확인하는 곳입니다. 서버를 올바르게 선택해도 요청 처리 방식이 올바르다는 뜻은 아니므로 두 항목을 모두 확인해야 합니다.
사용할 구성 파일이 준비되어 있고 도메인이나 IP별로 트래픽을 나누려면 구성(Config)을 선택하세요. 그런 다음 Config 화면에서 사용 중인 파일이 예상한 파일인지 확인하고 Rule을 살펴봅니다. 구성 파일과 구독은 서로 다른 종류의 자료입니다. 구독은 주로 서버 항목을 제공하고, 구성 파일에는 규칙, DNS 및 기타 처리 설정이 포함될 수 있습니다. 구독 업데이트에 성공해도 원하는 파일의 규칙으로 자동 전환된다는 뜻은 아닙니다.
스크린샷의 General, Rule, Hosts, URL Rewrite, HTTPS Decryption은 구성 편집 화면의 각 섹션입니다. 처음 연결할 때는 현재 파일과 Rule의 용도를 확인하는 것만으로 충분하며, ‘설정 완료’를 위해 모든 항목을 수정할 필요는 없습니다. Add Rule로 규칙을 추가할 수 있지만, 규칙의 순서와 정책 이름이 결과에 영향을 줍니다. 이 관계를 이해하기 전에는 인터넷에서 찾은 여러 설정을 그대로 이어 붙이지 마세요. 일반적인 연결 확인을 위해 HTTPS Decryption을 켤 필요도 없습니다.
방금 추가한 서버를 확인하는 것이 목적이라면 프록시(Proxy)를 잠시 선택해 서버 연결 경로를 먼저 테스트할 수 있습니다. 사용 가능 여부를 확인한 뒤 구성(Config)으로 돌아가 트래픽 분할 규칙을 확인하세요. 직접 연결(Direct)을 유지하면 웹페이지가 열려도 선택한 프록시가 작동한다는 증거가 되지 않습니다. 모드를 선택한 뒤 Home으로 돌아가 Global Routing에 표시된 값을 다시 확인합니다. 규칙 작성과 일치 순서는 규칙 키워드와 정책에서, 구성 파일 관리는 Config 설정 자세히 알아보기에서 확인할 수 있습니다.
먼저 선택 항목을 확인한 뒤 스위치를 켜세요. 첫 권한 승인은 시스템 설정 과정의 일부입니다.
이제 Home으로 돌아갑니다. 연결하기 전에 두 가지를 확인하세요. SERVER에서 테스트할 항목이 선택되어 있는지, Global Routing이 앞서 정한 모드인지 확인합니다. 방금 구독을 업데이트했다면 항목 이름이나 그룹이 달라졌을 수 있으므로 업데이트 전 기억에 의존하지 말고 현재 선택 항목을 다시 확인하세요. 처음 테스트할 때는 서버 하나를 고정해 두세요. 테스트 중 서버를 계속 바꾸면 결과를 특정 매개변수와 연결하기 어렵습니다.
Home 상단의 연결 스위치를 탭합니다. 연결 전에는 화면 상단에 Not Connected가 표시됩니다. 처음 사용할 때 시스템에서 Shadowrocket의 VPN 구성 추가를 허용할지 물을 수 있습니다. 이는 앱이 시스템 네트워크 확장을 통해 연결하는 데 필요한 권한 절차입니다. 방금 진행한 작업으로 표시된 안내인지 확인한 뒤 시스템 절차에 따라 허용하고, 기기에서 요구하는 인증을 완료하세요. 여기서 하는 인증은 기기 권한 확인이며 서버의 Password를 입력하는 과정이 아닙니다.
권한을 승인한 뒤 Shadowrocket으로 돌아와 스위치와 상태가 연결된 채 유지되는지 확인합니다. 스위치가 곧바로 원래 상태로 돌아가면 먼저 시스템 권한 승인이 완료되었는지 확인한 다음, 뒤에 나오는 연결 단계 문제 해결을 진행하세요. 뚜렷한 근거 없이 구독을 반복해서 삭제하지 마세요. 시스템에 VPN 상태 표시가 나타나더라도 다음 테스트를 진행해야 합니다. 이 표시는 시스템 연결 상태를 의미할 뿐, 모든 서버에 연결할 수 있다거나 모든 웹페이지가 예상한 정책대로 처리된다는 뜻은 아닙니다.
연결 중 서버 매개변수나 구성 파일을 수정해야 한다면 먼저 변경 사항이 어느 단계에 해당하는지 확인하세요. 결과를 비교하기 쉽게 하려면 먼저 연결을 끊고 수정한 뒤 저장한 다음, 다시 연결해 같은 대상을 테스트합니다. 사용을 마치면 Home 상단 스위치로 연결을 끊을 수 있습니다. 연결이 다시 자동으로 설정되면 On Demand가 활성화되어 있는지 확인하세요. 관련 동작은 On Demand 설정 안내에서 확인할 수 있습니다. 필요 시 연결이 시작되는 것을 스위치 설정이 저장되지 않은 것으로 오해하지 마세요.
테스트 결과, 실제 접속, 규칙 경로를 각각 확인해야 합니다.
Home에서 Connectivity Test를 탭하고 결과를 기다립니다. 테스트 방식에 따라 결과의 의미가 달라지므로 Settings의 Test Method에서 사용 중인 방식을 확인할 수 있습니다. 테스트 수치가 표시되더라도 해당 테스트 조건에서 응답을 받았다는 뜻일 뿐, 모든 프로토콜과 대상, 앱이 정상이라는 의미는 아닙니다.
테스트가 실패하면 현재 서버와 모드를 그대로 두고 어떤 네트워크 환경에서 실패했는지 기록하세요. 한 번 시간 초과가 발생했다고 전체 구성을 삭제하거나, 수치가 낮다는 이유만으로 특정 연결이 실제 사용에 더 적합하다고 판단하지 마세요. 테스트 방식의 차이는 Ping 및 테스트 설정에서 확인할 수 있습니다.
실제로 사용할 웹사이트나 앱을 열고 요청을 다시 보내 로딩이 완료되는지 확인합니다. 캐시된 화면만 보지 말고 새 요청을 보내세요. 필요하면 새로 고침하거나 대상 페이지를 다시 엽니다. 한 번 성공해도 현재 해당 대상에 접속할 수 있다는 뜻일 뿐, 다른 요청까지 확인한 것은 아닙니다.
그런 다음 앱으로 돌아와 현재 모드, 구성 및 확인 가능한 연결 기록을 바탕으로 경로를 판단합니다. 구성(Config)에서는 특정 요청이 직접 연결 정책과 일치할 수 있습니다. 프록시(Proxy)에서 요청이 성공해도 구성(Config)의 규칙 작성이 올바르다는 증거가 되지는 않습니다.
검증 결과를 설명할 수 있도록 다음 항목을 연결해 확인하세요. 현재 선택한 서버, Global Routing 모드, 테스트 응답 여부, 실제 대상 접속 여부, 해당 요청을 처리할 것으로 예상되는 정책입니다. 일부 항목만 확인했다면 DNS를 바로 바꾸거나 규칙을 더 추가하지 말고 나머지 정보부터 확인하세요. 기록을 살펴봐야 한다면 문제 해결에 필요한 도메인, 시간, 오류 유형만 남기세요. 공유하기 전에 구독 링크, 서버 인증 정보 및 기타 개인 정보를 삭제합니다.
구성(Config)에서 일부 대상만 접속되고 다른 대상은 실패한다면 프록시(Proxy)로 잠시 전환해 같은 대상을 다시 테스트할 수 있습니다. 모드에 따라 결과가 달라지면 구성 파일과 일치한 정책을 우선 확인하세요. 두 모드 모두 실패하면 서버, 현재 네트워크, 대상 자체를 계속 확인합니다. 이는 원인을 좁히기 위한 비교 방법이지 영구적인 설정 변경을 권장하는 내용이 아닙니다. 테스트가 끝나면 원래 필요한 모드로 복구해 임시 문제 해결 상태를 일상 설정으로 사용하지 않도록 합니다.
한 번에 한 항목만 변경하고 같은 대상을 다시 테스트하세요. 서버, 규칙, DNS를 동시에 바꾸지 마세요.
Add Server에 있는 구독 설정으로 돌아가 Type이 Subscribe인지, URL이 완전한지 확인합니다. 구독이 여전히 유효하고, 로그인 페이지나 안내 페이지, 오류 메시지가 아닌 파싱 가능한 설정 콘텐츠를 반환하는지 확인하세요. 원본 링크가 변경되었다면 현재 서비스 제공업체가 제공한 유효한 정보로 업데이트합니다. 이 단계의 문제는 서버 자료를 가져오기 전에 발생하므로 Global Routing이나 DNS를 조정하는 것이 일반적인 첫 단계는 아닙니다.
선택한 항목의 편집 화면을 열어 Type, Host, Port를 원본 자료와 하나씩 대조한 다음 인증 및 전송 계층 항목을 확인합니다. 복사 과정에서 문자가 빠지지 않았는지, 프로토콜을 잘못 선택하지 않았는지, 다른 용도의 Port를 입력하지 않았는지, TLS 또는 SNI가 자료와 일치하는지 주의해서 살펴보세요. 인증서와 호스트 이름을 확인하는 대신 Allow Insecure를 무작정 켜지 마세요. 관련 오류가 발생하면 먼저 서버 제공 정보와 기기 시간이 올바른지 확인해야 합니다.
현재 네트워크에서 같은 항목이 계속 실패한다면 나머지 매개변수는 그대로 두고 사용 권한이 있는 다른 네트워크 환경에서 다시 테스트할 수 있습니다. 이렇게 하면 특정 네트워크에서만 발생하는 문제인지, 모든 테스트 환경에서 발생하는지 구분하는 데 도움이 됩니다. 다만 결과만으로 구체적인 원인을 단정할 수는 없습니다. 서버 상태를 추가로 확인해야 한다면 기존 서비스 제공업체에 필요한 오류 정보만 전달하세요. 전체 인증 정보를 함께 보낼 필요는 없습니다.
연결 스위치를 켜자마자 꺼지면 먼저 시스템 VPN 구성 권한이 완료되었는지 확인한 다음, 시스템에서 현재 사용 중인 다른 VPN 연결이 있는지 확인하세요. 직접 연결을 끊은 뒤 다시 연결된다면 Settings에서 On Demand를 살펴봅니다. 문제를 점검하는 동안 설정된 자동 연결 조건을 잠시 끄고 수동으로 연결을 제어할 수 있습니다. 원래 설정을 기록해 두었다가 테스트 후 복구하세요. 관련 옵션의 조건과 작동 방식은 On Demand 참고 안내에서 확인할 수 있습니다.
먼저 앞 단계의 방법에 따라 구성(Config)과 프록시(Proxy)를 비교합니다. 구성(Config)에서만 문제가 발생하면 Config로 돌아가 현재 파일, Rule 순서, 정책 참조를 확인하세요. 범위가 넓은 규칙이 앞에 있으면 뒤에 있는 구체적인 규칙보다 먼저 일치할 수 있습니다. FINAL은 앞선 규칙과 일치하지 않은 요청을 처리합니다. 규칙을 하나 추가했다고 요청이 반드시 해당 규칙을 따른다고 가정하지 마세요.
도메인 해석 오류가 나타나면 현재 구성의 DNS 설정과 연결 가능 여부를 확인합니다. DNS는 도메인에서 주소를 확인하는 방식에 영향을 주고, 프록시 서버 매개변수는 연결을 설정하는 방식에 영향을 줍니다. 두 설정은 서로 대체할 수 없습니다. 출처가 불분명한 DNS 설정 여러 개를 한꺼번에 붙여 넣지 마세요. 기존 값을 보존하고 한 번에 하나씩 변경한 뒤 같은 도메인을 다시 테스트합니다. 구성의 전체 관계는 DNS 설정 자세히 알아보기에서 확인할 수 있습니다.
Settings에서 Diagnostics 관련 진단 메뉴를 확인하고 Test Method를 통해 테스트 조건을 확인합니다. 현재 모드, 연결 여부, 문제가 발생한 대상과 대략적인 작업 순서를 기록하면 단순히 ‘작동하지 않음’이라고 설명하는 것보다 원인을 파악하기 쉽습니다. 스크린샷의 Today Widget, Proxy, TCP, UDP 등은 서로 다른 설정 범위이므로 한 가지 문제를 해결하려고 모두 변경하지 마세요. 특정 설정이 증상과 관련 있다고 판단되는 경우에만 해당 섹션에서 의미를 확인합니다.
여기까지 진행하면 문제가 ‘자료를 가져오지 못함’, ‘서버에 연결할 수 없음’, ‘시스템 연결이 설정되지 않음’, ‘특정 요청의 규칙 또는 DNS 문제’ 중 어디에 있는지 구분할 수 있습니다. 여전히 원인을 파악하기 어렵다면 재현 가능한 최소 작업 순서를 정리하고 자주 묻는 질문에서 증상에 맞는 내용을 찾아보세요. 처음 설정할 때는 검증 가능한 연결 경로 하나를 완료하면 충분합니다. Widget, iCloud 동기화 및 세부 매개변수 조정은 기본 절차가 안정된 뒤 Settings 설정 자세히 알아보기를 참고해 하나씩 진행할 수 있습니다.
