Shadowrocket
설정 가이드

먼저 옵션이 속한 설정 범위를 확인하세요

한 번의 접속에는 세 가지 설정 범위가 동시에 영향을 줄 수 있습니다. 시스템 네트워크는 Wi-Fi와 셀룰러 네트워크 중 현재 연결 방식과 VPN 구성 허용 여부를 결정합니다. Shadowrocket의 Settings는 일부 앱 동작을 관리하고, 현재 활성화된 Config는 규칙과 설정값을 제공합니다. Home에서 선택한 서버도 실제 연결 정보에 영향을 줍니다. 따라서 Settings에 특정 값이 표시된다고 해서 모든 요청에 그 값이 적용된다고 단정할 수는 없습니다. 문제를 확인하기 전에 현재 네트워크, 서버, Global Routing 상태와 사용 중인 Config 파일을 기록하세요. 비활성 파일의 설정을 확인하는 일을 방지할 수 있습니다.

Settings를 열기 전에 해결하려는 문제를 구체적으로 정하세요. 예를 들어 도메인이 열리지 않으면 DNS와 라우팅을, 네트워크 변경 후 자동 연결이 필요하면 On Demand를, 기기를 바꾼 뒤 목록이 다르면 동기화를 확인해야 합니다. 이름에 네트워크가 포함되어 있다는 이유만으로 여러 스위치를 연달아 켜지 마세요. 옵션의 위치와 사용 가능 여부는 앱 및 시스템 환경에 따라 달라질 수 있습니다. 이 문서에서는 메뉴를 찾기 쉽도록 영어 이름을 그대로 사용합니다. 현재 화면에 해당 메뉴가 없다면 이름만 같은 다른 옵션으로 대신하지 마세요.

기본값과 권장값을 기록하는 방법

이 안내서는 특정 기기의 현재 값을 모든 사용자의 기본값으로 간주하지 않습니다. 새로 만든 Config, 가져온 파일, 복원된 앱 데이터는 서로 다른 상태에서 시작할 수 있습니다. 기본값을 확인할 때는 앱 초기 설정, 현재 Config에 명시된 값, 값이 명시되지 않았을 때의 상속 동작을 구분하세요. 초기 상태를 확인하려고 기존 데이터를 지우는 방법은 피해야 합니다. 기존 정보가 사라질 수 있으며, 가져온 파일의 최초 설정을 복원해 주지도 않습니다. 먼저 현재 상태를 기록한 다음 각 항목의 설명을 참고해 조정 여부를 판단하는 편이 안전합니다.

권장값은 사용 목적에 따라 달라집니다. 안정적으로 작동하는 기기라면 현재 설정을 유지하고, 임시 진단 중에는 변수를 줄이세요. 특정 DNS 확인, 자동 연결 또는 로컬 Proxy 접속이 필요한 경우에만 해당 설정을 추가하면 됩니다. 값을 기록할 때는 숫자뿐 아니라 화면 위치, Config 이름, 변경 이유와 검증 결과도 함께 적으세요. 입력란이 비어 있다고 해서 반드시 비활성 상태인 것은 아닙니다. 상속 또는 자동 선택을 뜻할 수도 있습니다. 화면 설명이나 Config의 의미가 명확한 경우에만 빈 값을 특정 동작으로 해석하세요.

변경은 검증과 되돌리기까지 한 번에 진행하세요

변경 전에 같은 웹페이지를 열어 새로고침하는 등 반복 가능한 검증 방법 하나를 정하세요. 변경 후에도 같은 네트워크, 같은 서버, 같은 대상을 사용해 다시 확인하세요. 필요하다면 연결을 끊었다가 다시 연결해 기존 연결의 영향을 배제합니다. 결과가 나아지지 않으면 두 번째 항목을 추가로 변경하지 말고, 기록해 둔 값으로 방금 변경한 항목을 되돌리세요. 네트워크, 서버, 규칙 변경은 각각 따로 테스트해야 합니다. 그래야 접속이 복구됐을 때 어느 변경이 효과가 있었는지 알 수 있습니다.

처음 연결할 때 시스템의 “VPN 구성 추가” 안내가 표시되면 앱이 네트워크 구성을 설정하도록 허용하는 절차로 이해하세요. 구독을 가져오는 단계가 아닙니다. 승인을 거부한 경우와 서버 설정이 잘못된 경우는 서로 다른 문제입니다. 시스템 항목을 삭제했다면 정상적인 연결 절차를 다시 진행해 승인을 처리하세요. DNS나 규칙을 바꿔 문제를 보완하려고 하지 마세요. 안내의 구체적인 의미는 VPN 구성 안내 설명을 참고하고, 구입 내역 문제는 정품 확인 페이지에서 확인하세요.

DNS 설정이 실제로 바꾸는 것

DNS는 도메인을 연결에 필요한 주소로 변환하지만 Proxy 연결 자체와는 다릅니다. 도메인을 확인하기 전에 서버 연결이 실패해 접속이 중단될 수도 있고, DNS 확인은 성공한 뒤 대상 연결 단계에서 실패할 수도 있습니다. 따라서 웹페이지가 열리지 않는다고 곧바로 DNS 문제라고 볼 수는 없습니다. 먼저 문제가 어느 범위에 영향을 주는지 확인하세요. 모든 도메인에서 실패하는지, 특정 도메인만 실패하는지, 특정 네트워크에서만 실패하는지 살펴봅니다. 기존 연결이나 캐시가 문제를 가려 같은 설정이 때로는 작동하고 때로는 작동하지 않는 것처럼 보일 수 있습니다. 새로운 접속 기록으로 현상을 확인하세요.

Config의 dns-server는 DNS 확인에 사용할 출처를 지정합니다. 예시의 system은 시스템이 제공하는 DNS를 사용하는 설정으로, 기본 비교를 위한 한 가지 방법입니다. 모든 Config의 기본값을 뜻하거나 모든 네트워크에 적합하다는 의미는 아닙니다. 시스템 DNS는 Wi-Fi, 셀룰러 네트워크 및 네트워크 설정에 따라 달라질 수 있습니다. 이미 가져온 Config에서 별도의 DNS 동작을 지정했다면 변경하기 전에 원본 설명을 읽고 요청이 DNS 서비스에 도달하는 경로를 이해하세요.

[General]
dns-server = system

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

값과 검증 경로를 선택하는 방법

특별한 요구가 없고 현재 정상 작동하는 Config라면 기존 DNS 설정을 유지하는 것이 좋습니다. 진단이 필요하다면 사본에서 시스템 DNS를 사용해 비교하되 다른 설정은 바꾸지 마세요. 암호화 DNS 주소를 사용하는 경우에는 해당 DNS 서비스의 도메인을 어떻게 확인하는지, 연결 경로에 접근할 수 있는지, 인증서 검증이 정상인지도 고려해야 합니다. 입력란에 주소를 넣었다고 해서 DNS 요청이 예상한 경로로 전송된다고 보장할 수는 없습니다. DNS 서비스에 연결할 수 있어도 현재 네트워크 경로에서 응답된 모든 주소에 접근할 수 있다는 뜻은 아닙니다.

DNS가 적절한지 판단할 때 서비스의 위치나 이름만 보지 마세요. 현재 네트워크에서 연결할 수 있는지, 질의에 적절한 응답이 오는지, 응답된 주소가 선택한 경로에서 연결 가능한지 확인해야 합니다. 일부 사이트는 DNS 출처에 따라 서로 다른 주소를 반환할 수 있습니다. DNS를 변경한 뒤 접속 결과가 달라졌다고 해서 어느 한쪽이 반드시 잘못된 것은 아닙니다. 반환된 주소와 클라이언트가 해당 주소에 연결하는 방식을 나누어 살펴보세요. 필요한 경우 Log에서 같은 대상의 기록도 함께 확인합니다.

IPv6, 캐시 및 네트워크 전환

도메인에는 IPv4와 IPv6 주소가 함께 지정될 수 있습니다. 한쪽 주소만 지원하는 경로에서는 일부 사이트가 느리거나 처음 열 때 오래 기다리고, 네트워크를 바꾸면 문제가 해결될 수 있습니다. 이럴 때 모든 규칙을 먼저 삭제하거나 수정하지 마세요. 로컬 네트워크가 실제로 어떤 주소 체계를 제공하는지, 서버와 프로토콜에 접근할 수 있는지 확인한 뒤 Log에서 대상 주소 유형을 살펴보세요. 화면에 주소 체계 옵션이 있다면 현재 값을 기록하고 한 항목씩 테스트하세요. 특정 주소 체계를 비활성화하는 방법을 모든 기기에 장기간 적용할 해결책으로 간주해서는 안 됩니다.

DNS를 변경해도 실행 중인 앱이 기존 연결을 계속 사용할 수 있습니다. 시스템, 앱 및 원격 서비스가 각각 결과를 캐시할 수도 있습니다. 따라서 설정을 저장하고 바로 새로고침하는 것만으로 새 설정의 적용 여부를 확인하기는 어렵습니다. Shadowrocket 연결을 끊었다가 다시 연결한 뒤 대상 사이트에 새로 접속하고, Log에서 새 요청이 발생했는지 확인하세요. 캐시 문제를 해결하려고 앱 데이터를 전부 지우지 마세요. 추가 변수가 생깁니다. 비교 테스트 중에는 Wi-Fi와 셀룰러 네트워크를 동시에 전환하지 마세요. DNS 출처와 네트워크 경로가 모두 바뀝니다.

특정 도메인 하나만 문제가 있다면 철자, 해당 규칙 및 적용 전략부터 확인하세요. 모든 도메인에서 실패한다면 DNS 서비스에 연결할 수 있는지 확인하고, DNS 응답은 있지만 연결이 실패한다면 서버, 대상 포트 및 라우팅을 확인하세요. 다른 사람에게 문제를 설명할 때는 민감 정보를 제거한 도메인, 테스트 시간, 네트워크 유형 및 실패 단계만 제공하면 됩니다. 전체 구독 주소나 접속 인증 정보를 공개하지 마세요. 단계별 점검은 연결은 켜졌지만 접속되지 않을 때 확인할 네 가지를 참고하세요.

먼저 라우팅 상태를 확인한 뒤 규칙을 살펴보세요

Global Routing은 현재 라우팅 동작을 이해하는 기준입니다. Config는 활성 Config의 규칙에 따라 요청을 처리합니다. Proxy는 트래픽을 프록시 경로로 보내고, Direct는 직접 연결 경로를 사용합니다. 각 방식은 진단을 위한 비교에 유용하지만, 이름만으로 모든 시스템 트래픽의 처리를 단정할 수는 없습니다. 시스템의 예외 경로, Config의 우회 동작, 연결 처리 범위에 포함되지 않는 트래픽도 따로 고려해야 합니다. 규칙을 확인하기 전에 현재 상태가 Config인지 살펴보세요. Config가 아닌 상태에서 규칙을 수정했다면 기대한 변화가 나타나지 않더라도 규칙 문법이 잘못됐다고 볼 수 없습니다.

Settings의 앱 수준 옵션과 Config 안의 설정값은 연결 동작에 각각 영향을 줄 수 있습니다. 한 곳에 표시된 값만으로 전체 적용 설정을 판단하지 마세요. 파일을 가져온 뒤에는 현재 활성화된 파일을 확인하고 [General]과 [Rule]을 살펴보세요. 목록의 다른 파일을 편집해도 현재 Config가 자동으로 바뀌지는 않습니다. 예상과 다른 동작이 나타나면 파일을 다시 가져오기보다 활성 파일 이름과 실제로 적용된 규칙을 먼저 기록하고 설정의 의미를 확인하는 편이 현재 상태를 보존하기 쉽습니다.

General 설정 및 규칙 순서

bypass-system은 시스템 트래픽의 우회 동작과 관련이 있고, skip-proxy는 Proxy 처리를 건너뛸 주소 범위를 지정합니다. 아래의 사설 주소 대역은 문법을 이해하기 위한 예시이며 기존 목록을 확인 없이 덮어쓰면 안 됩니다. 사용 중인 네트워크에 다른 주소 대역이나 특정 접속 요구 사항이 있을 수 있습니다. DNS, 우회 목록, 규칙은 서로 다른 조건입니다. 도메인에 PROXY를 지정했다고 해서 관련된 모든 트래픽이 다른 조건을 무시한다고 가정하지 마세요.

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT

규칙은 일반적으로 순서대로 적용되므로 앞에서 일치한 조건이 뒤의 판단에 영향을 줄 수 있습니다. 예시에서는 먼저 example.com과 하위 도메인을 처리하고 지정된 주소 대역을 처리한 다음 FINAL로 나머지를 처리합니다. DOMAIN은 전체 도메인에, DOMAIN-SUFFIX는 도메인 접미사에 사용합니다. DOMAIN-KEYWORD는 더 넓은 범위에 일치하므로 의도하지 않은 매칭에 주의하세요. IP-CIDR과 IP-CIDR6은 주소 대역에 적용되며, 도메인 텍스트를 주소 규칙에 직접 입력해서는 안 됩니다.

변경이 적용됐는지 확인하는 방법

긴 규칙 목록을 먼저 가져오기보다 최소한의 규칙으로 비교 테스트를 시작하세요. 지정한 사이트만 Proxy를 사용하려면 앞의 DOMAIN-SUFFIX와 FINAL,DIRECT 예시를 활용할 수 있습니다. 나머지 요청의 처리 방식을 달리해야 한다면 실제 사용 목적에 맞게 조정하세요. 정책 이름은 현재 Config에 정의된 유효한 이름이어야 합니다. 정의되지 않은 이름을 임의로 입력하지 마세요. 변경 후 Config를 저장하고 활성화했는지 확인한 다음 새 요청을 만들어 적용된 규칙을 살펴보세요. 앞선 다른 규칙이 적용됐다면 같은 도메인을 반복해서 추가하지 말고 순서를 먼저 고치세요.

규칙 판단은 요청에서 확인할 수 있는 정보에도 영향을 받습니다. 특정 연결에 대상 주소만 표시되면 도메인 기반 규칙의 예상 결과를 그대로 재현하지 못할 수 있습니다. 한 웹페이지가 여러 도메인에 연결될 수도 있으므로 페이지 본문은 표시되지만 이미지가 실패한다면 관련 연결을 각각 확인해야 합니다. 페이지를 한 번 불러온 결과만으로 모든 규칙이 올바르다고 판단하지 마세요. 하나의 대상 도메인을 정해 요청, 적용된 규칙 및 정책을 확인한 뒤 테스트 범위를 넓히세요. 일부 사이트에만 Proxy를 적용하는 방법은 DOMAIN-SUFFIX 및 FINAL 설정 안내를 참고하세요.

‘언제 연결할지’와 ‘어떤 경로로 보낼지’를 구분하세요

On Demand는 설정한 조건에 따라 시스템이 연결 동작을 시작하도록 합니다. 연결을 언제 시작하거나 유지할지에 초점을 둡니다. Config의 규칙은 처리 대상 요청에 어떤 정책을 적용할지 결정합니다. 두 기능은 서로 다릅니다. On Demand를 켜도 서버 정보가 자동으로 채워지지 않고, 모든 사이트가 특정 경로를 사용하게 되지도 않습니다. 이미 보유한 서버에 연결할 수 없다면 먼저 수동 연결 상태에서 문제를 해결하세요. 그런 다음 자동 트리거를 설정해야 합니다. 그렇지 않으면 시스템이 반복해서 연결을 시도해 문제를 확인하기 더 어려워집니다.

On Demand의 현재 값을 확인할 때는 앱에서 켜져 있는지뿐 아니라 시스템 VPN 구성의 상태와 관련 조건도 확인해야 합니다. 기존 구성, 복원된 데이터 또는 이전 설정이 현재 상태에 영향을 줄 수 있으므로 이 문서에서는 켜기나 끄기를 모든 기기의 기본값으로 지정하지 않습니다. 처음 연결하거나 문제를 해결하는 중이라면 제어하기 쉬운 수동 연결 절차를 먼저 사용하세요. 수동 연결이 안정적으로 작동하고 대상 네트워크의 조건을 파악한 뒤 실제 필요에 맞는 On Demand 규칙을 설정하면 됩니다.

네트워크 조건별로 하나씩 검증

현재 화면에 Wi-Fi, 셀룰러 네트워크 또는 네트워크 이름과 관련된 조건이 있다면 각 조건의 적용 범위를 먼저 확인하세요. 네트워크 이름이 같아도 환경이 완전히 동일하지 않을 수 있으며, 공용 네트워크는 먼저 웹 로그인을 해야 할 수도 있습니다. 익숙한 Wi-Fi 이름이 표시된다는 이유만으로 자동 연결이 반드시 성공한다고 판단하지 마세요. 설정 후에는 셀룰러에서 Wi-Fi로 전환, Wi-Fi에서 셀룰러로 전환, 잠시 연결이 끊겼다가 복구되는 상황을 각각 테스트하고 시스템 상태와 앱 상태가 일치하는지 기록하세요.

간단한 조건부터 테스트하세요. 먼저 명확한 네트워크 조건 하나로 예상대로 연결이 시작되는지 확인한 다음 예외를 추가합니다. 조건이 여러 개라면 현재 화면에 표시된 순서, 일치 방식 및 동작 설명을 살펴보세요. 목록 위치만으로 우선순위를 추측해서는 안 됩니다. 범위가 지나치게 넓은 조건은 뒤에 있는 예외를 무효화할 수 있습니다. 조건을 추가할 때마다 실행되어야 하는 상황과 실행되지 않아야 하는 상황을 각각 한 번 이상 확인하세요. 그래야 스위치가 켜지는 것뿐 아니라 적용 범위의 경계도 확인할 수 있습니다.

네트워크가 바뀌면 기존 연결이 끊기고 새로 만들어질 수 있습니다. 특정 앱의 기존 연결이 실패하더라도 On Demand가 작동하지 않았다는 뜻은 아닙니다. 새 연결은 복구됐지만 이전 세션을 계속 사용할 수 없는 상황일 수도 있습니다. 새로 접속을 시도한 뒤 VPN 상태를 확인하세요. 반대로 시스템에 VPN 연결됨으로 표시되어도 선택한 서버가 대상에 접근할 수 있다는 뜻은 아닙니다. 자동 트리거, 터널 연결, 대상 접속은 연속되지만 서로 다른 단계입니다. 각각의 상태를 따로 기록해 뒤 단계의 문제를 트리거 조건 탓으로 돌리지 않도록 하세요.

연결 중지 및 되돌리기

On Demand를 켜면 연결을 수동으로 끊어도 조건을 만족하는 시스템 동작이 곧바로 연결을 다시 시작할 수 있습니다. 그렇다고 버튼이 작동하지 않는 것은 아닙니다. 일시적으로 연결을 중지하려면 관련 자동 연결 조건을 먼저 일시 중지한 다음 현재 연결을 끊으세요. 다른 자동 트리거 설정이 여전히 유효한지도 확인해야 합니다. 구체적인 메뉴는 사용 중인 시스템과 앱 화면을 기준으로 확인하세요. 일시적으로 연결을 끊으려고 모든 VPN 항목을 반복해서 삭제하고 다시 추가하지 마세요. 승인, 조건 및 연결 문제가 뒤섞일 수 있습니다.

먼저 네트워크 인증이 필요한 Wi-Fi에서는 자동 연결을 켜기 전에 로컬 네트워크가 실제로 사용 가능한지 확인하세요. 그렇지 않으면 DNS 확인, 인증 페이지 및 원격 연결이 동시에 대기해 모든 네트워크가 작동하지 않는 것처럼 보일 수 있습니다. 문제를 확인할 때는 잠시 수동 연결로 전환해 네트워크 인증을 완료한 뒤 다시 테스트하세요. 이는 네트워크 준비 단계를 확인하는 방법이지 On Demand를 계속 끄라는 뜻은 아닙니다. 회사 또는 학교에서 관리하는 기기라면 관리 정책을 따르고 시스템 구성을 임의로 삭제해 요구 사항을 우회하지 마세요.

최종 설정은 “확인된 네트워크 조건에서 연결을 시작하고, 진단 중에는 일시 중지한다”처럼 한 문장으로 설명할 수 있어야 합니다. 각 조건의 목적을 분명히 설명하기 어렵다면 조건 수를 줄이세요. 변경할 때마다 트리거 결과, 선택한 서버 및 재승인 필요 여부를 기록하고 예상과 다르면 검증을 마친 이전 설정으로 되돌리세요. 자동 연결은 반복 조작을 줄이는 기능이지 연결 품질을 보장하지 않습니다. 서버의 이용 가능 여부, 구독 유효성 및 현재 Config는 사용자가 별도로 확인해야 합니다. 관련 내용은 자주 묻는 질문에서 더 살펴볼 수 있습니다.

Ping 수치는 실제 접속 속도와 다릅니다

화면에서 Ping은 연결 테스트를 통칭하는 이름으로 쓰일 수 있지만 실제 측정 방식은 다를 수 있습니다. 모든 결과가 같은 왕복 시간이라고 생각하지 말고 현재 테스트 방식을 먼저 확인하세요. 서버 주소 탐색, 포트 연결, Proxy를 통한 지정 URL 접속은 서로 다른 단계를 검증합니다. 서버가 탐색 요청에 응답하더라도 프로토콜 인증이 성공했다는 뜻은 아닙니다. 포트 연결이 가능해도 앱 계층의 설정, 인증서 또는 대상 접속이 모두 정상이라는 의미는 아닙니다.

낮은 수치만으로 다운로드 속도가 빠르다고 판단할 수는 없습니다. 짧은 테스트는 주로 연결을 시작하고 응답을 받는 과정을 확인합니다. 지속적인 데이터 전송은 로컬 네트워크, 서버 부하, 연결 경로 상태 및 대상 사이트의 영향을 받습니다. 한 번의 테스트가 실패했다고 서버를 전혀 사용할 수 없는 것도 아닙니다. 현재 경로에서 테스트 방식이 지원되지 않을 수 있습니다. 결과를 확인할 때는 테스트 방식, 대상, 네트워크 유형 및 테스트 시각을 함께 기록하세요. 이런 정보 없이 목록의 숫자 두 개만 비교하면 서로 다른 측정 결과를 같은 품질 지표로 오해하기 쉽습니다.

테스트 방식과 URL 선택 방법

Settings의 관련 테스트 옵션은 현재 기기에 표시된 값을 기준으로 확인하세요. 다른 사용자가 공유한 화면을 공통 기본값으로 간주하지 마세요. 기존 테스트 결과가 안정적이고 실제 사용에 적합하다면 유지할 수 있습니다. 진단이 필요하면 문제 단계에 맞는 방식을 선택하세요. 서버 포트를 확인할 때는 연결 단계를 테스트하고, Proxy를 통한 접속을 확인할 때는 해당 URL 테스트를 사용하세요. 선택 가능한 방식은 현재 화면을 기준으로 확인하세요. 표시되는 숫자를 더 낮추려고 방식을 계속 바꾸지 마세요. 이전 결과와 비교하기 어려워집니다.

URL 입력을 지원하는 테스트라면 응답 형식이 예상에 맞고 안정적으로 접근할 수 있는 대상을 선택하세요. 리디렉션, 로그인 페이지, 인증서 오류 및 접속 빈도 제한으로 테스트는 실패해도 일반적인 브라우징 결과는 다를 수 있습니다. 안내에 나오는 example.com은 형식을 설명하기 위한 예시일 뿐, 장기간 사용 가능한 속도 측정 서비스가 아닙니다. 로그에 표시될 수 있는 테스트 입력란에 비공개 접속 정보가 포함된 주소를 입력하지 마세요. 진단 자료를 공유할 때 정보가 노출될 수 있습니다.

비교 가능한 테스트 기록 만들기

서버 하나와 테스트 대상 하나를 고정한 뒤 같은 네트워크에서 몇 차례 반복 테스트하세요. 실패가 계속되는지, 결과가 크게 달라지는지 확인하면 됩니다. 한 번의 튀는 값으로 결론을 내리거나 짧은 시간에 모든 서버를 집중적으로 테스트할 필요는 없습니다. 테스트 기능에 시간 초과 한도가 표시된다면 대기 시간의 상한으로 이해하세요. 네트워크 품질 목표가 아닙니다. 한도를 줄여도 느린 응답을 더 빨리 실패로 판정할 뿐 실제 연결이 빨라지지는 않습니다. 대기 시간을 늘려도 잘못된 주소, 포트 또는 프로토콜 인증 정보는 해결되지 않습니다.

목록 테스트는 정상인데 실제 웹페이지가 실패한다면 웹페이지 요청이 같은 서버를 사용하는지, Config에서 다른 정책이 적용되는지, 실패한 리소스 도메인이 추가로 있는지 확인하세요. 반대로 테스트는 실패하지만 실제 접속이 정상이라면 모든 설정을 곧바로 바꾸기보다 테스트 대상과 방식을 확인하세요. Connectivity Test 결과도 테스트 대상에 맞춰 해석해야 합니다. 테스트 도구는 문제 단계를 좁히기 위한 근거이지 실제 접속을 대신할 수 없으며, 성공 상태 하나만으로 모든 앱이 정상 작동한다고 증명할 수도 없습니다.

마지막으로 로컬 네트워크를 비교할 때는 서버, 프로토콜 및 DNS를 바꾸지 말고 Wi-Fi와 셀룰러 네트워크만 전환하세요. 결과가 로컬 네트워크에 따라 달라지면 네트워크 제한과 주소 연결 가능 여부를 확인합니다. 네트워크에 관계없이 결과가 같다면 서버 설정과 원격 경로를 살펴보세요. 테스트가 끝나면 필요한 Global Routing 상태로 복구하고 불필요한 대량 탐색을 중지하세요. 지속적인 속도 문제를 단계별로 확인하려면 속도가 느릴 때 네트워크, 프로토콜 및 경로 확인을 참고하세요. 지연 시간 수치를 대역폭 측정값으로 보지 마세요.

유용한 Log를 확인하는 방법

Log는 내용이 많을수록 유용한 것이 아니라 명확한 작업 하나와 대응될 때 가치가 있습니다. 문제를 확인하기 전에 네트워크, 서버, Global Routing 및 활성 Config를 기록하세요. 그런 다음 현재 화면의 로그 기능으로 필요한 기록을 켜고 실패한 접속을 한 번 시도한 뒤 해당 시각의 기록을 바로 확인합니다. 기록 범위를 선택할 수 있다면 문제를 살펴보기에 충분한 범위를 사용하세요. 오랜 시간 쌓인 여러 작업의 로그에는 관련 없는 연결이 많아 방금 발생한 작업의 오류를 찾기 어려울 수 있습니다.

로그 기능과 기록 범위의 초기 상태는 현재 기기에서 확인하세요. 평소에는 실제로 필요한 설정을 유지하고, 문제를 재현하는 동안에만 기록 범위를 일시적으로 넓힌 뒤 원래 값으로 돌리는 것이 좋습니다. 상세 기록을 계속 켜둔다고 연결 품질이 개선되는 것은 아닙니다. 관찰할 정보가 늘어날 뿐입니다. 오래된 기록을 지우기 전에 진단 근거로 보관해야 하는지 확인하세요. 필요한 부분을 민감 정보 제거 후 저장하고 시간 범위를 정한 새 테스트를 시작하는 편이 안전합니다. 기록을 지우면서 계속 테스트하지 마세요.

오류 단어만 찾지 말고 요청 단계에 따라 읽으세요

로그는 대상 식별, 규칙 적용, 주소 확인, 원격 연결, 프로토콜 통신, 데이터 전송 순서로 단서를 살펴볼 수 있습니다. 실제 로그에 모든 단계가 표시되거나 순서대로 나열된다는 보장은 없으므로 기록된 근거만으로 판단해야 합니다. 시간 초과가 발생하면 어떤 대상에서 일어났는지 먼저 확인하세요. DNS 서비스, Proxy 서버, 대상 사이트는 서로 다른 문제입니다. 같은 오류 단어가 보인다고 DNS를 일괄 변경하거나 모든 서버 정보를 바꾸지 마세요.

요청에 DIRECT가 적용된 것으로 표시되면 먼저 규칙과 로컬 직접 연결 경로를 확인하세요. 예상한 Proxy 정책이 적용됐다면 서버 연결과 프로토콜 설정을 살펴봅니다. 인증 실패가 표시되면 사용자가 보유한 정보의 비밀번호, 식별자 또는 관련 설정값을 확인하세요. 인증서 오류라면 대상 이름, 시간 및 인증서 조건을 확인해야 하며 검증을 끄는 방법을 일반적인 해결책으로 사용해서는 안 됩니다. 예상한 요청이 로그에 없다면 기록 범위, 새 연결이 발생했는지, 요청이 현재 처리 범위에 포함되는지 먼저 확인하세요. 이를 근거로 앱이 실행되지 않는다고 단정하지 마세요.

Data 수치를 활용하는 방법

Data는 누적 변화를 살펴보는 데 적합하며 연결 한 번의 성공을 증명하지는 않습니다. 업로드, 다운로드 및 누적 수치를 볼 때는 현재 화면의 통계 대상과 집계 시작 시점을 먼저 확인해야 합니다. 서버별 또는 앱별 보기가 있다면 각 항목이 어떤 기준으로 나뉘는지 확인하세요. 특정 서버에 과거 수치가 있다고 해서 방금 그 서버를 사용했다는 뜻은 아닙니다. 특정 앱의 수치가 늘지 않았더라도 연결 재사용, 통계 갱신 또는 처리 범위가 원인일 수 있습니다. Log와 실제 작업을 함께 확인하세요.

집계 기간, 트래픽 분류, 연결 오버헤드 및 적용 범위가 달라 Data와 시스템 트래픽 통계가 서로 다를 수 있습니다. 비교하기 전에 관찰 기간을 동일하게 맞추고 서로 다른 시작 시점의 총량 대신 작업 전후의 증가량을 기록하세요. 통계 초기화 기능이 있더라도 해당 통계 기록만 바뀌며 연결이 복구되지는 않습니다. 기준을 저장하지 않은 채 초기화하면 비교 근거를 잃게 되므로 주의하세요. 서버별 보기와 앱별 보기의 차이는 Data 화면의 트래픽 수치 안내를 참고하세요.

진단 자료를 공유하기 전에 민감 정보 제거

로그와 Config에는 구독 주소, 서버 정보, 인증 정보 및 접속 대상이 포함될 수 있습니다. 공유 전에 비밀번호 한 곳만 가리지 말고 항목별로 확인하세요. 전체 URL의 쿼리 부분, QR 코드 내용, 요청 헤더, Config 주석 및 화면 가장자리에도 민감 정보가 남을 수 있습니다. 보통은 발생 시각, 민감 정보를 제거한 오류 기록, 현재 상태 및 재현 절차만 제공하면 됩니다. 문제 판단에 필요한 단계 정보만 남기고 전체 Config를 공개하지 마세요. 진단을 마친 뒤에는 임시로 내보낸 파일도 평소 자료 관리 방식에 따라 처리하세요.

Widget 표시를 확인하는 방법

Widget은 상태를 확인하거나 조작할 수 있는 편리한 진입점입니다. 제공되는 모양과 동작은 현재 시스템과 앱의 기능에 따라 달라집니다. 시스템이 백그라운드 갱신을 제한할 수 있으므로 Widget에 표시된 상태가 방금 발생한 변화와 동시에 업데이트되지 않을 수 있습니다. Widget에 이전 상태가 계속 표시되면 먼저 Shadowrocket의 Home을 열어 실제 연결과 선택한 서버를 확인한 뒤 새로 접속해 보세요. Widget에 표시된 글자만 보고 연결이 설정됐다고 판단하지 마세요. 갱신이 늦다는 이유로 프로토콜, 규칙 또는 DNS를 변경하지 마세요.

Widget을 추가하거나 조정한 뒤에는 예상한 항목과 연결되어 있는지 먼저 확인하세요. 앱 안에서 상태 변경, 시스템 Widget에서 조작, 기기를 다시 잠금 해제한 후 표시되는 상태를 각각 테스트합니다. 조작하려면 앱을 열거나 시스템 확인이 필요한 경우 현재 화면의 안내를 따르세요. 시스템 승인, On Demand 조건 및 실제 서버의 이용 가능 여부는 여전히 적용됩니다. Widget에서 이 절차를 건너뛸 수는 없습니다. 여러 진입점의 상태 갱신 시각이 달라 혼동되지 않도록 용도를 설명할 수 있는 Widget만 사용하는 것이 좋습니다.

iCloud 동기화는 연결 상태를 동기화하지 않습니다

iCloud 동기화는 동기화 가능한 데이터를 저장하고 전달하는 기능입니다. 두 기기에서 동시에 연결을 설정한다는 뜻이 아니며 시스템 승인, 현재 네트워크 또는 임시 상태가 두 기기에서 같다는 의미도 아닙니다. 동기화 범위는 Shadowrocket에서 현재 제공하는 옵션을 기준으로 확인하세요. 목록에 항목이 나타났다고 모든 설정이 복사됐다고 판단하지 마세요. 서버 목록, Config 파일, 선택 항목 및 앱 수준 설정을 각각 확인하고, 특히 대상 기기에서 실제 활성화된 Config가 무엇인지 살펴보세요.

동기화 옵션의 기본 상태는 사용 중인 기기에서 확인해야 합니다. 기존 자료를 여러 기기에서 관리하려면 먼저 시스템에서 원하는 개인 계정에 로그인했는지, iCloud를 사용할 수 있는지 확인한 뒤 Shadowrocket의 동기화 옵션을 살펴보세요. 여러 기기에서 사용할 필요가 없다면 현재 설정을 유지해도 됩니다. 동기화를 켜기 전에 로컬 사본을 보관하는 것이 좋습니다. 동기화는 일정한 변경 이력이 유지되는 백업을 보장하지 않습니다. 삭제, 덮어쓰기 또는 충돌 처리 결과가 다른 기기에도 적용될 수 있으므로 다른 기기를 항상 별도의 복구 수단으로 간주하지 마세요.

동기화 지연 및 충돌 해결 방법

두 기기의 목록이 다르면 먼저 계정과 동기화 범위를 확인하고 양쪽 네트워크가 정상인지 살펴본 뒤 시스템이 동기화를 완료할 시간을 주세요. 두 기기에서 같은 Config를 동시에 편집하거나 동기화를 반복해서 껐다 켜 강제로 갱신하지 마세요. 문제를 파악하기 어려워질 수 있습니다. 이번 편집의 기준이 될 기기 하나를 정해 내용을 기록한 다음 다른 기기에서 변경 사항을 확인하세요. 현재 화면에 가져오기, 내보내기 또는 복원 기능이 있다면 실행 전에 기존 자료에 병합되는지 대체되는지 확인하세요.

충돌을 해결할 때는 Config 이름만 비교해서는 충분하지 않습니다. 이름이 같은 파일도 규칙이 다를 수 있습니다. 주요 설정값, 규칙 순서 및 직접 기록한 변경 설명을 확인하세요. 두 사본을 보관해 비교하면 바로 덮어쓰는 것보다 되돌리기 쉽습니다. 동기화가 완료된 뒤에는 대상 기기에서 선택한 서버, Global Routing, VPN 승인 및 On Demand를 다시 확인하고 별도로 접속을 테스트하세요. 원본 기기에서 정상 작동했다는 사실만으로 대상 기기에서도 사용할 수 있다고 판단할 수 없습니다.

사용자가 이미 보유한 구독과 로컬 Config도 구분해야 합니다. 구독 항목을 동기화해도 구독 내용을 바로 다시 가져온다는 뜻은 아닙니다. 원격 구독 업데이트와 iCloud 데이터 동기화는 서로 다른 과정입니다. 항목은 있지만 목록 내용이 오래된 상태라면 시스템 동기화만 기다리지 말고 해당 구독의 업데이트 결과를 확인하세요. 구독 주소에는 접속 정보가 포함되므로 민감한 자료로 관리하고 두 기기의 내용을 비교하려고 전체 주소를 공개 게시판에 올리지 마세요. 이 문서는 보유 중인 자료의 관리 방법만 설명하며 서비스 제공이나 추천은 다루지 않습니다.

기기 변경 시 구입 내역과 데이터를 따로 확인

App Store 구입 자격, 앱 데이터 복원 및 네트워크 연결 승인은 서로 다른 사항입니다. 구입한 앱을 다시 받을 수 있어도 모든 로컬 Config가 복원된다는 뜻은 아닙니다. Config가 복원됐더라도 새 기기에서 처음 VPN 승인을 마쳤다는 의미는 아닙니다. 기기를 바꿀 때는 앱 받기, 자료 확인, Config 선택, 승인 완료, 접속 검증 순서로 확인하세요. 구입 및 재설치 방법은 구입한 앱 복원 안내를 참고하세요. 기존 기기를 계속 사용할 수 있다면 새 기기에서 정상 작동하는지 확인할 때까지 원래 데이터를 보관해 이전 과정에서 복구 가능한 유일한 사본을 잃지 않도록 하세요.

서로 다른 두 포트를 구분하세요

Add Server의 포트는 사용자가 이미 보유한 서버 접속 정보의 일부이며 원격 서버에서 실제로 수신하는 프로토콜 및 포트와 일치해야 합니다. Settings에 로컬 Proxy 포트가 있다면 이는 해당하는 상황에서 클라이언트 요청을 받는 이 기기의 Proxy 서비스 수신 설정입니다. 로컬 포트를 변경해도 원격 서버 설정은 바뀌지 않으며 원격 포트가 잘못 입력된 문제도 해결되지 않습니다. 확인할 때는 ‘누가 누구에게 연결하는지’를 명확히 적으세요. Shadowrocket이 서버에 연결하는지, 같은 기기의 요청 프로그램이 로컬 Proxy에 연결하는지 구분하면 됩니다.

로컬 Proxy 옵션의 이름, 사용 가능한 프로토콜 및 접속 범위는 현재 화면의 설명을 기준으로 확인하세요. 기기 상태, 기존 설정 및 기능 사용 여부가 다를 수 있으므로 이 문서에서는 공통 기본 포트를 지정하지 않습니다. 로컬 Proxy를 사용할 이유가 없다면 현재 설정을 유지하고 일반적인 VPN 연결에 필요하지 않은 수신 기능을 임의로 켜지 마세요. 필요한 경우 수신 주소, 포트, 프로토콜 및 다른 기기의 접속 허용 여부를 기록하고 연결하는 쪽에서 같은 프로토콜을 사용하는지 확인하세요.

수신 주소에 따라 접속할 수 있는 대상이 달라집니다

이 기기에서만 사용하도록 설정하는 것과 로컬 네트워크의 다른 기기에도 허용하는 것은 접속 범위가 다릅니다. 주소가 루프백 주소라면 일반적으로 이 기기에서만 접속할 수 있습니다. 수신 범위가 네트워크 인터페이스까지 확장되면 다른 기기에서도 연결을 시도할 수 있습니다. 포트 번호가 같다는 이유만으로 양쪽이 통신할 수 있다고 판단하지 마세요. 같은 네트워크에서 서로 통신할 수 있는지, 네트워크가 기기 간 연결을 차단하는지, 현재 주소가 바뀌었는지, 시스템과 앱에서 해당 연결을 허용하는지도 확인해야 합니다. 실제 접속 범위는 현재 기능 설명과 테스트 결과를 기준으로 판단하세요.

더 넓은 접속 범위를 허용하기 전에 실제로 필요한지 확인하고 현재 기능에서 제공하는 접근 제어를 사용하세요. 수신 범위를 넓히는 것을 이 기기의 연결 실패를 해결하는 첫 번째 방법으로 삼지 마세요. 신뢰할 수 없는 네트워크에서는 접근 범위를 좁혀 관계없는 기기가 Proxy 진입점에 접속하지 못하게 하세요. 사용을 마친 뒤에는 더 이상 필요하지 않은 수신 기능이나 접속 옵션을 끄고 요청하는 쪽에서도 이전 설정을 삭제했는지 확인하세요. 그렇지 않으면 앱 상태가 바뀐 뒤에도 이전 주소를 가리키는 요청이 계속 실패해 전체 네트워크 문제처럼 보일 수 있습니다.

포트 충돌과 연결 불가 구분하기

일반적으로 같은 수신 주소의 같은 포트를 여러 서비스가 임의로 중복 사용하기는 어렵습니다. 화면이나 Log에 바인딩 실패가 표시되면 원격 프로토콜을 계속 바꾸지 말고 포트 충돌이 있는지, 입력한 포트 값이 유효한지 먼저 확인하세요. 서비스가 이미 수신 중인데 요청 쪽에서 접속할 수 없다면 주소, 네트워크 경로 및 프로토콜을 확인합니다. HTTP와 SOCKS5는 접속 방식이 다릅니다. 요청 쪽에 잘못된 프로토콜을 입력하면 연결은 설정되지만 요청 처리가 완료되지 않을 수 있습니다. 포트에 연결할 수 있다는 이유만으로 설정이 올바르다고 판단해서는 안 됩니다.

로컬 진입점을 확인할 때는 가장 좁은 접속 범위에서 먼저 테스트한 뒤 필요에 따라 범위를 넓히세요. 원격 서버와 Global Routing은 그대로 두고 로컬 설정 하나만 변경한 다음 요청 쪽에도 해당 값을 업데이트하세요. 포트만 바꾸고 요청 쪽 값을 갱신하지 않았다면 양쪽 정보가 일치하지 않아 테스트가 실패한 것입니다. 새 포트를 사용할 수 없다는 뜻은 아닙니다. 기록에는 수신 범위, 양쪽 포트, 접속 프로토콜 및 오류 단계를 포함하세요. 네트워크 주소는 민감 정보를 제거해 저장할 수 있지만, 로컬과 원격 역할을 구분하는 맥락은 남겨야 합니다.

모든 변경을 복구 가능한 상태로 정리

진단을 마친 뒤 기록을 따라 하나씩 정리하세요. 불필요한 테스트 상태를 되돌리고 임시로 확대했던 기록 범위와 수신 기능을 끄며, On Demand 조건이 여전히 필요한지 확인하고 현재 활성 Config를 살펴본 뒤 확인된 대상으로 다시 접속합니다. 어떤 자료에 영향을 주는지 확인하고 전체 사본을 보관한 경우가 아니라면 ‘모든 설정 복원’으로 항목별 되돌리기를 대신하지 마세요. 진단을 제대로 마치면 설명할 수 없는 스위치가 늘어나는 것이 아니라 불확실한 항목이 줄어들어야 합니다.

문제를 찾지 못했다면 현재 네트워크, 선택한 서버, 라우팅 상태, Config 이름, 재현 절차 및 민감 정보를 제거한 Log를 정리한 뒤 서버, DNS 확인, 규칙, 시스템 승인 순으로 다시 살펴보세요. 새로 생긴 문제는 가장 최근에 변경한 항목부터 확인합니다. 변경하지 않았는데 갑자기 실패했다면 로컬 네트워크와 기존 서비스 상태를 살펴보세요. 전체 사용 절차를 다시 확인하려면 사용법 안내로 돌아가고, 증상별 답변을 찾으려면 자주 묻는 질문을 확인하세요. 검증되지 않은 설정을 계속 추가하기보다 문제를 재현할 수 있는 최소한의 상태를 보존하는 편이 원인을 찾기 쉽습니다.