Shadowrocket 설정 참고

Settings / 적용 범위

설정 범위, 기본값 및 변경 기록

앱 설정과 요청 처리 구분하기

Settings가 모든 네트워크 동작을 결정하는 유일한 곳은 아닙니다. Home에서 선택한 서버는 연결에 사용할 대상을 정하고, Global Routing은 Config 규칙을 따를지 Proxy 또는 Direct를 일괄 적용할지 정합니다. Config에는 규칙과 관련 매개변수가 저장되며, Settings에는 앱의 연결, 테스트, 표시 및 관리 옵션이 포함됩니다. 문제를 해결하기 전에 어느 계층에 해당하는지 먼저 파악하세요. 웹페이지의 연결 경로가 예상과 다를 때 테스트 매개변수만 바꾸는 것은 대개 도움이 되지 않습니다. Widget 표시가 늦게 바뀌더라도 표시만 보고 규칙이 작동하지 않는다고 단정할 수 없습니다.

설정 항목을 조정할 때는 페이지 위치, 현재 값, 바꾸려는 동작, 변경 효과를 확인하는 방법을 함께 기록하세요. 예를 들어 DNS 조정의 목표는 테스트 수치를 낮추는 것이 아니라 특정 도메인이 안정적으로 조회되게 하는 것입니다. On Demand 조정의 목표는 앱을 백그라운드에서 계속 보이게 하는 것이 아니라 지정한 네트워크 조건에서 예상대로 연결되게 하는 것입니다. 목표를 반복 가능한 동작으로 정해야 설정이 실제로 작동하는지 판단하고 관련 없는 변경도 찾아낼 수 있습니다.

기본 상태 이해하기

‘기본값’에는 적어도 세 가지 의미가 있습니다. 처음 실행했을 때 표시되는 앱 초기값, Config를 가져온 뒤 파일에 명시된 값, 시스템이 현재 네트워크에서 제공하는 값입니다. 이 값들은 서로 다를 수 있습니다. 데이터를 복원하거나 iCloud로 동기화했거나 Config를 전환한 기기의 상태를 출고 시 상태라고 부르기도 어렵습니다. 이 매뉴얼은 현재 기기에서 확인할 수 없는 기본 수치를 추정하지 않습니다. 권장 설정은 모든 기기에 같은 매개변수를 입력하도록 요구하는 대신, 검증된 설정을 유지하고 불필요한 변수를 줄이는 것을 원칙으로 합니다.

되돌릴 수 있는 변경 절차 마련

변경을 시작하기 전에 정상 작동하는 현재 Config를 복사해 두고, 선택한 서버, Global Routing, 네트워크 유형, 연결 스위치 상태를 기록하세요. 개인 기록에는 이름과 변경 사항만 적고 구독 전체 주소나 비밀번호를 공개된 곳에 붙여 넣지 마세요. 그런 다음 한 항목만 변경하고 저장한 뒤, 화면 안내에 따라 연결을 다시 설정하고 동일한 실제 접속 동작으로 확인합니다. 서버 변경, DNS 수정, 규칙 전환을 동시에 하면 문제가 해결되더라도 어떤 조치가 효과가 있었는지 알 수 없습니다.

‘저장됨’과 ‘새 연결에 적용됨’은 서로 다른 상태입니다. 일부 매개변수는 터널을 다시 설정하거나 새 요청을 시작해야 반영될 수 있으며 기존 연결은 이전 경로를 계속 사용할 수 있습니다. 확인할 때는 기존 테스트 요청을 중지하고, 필요하면 클라이언트 연결을 껐다가 다시 켠 다음 새 요청을 시작하세요. 다운로드, 통화 또는 다른 전송이 진행 중일 때 매개변수를 반복해서 바꾸지 마세요. 변경으로 인한 중단이 문제 증상에 섞여 로그를 특정 변경과 연결하기 어려워집니다.

권장 기준은 전체 초기화가 아니라 현재 상태를 설명할 수 있는 설정을 유지하는 것입니다. 특별한 이유가 없다면 테스트 방식, 포트, 동기화 범위, 자동 연결 조건을 그대로 두고 문제가 생겼을 때 이 페이지의 해당 절을 확인하세요. 앱 출처를 확인하려면 정품 확인 안내에서 개발자 Shadow Launch Technology Limited와 앱 ID 932747118을 확인하세요. 구매 및 설치 문제는 스토어 절차에 따라 처리하고 네트워크 설정 변경으로 대신하지 마세요.

DNS / 도메인 조회

DNS 설정 및 조회 경로

DNS는 이름을 주소로 변환합니다

DNS는 도메인 이름을 네트워크 주소로 변환하며 프록시 연결 자체와는 다릅니다. 요청은 먼저 주소를 조회한 뒤 규칙에 따라 연결 경로를 선택할 수도 있고, 프록시 측에서 대상 이름을 처리할 수도 있습니다. 실제 경로는 Config와 프로토콜에 따라 달라집니다. 따라서 서버 테스트가 성공했는데 웹페이지가 열리지 않는다고 DNS 문제로 단정할 수 없으며, 도메인 조회가 된다고 대상 서비스에 접속할 수 있다는 뜻도 아닙니다. 전체 경로를 하나의 결과로 판단하지 말고 이름 조회, 서버 연결, 규칙 선택, 대상 응답을 나누어 확인하세요.

먼저 Config에서 사용 중인 파일을 확인하고, DNS가 명시적으로 설정되어 있는지 살펴본 다음 Settings에 표시된 기기별 관련 옵션과 비교하세요. 입력란이 비어 있다는 이유만으로 DNS 동작이 없다고 판단하지 마세요. 다른 설정 출처를 사용한다는 의미일 수 있습니다. 파일에 dns-server가 있다면 해당 항목과 관련 설명을 확인하고 다른 페이지에 보이는 값만 바꾸지 마세요. Config 적용 관계가 불분명하면 파일을 복사한 뒤 사본에서 실제 적용 결과를 검증하세요.

기본 출처 및 권장값

명확한 조회 요구가 없다면 현재 정상 작동하는 DNS 구성을 유지하세요. 시스템 DNS를 비교 기준으로 사용할 수는 있지만 모든 네트워크에 적합한 것은 아니며 모든 요청이 프록시를 우회한다는 뜻도 아닙니다. 아래는 매개변수 위치를 이해하기 위한 system 표기 예시입니다. 서버 정보는 포함되어 있지 않으며 개인 Config를 대체하는 완성 파일도 아닙니다. 수정 전 기존 값을 보존하고 현재 파일에 조회 경로에 영향을 주는 다른 설정이 있는지 확인하세요.

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

‘예비용’ 주소 수를 늘리려고 용도가 불분명한 조회 주소를 여러 개 추가하지 마세요. 여러 출처에서 다른 결과를 돌려줄 수 있고 시간 초과와 캐시 차이도 생길 수 있습니다. 다른 조회 방식을 선택하기 전에 현재 앱 화면이나 Config 문법에서 해당 형식을 지원하는지, 사용 중인 네트워크에서 접속할 수 있는지 확인하세요. 암호화된 조회를 사용할 때는 전송 암호화, 조회 서비스 접속 가능 여부, 대상 서비스 접속 가능 여부를 구분해야 합니다. 그중 하나만 충족해도 전체 요청이 성공한다고 볼 수 없습니다.

증상별 DNS 조회 실패 확인

특정 도메인 하나만 실패한다면 먼저 철자와 대상의 유효성을 확인하고 같은 네트워크에서 해당 도메인이 반복해서 어떻게 동작하는지 살펴보세요. 서로 관련 없는 여러 도메인이 모두 실패한다면 Log에서 조회 관련 오류를 확인합니다. 주소로 직접 접속하는 방법은 제한적인 단서일 뿐입니다. 많은 서비스가 도메인, 인증서, 요청 헤더에 의존하므로 주소 접속이 실패해도 네트워크가 끊겼다고 단정할 수 없습니다. 비교 테스트는 가능한 한 정상적인 도메인 접속으로 진행하고 인증서 오류를 DNS 문제로 혼동하지 마세요.

Wi-Fi를 전환한 뒤에만 문제가 생긴다면 전환 전후에 네트워크 로그인이 필요한지, 시스템이 정상 연결을 확보했는지, 클라이언트가 터널을 다시 설정했는지 기록하세요. 일부 네트워크는 로그인하기 전까지 외부 대상을 정상적으로 조회하거나 접속하지 못합니다. 이때 DNS를 바꾸면 실제 접속 단계의 문제를 가릴 수 있습니다. 먼저 시스템 네트워크의 기본 연결을 복구한 다음 Shadowrocket을 확인하세요. 기존 네트워크에서는 정상이고 다른 네트워크에서 계속 실패한다는 차이를 기록하는 편이 Config를 반복해서 바꾸는 것보다 진단에 도움이 됩니다.

캐시 때문에 변경 효과가 즉시 나타나지 않을 수 있습니다. 앱, 시스템, 브라우저, 원격 서비스가 각각 결과 일부를 저장할 수 있으므로 페이지를 한 번 새로 고친 뒤 결론을 내리지 마세요. 클라이언트 연결을 다시 설정하고 기존 테스트 페이지를 닫은 뒤 새 요청을 만들어 같은 도메인의 동작을 여러 번 확인하면서 시간을 기록하세요. 캐시 삭제는 기기에서 제공하는 방법을 따르세요. 도메인 하나를 확인하려고 Config 전체를 삭제하거나 앱을 재설치하거나 관련 없는 데이터를 모두 지울 필요는 없습니다.

문제 해결 후 유지할 DNS 출처, 적용할 네트워크, 검증한 도메인을 개인 Config 메모에 기록하세요. 효과를 확인하기도 전에 임시 테스트 값을 모든 기기에 동기화하지 마세요. DOMAIN, IP-CIDR, 이름 조회의 차이를 더 알아보려면 용어집을 확인하세요. 스위치가 켜져 있는데도 접속할 수 없다면 서버, 모드, DNS 및 규칙 문제 해결 체크리스트에 따라 전체 경로를 다시 살펴보세요.

Global Routing / Config

Global Routing, 규칙 및 Config 적용 관계

모드에 따라 규칙 사용 방식이 달라집니다

Global Routing은 트래픽 경로를 살펴볼 때 가장 먼저 확인할 항목입니다. Config 모드는 현재 Config 파일에 따라 요청을 처리하고, Proxy 모드는 클라이언트가 처리하는 범위의 트래픽을 프록시 방식으로 처리하며, Direct 모드는 직접 연결 방식으로 처리합니다. 이는 클라이언트의 처리 방식에 대한 설명이며 기기의 모든 시스템 트래픽을 단정하는 근거는 아닙니다. 특정 규칙을 테스트하기 전에 Config 모드인지 확인하세요. Config 파일의 내용이 올바르더라도 현재 동작을 결정하는 설정이 아닐 수 있습니다.

일상적으로 도메인이나 주소에 따라 트래픽을 분기해야 한다면 검증된 Config를 사용하세요. Proxy와 Direct는 문제 범위를 좁히는 데 도움이 되지만 임시 비교 결과를 장기 설정으로 그대로 사용하지 않는 편이 좋습니다. 모드를 전환할 때는 기존 값을 기록하고 테스트가 끝나면 복원하세요. Direct에서 접속할 수 있다는 것은 해당 테스트에서 직접 연결 경로가 작동했다는 뜻일 뿐입니다. Proxy에서 접속할 수 있어도 Config의 모든 정책이 올바르다는 뜻은 아닙니다. 모드, 규칙, 서버를 각각 검증해야 하며 서로를 대신할 수 없습니다.

규칙 순서 및 최종 매칭

규칙은 일반적으로 순서대로 확인하므로 구체적인 규칙을 포괄적인 규칙보다 앞에 두고, 마지막 항목에서 앞서 일치하지 않은 요청을 처리합니다. DOMAIN은 전체 도메인과 대조하고, DOMAIN-SUFFIX는 해당 도메인 접미사 범위를 적용하며, IP-CIDR 및 IP-CIDR6은 주소 대역을 대상으로 합니다. GEOIP는 주소의 지리 정보에 따라 매칭되며 데이터베이스와 주소 할당 정보의 영향을 받습니다. GEOIP를 웹사이트 콘텐츠 출처를 판별하는 규칙으로 보거나 하나의 도메인이 항상 고정된 주소를 사용한다고 가정하지 마세요.

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

예시의 도메인과 문서용 주소 대역은 문법 설명을 위한 것이며 실제 서버도, 일반적인 트래픽 분기 권장안도 아닙니다. PROXY는 이미 사용할 수 있는 프록시 연결이 필요하고, DIRECT는 직접 연결을 뜻하며, FINAL은 나머지 요청을 처리할 방향을 나타냅니다. 최종 항목을 DIRECT로 바꾸면 일치하지 않은 요청의 경로가 달라집니다. Config를 읽을 때 대상 도메인이 포함된 한 줄만 찾지 말고 그보다 앞선 규칙과 최종 항목도 확인해 요청이 실제로 어느 분기에 들어가는지 살펴보세요.

파일 이름보다 선택된 파일이 중요합니다

Config 파일을 가져왔다고 해서 자동으로 활성화되는 것은 아니며, 특정 파일을 편집했다고 해서 현재 연결이 그 사본을 읽는 것도 아닙니다. 확인하기 전에 Config로 돌아가 선택된 파일을 확인하고 저장 내용도 점검하세요. 파일 이름이 비슷하다면 일상용 기준 파일이나 임시 테스트 파일처럼 용도를 개인 메모에 적어 두고 목록 위치만 기억에 의존하지 마세요. 여러 부분으로 구성된 파일에서는 대상 부분만 수정하고 기존 서버와 필수 매개변수를 유지하세요. 코드 조각을 복사하다 문맥이 의도치 않게 사라지지 않도록 주의하세요.

사용자가 보유한 구독과 Config 파일도 서로 혼동하면 안 됩니다. 구독 업데이트로 서버 목록이 바뀔 수 있지만 규칙이 바뀌는지는 가져온 내용과 실제 작업에 따라 다릅니다. 구독에 특정 서버가 없다면 현재 선택을 다시 확인해야 할 수 있지만 DNS를 반드시 다시 입력해야 한다는 뜻은 아닙니다. 업데이트 전후의 사용 가능한 서버, 선택 항목, 현재 Config를 비교하면 모든 데이터를 다시 만드는 것보다 원인을 찾기 쉽습니다. 인증 정보가 포함된 링크는 개인 기기에 보관하고 공개된 문제 해결 자료에 올리지 마세요.

같은 도메인의 경로가 달라지는 문제가 생기면 관련 도메인이 여러 개인지, 주소 계열이 다른지, 기존 연결이 재사용되는지, 리소스 요청이 다른 곳으로 이동하는지 확인하세요. 페이지 자체와 이미지, 동영상, API가 서로 다른 도메인을 사용할 수 있습니다. Log에서 실제로 실패한 요청을 찾아 해당 범위만 조정하세요. 페이지의 기본 도메인에 규칙을 추가해도 모든 리소스에 적용되지 않을 수 있습니다. DOMAIN-SUFFIX를 수정할 때는 적용 범위를 특히 주의해서 살펴보고 한 대상을 해결하려다 관련 없는 요청까지 바꾸지 않도록 하세요.

On Demand / 연결 트리거

On Demand 및 연결 상태

자동 연결은 계속 사용할 수 있음을 보장하지 않습니다

On Demand는 저장한 조건에 따라 VPN 연결을 시작하는 기능이며 실제 동작은 시스템 네트워크 상태와 기기에서 허용하는 작업에도 영향을 받습니다. 서버 상태를 점검하거나 잘못된 비밀번호, 접속할 수 없는 주소, DNS 실패를 해결하는 기능은 아닙니다. 수동 연결이 안정적으로 작동하지 않는다면 서버와 규칙을 검증할 때까지 자동 연결 조건을 추가하지 않는 편이 좋습니다. 그렇지 않으면 자동 연결 시도와 수동 문제 해결이 뒤섞여 연결이 시작된 시점과 실패 원인을 구분하기 어려워집니다.

VPN 구성을 처음 추가할 때 시스템에 권한 승인 안내가 표시됩니다. Shadowrocket의 연결 작업을 직접 진행 중인지 확인한 경우에만 시스템 안내에 따라 권한을 승인하세요. 안내 내용과 인증 방식은 기기에 실제로 표시되는 내용을 따릅니다. 기존 VPN 구성도 기기 관리 정책이나 다른 연결 상태의 영향을 받을 수 있습니다. 권한을 승인할 수 없거나 상태가 곧바로 되돌아오면 시스템 안내를 먼저 확인하고 앱 데이터를 반복해서 삭제하지 마세요. 시스템에서 터널 생성을 허용하지 않는 경우 규칙을 수정해도 권한 문제가 해결되지는 않습니다.

조건, 초기 상태 및 권장 설정

기기의 On Demand 화면에 들어가 현재 활성화 여부와 설정된 네트워크 조건을 먼저 기록하세요. 화면에서 제공되는 조건과 표시 방식은 다를 수 있으므로 모든 기기에 같은 옵션이 있거나 복원 후 기본적으로 꺼져 있다고 가정하지 않습니다. 명확하게 검증할 수 있는 조건 하나부터 시작하고 서로 겹치는 조건을 한꺼번에 여러 개 추가하지 마세요. Wi-Fi 환경에 따라 구분해야 한다면 네트워크 이름을 정확히 확인하고 이름이 같은 네트워크라도 실제 환경은 다를 수 있다는 점을 고려하세요.

자동 연결을 검증할 때는 지속적인 데이터 전송을 먼저 중지하고 시작 네트워크와 스위치 상태를 기록하세요. 네트워크를 한 번 전환한 뒤 시스템이 연결을 완료할 때까지 기다리고 실제 요청을 시작합니다. 테스트마다 조건 하나만 바꾸고 Wi-Fi, 셀룰러 네트워크, 기기 잠금 전후의 현상을 각각 기록하세요. 네트워크를 전환하는 순간의 짧은 끊김을 지속적인 문제로 보거나 상태 아이콘만 보고 판단하지 마세요. 네트워크 전환, 터널 재설정, 앱의 새 연결 사이에는 시간 차이가 생길 수 있습니다.

연결을 껐다가 다시 켜지는 경우

수동으로 연결을 껐는데 곧 다시 연결되면 On Demand가 여전히 활성화되어 있는지, 현재 환경이 트리거 조건을 충족하는지 먼저 확인하세요. 일시적으로 중지하려면 자동 연결 설정을 먼저 확인한 다음 연결을 끄고 상태를 다시 관찰합니다. 조건을 확인하지 않고 Home 스위치만 반복해서 누르면 연결 종료와 재시작이 반복될 수 있습니다. 자동 연결을 껐는데도 문제가 계속되면 시스템 VPN 상태와 조작 시간을 기록한 뒤 연결에 영향을 줄 수 있는 다른 시스템 설정을 확인하세요.

Wi-Fi 로그인 페이지도 흔히 놓치기 쉬운 상황입니다. 일부 네트워크는 정상적으로 접속하려면 먼저 시스템 안내에 따라 로그인해야 합니다. 네트워크가 준비되기 전에 자동 연결이 시작되면 계속 대기하거나 접속에 실패할 수 있습니다. 해당 네트워크의 정상적인 접속 절차를 확인하고 시스템 로그인을 완료한 뒤 기본 연결을 검증하고 On Demand를 살펴보세요. 네트워크에 아직 접속하지 못한 상태에서 서버를 반복해서 바꾸다가 접속 문제를 클라이언트 설정 문제로 오해하지 마세요.

기기가 잠겨 앱이 화면 앞에 표시되지 않는다고 해서 VPN이 반드시 중지된 것은 아닙니다. 마찬가지로 Widget에 연결 문구가 남아 있다고 해서 현재 요청이 성공했다는 뜻도 아닙니다. 관련 네트워크 구성 요소는 시스템이 관리하므로 화면 표시만으로 백그라운드 동작을 단정할 수 없습니다. 기기를 다시 사용한 뒤 새 요청을 시작하고 실제 상태와 Log를 비교하세요. 앱을 자주 열고 닫거나 스위치를 연속으로 전환하면 관찰하려던 조건이 바뀌어 자동 연결의 안정성을 판단하기 어려워집니다.

최종적으로 유지할 조건은 어떤 네트워크 상태에서 언제 연결되기를 원하는지 한 문장으로 설명할 수 있어야 합니다. 예외가 여러 개 필요하면 하나씩 검증하고 기록하세요. 조건을 많이 만드는 것 자체가 목표는 아닙니다. 기기를 교체하거나 데이터를 복원한 뒤에는 기존 조건이 남아 있어도 새 기기의 네트워크 환경은 다를 수 있으므로 전체 테스트를 다시 진행하세요. 기본 권한 및 첫 연결 절차는 튜토리얼 페이지에서 다시 확인하고, 이 페이지에서는 해당 절차를 마친 뒤 고려할 설정 범위를 설명합니다.

Ping / Connectivity Test

Ping, 테스트 방식 및 결과 해석

테스트한 구간만큼만 결론을 내리세요

Ping 및 Connectivity Test는 연결 상태를 판단할 단서를 제공하지만 테스트 방식에 따라 확인하는 경로가 다릅니다. 일부 테스트는 서버 주소에 접속할 수 있는지 확인하고, 일부는 전송 연결을 시도하며, 일부는 Proxy를 통해 테스트 대상에 접속합니다. 결과를 해석하기 전에 기기에서 실제로 선택된 테스트 방식과 대상을 확인하세요. 목록에 응답 시간이 표시되어도 대상 웹페이지, 전체 규칙 경로, 모든 프로토콜 기능이 검증된 것은 아닙니다. 결과가 없더라도 원격 네트워크가 해당 테스트 방식에 응답하지 않았을 수 있습니다.

기본 네트워크 탐색, 포트 연결, Proxy를 통한 요청은 서로 다른 동작입니다. 서버가 특정 탐색에 응답하지 않아도 Proxy 연결은 정상적으로 받을 수 있습니다. 반대로 포트 연결은 빠르게 수립되더라도 인증이나 이후 전달 단계에서 실패할 수 있습니다. 그러므로 ‘수치가 낮은데 웹페이지가 열리지 않는 상황’은 모순이 아닙니다. 테스트 결과를 해석할 때 실제 Proxy 프로토콜을 사용했는지, 인증이 완료됐는지, 테스트 대상이 문제가 발생한 서비스인지 명확히 확인하세요. 일부 단계의 성공을 전체 성공으로 확대 해석하지 마세요.

기본 테스트 방식 및 권장 매개변수

Ping 페이지의 초기 테스트 방식, 시간 제한, 대상은 기기에 현재 표시된 값을 기준으로 확인하세요. 설정을 복원하거나 사용 방식을 바꾼 뒤 모든 기기의 값이 같다고 가정하지 마세요. 이미 알고 있는 테스트 방식을 유지하고 동일한 대상을 사용해 전후를 비교하는 편이 좋습니다. 시간 제한이 너무 짧으면 정상적인 변동도 실패로 기록될 수 있고, 너무 길면 대기만 늘어날 뿐 실패한 연결이 사용할 수 있게 되지는 않습니다. 대기 시간 설정이 부적절하다는 근거가 없다면 수치를 먼저 바꿀 필요가 없으며 여러 테스트 항목을 한꺼번에 수정하지 마세요.

테스트 대상은 안정적이고 명확해야 하며 현재 문제를 확인하기에 적합해야 합니다. 앱에서 사용자 지정 대상을 제공한다면 입력 형식이 화면 안내에 맞는지 확인하세요. 인증 정보가 포함된 내용을 넣거나 로그인해야 접속할 수 있는 페이지를 사용하지 마세요. 대상 자체의 리디렉션, 속도 제한, 점검, 인증서 문제도 결과에 영향을 줄 수 있습니다. 테스트 대상을 바꿀 때는 기존 대상을 비교용으로 남기고 테스트 조건이 달라졌다는 점을 기록하세요. 새 수치와 이전 수치를 서버 성능 순위처럼 직접 비교할 수는 없습니다.

반복 가능한 테스트 묶음 만들기

간단한 검증 절차를 준비하세요. 고정된 네트워크에서 현재 서버를 테스트하고, 동일한 Global Routing 및 Config로 대상에 접속한 뒤 실패 요청의 Log를 확인합니다. 여러 번 반복해 계속 실패하는지, 간헐적으로 실패하는지, 특정 동작 후에만 실패하는지 기록하세요. 특히 네트워크가 약하거나 서버의 연결 수가 제한된 환경에서는 테스트를 한꺼번에 많이 실행하지 마세요. 테스트 자체가 연결 자원을 사용하므로 동시에 여러 개를 실행하면 일상적인 단일 접속과 다른 현상이 생길 수 있습니다.

서버 테스트는 정상인데 웹페이지가 실패한다면 대상 도메인 조회, 규칙 매칭, 인증, 원격 응답을 차례로 확인하세요. 테스트는 실패하지만 웹페이지가 정상이라면 사용할 수 있는 서버를 바로 삭제하지 말고 해당 테스트 방식이 적합한지 확인합니다. 특정 서버 하나만 계속 실패한다면 사용자가 보유한 서비스의 주소, 포트, 프로토콜 매개변수, 유효 상태를 확인하세요. 이 정보는 기존 서비스 제공처에서 확인해야 하며 시간 제한을 계속 늘려서 올바른 값을 알아낼 수는 없습니다.

TLS 연결에서는 서버 주소와 인증서 검증에 사용하는 이름도 구분해야 합니다. 유효한 Config에서 두 값은 다를 수 있으므로 구체적인 요구 사항은 사용자가 이미 보유한 서버 정보를 기준으로 확인하세요. 인증서 검증 실패를 해결한다며 검증 수준을 낮추는 방법을 일반적인 대처로 사용하지 마세요. 먼저 기기 시간, 이름 입력, 인증서 체인, 서버 상태를 확인하세요. 포트 연결이 수립됐다는 사실은 앞선 전송 단계에서 응답이 있었다는 뜻일 뿐, 암호화 협상과 이후 요청까지 완료됐다는 뜻은 아닙니다.

테스트가 끝나면 임시로 바꾼 대상과 방식을 복원하고 유지할 매개변수를 변경 기록에 적으세요. 특정 네트워크에서만 문제가 발생한다면 같은 조건의 결과를 두 번 이상 확보한 뒤 Log 절에서 문제 단계를 찾으세요. 프로토콜 필드 이름을 확인하려면 기능 및 설정 안내와 용어집을 참고하세요. 해당 페이지는 개념을 설명하며, 이 절에서는 테스트 증거로 어디까지 결론 내릴 수 있는지 다룹니다.

Log / Data

Log, 요청 기록 및 문제 해결 증거

한 번의 요청을 중심으로 로그 읽기

Log는 모든 기록을 한 줄씩 해석하라고 요구하는 도구가 아니라 현상을 처리 단계와 연결하는 데 사용합니다. 문제 해결을 시작하기 전에 시간, 네트워크, 서버, Global Routing, Config를 기록하고 재현 가능한 실패 동작을 한 번 실행하세요. 그런 다음 비슷한 시간대의 관련 기록만 살펴보고 도메인, 연결 대상, 규칙, 오류 정보의 관계를 찾습니다. 웹페이지에 접속할 때 여러 리소스 요청이 발생할 수 있으며 가장 먼저 나타난 실패가 전체 페이지 사용 불가의 원인이라고 단정할 수는 없습니다.

요청이 클라이언트에 들어왔는지 확인한 다음 조회 결과, 선택된 정책, 연결 수립 여부, 원격 응답 여부를 살펴보세요. 기록에서 대상이 보이지 않는다고 해서 규칙이 정상이라고 단정하면 안 됩니다. 요청을 다시 보내지 않았거나 앱 캐시를 사용했거나 다른 시스템 경로로 처리됐거나 현재 기록 방식에 해당 정보가 포함되지 않았을 수 있습니다. 새 요청을 명확하게 시작한 뒤 로그 범위를 다시 확인하세요. 특정 오류 단어만 검색하는 것보다 단계별로 제외해 문제를 좁히는 편이 더 신뢰할 수 있습니다.

기록 범위 및 기본 상태

Log에 표시되는 내용과 상세 수준은 기기에서 제공하는 옵션 및 현재 상태에 따라 다릅니다. 일부 세부 정보는 관련 기록을 켠 뒤에만 나타나며 활성화 이전의 요청 기록이 소급해 채워지지는 않습니다. 일상적으로는 기본 상태를 살펴보기에 충분한 기록 방식을 유지하고 문제를 재현하는 짧은 시간 동안만 상세 수준을 높이는 편이 좋습니다. 로그가 많아지면 저장 공간과 처리 부담이 늘고 더 많은 접속 정보가 포함될 수 있습니다. 진단이 끝나면 기존 설정으로 복원하고 필요 없는 기록은 실제 사용 상황에 따라 정리하세요.

로그 오류는 대개 특정 단계의 결과일 뿐 최종 원인은 아닙니다. 예를 들어 시간 초과는 주소에 접속할 수 없거나 서버가 응답하지 않거나 원격 대상이 대기 중이거나 네트워크가 전환되는 등 여러 이유로 발생할 수 있으며 단어 하나만 보고 책임을 판단할 수 없습니다. 오류 전후의 기록을 연결해 실제 조작 시간과 비교하세요. 설정 하나를 바꾼 뒤 오류 단계가 달라졌다면 그것도 기록해야 합니다. 조회 실패가 연결 실패로 바뀌었다면 요청이 다음 단계로 진행된 것이지만 전체 문제가 해결된 것은 아닙니다.

Data와 연결 상태의 차이

Data에 표시되는 트래픽이나 관련 통계는 일정 시간 동안 데이터 활동이 있었는지 확인하는 데 도움이 되지만 대상 서비스의 응답 성공을 뜻하지는 않습니다. 누적값에는 다른 백그라운드 요청이 포함될 수 있고 이전 연결의 데이터가 남아 있을 수도 있습니다. 비교하기 전에 현재 화면 통계의 집계 범위를 파악하고 짧은 시간 동안 관찰하세요. 범위를 모르는 상태에서 누적값의 변화로 특정 규칙의 적용 여부를 추정하지 마세요. 대상을 정확히 찾으려면 해당 요청 기록과 반복 가능한 접속을 주요 증거로 사용하세요.

문제가 간헐적으로 발생하면 먼저 Config를 그대로 두고 재현 조건을 명확하게 유지하세요. 네트워크 전환, 기기 잠금, 구독 업데이트, 지속적인 데이터 전송과 관련이 있는지 기록하고 같은 조건에서 제한된 횟수만 테스트합니다. 실패할 때마다 다른 설정을 바꾸면 결과를 비교할 수 없습니다. 안정적인 기준 사본과 한 항목만 변경한 사본을 보관하면 이후 문제 해결 중 원래 상태를 잊지 않고 임시 설정에 따라 복구되는지 확인하기도 쉽습니다.

기록을 정리할 때 구독 주소, 서버 인증 정보, 개인 도메인, 기기 정보를 보호하세요. 필요한 시간대만 캡처하고 오류 유형, 규칙 키워드, 처리 단계는 남기되 인증 데이터와 개인 식별 정보는 삭제합니다. 전체 Config와 Log를 함께 공개하지 마세요. 비밀번호 필드만 숨겼다고 모든 민감한 정보가 제거되는 것은 아닙니다. 구독 주소의 쿼리 매개변수, 연결 주소, 일부 이름에도 개인 서비스 정보가 포함될 수 있으므로 항목별로 확인하세요.

문제가 해결된 것을 확인한 뒤 동일한 조건으로 다시 테스트하고 임시로 켠 상세 기록을 원래 상태로 복원하세요. 이전 Log 전체를 삭제하는 것을 일반적인 해결 절차로 삼지 마세요. 기록을 지워도 화면에 보이는 기록과 저장 공간만 바뀔 뿐 서버 매개변수나 규칙이 자동으로 수정되지는 않습니다. 전체 처리 순서는 연결 후 접속 불가 문제 해결 안내와 함께 확인하세요. 현상으로 문제 단계를 찾은 다음 조정할 항목을 결정하면 됩니다.

Widget / iCloud

Widget, iCloud 동기화 및 기기 복원

Widget은 조작을 위한 진입점이지 전체 진단 화면이 아닙니다

Widget은 시스템에서 제공하는 위치에서 상태를 확인하거나 빠른 동작을 실행하는 기능입니다. 이용 가능한 항목은 기기에 실제로 표시되는 Widget을 기준으로 확인하세요. 업데이트는 시스템이 관리하므로 네트워크 상태가 바뀐 직후의 상황이 표시 시점과 정확히 일치하지 않을 수 있습니다. Widget과 Home 표시가 다르면 앱을 열어 현재 서버, 연결 상태, 실제 요청을 확인한 뒤 새로 고침을 기다리세요. 표시가 늦다는 이유로 Config를 다시 작성하지 말고 Widget 문구만 보고 연결이 계속 성공 중이거나 이미 중지됐다고 판단하지 마세요.

Widget을 추가할 때는 시스템의 위젯 편집 절차에서 Shadowrocket을 선택하고 현재 Widget이 제공하는 설정 항목을 확인하세요. Widget에서 관련 항목을 선택할 수 있다면 아직 존재하고 용도에 맞는 항목이 지정되어 있는지 확인합니다. 데이터를 복원하거나 이름을 바꾸거나 기존 항목을 삭제한 뒤에는 이전 선택을 다시 살펴봐야 할 수 있습니다. 용도를 명확히 알 수 있는 간단한 표시부터 사용하고 의미가 비슷한 진입점을 여러 개 동시에 배치하지 않는 편이 좋습니다. 상태를 확인하기 전에 연결 조작을 연달아 실행할 수 있습니다.

동기화 데이터와 구매 자격은 별도로 처리합니다

iCloud 동기화는 앱이 지원하는 데이터를 동기화하는 기능이며 App Store 구매 기록과는 다릅니다. 현재 VPN 세션을 기기 간에 그대로 옮기는 기능도 아닙니다. 앱 구매, 설정 동기화, 연결 권한 승인은 서로 독립된 절차입니다. 새 기기에서 구입 항목으로 앱을 다시 받을 수 있다고 해서 모든 설정이 동기화됐다고 볼 수 없습니다. Config가 표시되더라도 연결을 확인하기 전에 이 기기의 네트워크 권한, 서버 선택, 규칙이 올바른지 확인하세요.

기본 동기화 상태와 동기화 가능한 범위는 이 기기의 Settings에 표시된 내용을 기준으로 확인하세요. 동기화를 켜기 전에 시스템의 iCloud 로그인 및 관련 접근 권한을 확인하고 사용할 수 있는 로컬 Config 사본을 저장해 두세요. 두 기기에서 같은 내용을 동시에 크게 수정한 뒤 동기화를 기다리지 마세요. 동기화는 기록을 무한히 보관하는 백업 도구가 아니므로 오래된 값을 모두 복구할 수 있다고 가정할 수 없습니다. 중요한 Config 변경 사항은 보안이 유지되는 개인 저장 공간에도 복구 가능한 사본으로 보관하고 인증 정보를 보호하세요.

동기화 지연 및 충돌 처리

다른 기기에 변경 사항이 나타나지 않으면 두 기기의 네트워크가 정상인지, iCloud 관련 권한이 허용되어 있는지, 앱의 동기화 상태가 어떤지 먼저 확인하세요. 적절한 시간을 기다린 뒤 내용을 확인하고 동기화를 재촉하려고 가져오기, 덮어쓰기, 삭제를 연달아 실행하지 마세요. 두 기기의 내용이 이미 다르면 각각 사본을 보존한 뒤 어느 쪽을 기준으로 유지할지 결정합니다. 자동 병합, 덮어쓰기, 충돌 내용 보존 여부는 실제 화면에 나타나는 결과를 따르며 이 매뉴얼은 일정한 처리 방식을 가정하지 않습니다.

기기마다 서로 다른 네트워크 정책이 필요할 수 있습니다. iPhone의 셀룰러 네트워크 상황은 iPad에서 주로 사용하는 Wi-Fi 환경과 다를 수 있으며 On Demand 조건, 테스트 대상의 접속 여부, 로컬 포트 용도도 달라질 수 있습니다. 따라서 동기화 후에는 네트워크 환경과 관련된 항목을 다시 확인하고 파일 이름이 같다는 이유만으로 검증을 건너뛰지 마세요. 동일한 Config로 최소한의 연결을 먼저 설정한 다음 자동 연결과 Widget 진입점을 하나씩 복원하면 동기화 성공을 모든 설정의 적합성으로 오해하지 않을 수 있습니다.

기기를 교체하거나 앱을 다시 설치할 때는 기존 구매 계정의 App Store 구입 항목에서 앱을 다시 받으세요. 재다운로드 절차 및 일반적인 구매 적용 여부는 App Store 페이지를 기준으로 확인합니다. 이후 지원되는 데이터가 복원됐는지 확인하고 서버 및 구독 정보가 여전히 유효한지 살펴본 뒤 시스템 안내에 따라 이 기기의 연결 권한을 승인하세요. 자세한 내용은 구입 항목 복원 안내와 새 iPhone에서 Shadowrocket 복원하기를 확인하세요. 구매와 동기화 문제를 한 단계에서 함께 처리할 필요는 없습니다.

iPad에서는 가로 화면이나 분할 화면에 따라 페이지 위치가 달라질 수 있지만 화면의 고정된 좌표가 아니라 Home, Config, Settings 같은 화면 용어를 기준으로 찾으세요. iPad 구매 및 화면 안내도 참고할 수 있습니다. 복원 후에는 Widget이 가리키는 항목과 On Demand 조건을 다시 확인해 빠른 실행 항목이 실제로 보존된 데이터와 일치하도록 하세요.

Proxy / 포트 및 복구

Proxy 포트, 매개변수 범위 및 복구 확인

로컬 수신 포트와 원격 서버 포트

‘포트’는 어느 쪽의 값인지 먼저 확인해야 합니다. Add Server에 입력하는 서버 포트는 사용자가 이미 보유한 서비스 정보를 기준으로 하며 원격 서버에 연결할 때 사용합니다. Settings에 로컬 Proxy 수신 관련 항목이 있다면 기기 자체 또는 허용된 출처에서 시작하는 프록시 요청에 사용됩니다. 두 항목의 역할은 다르므로 원격 연결 문제를 해결하려고 로컬 포트를 임의로 바꾸거나 서버 정보에 로컬 포트를 입력하면 안 됩니다. 수정 전에 주소, 포트, 프로토콜을 함께 확인해 어느 계층의 설정을 바꾸는지 파악하세요.

로컬 HTTP 또는 SOCKS5 연결 방식과 원격 서버 프로토콜도 서로 다른 개념입니다. 접속을 요청하는 쪽은 로컬에서 실제로 제공하는 서비스에 맞는 방식을 사용해야 하며 원격 서버는 저장된 서버 매개변수에 따라 계속 동작합니다. 특정 포트가 수신 대기 중이라는 사실만으로 DNS, 규칙, 원격 전달이 검증되는 것은 아닙니다. 로컬 Proxy에 명시적으로 연결해야 하는 앱이나 기기가 없다면 현재 상태를 유지하고 일반적인 VPN 연결을 위해 추가 수신 설정을 할 필요는 없습니다.

기본 포트 및 접근 범위

구체적인 포트 번호, 수신 범위, 인증 옵션은 기기의 Settings에서 확인하세요. 모든 설치 상태에 적용되는 고정값을 이 매뉴얼에서 지정하지 않습니다. 변경 전 기존 값을 기록하고 해당 포트를 사용하는 쪽에 값이 이미 입력되어 있는지 확인하세요. 포트를 바꾼 뒤에는 관련된 사용처에서도 값을 수정해야 합니다. 한쪽만 변경하면 연결이 거부되거나 계속 대기할 수 있습니다. 포트 충돌이 발생하면 먼저 충돌 원인을 확인하고 마지막으로 유지한 값을 기록하지 않은 채 여러 숫자를 연속으로 시도하지 마세요.

기기 자체에서만 사용하는 경우와 허용된 LAN 출처의 접근을 허용하는 경우는 위험이 다릅니다. 수신 범위를 넓히기 전에 현재 네트워크를 신뢰할 수 있는지, 인증이 제공되고 올바르게 사용되는지, 어떤 출처에서 해당 포트에 접근할 수 있는지 확인하세요. 한 번 테스트하기 편하다는 이유로 필요 이상의 접근 범위를 계속 열어 두지 마세요. LAN 요청이 도달할 수 있는지는 네트워크 격리 및 시스템 상태에도 달려 있습니다. 앱에서 관련 옵션을 켜더라도 모든 기기가 접속할 수 있다는 뜻은 아니며 권한 범위를 더 넓혀야 한다는 뜻도 아닙니다.

프로토콜 매개변수는 Settings로 보완할 수 없습니다

Shadowsocks, VMess, VLESS, Trojan, WireGuard, Hysteria2 등 각 프로토콜에는 고유한 필드가 있습니다. 사용자가 이미 보유한 서비스에서 제공한 정보를 기준으로 입력하세요. 주소, 포트, 인증 정보, 전송 방식, 암호화 매개변수가 맞지 않는다면 Ping, Widget, Log 수준을 조정해도 누락된 필드를 보완할 수 없습니다. 가져온 뒤에도 프로토콜 유형과 필수 매개변수를 확인하세요. 특히 수동으로 입력했다면 더 주의해야 합니다. 다른 연결에서 사용한 필드 구성을 근거로 현재 프로토콜에도 같은 설정이 적용된다고 추정하지 마세요.

서버에서 도메인을 제공하는 경우 주소가 바뀌어도 도메인은 유효한 서비스를 계속 가리킬 수 있습니다. 특정 시점에 조회된 주소로 임의로 바꾸면 이름 검증이나 이후 업데이트가 제대로 작동하지 않을 수 있습니다. TLS 이름이나 전송 경로와 관련된 필드에는 기존 정보에서 명시한 요구 사항을 유지하고 포트 테스트에 응답이 있었다는 이유만으로 관련 매개변수를 삭제하지 마세요. 입력 오류가 확인된 경우 한 번에 하나만 수정하고 실제 연결을 테스트한 뒤 수정 전후의 오류 단계를 비교해 기록하세요.

마지막으로 검증된 상태로 복원

문제 해결 후에도 복구되지 않으면 변경 기록을 역순으로 되돌리세요. 임시 포트와 테스트 항목을 먼저 복원하고 DNS를 되돌린 다음 기존 Config와 서버를 다시 선택하고 마지막으로 On Demand를 확인합니다. 한꺼번에 모든 데이터를 지우면 사용할 수 있었던 기준 설정과 문제 증거가 함께 사라집니다. 복원한 뒤 동일한 대상으로 연결을 다시 테스트하세요. 기존 Config에서도 문제가 생긴다면 네트워크와 보유 중인 서비스 상태를 확인하고 모든 변화가 클라이언트 설정 때문이라고 계속 가정하지 마세요.

구매와 시스템 요구 사항을 다시 확인하려면 App Store에서 받기 안내를 이용하세요. Shadowrocket은 유료 상용 클라이언트이며 클라이언트의 일회성 구매는 회선 요금제와 별개입니다. 기존 서비스의 유효 여부와 클라이언트 구매는 각각 확인해야 합니다. Settings 설정의 목표는 모든 항목을 바꾸는 것이 아닙니다. 유지하는 각 값의 용도를 분명히 하고 자동 동작을 설명할 수 있으며 문제가 생겼을 때 마지막으로 검증된 상태로 돌아갈 수 있어야 합니다.