Shadowrocket 설정 자세히 보기

01 / 설정 출처

Config 및 Global Routing

먼저 현재 어떤 Config를 사용 중인지 확인한 다음, 특정 Settings 항목의 적용 여부를 살펴보세요. Shadowrocket의 실제 연결 결과는 하나의 스위치만으로 결정되지 않습니다. Home에서 선택한 서버는 연결 매개변수를 제공하고, Config는 규칙과 관련 설정을 담으며, Global Routing은 라우팅 방식을 정하고, 시스템 네트워크는 기본 연결 조건을 제공합니다. 보유한 구독은 보통 서버 항목을 관리하는 데 사용하며, 트래픽 분류에 사용하는 구성 파일과는 다릅니다. 구독 업데이트에 성공했다고 해서 규칙이나 DNS도 함께 변경된 것은 아닙니다.

Config, 프록시, 직접 연결 구분하기

Global Routing의 Config, Proxy, Direct는 각각 구성에 따른 라우팅, 프록시, 직접 연결을 뜻합니다. Config는 현재 구성의 규칙에 따라 요청을 처리하고, Proxy는 프록시 경로로 트래픽을 처리하며, Direct는 직접 연결 경로로 처리합니다. 이는 라우팅 의도를 설명하는 것으로, 모든 요청의 성공이나 시스템의 모든 연결을 앱이 처리한다는 뜻은 아닙니다. 문제를 확인할 때 현재 방식을 기록해 두세요. Proxy 상태에서 규칙을 수정한 뒤 규칙이 저장되지 않았다고 오해하는 일을 막을 수 있습니다.

규칙은 개수보다 순서가 중요합니다

규칙은 보통 위에서 아래로 확인하며, 먼저 일치한 항목이 이후 정책을 결정합니다. DOMAIN-SUFFIX는 도메인 자체와 하위 도메인에 일치하고, GEOIP는 대상 주소의 지리 데이터베이스 결과를 기준으로 일치하며, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 범위가 넓은 규칙을 앞에 두면 아래의 더 구체적인 예외 규칙이 적용되지 않을 수 있습니다. 수정할 때는 대상 도메인과 관련된 항목을 찾고 그 위의 규칙을 확인하세요. 파일 끝에 올바른 것처럼 보이는 줄이 있는지만 검색해서는 안 됩니다.

[General]
dns-server = system

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

위 예시는 구조를 설명하기 위한 것으로, 모든 네트워크에 적합한 완성 구성은 아닙니다. example.com은 예시 도메인입니다. PROXY와 DIRECT는 정책 키워드이므로 서버 주소로 입력하면 안 됩니다. 도메인 규칙이 예시 도메인을 먼저 확인하고 GEOIP가 해당 주소를 처리한 뒤 FINAL이 나머지를 처리합니다. 실제 사용 전 보유한 서버가 작동하는지 확인하고, 자신의 접속 목적에 따라 각 규칙을 검토하세요. 일치 범위에 관한 자세한 내용은 DOMAIN-SUFFIX, GEOIP 및 FINAL 규칙 작성법을 참고하세요.

기본 상태와 권장 기준

기본값은 현재 설치된 기기에서 표시되는 값과 선택된 Config를 기준으로 확인하세요. 구성을 가져오거나 데이터를 복원하거나 Config를 전환하면 확인되는 상태가 달라질 수 있습니다. 규칙을 이해한 뒤에는 일상적으로 Config를 사용하는 것을 권장합니다. Proxy와 Direct는 문제를 비교·진단하는 데 사용할 수 있지만, 테스트 후 원래 방식으로 되돌리는 것을 잊지 마세요. 기준 상태를 처음 기록할 때는 Config 이름, 선택한 서버, Global Routing, 테스트 요청 하나를 적어 두세요. 그래야 이후 변화의 원인을 판단할 수 있습니다.

파일을 저장하는 것과 설정을 적용하는 것은 각각 확인해야 합니다. 수정한 뒤 먼저 편집 내용이 제대로 저장되었는지 확인하고, 해당 파일이 현재 활성화된 Config인지 확인하세요. 그런 다음 앱 화면의 안내에 따라 연결 상태를 처리합니다. 이미 연결된 세션은 기존 경로를 계속 사용할 수 있으므로, 계속 열려 있는 페이지를 관찰하는 데 그치지 말고 새 테스트 요청을 보내세요. 결과가 여전히 예상과 다르면 Log에서 요청 기록을 확인하고, 같은 내용을 바로 다시 가져오지는 마세요.

“서버 테스트는 되지만 특정 도메인에 접속할 수 없는” 경우에는 먼저 서버 연결 가능 여부와 규칙 일치 여부를 구분하세요. 실제 요청의 전체 도메인을 확인하고, 하위 도메인이나 리디렉션 도메인, 서로 다른 주소 계열이 있는지 살펴본 다음 적용된 정책을 확인합니다. 모든 요청이 실패한다면 연결 상태와 서버 매개변수를 먼저 확인하고, 특정 유형의 요청만 실패한다면 규칙과 DNS를 집중적으로 살펴보세요. 처음 연결 절차를 다시 진행해야 한다면 빠른 시작 안내로 돌아가세요. 원인을 가리기 위해 모든 설정을 한꺼번에 초기화하지 마세요.

02 / 이름 확인

DNS 설정 및 확인 경로

DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. 프록시 서버와 같은 것은 아니며, 모든 요청의 경로를 직접 결정하지도 않습니다. DNS 문제를 확인하기 전에 먼저 증상을 구분하세요. 도메인을 확인할 수 없는 경우, 주소를 받았지만 연결에 실패한 경우, 웹페이지의 주 문서는 열리지만 추가 리소스가 실패하는 경우는 서로 다른 단계의 문제입니다. 첫 번째 증상만 이름 확인 문제를 직접 시사합니다. 나머지는 라우팅, 서버, 대상 서비스, 연결 기록도 살펴봐야 합니다. 페이지가 열리지 않는 모든 문제를 DNS 탓으로 돌리지 마세요.

현재 Config의 DNS 설정부터 확인

DNS 관련 동작은 Settings의 특정 메뉴뿐 아니라 현재 Config의 영향을 받을 수 있습니다. 먼저 현재 구성을 열어 DNS 서버, 도메인 매핑 또는 관련 옵션이 명시되어 있는지 확인한 뒤 앱 화면에 표시되는 상태를 살펴보세요. 설정을 명시하지 않았다고 해서 모든 네트워크에서 결과가 같아지는 것은 아닙니다. 시스템에서 제공하는 DNS 조건은 Wi-Fi, 셀룰러 네트워크, 네트워크 접속 상태에 따라 달라집니다. 이 문서에서는 모든 기기에 적용되는 고정 DNS 주소를 지정하지 않습니다.

구성의 dns-server = system은 시스템에서 제공하는 DNS를 사용한다는 뜻입니다. 설정 출처를 이해하기 위한 기준 예시이며, 모든 상황에서 앱의 출고 시 기본 설정이라는 의미는 아닙니다. 기존 구성에 DNS 방식이 명시되어 있다면 먼저 원래 설계를 이해한 뒤 수정하세요. 이 한 줄만 파일 끝에 붙여 넣지 마세요. 적절한 구성 섹션에 넣어야 하며, 중복 정의로 혼동이 생기지 않도록 해야 합니다. 수정 전에 전체 사본을 보관하면 항목별로 되돌리기 쉽습니다.

DNS 전송과 요청 라우팅을 따로 확인

일반 DNS와 암호화 DNS의 차이는 DNS 요청의 전송 방식에 있습니다. 암호화 DNS를 사용한다고 해서 조회 결과가 반드시 정확하거나 접속이 반드시 성공하는 것은 아닙니다. 암호화 조회를 사용하려면 먼저 DNS 서비스에 연결할 수 있어야 합니다. DNS 서비스의 접속 주소가 도메인 이름이라면 서비스 자체의 주소를 확인하는 과정도 선행 조건이 될 수 있습니다. 구성이 지나치게 복잡하면 문제 해결이 순환할 수 있습니다. 서비스 도메인은 DNS 확인을 기다리고, DNS 서비스는 아직 준비되지 않은 경로에 의존하는 식입니다. 이런 경우 먼저 검증된 단순한 기준 설정으로 되돌리세요.

IPv4, IPv6 및 캐시 확인 범위

같은 도메인에서 IPv4와 IPv6 주소가 모두 반환될 수 있습니다. 한 주소 계열의 주소를 확인할 수 있다고 해서 현재 네트워크나 선택한 서버에 해당 경로가 사용 가능하다는 뜻은 아닙니다. 특정 주소 계열에서 요청이 계속 실패한다면 Log에서 실제 연결 주소를 확인한 뒤 네트워크 조건을 살펴보세요. 특정 주소 계열을 비활성화하는 것을 일반적인 해결책으로 권장하지 마세요. 테스트가 일시적으로 통과하더라도 기존 경로 문제를 가릴 수 있고, 정상적으로 작동하던 다른 요청에 영향을 줄 수도 있습니다.

캐시 때문에 수정 후에도 결과가 달라지지 않은 것처럼 보일 수 있지만, 캐시는 Shadowrocket 안에만 있는 것이 아닙니다. 시스템, 브라우저, 앱, 상위 DNS 서비스가 결과를 보관할 수 있고 기존 연결은 다시 조회하지 않을 수도 있습니다. 확인하려면 기존 테스트 연결을 닫고 새 요청을 보내세요. 앱에 관련 캐시 삭제 기능이 있다면 먼저 삭제 범위를 확인하세요. 여러 곳에서 반복해서 데이터를 지우지 마세요. 작업만 늘어나고 비교에 필요한 당시 정보도 사라집니다.

권장 설정과 확인 절차

특별한 DNS 요구 사항이 없다면 현재 작동하는 구성의 DNS 설정을 그대로 유지하는 것이 좋습니다. 변경이 필요하다면 용도와 연결 가능성을 확인한 DNS 서비스만 사용하고 한 번에 하나의 항목만 수정하세요. 기존 구성, 대상 도메인, 반환된 주소, 적용된 정책, 연결 결과를 차례로 기록한 뒤 같은 네트워크에서 다시 테스트하세요. 실제로 DNS 조회가 이뤄졌는지 확인하지 않고 웹페이지 로딩 속도만 비교하면 변화가 DNS, 캐시, 대상 서비스 중 어디에서 비롯됐는지 판단할 수 없습니다.

앱 내부에서 자체적으로 수행한 DNS 조회, 유지 중인 기존 연결, 서로 다른 네트워크 요청 방식 때문에 진단 결과와 특정 앱의 실제 동작이 다를 수 있습니다. 같은 네트워크, 같은 Global Routing, 같은 서버에서 동일한 대상을 연속으로 비교하는 것이 더 정확합니다. DNS가 정상적인 주소를 반환했는데도 접속에 실패한다면 DNS 주소를 계속 바꾸지 말고 Log 및 Proxy 포트 섹션에서 원인을 확인하세요. 흔한 연결 증상은 자주 묻는 질문에서 찾아볼 수 있습니다.

03 / 연결 트리거

On Demand 자동 연결

On Demand는 조건에 따라 VPN 연결을 시작하는 기능이며, 규칙 기반 라우팅을 다른 방식으로 설정하는 기능은 아닙니다. “언제 연결을 시도할지”를 정하는 것은 On Demand이고, 연결 후 요청을 어떻게 처리할지는 Global Routing과 Config가 정합니다. 따라서 On Demand를 켠다고 잘못된 서버 매개변수가 자동으로 수정되거나 적절한 규칙이 대신 선택되는 것은 아닙니다. 설정 전에 수동 연결로 보유한 서버가 작동하는지 확인하고, 검증된 연결에 조건 트리거를 적용하세요.

기본 상태는 현재 설정에서 확인

다른 기기의 스크린샷만 보고 On Demand의 기본 상태를 추측하지 마세요. 최초 설치, 시스템 데이터 복원, VPN 구성 재추가, 앱 내 조건 변경에 따라 현재 상태가 달라질 수 있습니다. Shadowrocket에서 스위치와 조건을 확인한 다음 시스템의 VPN 관련 설정에서도 해당 구성을 확인하세요. 기기에 VPN 구성이 여러 개 남아 있다면 Shadowrocket에서 사용하는 구성을 먼저 확인하세요. 과거에 사용한 다른 항목을 수정하지 않도록 주의해야 합니다.

연결 기능을 처음 켤 때 시스템에서 VPN 구성을 추가할 수 있도록 허용을 요청할 수 있습니다. 이는 시스템에 연결 구성을 등록하기 위한 권한 단계이지, 구매 확인이나 서버 연결 성공을 뜻하지 않습니다. 시스템 팝업 내용을 읽고 출처를 확인한 뒤 진행하세요. 권한 요청을 취소했다면 앱으로 돌아가 화면 안내에 따라 다시 시작하면 됩니다. 영향 범위를 이해하지 못한 상태에서 다른 시스템 구성을 삭제하지 마세요. 관리 대상 기기에서는 관리자의 처리가 필요한 제한이 있을 수도 있습니다.

추측으로 조건을 늘리지 말고 네트워크 상황에 맞게 설정

현재 화면에서 Wi-Fi, 셀룰러 네트워크, 특정 네트워크 등의 조건을 제공한다면 각 조건이 언제 작동하는지 읽어보세요. 특정 Wi-Fi 이름을 인식한다고 해서 해당 네트워크의 모든 특성이 확인되는 것은 아니며, 연결 직후 인터넷을 사용할 수 있다는 보장도 없습니다. 공용 네트워크는 먼저 접속 확인을 요구할 수 있고, 같은 네트워크 이름을 여러 곳에서 사용할 수도 있습니다. 서로 겹치는 조건을 한꺼번에 많이 만들기보다 단순하고 이해하기 쉬운 조건부터 사용하고 실제 필요에 따라 예외를 추가하세요.

테스트할 때는 최소 세 단계를 확인하세요. 네트워크에 연결한 뒤 조건이 충족되는지, 시스템이 연결을 시도하는지, 연결 후 대상 요청이 완료되는지 살펴봅니다. 스위치가 켜진 것만으로 마지막 단계까지 성공했다고 볼 수는 없습니다. 네트워크 전환 전후의 유형과 시간을 기록한 다음 앱 상태와 Log를 확인하세요. 트리거는 작동했지만 서비스 요청이 실패했다면 연결 매개변수와 라우팅을 살펴보세요. 트리거 조건을 계속 바꾸지는 마세요. 이렇게 하면 서로 다른 단계의 문제를 혼동하지 않을 수 있습니다.

수동 연결 해제 후 다시 트리거되는 경우

조건 트리거를 켠 상태에서는 수동으로 연결을 끊어도 계속 연결 해제 상태가 유지되지 않을 수 있습니다. 네트워크 조건이 다시 충족되면 시스템이 재연결을 시도할 수 있습니다. 자동 동작을 잠시 멈춰야 한다면 먼저 On Demand를 일시 중지한 다음 현재 연결을 처리하고 시스템에 표시된 상태를 확인하세요. “끊었는데 다시 연결되는” 문제가 발생하면 스위치 고장으로 단정하지 말고 조건이 여전히 유효한지 먼저 확인하세요. 테스트가 끝나면 필요한 조건을 복원하세요.

기기 절전, 네트워크 전환, 연결 복구

기기 절전, Wi-Fi와 셀룰러 네트워크 간 전환, 일시적인 네트워크 단절은 기존 연결을 끊거나 다시 연결하게 할 수 있습니다. On Demand가 이런 기본적인 조건 변화를 없애 주거나 항상 연결 상태를 보장하지는 않습니다. 네트워크 전환 후 잠시 접속에 실패한다면 시스템의 네트워크 연결이 완료될 때까지 기다린 다음 재연결 기록을 확인하세요. 네트워크 자체가 아직 복구되지 않았다면 앱 스위치를 반복해서 전환해도 실패 기록만 늘어날 수 있습니다.

권장 설정은 사용 목적에 따라 달라집니다. 자동 연결이 필요하다면 수동 기준 상태가 안정적인지 확인한 뒤 필요한 최소 조건만 활성화하세요. 문제를 통제된 환경에서 진단하려면 조건 트리거를 일시적으로 비활성화해 한 번의 테스트가 한 번의 연결 동작에 대응하도록 하세요. “모두 켜기”를 일괄 권장 설정으로 삼지 마세요. 배터리 사용량, 백그라운드 상태, 연결 안정성 사이에는 모든 기기에 공통으로 적용되는 고정 설정이 없습니다. 실제 사용 기록을 바탕으로 판단하세요.

자동 연결에서만 문제가 발생한다면 수동 연결이 성공한 경우와 자동 연결이 실패한 경우를 각각 기록하고 네트워크 조건, 선택한 서버, 현재 Config를 비교하세요. 두 경우의 조건이 같은데 결과가 다르면 시스템 구성과 앱 상태를 항목별로 확인합니다. 권한 승인과 연결 확인을 처음부터 다시 진행해야 한다면 빠른 시작 안내를 따라 진행하세요. On Demand를 테스트한다고 DNS, 규칙, 프로토콜 종류를 동시에 바꾸지 마세요.

04 / 연결 가능성 테스트

Ping 및 Connectivity Test

Ping과 Connectivity Test 결과는 특정 테스트 조건에서 확인한 것으로, 서버 품질 전체를 평가하지는 않습니다. 테스트는 정해진 시간 안에 특정 탐색이 완료됐는지 확인할 수 있지만 실제 서비스 요청을 대신하지는 않습니다. 수치가 낮다고 모든 페이지가 더 빨리 열린다고 단정할 수 없고, 시간 초과가 발생해도 서버 구성이 잘못됐다고 바로 판단할 수 없습니다. 먼저 테스트 방식과 대상, 현재 네트워크를 확인한 뒤 수치의 의미를 해석하세요.

먼저 테스트가 확인한 구간을 파악하세요

테스트 방식에 따라 확인하는 연결 단계가 다릅니다. 기본 연결 가능성 탐색, 지정 포트 연결 시도, 프록시를 통한 대상 주소 접속은 각각 필요한 조건이 다릅니다. 구체적인 테스트 방식은 현재 앱 화면을 기준으로 확인하세요. “Ping”이라는 이름만 보고 특정 프로토콜을 사용한다고 추측해서는 안 됩니다. 탐색이 어떤 단계를 거치는지 알아야 성공이나 실패로 무엇을 확인할 수 있고 무엇은 확인할 수 없는지 판단할 수 있습니다.

예를 들어 서버 포트에 연결하는 데 성공해도 이후 인증, TLS 협상, 대상 접속까지 성공한다는 뜻은 아닙니다. 프록시를 통해 테스트 대상에 접속할 수 있었더라도 당시 해당 대상에 연결할 수 있었다는 것만 확인한 것입니다. 서버가 특정 탐색은 허용하고 다른 탐색은 제한할 수 있으며 테스트 대상에 일시적인 문제가 있을 수도 있습니다. “테스트는 통과했는데 웹페이지가 열리지 않는” 경우에는 테스트만 반복하지 말고 Log에서 실제 요청을 확인하세요.

기본 대상, 시간 제한, 동시 실행

기본 테스트 대상, 시간 제한, 동시 실행 설정은 현재 기기에서 직접 확인하세요. 기존 설정을 복원한 경우 초기 상태와 다를 수 있습니다. 명확한 문제가 없다면 앱의 현재 테스트 설정을 유지하는 것이 좋습니다. 대상을 바꿔야 한다면 용도를 설명할 수 있고 현재 네트워크에서 확인 가능한 대상을 선택하세요. 로그인 정보나 개인 토큰이 포함된 주소를 테스트 대상으로 사용하지 말고, 특정 서비스의 접속 결과를 모든 서비스의 결과로 간주하지 마세요.

시간 제한은 이번 테스트에서 기다릴 시간을 뜻하며 연결에 더 많은 대역폭을 할당하지는 않습니다. 너무 짧으면 일시적인 변동을 실패로 판단할 수 있고, 너무 길면 일괄 확인이 느려집니다. 동시 실행 수가 너무 많으면 제한된 네트워크 자원을 차지해 테스트끼리 경쟁할 수도 있습니다. 먼저 서버 몇 개와 동일한 테스트 대상으로 기준을 기록한 다음 필요에 따라 조정하세요. 더 낮은 수치를 얻으려고 모든 매개변수를 반복해서 바꾸지 마세요.

지연 시간, 처리량, 안정성은 따로 비교

지연 시간은 한 번의 상호작용에 걸리는 시간을, 처리량은 지속적인 데이터 전송 능력을, 안정성은 일정 시간 동안의 실패와 변동을 나타냅니다. 서로 연관은 있지만 같은 기준으로 볼 수는 없습니다. 웹페이지에는 DNS, 연결 설정, 암호화 협상, 서버 처리, 리소스 로딩 등의 단계가 포함되며 단일 탐색은 그중 일부만 확인합니다. 서버를 선택할 때는 목록의 숫자 하나만으로 순위를 정하지 말고 실제로 필요한 접속 작업을 고려하세요.

조건을 통제해야 비교가 더 의미 있습니다. 같은 기기, 같은 네트워크, 같은 대상, 같은 테스트 방식으로 여러 차례 결과와 실패 여부를 기록하세요. Wi-Fi와 셀룰러 네트워크를 전환한 뒤에는 결과를 별도 데이터로 취급하고 이전 결과와 섞지 마세요. 테스트 중 백그라운드에서 동기화나 대용량 전송이 진행 중이었다면 기록에 남기세요. 그래야 변동이 서버와 기기 내 네트워크 사용 경쟁 중 어디에서 비롯됐는지 판단할 수 있습니다.

실패 시 확인 순서

모든 서버에서 동시에 실패한다면 먼저 기기가 실제로 인터넷에 연결되어 있는지, 네트워크 접속 확인이 남아 있는지, 테스트 대상이 작동하는지 확인하세요. 특정 항목 하나만 실패한다면 해당 항목의 주소, 포트, 프로토콜 매개변수를 확인합니다. 구독을 방금 업데이트했다면 수동으로 남겨 둔 예전 사본이 아니라 업데이트된 현재 항목을 테스트하는지 확인하세요. 프로토콜마다 필요한 매개변수가 다르므로 테스트 통과를 위해 유형을 임의로 바꾸지 마세요.

설정을 조정하기 전후에 같은 조건으로 각각 테스트한 다음 실제 요청으로 결과를 확인하세요. 수치가 개선됐지만 서비스 문제가 그대로라면 해당 조정을 해결책으로 간주해서는 안 됩니다. Trojan 인증과 TLS 항목을 확인하려면 Password, SNI 및 Allow Insecure 매개변수 안내를 참고하세요. 프로토콜 항목은 보유한 서버 정보를 기준으로 설정해야 합니다. 테스트 실패는 인증서 확인 요구 수준을 낮출 이유가 되지 않습니다.

마지막으로 재현할 수 있는 기록을 남기세요. 테스트 시간, 네트워크 유형, 항목 이름, 방식, 대상, 결과를 적습니다. 비밀번호나 구독 주소를 공개할 필요는 없습니다. 직접 알아볼 수 있는 별칭을 사용하세요. 이런 정보가 “가끔 빠르고 가끔 느리다”는 설명보다 문제를 찾는 데 유용하며, 설정 변경 후 실제로 반복 가능한 개선이 있었는지도 판단할 수 있습니다.

05 / 요청 기록

Log 및 연결 문제 해결

Log는 연결 문제를 확인 가능한 단계로 나누는 데 쓰이며, 오류 문구 하나만 보고 모든 설정을 바로 바꾸는 도구가 아닙니다. 실패는 DNS 확인, 규칙 선택, 서버 연결, 인증, TLS 협상, 대상 응답 단계에서 발생할 수 있습니다. 실제 작업과 일치하는 기록을 찾고 실패가 어느 단계에서 발생했는지 확인한 뒤 DNS, Config, 서버 매개변수 중 무엇을 수정할지 결정하세요. 화면마다 표시되는 상세 정보는 다를 수 있으므로 현재 앱에 표시되는 내용을 기준으로 확인해야 합니다.

기본 기록 상태와 기록 범위

로그 스위치, 기록 수준, 저장 방식은 현재 기기에서 확인하세요. 특정 설치 환경의 표시를 고정 기본값으로 간주하지 마세요. 일상적으로는 기본 확인에 필요한 수준을 유지하는 것이 좋습니다. 문제를 재현할 때만 상세 수준을 높이고 끝난 뒤 원래 상태로 되돌리세요. 상세 기록은 읽을 내용이 늘어나며 더 많은 요청 정보를 포함할 수도 있습니다. 기록을 켠다고 과거 요청이 모두 복구되는 것은 아니므로 대상 작업을 시작하기 전에 테스트 순서를 정하세요.

한 번의 재현은 가능한 한 짧게 진행하세요. 현재 시간, 네트워크 유형, Global Routing, Config, 선택한 서버를 적고 대상에 한 번만 접속한 다음 관련 기록을 확인합니다. 여러 앱을 동시에 열거나 페이지를 반복해서 새로고침하면 백그라운드 연결이 대상 요청의 기록을 묻을 수 있습니다. 앱에서 필터나 검색 기능을 제공한다면 도메인, 시간, 연결 정보를 기준으로 범위를 좁힐 수 있습니다. 다만 모호한 이름 하나만 보고 찾은 기록이 같은 연결이라고 단정하지 마세요.

문구만 추측하지 말고 연결 단계별로 확인

먼저 요청 도메인이나 주소를 보고 적용된 정책과 서버를 확인하세요. 예상과 달리 DIRECT가 적용되었다면 서버 암호를 바꾸지 말고 Config로 돌아가 규칙 순서를 확인하세요. 정책이 예상대로 적용됐다면 DNS 확인이 완료됐는지, 연결을 시도했는지, 이후 인증이나 핸드셰이크 오류가 있었는지 살펴봅니다. Log에 특정 단계의 정보가 없더라도 해당 단계가 발생하지 않았다는 뜻은 아닙니다. 현재 기록 수준에서 표시되지 않았을 수 있습니다.

연결 시간 초과는 허용된 시간 안에 연결이 완료되지 않았다는 뜻입니다. 경로가 끊겼거나 포트에 연결할 수 없거나 원격 서버가 응답하지 않은 경우일 수 있으며, 어느 쪽의 문제인지 자동으로 판별해 주지는 않습니다. 인증 오류가 발생하면 보유한 서버의 인증 정보를 먼저 확인하고, 복사할 때 공백이나 항목 대응이 잘못되지 않았는지 살펴보세요. TLS 관련 오류는 서버 이름, 인증서, 기기 시간 등을 확인해야 합니다. Allow Insecure를 일반적인 해결 방법으로 켜지 마세요. 인증서 검증 범위가 달라집니다.

Data와 Log는 서로 대체할 수 없습니다

Data의 통계와 Log의 요청 상세 정보는 서로 다른 목적에 쓰입니다. 통계로 일정 시간 동안의 트래픽 변화를 확인할 수 있지만 특정 페이지가 실패한 이유를 단독으로 밝힐 수는 없습니다. 요청 기록은 실패 단계 확인에 도움이 되지만 전체 서비스 트래픽 내역과 같지는 않습니다. 앱 통계를 보유한 서비스의 과금 기준으로 간주하지 마세요. 집계 기준, 시간 범위, 계산 방식이 다를 수 있습니다. 문제를 해결할 때는 증상에 맞는 자료를 우선 확인하세요.

화면에서 요청이 실패했는데 해당 기록을 찾지 못했다면 예상한 연결 방식을 사용했는지, 기존 연결을 재사용 중인지, 요청 전에 Log를 켰는지 확인하세요. 그런 다음 실제 요청 도메인을 확인합니다. 페이지 리디렉션이나 리소스 로딩에 다른 도메인이 사용될 수 있습니다. 페이지 제목으로 검색되지 않는다는 이유만으로 요청이 앱을 거치지 않았다고 단정하지 마세요. Log는 보통 웹페이지의 화면 제목이 아니라 네트워크 연결 정보를 기준으로 정리됩니다.

내보내기, 민감 정보 삭제, 원상 복구

Log에는 방문 도메인, IP 주소, 네트워크 이름, 연결 식별 정보가 포함될 수 있으므로 내보내기 전에 내용을 확인하세요. 구독 주소, 인증 항목, 재사용할 수 있는 연결 정보는 공개하지 마세요. 일부만 캡처해도 주변 내용에 민감한 값이 들어 있는지 살펴보세요. 오류 단계와 항목 구조만 남겨도 문제를 설명하기에 충분한 경우가 많으며 전체 구성을 첨부할 필요는 없습니다. 이 문서의 example.com 예시는 실제 기록의 민감 정보 삭제를 대신할 수 없습니다.

수정 후에는 처음 실패했던 작업을 다시 실행하고 새 기록의 경로가 예상과 일치하는지 확인하세요. 오류가 사라졌더라도 다른 정책이나 서버가 적용됐다면 조건이 바뀐 것입니다. 원래 문제가 해결됐다고 단정할 수는 없습니다. 원인을 계속 찾기 어렵다면 자주 묻는 질문의 증상별 분류를 참고하세요. 도메인 거부 정책과 관련해서는 REJECT의 역할과 범위를 확인해 의도적인 거부를 네트워크 장애로 오해하지 마세요.

06 / 로컬 포트와 원격 서버

Proxy 포트 및 프로토콜 매개변수

먼저 각 포트가 어디에 속하는지 구분해야 합니다. Add Server의 원격 포트는 보유한 서버의 연결 정보에 속합니다. 로컬 Proxy 설정의 수신 포트는 기기에서 사용하는 프록시 접속 지점입니다. 서비스 요청은 대상 서비스의 자체 포트에도 연결됩니다. 우연히 세 포트의 숫자가 같더라도 서로 다른 설정입니다. 로컬 수신 포트를 바꿔도 원격 서버 포트 오류는 해결되지 않습니다. 원격 포트를 변경해도 아직 켜지지 않은 로컬 접속 지점을 사용할 수 있게 되지는 않습니다.

원격 매개변수는 보유한 서버 정보에 따라 입력

서버 유형, 주소, 포트, 인증 항목을 함께 확인해야 합니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, HTTP, SOCKS5는 매개변수 구조가 서로 다릅니다. 모든 프로토콜에 같은 항목을 적용할 수 있는 공통 설정은 없습니다. 보유한 서버 안내에 따라 유형을 선택하고 항목별로 입력하세요. 모르는 값은 다른 프로토콜의 경험으로 추측하지 말고, 익숙해 보인다는 이유만으로 유형을 바꾸지 마세요.

포트 번호는 연결 대상의 일부 정보일 뿐, 프로토콜 유형이나 TLS 상태를 단독으로 입증하지 않습니다. 두 서비스가 같은 일반적인 포트를 사용하더라도 필요한 인증 및 전송 방식은 완전히 다를 수 있습니다. TLS 구성을 사용할 때는 서버 주소와 이름 확인에 쓰이는 항목을 각각 확인하세요. 두 값이 항상 같다고 가정해서는 안 됩니다. 항목별 설명은 입력을 시도해 보며 암호를 바꾸는 대신 Trojan 매개변수 안내를 참고하세요.

로컬 수신 포트의 기본값과 조정 방법

로컬 Proxy 기능의 사용 가능 여부와 수신 주소 및 포트는 현재 앱 화면에서 제공하는 옵션을 기준으로 확인하세요. 이 문서에서는 특정 포트를 고정 기본값으로 지정하거나 다른 기기의 값을 그대로 따라 하도록 안내하지 않습니다. 로컬 프록시를 사용할 필요가 없다면 기존 설정을 유지하고 일반적인 웹페이지 접속 문제를 해결하기 위해 별도의 수신 기능을 켜지 않는 것이 좋습니다. 설정을 바꿔야 한다면 기존 값을 기록하고 해당 접속 지점을 사용하는 앱에서도 주소와 포트를 함께 변경했는지 확인하세요.

사용 가능한 포트인지 판단하려면 수신 주소와 프로토콜 유형도 함께 확인해야 합니다. 루프백 주소는 보통 기기 자체에서만 접속할 수 있음을 뜻하며, 로컬 네트워크 주소는 다른 기기에서의 접근과 관련됩니다. 수신 범위를 넓히면 접근 가능 범위도 달라집니다. 화면에 로컬 네트워크 접속 옵션이 있다면 용도를 충분히 이해한 경우에만 켜고 네트워크 환경을 확인하세요. 테스트 통과만을 위해 범위를 넓히지 말고 시스템 VPN 구성과 로컬 네트워크 프록시 공유를 같은 방식으로 취급하지 마세요.

포트 충돌과 연결 방식 불일치

호출 앱에서 로컬 프록시에 연결할 수 없다고 표시되면 먼저 Shadowrocket에서 해당 접속 지점이 사용 가능한 상태인지 확인한 다음 수신 주소, 포트, 프로토콜을 살펴보세요. HTTP 프록시와 SOCKS5 접속 방식은 다르므로 호출 앱 설정도 이에 맞아야 합니다. 특정 포트에 임의로 요청을 보내는 것으로 모든 프로토콜을 확인할 수는 없습니다. 포트 사용 중이 의심된다면 원격 서버를 계속 바꾸지 말고 현재 화면의 오류 안내를 확인하세요.

수신 포트를 변경해도 호출 앱이 새 값을 자동으로 인식하지 않습니다. 브라우저, 테스트 도구, 프록시 설정을 지원하는 다른 앱에 이전 접속 주소가 남아 있을 수 있습니다. 기존 테스트를 먼저 중단하고 호출 앱 설정을 업데이트한 다음 다시 연결하세요. 시스템 연결과 앱 내 개별 프록시 설정을 모두 사용한다면 테스트가 어느 경로를 거치는지 확인하세요. 설정이 중복되면 결과를 해석하기 어려워집니다.

연결 매개변수와 보안 검증을 따로 확인

VMess와 VLESS는 이름만 비교하지 말고 보유한 서버 정보를 바탕으로 UUID, 전송 방식, 관련 항목을 확인하세요. 두 프로토콜의 매개변수 사용 방식에는 차이가 있습니다. WireGuard는 자체 키, 피어, 주소 정보를 기준으로 이해해야 하며 암호와 포트만 있는 항목으로 취급해서는 안 됩니다. 관련 내용은 VMess와 VLESS의 차이 및 프로토콜 용어집을 참고하세요. 링크는 항목 설명을 제공하며 연결 정보를 제공하지 않습니다.

권장 확인 순서는 먼저 기기의 인터넷 연결을 확인하고, 원격 서버 정보를 검토한 다음 프로토콜 인증과 핸드셰이크를 확인하고, 마지막으로 테스트 경로에 실제로 포함된 로컬 수신 지점을 살펴보는 것입니다. 한 번 조정한 뒤에는 같은 대상으로 다시 테스트하고 Log에서 실제 경로를 확인하세요. 보유한 구독에서 포트나 인증 정보가 업데이트됐다면 선택한 항목이 최신 상태인지 먼저 확인하세요. 오래된 수동 사본과 구독의 새 항목을 혼용하지 마세요. 근거가 없다면 여러 포트를 동시에 바꾸기보다 기본 상태를 유지하는 편이 원인을 찾기 쉽습니다.

07 / 상태 바로가기

Widget 및 시스템 상태

Widget은 상태를 확인하거나 앱이 제공하는 작업을 실행하는 바로가기이며 별도의 연결 엔진은 아닙니다. 표시하거나 실행할 수 있는 항목은 현재 시스템, 앱에서 제공하는 컴포넌트, 선택한 컴포넌트 스타일에 따라 달라집니다. 다른 기기의 화면 배치를 보고 같은 버튼이 반드시 있다고 생각하지 마세요. Widget에 상태가 표시된다는 것만으로 대상 요청이 성공했다고 볼 수도 없습니다. 연결 상태를 정확히 확인하려면 Home으로 돌아가 실제 요청을 보내세요.

추가 전에 앱 내 기준 상태 확인

Widget을 추가하기 전에 Shadowrocket에서 서버를 선택하고 Global Routing을 확인한 뒤 수동 연결을 테스트하는 것이 좋습니다. Widget은 최초 가져오기를 대신하거나 누락된 인증 정보를 채워 주지 않습니다. 처음 관련 작업을 사용할 때 시스템에서 권한 승인을 위해 앱으로 이동하라고 요청하면 안내에 따라 앱으로 돌아가 처리하세요. Widget을 반복해서 탭해도 앱이 열려 있는 상태에서 완료해야 하는 단계를 건너뛸 수 없으며, 여러 번 상태가 바뀌면 구분하기 어려워질 수 있습니다.

추가 위치와 컴포넌트 크기는 시스템 편집 화면에서 정합니다. Shadowrocket을 선택한 뒤 현재 사용할 수 있는 스타일의 설명을 확인하고 필요한 내용을 표시하도록 선택하세요. 기기와 시스템 기능에 따라 달라지므로 이 문서에서는 특정 기본 크기나 레이아웃을 지정하지 않습니다. 추가한 뒤 먼저 표시된 정적 정보가 Home과 일치하는지 확인하고, 그다음 제공되는 작업을 테스트하세요. 첫 동기화 표시가 완료되기 전에 Widget이 작동하지 않는다고 판단하지 마세요.

새로고침 지연이 연결 실패를 뜻하지는 않습니다

Widget 표시 내용은 시스템 새로고침 방식의 영향을 받으므로 연결이 바뀔 때마다 바로 갱신되지 않을 수 있습니다. 백그라운드 상태, 절전 조건, 시스템 스케줄에 따라 갱신 시점이 달라질 수 있습니다. Widget과 앱 내 상태가 잠시 다르면 먼저 앱을 열어 확인한 뒤 실제 요청을 보내세요. Widget을 삭제하고 다시 추가하는 것은 화면 표시 문제를 다루는 방법일 뿐 모든 연결 문제의 첫 단계가 아니며 실제 연결 로그 확인을 대신하지도 않습니다.

On Demand와의 관계

On Demand가 작동 중일 때 Widget에서 연결을 끊더라도 네트워크 조건이 다시 충족되면 새 연결 시도가 발생할 수 있습니다. Widget에 별도의 숨겨진 설정이 있는 것이 아니라 조건 트리거가 계속 작동하기 때문입니다. Widget의 단일 작업을 확인하려면 먼저 On Demand를 일시 중지한 뒤 탭하기 전후의 Home과 시스템 상태를 살펴보세요. 테스트가 끝나면 기존 조건을 복원하세요. 자동 연결 조건과 Widget 레이아웃을 동시에 바꾸면 어느 변경이 결과에 영향을 줬는지 알기 어렵습니다.

현재 서버나 Config를 바꾼 뒤 Widget에 표시된 항목이 변경 내용을 반영하기까지 시간이 걸릴 수도 있습니다. 먼저 앱에서 선택한 값을 기준으로 삼고 기다리거나 시스템에서 제공하는 일반적인 방법으로 새로고침하세요. Widget을 탭해 앱이 열렸다면 시스템 화면이 닫혔는지만 보지 말고 앱 화면에서 실제 작업 결과를 확인하세요. 바로가기는 진입 단계를 줄여 줄 뿐 연결 확인에 필요한 조건까지 줄여 주지는 않습니다.

표시 내용과 개인정보 보호

Widget은 다른 사람이 볼 수 있는 화면에 놓일 수 있습니다. 서버 이름이나 연결 상태가 표시된다면 이름에 개인 계정, 사용 목적, 재사용 가능한 연결 정보를 넣지 마세요. 기기 화면을 공유할 때는 앱 창뿐 아니라 Widget 영역도 확인하세요. Widget은 구독 인증 정보를 보관하는 수단이 아닙니다. 알아보기 쉽다는 이유로 항목 이름에 전체 구독 주소를 넣지 마세요.

일상적으로는 필요한 최소한의 내용만 표시하고, 앱 내에서 알아볼 수 있으면서 민감하지 않은 이름을 사용하는 것이 좋습니다. 바로가기 작업이 필요하지 않다면 Widget을 추가하지 않아도 이미 설정한 수동 연결에는 영향이 없습니다. 표시 문제가 발생하면 앱 상태, 시스템 상태, Widget 내용을 각각 기록한 뒤 차이를 확인하고 시스템에 Widget이 남아 있는지 살펴보세요. 표시 계층에만 문제가 있을 때 다시 추가를 고려하세요. 네트워크 구성을 초기화할 필요는 없습니다.

흔한 증상을 세 가지로 구분하세요. Widget이 갱신되지 않으면 우선 표시 상태를 확인합니다. Widget 작업이 완료되지 않으면 앱을 열어 권한을 승인해야 하는지 확인합니다. 연결은 실제로 설정됐는데 접속에 실패하면 DNS, Config, Log로 돌아가 살펴봅니다. 이 순서대로 확인하면 오래된 표시 때문에 정상 연결을 반복해서 끊는 일을 피할 수 있습니다. 네트워크 전환 후에만 문제가 발생한다면 On Demand 섹션에서 조건 변화를 확인하세요. 최초 연결이 아직 완료되지 않았다면 먼저 시작 안내의 기본 절차를 마친 뒤 바로가기를 설정하세요.

08 / 데이터 복구

iCloud 동기화 및 설정 복원

iCloud 기능은 앱이 지원하는 범위에서 데이터를 동기화하거나 복원하는 데 사용됩니다. 모든 기기의 모든 상태가 완전히 같아지는 것은 아닙니다. 먼저 현재 화면에서 동기화할 수 있는 항목과 스위치, 작업 안내를 확인한 뒤 사용 여부를 결정하세요. 서버 항목, 구성 파일, 시스템 VPN 권한, 현재 네트워크, 연결 상태는 서로 다른 계층입니다. 한 종류의 데이터가 동기화됐더라도 다른 계층은 대상 기기에서 따로 확인해야 할 수 있습니다.

기본 상태 및 시스템 사전 조건

기본 동기화 상태는 현재 앱과 시스템 설정에서 확인하세요. 사용 전에 기기에 원하는 Apple 계정으로 로그인했는지, 시스템에서 앱의 관련 iCloud 기능 사용을 허용했는지, 현재 네트워크에서 동기화할 수 있는지 확인합니다. 스위치가 켜져 있다고 데이터가 모두 업로드됐다고 판단하지 마세요. 다른 기기에 내용이 잠시 나타나지 않는다고 바로 다시 가져오지도 마세요. 앱 내 기록과 시스템 화면을 함께 살펴야 시스템 상태에 따른 동작을 파악할 수 있습니다.

앱을 다시 받는 것과 구성을 복원하는 것은 별개의 작업입니다. 새 기기로 바꾼 뒤 먼저 App Store에서 Shadowrocket을 받은 다음 데이터와 최초 연결 권한을 처리하세요. 시스템 요구 사항, 기기 호환성, 구입 항목 적용 여부는 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 정식 앱 확인 방법은 정식 앱 확인 기준 세 가지를, 구입한 앱 복원은 기기 변경 및 다시 받기 안내를 참고하세요. 이 사이트는 동기화 기능을 여러 기기에서 구입 항목이 적용된다는 근거로 설명하지 않습니다. 두 가지를 따로 확인해야 합니다.

기준 기기를 먼저 정한 뒤 여러 기기의 수정 사항 처리

동기화를 켜기 전에 보관할 전체 구성이 들어 있는 기기를 기준 기기로 정하고, 알아볼 수 있는 사본을 저장하세요. 두 기기에서 같은 중요 내용을 동시에 편집한 뒤 시스템이 원하는 방식으로 병합해 줄 것이라고 가정하지 마세요. 두 기기의 버전이 이미 다르다면 파일과 항목을 먼저 비교한 다음 유지할 버전을 결정하세요. 동기화는 직접 검토를 대신하지 않습니다. 용도를 알 수 없는 중복 기록도 확인 전에 한꺼번에 삭제하지 마세요.

일상용 구성, 테스트 사본, 복구용 사본을 구분할 수 있는 이름을 사용하되 암호나 구독 토큰은 이름에 넣지 마세요. 새 기기에서 복원한 뒤 항목 수, 주요 매개변수, Config 내용을 확인하고 현재 사용할 서버와 Global Routing을 선택하세요. 이름이 같아도 내부 항목은 다를 수 있습니다. 목록 제목만 봐서는 복원이 완전한지 확인할 수 없으며 서버가 여전히 작동하는지도 알 수 없습니다.

동기화, 백업, 구독 업데이트의 차이

동기화는 변경 내용을 다른 기기로 전파할 수 있으므로 이전 상태를 영구히 보관하는 백업과 같지 않습니다. 구독 업데이트는 보유한 구독에서 제공하는 항목 정보를 새로 가져오는 작업이며, 로컬 수동 수정 내용을 어떻게 병합할지 결정해 주지 않습니다. 오래 보관해야 하는 구성은 현재 앱에서 제공하는 내보내기나 백업 기능으로 별도 저장하고, 보관 위치와 접근 권한을 명확히 하세요. 클라우드나 기기의 내용을 삭제하기 전에 사본을 실제로 열 수 있는지 확인하세요.

새 기기 확인 및 민감 정보 보관

복원 후에는 최소 확인 절차를 다시 진행하세요. 기기 네트워크 연결, 선택한 항목, Config 내용을 확인하고 시스템 안내에 따라 VPN 구성을 허용한 뒤 실제 요청을 한 번 보냅니다. 수동 기준 상태가 정상인 것을 확인한 뒤 On Demand를 테스트하고, 앱 내 상태가 정상인 것을 확인한 뒤 Widget을 점검하세요. 이렇게 하면 데이터 누락, 권한 미완료, 서버 작동 여부를 구분할 수 있습니다. 연결 한 번이 실패했다고 전체 동기화 과정에 문제가 있다고 단정할 필요는 없습니다.

내보낸 구성에는 서버 주소, 암호, 키, 구독 토큰이 포함될 수 있으므로 연결 인증 정보처럼 안전하게 보관하세요. 진단 정보를 보낼 때는 필요한 구조만 남기고 전체 파일을 공개하지 마세요. 이 문서에서는 현재 화면에 표시된 내용 이상으로 구체적인 동기화 항목의 암호화 방식이나 보관 기간을 보장하지 않습니다. 데이터 처리 범위를 확인하려면 개인정보 처리방침과 시스템에서 제공하는 관련 안내도 함께 읽으세요. 삭제 전에는 다른 기기에 영향을 주는 작업인지 확인하세요.

이전 상태로 되돌려야 한다면 먼저 계속 변경을 일으키는 작업을 일시 중지하고 확인된 사본을 복원한 다음 DNS, On Demand, 테스트 설정, 현재 라우팅 방식을 항목별로 확인하세요. “모든 설정을 기본값으로 복원”하는 것을 첫 번째 선택으로 삼지 마세요. 문제 원인을 판단하기 어려워질 수 있습니다. 작업을 마친 뒤 변경 항목, 기존 값, 새 값, 확인 결과를 간단히 기록하세요. 다음에 문제가 생기면 모든 설정을 처음부터 시험하기보다 마지막으로 작동했던 상태를 기준으로 확인하는 편이 명확합니다.