Shadowrocket Settings 설정 가이드

Chapter 01

Settings를 읽는 순서와 복구 가능한 기준 상태

먼저 연결 상태, 라우팅 모드와 설정값을 구분하세요

Shadowrocket의 일반적인 문제는 하나의 스위치만으로 발생하기보다 Home의 연결 상태, Global Routing의 현재 모드, 선택한 Config, 서버 정보와 Settings 값이 함께 작용한 결과인 경우가 많습니다. 조정하기 전에 Home에서 현재 선택한 서버 또는 설정이 예상과 일치하는지 확인하고, Global Routing이 Config, Proxy 또는 Direct 중 어느 상태인지 기록하세요. Config는 설정 파일의 Rule에 따라 차례로 매칭한다는 뜻입니다. Proxy는 해당 트래픽을 현재 Proxy로 전달하고, Direct는 직접 연결합니다. 세 모드는 용도가 다르므로 Direct에서 확인한 결과를 Config 규칙이 작동하지 않는 근거로 삼아서는 안 되며, Proxy 상태에서 특정 DIRECT 규칙이 매칭되었는지도 판단할 수 없습니다.

Settings는 DNS 해석, 연결 트리거, 테스트 방식, 로그 기록, 동기화와 로컬 포트 같은 동작을 다루는 데 적합합니다. 서버 정보를 대신 제공하거나 아직 설정하지 않은 서비스를 자동으로 추가하지는 않습니다. 이 안내서는 사용자가 자신의 Subscribe 주소 또는 서버 파라미터를 이미 보유하고 있고, 해당 정보는 원래 제공자가 관리한다는 전제에서 작성되었습니다. Shadowrocket은 App Store에서 구매하는 일회성 유료 클라이언트입니다. 클라이언트 일회성 구매 ≠ 회선 요금제이며, 앱을 구매해도 사용할 서버 정보가 포함되지는 않습니다. 개발자명 Shadow Launch Technology Limited, 앱 ID 932747118 및 스토어 진입 경로를 확인하려면다운로드 안내의 정품 확인 항목을 참고하세요.

변경 전 네 가지 기준 기록

설정을 변경하기 전에 네 가지 기준을 적어 두는 것이 좋습니다. 첫째는 현재 가정용 Wi‑Fi, 사무실 Wi‑Fi 또는 셀룰러 네트워크 중 어떤 환경인지입니다. 둘째는 Home에서 실제로 선택한 서버 항목입니다. 셋째는 현재 Config 이름과 Global Routing 모드입니다. 넷째는 “특정 도메인만 해석되지 않음”, “셀룰러 네트워크로 전환해도 자동 연결되지 않음”, “Connectivity Test가 특정 단계에서 멈춤”처럼 재현 가능한 현상입니다. 이 네 가지 정보는 막연한 “작동하지 않음”을 확인 가능한 조건으로 나누고, 설정을 복구한 뒤 원래 상태로 돌아왔는지 판단하는 데 도움이 됩니다.

변경할 때는 단일 변수 방식을 사용하세요. 한 번에 하나의 항목만 조정하고 저장한 뒤 닫았다가 다시 연결한 다음 같은 방식으로 확인합니다. DNS, Config, 서버와 On Demand 조건을 동시에 바꾸면 문제가 잠시 사라져도 어느 항목이 영향을 주었는지 알 수 없습니다. 새 문제가 생겼을 때 정확히 되돌리기도 어렵습니다. DNS, IPv6, Proxy 포트와 iCloud 동기화처럼 여러 상황에 영향을 줄 수 있는 항목일수록 단일 변수 기록이 중요합니다.

기본값과 권장값을 이해하는 방법

Settings의 기본 상태는 스토어 버전, 기기 시스템과 기존 설정 마이그레이션에 따라 달라질 수 있습니다. 따라서 이 안내서에서는 모든 기기에서 동일하다고 단정할 고정 숫자를 기본값으로 제시하지 않습니다. 항목을 확인할 때는 클라이언트에 현재 표시된 값, 재설치 후 시스템이 제공하는 상태, Config에 명시된 파라미터를 구분해서 보세요. Config에 명시적으로 작성된 항목은 화면의 관례에만 의존하는 것보다 재현하기 쉽지만, 문법이 올바르고 해당 파라미터의 적용 범위를 알고 있어야 합니다.

권장값이 복잡할수록 좋은 것은 아닙니다. 안정적으로 사용할 때는 시스템이나 Config에서 이미 작동하는 값을 우선 유지하고, 구체적인 문제가 있을 때만 재정의 설정을 추가하세요. DNS 해석에 실패할 때 DNS를 조정하고, 네트워크 전환 시 트리거가 예상과 다를 때 On Demand를 확인하며, 테스트 결과와 실제 접속이 다를 때 Ping 또는 Connectivity Test 방식을 다시 선택합니다. 이 순서를 따르면 진단 기능을 속도 향상 기능으로 오해하는 일을 줄이고, 용도를 아무도 모르는 설정이 장기간 남는 것도 방지할 수 있습니다.

Chapter 02

DNS: 해석 경로, 값의 범위와 실패 원인 찾기

연결 과정에서 DNS가 차지하는 위치

도메인에 접속할 때 기기는 먼저 도메인을 주소로 해석한 다음 후속 연결을 설정합니다. 서버 지연 시간이 반환되었다는 사실은 테스트에 사용된 대상과 경로가 특정 단계에서 도달 가능하다는 뜻일 뿐, 모든 도메인이 올바르게 해석된다는 의미는 아닙니다. 따라서 “Ping은 정상인데 웹페이지가 열리지 않음”이라는 상황에서는 DNS를 별도로 확인해야 합니다. Shadowrocket의 DNS 동작은 시스템 네트워크, Settings, 현재 Config와 개별 Rule의 영향을 동시에 받을 수 있습니다. 문제를 판단할 때는 모든 도메인이 실패하는지, 특정 접미사만 실패하는지, 네트워크 전환 후에만 캐시 차이가 나타나는지부터 확인하세요.

시스템 DNS는 기준 상태로 사용하기 좋습니다. Direct 상태에서도 자주 사용하는 사이트가 열리지 않는다면 복잡한 파라미터를 바로 바꾸기보다 현재 Wi‑Fi 또는 셀룰러 네트워크부터 확인하세요. Direct와 Proxy에서는 정상인데 Config에서만 일부 도메인이 실패한다면 규칙 매칭과 Config의 DNS 선언을 확인해야 합니다. 한 도메인만 이상하다면 기본 도메인, 하위 도메인과 주소를 직접 입력했을 때의 결과를 비교하여 대상 서비스 자체의 장애를 전체 DNS 장애로 오해하지 않도록 하세요.

해석 방식을 선택할 때 확인할 세 가지 경계

첫째는 해석 요청이 어디에서 시작되는지입니다. 시스템이 제공하는 해석 경로를 사용하면 결과가 현재 네트워크와 대체로 일치합니다. Config에서 DNS를 지정할 때는 해당 주소가 현재 네트워크 환경에서 도달 가능한지 확인하세요. 둘째는 반환된 결과가 규칙 판단에 어떻게 전달되는지입니다. DOMAIN, DOMAIN-SUFFIX와 DOMAIN-KEYWORD는 도메인을 기준으로 직접 매칭하지만, GEOIP, IP-CIDR과 IP-CIDR6은 주소 정보가 필요합니다. 셋째는 캐시가 언제 갱신되는지입니다. DNS를 변경한 뒤에도 이전 결과가 보이면 현재 연결을 끊고 시스템 네트워크 상태가 갱신될 때까지 기다린 다음 다시 연결하여 같은 도메인을 재테스트하세요.

일상적인 사용에서는 안정적으로 작동하는 시스템 해석 경로를 먼저 사용하고, 한 번의 우연한 현상 때문에 여러 해석 주소를 동시에 추가하지 않는 것이 좋습니다. Config에서 지정해야 한다면 개수와 순서를 기록하고, 첫 번째 주소에 도달하지 못해 매번 타임아웃을 기다리는 일이 없도록 하세요. 암호화된 해석 방식을 사용할 때는 해당 서비스 도메인 자체가 초기 해석을 어떻게 완료하는지도 고려해야 합니다. 초기 경로가 차단되면 “더 발전된 설정인데 전혀 해석되지 않음”처럼 보일 수 있습니다. 문제 해결 시에는 단순한 경로로 돌아간 뒤 조건을 단계적으로 추가하세요.

Config의 DNS와 규칙 연동

설정 파일에 DNS와 Rule을 명시할 수 있지만, 익숙하지 않은 예시 전체를 작동 중인 Config에 그대로 복사하지 마세요. 먼저 설정을 테스트용으로 복사한 뒤 필요한 항목만 추가하세요. 규칙은 위에서 아래로 매칭되며, 더 구체적인 도메인 규칙은 일반적으로 앞쪽에 배치해야 합니다. FINAL은 앞에서 매칭되지 않은 연결을 처리합니다. DOMAIN-SUFFIX가 특정 도메인을 PROXY로 전달했다면 뒤의 GEOIP 규칙이 같은 요청의 정책을 다시 바꾸지는 않습니다. DNS를 진단할 때는 해석 성공 여부와 최종적으로 어떤 규칙이 매칭되었는지를 함께 확인하세요.

[General]
dns-server = system

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

위 예시는 구조와 매칭 순서를 설명하기 위한 것입니다. example.com은 문서용 예시 도메인이며 실제 서비스를 의미하지 않습니다. dns-server = system은 시스템 해석 경로에서 기준 상태를 시작한다는 뜻입니다. 실제 Config에는 프록시 그룹, 원격 규칙과 기타 General 항목이 포함될 수 있으므로 병합할 때 기존 섹션 구조를 유지하고 중복된 섹션 제목이나 오탈자를 피해야 합니다. 저장한 뒤 먼저 Config가 정상적으로 읽히는지 확인하고 규칙을 테스트하세요. 해석에 실패한 상태에서 DNS 주소를 계속 추가해서는 안 됩니다.

해석 실패 단계별 문제 해결

첫 단계로 Direct로 전환해 관련 없는 도메인 두 개를 테스트합니다. 둘 다 실패하면 로컬 네트워크를 확인하고, 둘 다 성공하면 두 번째 단계로 넘어갑니다. 두 번째 단계에서는 같은 서버를 유지한 채 Proxy로 전환합니다. 실패하면 Rule을 먼저 바꾸지 말고 서버 연결과 프로토콜 파라미터를 확인하세요. 세 번째 단계에서는 Config로 전환하여 문제가 규칙 모드에서만 나타나는지 확인합니다. 네 번째 단계에서는 Log를 열고 대상 도메인에 해당하는 매칭 결과를 찾아 DOMAIN-SUFFIX, GEOIP 또는 FINAL 중 무엇이 처리했는지 확인합니다. 다섯 번째 단계에서야 DNS를 변경하고, 변경할 때마다 다시 연결하세요.

문제가 “될 때도 있고 안 될 때도 있는” 형태라면 발생 시각, 네트워크 유형과 직전에 Wi‑Fi를 전환했는지를 기록해야 합니다. 간헐적 실패는 첫 번째 해석 주소의 타임아웃, 네트워크 전환 후 연결이 재설정되지 않은 상태 또는 여러 주소의 반환 순서 변화와 관련되는 경우가 많습니다. Ping만 연속으로 눌러 결론을 내리지 말고 실제 도메인 요청, Log와 Connectivity Test의 결과를 함께 판단하세요. 더 자세한 단계별 사례는DNS 설정 및 해석 실패 문제 해결에서 확인할 수 있습니다.

Chapter 03

On Demand: 자동 연결 조건과 네트워크 전환

On Demand가 해결하는 문제

On Demand는 네트워크 상태에 따라 연결을 트리거하는 기능이며, Home의 수동 스위치를 대신하지 않고 특정 서버가 현재 적합한지도 자동으로 판단하지 않습니다. 활성화하기 전에 수동 연결이 안정적인지 확인해야 합니다. 고정된 네트워크에서 명확한 서버와 Config를 선택하고 수동으로 연결한 뒤 실제 접속을 확인하세요. 수동 연결 자체가 실패하는 상태에서 On Demand를 추가하면 실패가 더 자주 트리거될 뿐 아니라 클라이언트가 언제 다시 연결되는지 판단하기 어려워질 수 있습니다.

자동 연결의 가장 일반적인 용도는 기기가 Wi‑Fi와 셀룰러 네트워크 사이를 전환한 뒤 예상한 상태를 유지하거나, 알려진 네트워크에 서로 다른 동작을 적용하는 것입니다. 조건은 적고 명확하며 서로 충돌하지 않는 규칙부터 설계하세요. 각 조건은 세 가지 질문에 답할 수 있어야 합니다. 어떤 네트워크와 매칭되는가, 매칭 후 어떤 동작을 수행하는가, 매칭되지 않으면 어떤 기본 동작을 사용하는가입니다. 하나의 네트워크를 여러 범위가 겹치는 조건으로 설명하지 마세요. 실제 결과가 매칭 순서에 좌우되고 이후 문제 해결도 어려워집니다.

먼저 네트워크를 분류한 뒤 동작을 정하세요

일상 환경을 신뢰하는 고정 Wi‑Fi, 기타 Wi‑Fi와 셀룰러 네트워크의 세 가지로 나눌 수 있습니다. 여기서 “신뢰”는 사용자가 해당 네트워크를 알고 별도 동작을 지정하겠다는 뜻일 뿐, 네트워크 보안을 절대적으로 판단한다는 의미가 아닙니다. 고정 Wi‑Fi는 보통 네트워크 이름으로 식별하고, 기타 Wi‑Fi는 예외 처리용으로 사용하며, 셀룰러 네트워크는 별도로 다룹니다. 이름은 같지만 실제로 다른 네트워크에 자주 연결되는 기기라면 이름만으로 복잡한 결정을 내리지 말고 수동 확인 단계를 남겨 두세요.

동작 선택은 실제 요구를 중심으로 해야 합니다. 특정 네트워크에 들어갔을 때 Shadowrocket 연결을 자동으로 설정하려면 해당 조건에 연결 동작을 지정하세요. 수동 제어를 유지하려면 그 네트워크에 강제 트리거를 설정하지 마세요. 설정을 완료한 뒤에는 스위치가 켜져 있는지만 보지 말고 각 환경에서 개별적으로 테스트해야 합니다. 먼저 한 네트워크에 머물며 Home 상태를 기록하고, 두 번째 네트워크로 전환해 시스템이 전환을 완료할 때까지 기다린 뒤 연결이 다시 설정되는지 확인하세요. 마지막으로 첫 번째 네트워크로 돌아가 동작이 재현되는지 확인합니다.

조건 순서와 충돌 판단

범위가 구체적인 조건은 범위가 넓은 조건보다 앞에 배치해야 합니다. 예를 들어 특정 고정 Wi‑Fi를 대상으로 하는 규칙은 “모든 Wi‑Fi”와 같은 기본 조건보다 앞에 와야 합니다. 넓은 조건이 먼저 매칭되면 뒤의 구체적인 조건이 적용될 기회를 잃을 수 있습니다. 순서를 변경한 뒤에는 네트워크 전환 테스트를 다시 실행하고 Home에 예상한 상태가 표시되는지 확인하세요. 연결이 반복되거나 짧은 시간에 연결 스위치가 여러 번 바뀐다면 조건이 서로 덮어쓰는지, 시스템 네트워크가 두 액세스 포인트 사이에서 전환되는지, 현재 Config가 새 네트워크에서 연결을 완료하지 못하는지를 우선 의심하세요.

On Demand는 시스템 네트워크 상태와 밀접하게 관련됩니다. 기기를 막 잠금 해제했거나 신호가 약하거나 Wi‑Fi가 주소를 가져오는 중이라면 연결 설정이 화면 변화보다 늦을 수 있습니다. 이때 스위치를 연속으로 수동 전환하지 마세요. 수동 동작이 자동 트리거와 겹칠 수 있습니다. 네트워크 상태가 안정될 때까지 기다린 뒤 Log에 새로운 연결 과정이 나타나는지 확인하세요. 자동 트리거 후 잘못된 서버나 Config가 사용되었다면 On Demand 조건 자체를 탓하기보다 전환 전에 Home에서 실제로 선택된 항목을 확인하세요.

권장 활성화 순서

첫 단계에서는 On Demand를 끄고 자주 사용하는 Wi‑Fi에서 수동으로 연결하여 DNS, 규칙과 실제 접속이 모두 정상인지 확인합니다. 두 번째 단계에서는 서버와 Config를 유지한 채 셀룰러 네트워크에서 수동 확인을 반복합니다. 세 번째 단계에서는 가장 자주 사용하는 조건 하나만 만들고 On Demand를 켠 뒤 왕복 전환을 한 번 실행합니다. 네 번째 단계에서는 Log를 확인하여 네트워크 변화마다 명확한 재연결이 한 번만 트리거되는지 확인합니다. 다섯 번째 단계에서 두 번째 네트워크 조건을 추가하세요. 어느 단계에서든 문제가 생기면 방금 추가한 조건으로 되돌리고 확장하지 마세요.

네트워크 문제를 일시적으로 확인해야 한다면 On Demand를 꺼서 자동 재연결이 비교 테스트를 방해하지 않게 할 수 있습니다. 끈 뒤에도 Home의 현재 연결 상태를 확인해야 합니다. 자동 트리거를 끄는 것과 이미 설정된 연결이 즉시 변경되는 것은 다릅니다. 문제 해결이 끝나면 먼저 작동하는 수동 상태를 복구한 다음 On Demand를 다시 켜세요. 이렇게 하면 “연결 자체가 작동하는가”와 “자동 조건이 올바른가”를 별개의 문제로 나눌 수 있습니다.

Chapter 04

Ping 및 Connectivity Test: 테스트 결과 해석 방법

지연 시간 숫자는 전체 연결 품질과 다릅니다

Ping은 지정한 테스트 방식에서 대상이 응답하는지와 왕복 시간의 대략적인 범위를 빠르게 확인하는 기능입니다. 완전히 도달할 수 없거나 명확한 타임아웃이 발생하거나 같은 네트워크에서 결과 차이가 큰 항목을 찾는 데 적합하지만, 웹페이지·동영상 또는 다른 앱의 트래픽이 반드시 정상이라는 것을 단독으로 증명하지는 못합니다. 실제 연결에는 DNS, 대상 포트, 프로토콜 핸드셰이크, 전송 파라미터, 규칙 매칭과 대상 서비스의 응답이 모두 관련됩니다. 한 번의 지연 시간 순위만으로 서버를 선택하면 우연한 변동을 지속적인 차이로 오해하기 쉽습니다.

Ping을 실행하기 전에 테스트 조건을 고정하세요. 같은 네트워크, 같은 Global Routing 모드와 같은 테스트 방식을 유지하고 스캔 중에는 Wi‑Fi를 전환하지 않습니다. 결과는 최소 두세 차례 관찰하고, 한 번의 최저 숫자보다 지속적인 타임아웃과 큰 변동 여부를 확인하세요. 모든 항목이 동시에 나빠진다면 로컬 네트워크를 먼저 확인하고, 한 항목만 계속 이상하다면 해당 서버 정보나 네트워크 경로를 확인하세요. 테스트 데이터는 위치를 파악하기 위한 것이며 장기적인 성능 결론을 만들어 내는 데 사용해서는 안 됩니다.

Connectivity Test의 단계별 활용

Connectivity Test는 “연결 과정이 어느 단계에서 멈추는가”를 파악하는 데 적합합니다. 테스트 항목은 현재 화면과 네트워크 환경에 따라 다르게 표시될 수 있지만, 읽는 순서는 유지해야 합니다. 먼저 로컬 네트워크의 기본 연결을 확인하고, 다음으로 서버 주소에 도달할 수 있는지 확인한 뒤 프로토콜 핸드셰이크와 실제 요청이 완료되는지 살펴보세요. 한 단계가 통과했다는 것은 해당 단계만 성립한다는 뜻이며, 이후 단계는 실패할 수 있습니다. 예를 들어 서버 주소에 도달할 수 있어도 인증 파라미터가 올바르다는 뜻은 아니며, 프로토콜 핸드셰이크가 성공해도 DNS와 Rule이 대상 요청을 예상한 정책으로 전달한다는 보장은 없습니다.

테스트가 실패하면 최종적으로 표시된 빨간 결과만 기록하지 말고 가장 먼저 실패한 단계를 기록하세요. 초기 실패 지점이 원인에 더 가깝습니다. 해석 단계에서 멈추면 DNS 항목으로 이동하고, 서버 연결 단계에서 타임아웃되면 네트워크 연결 가능 여부와 서버 정보를 확인하세요. 앞 단계는 통과했지만 실제 요청이 실패한다면 Rule, FINAL, 대상 서비스와 프로토콜 전송 파라미터를 점검하세요. 변경 후 같은 테스트를 반복하여 실패 지점이 뒤로 이동했는지 또는 사라졌는지 확인합니다.

테스트 오차를 줄이는 방법

테스트 중 지속적으로 많은 네트워크 요청을 발생시키는 백그라운드 작업을 끄면 Log를 읽기 쉬워지지만, 모든 시스템 설정을 바꿀 필요는 없습니다. 기기 위치와 네트워크 액세스 포인트를 유지하고, 먼저 작동이 확인된 항목 하나를 기준으로 테스트한 다음 대상 항목을 테스트하세요. 셀룰러 네트워크에서는 신호 변화가 지연 시간에 직접 영향을 주고, Wi‑Fi에서는 액세스 포인트 전환과 로컬 네트워크 혼잡이 변동을 일으킬 수 있습니다. 한 번 타임아웃되었다고 바로 프로토콜 파라미터를 바꾸지 말고 먼저 다시 확인하세요.

서버를 비교할 때는 테스트 방식이 같은지 확인해야 합니다. 일부 테스트는 TCP 연결만 확인하고, 다른 테스트는 실제 요청을 포함할 수 있으므로 방식이 다르면 숫자를 직접 비교할 수 없습니다. Shadowrocket 화면에서 제공되는 Ping 방식은 Settings에 실제 표시된 항목을 기준으로 하세요. 옵션의 의미를 모르면 기본값 또는 현재 작동하는 방식을 유지하고, 숫자가 작다는 이유로 자주 전환하지 마세요. “속도가 느림”을 해결할 때는 로컬 네트워크, 서버, 회선 시간대, 프로토콜과 대상 서비스를 나누어 고려하고속도 저하 단계별 문제 해결을 참고할 수 있습니다.

테스트 결과를 설정 항목으로 연결하기

Ping이 모두 타임아웃되지만 Direct 접속은 정상이라면 테스트가 현재 Proxy를 통과하는지, 서버 주소에 도달할 수 있는지와 프로토콜 파라미터가 완전한지 확인하세요. Ping은 정상인데 Connectivity Test가 해석 단계에서 실패한다면 DNS 경로에 따라 점검합니다. 두 항목 모두 정상인데 Config에서 접속 결과가 예상과 다르면 Log에서 DOMAIN, GEOIP, IP-CIDR 또는 FINAL의 매칭 결과를 확인하세요. Proxy에서는 정상이고 Config에서만 실패한다면 문제는 대개 서버 자체보다 규칙이나 설정에 가깝습니다.

진단이 끝나면 임시 테스트 설정을 장기 사용에 필요한 상태로 복구해야 합니다. 비교를 위해 Direct로 전환했다면 종료 후 Config로 돌아왔는지 확인하세요. 상세 과정을 보기 위해 Log 기록 범위를 늘렸다면 완료 후 실제 필요에 맞게 조정합니다. 특정 서버를 테스트하기 위해 선택 항목을 바꿨다면 Home에서 최종적으로 예상한 항목을 사용하고 있는지도 확인하세요. 진단의 종료 기준은 문제가 잠시 사라지는 것뿐 아니라 설정이 이해 가능하고 재현 가능하며 복구할 수 있는 상태로 돌아오는 것입니다.

Chapter 05

Log 및 Data: 규칙 매칭과 트래픽 기록 확인

Log에서 확인해야 할 질문

Log의 주요 용도는 눈에 띄는 오류 문구만 찾는 것이 아니라 특정 요청이 어떤 판단을 거쳤는지 복원하는 것입니다. 한 기록을 읽을 때는 시간, 대상 도메인 또는 주소, 매칭된 Rule, 최종 정책과 오류가 발생한 단계를 순서대로 확인하세요. 규칙 문제에서는 요청이 예상한 DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, IP-CIDR6 또는 FINAL과 매칭되었는지가 가장 중요합니다. 더 앞에 있는 규칙과 매칭되었다면 서버를 반복해서 전환하기보다 Config로 돌아가 순서를 조정해야 합니다.

기록을 시작하기 전에 관련 없는 동작을 정리하세요. 테스트 대상 하나만 유지하고 한 번 열거나 새로 고친 다음 즉시 Log로 돌아가 해당 시간대를 찾습니다. 백그라운드 앱은 많은 시스템 요청을 발생시키므로 낯선 도메인이 보였다고 이상으로 단정해서는 안 됩니다. 시간, 대상과 반복 동작을 연결해야 합니다. 예를 들어 같은 예시 도메인에 연속으로 두 번 접속하고 비슷한 시간에 유사한 기록 두 개가 나타나야 이번 테스트에 해당하는 기록을 확인하기 쉽습니다.

오류 메시지를 단계별로 읽는 방법

해석 관련 오류는 보통 DNS 주소에 도달할 수 없거나 도메인이 결과를 반환하지 않거나, 네트워크 전환 후 해석 경로가 아직 복구되지 않았음을 의미합니다. 연결 타임아웃은 서버 주소, 대상 포트 또는 네트워크 경로 문제에 더 가깝습니다. 핸드셰이크 또는 인증 실패가 발생하면 사용자가 보유한 서버 정보의 프로토콜, 비밀번호, UUID, 전송 파라미터 또는 인증서 관련 설정이 일치하는지 확인해야 합니다. 규칙 매칭이 예상과 다르면 Config의 순서와 키워드를 확인하세요. 서로 다른 단계의 오류를 같은 방식으로 처리해서는 안 됩니다.

오류가 한 번만 나타난 뒤 요청이 성공했다면 네트워크 전환이나 일시적인 타임아웃과 관련이 있는지 먼저 관찰하세요. 같은 단계에서 매번 실패한다면 해당 단계에 맞춰 단일 변수로 확인합니다. 많은 로그를 한꺼번에 내보낸 뒤 “error”만 검색하지 마세요. 앞의 연결 동작과 뒤의 대체 정책도 중요합니다. 고립된 오류 단어보다 시간 순서를 기록하는 것이 더 유용합니다.

Data로 확인할 수 있는 내용

Data는 클라이언트가 기록한 트래픽 개요와 연결 사용량을 확인하는 데 사용합니다. 특정 앱이나 도메인이 계속 요청을 발생시키는지 파악하고 규칙 변경 전후를 보조적으로 비교하는 데 도움이 되지만, 과금·네트워크 품질·서버 상태를 단독으로 판단할 수는 없습니다. 시스템의 집계 기준, 연결 재사용과 캐시 때문에 Data와 사용자가 화면에서 체감하는 페이지 크기가 다를 수 있으므로 정확한 청구서가 아니라 추세 정보로 보세요.

Data를 확인할 때는 먼저 시간 범위와 테스트 동작을 제한하세요. 예를 들어 DOMAIN-SUFFIX 규칙을 조정하기 전에 해당 대상이 현재 정책에서 어떻게 처리되는지 기록하고, 변경 후 다시 연결해 같은 요청만 실행한 뒤 예상한 정책으로 처리되었는지 비교합니다. 백그라운드 앱이 계속 트래픽을 발생시킨다면 총량으로 개별 대상을 판단하지 마세요. 비정상적인 증가를 조사할 때는 Data만 보고 Config나 서버 항목을 삭제하지 말고 Log로 돌아가 구체적인 도메인과 정책을 확인해야 합니다.

진단 정보를 공유하기 전 정리할 내용

서버 정보 제공자에게 문제를 전달할 때는 발생 시각, 네트워크 유형, 프로토콜 이름, Connectivity Test에서 가장 먼저 실패한 단계와 정리된 Log 일부를 제공하는 것이 좋습니다. 서버 주소, 비밀번호, UUID, Subscribe 주소의 인증 정보와 기타 민감한 파라미터를 공개 스크린샷이나 공개 문서에 포함해서는 안 됩니다. 도메인 접미사, 오류 단계와 규칙 키워드는 남겨 문제의 계층을 설명할 수 있습니다.

로그를 정리할 때 오류의 의미를 바꾸지 마세요. 가려야 한다면 민감한 부분을 일관된 방식으로 바꾸고 필드 구조와 인접한 문맥은 유지하세요. 예를 들어 “대상이 DOMAIN-SUFFIX와 매칭된 뒤 PROXY를 사용했고, 이후 연결이 타임아웃됨”이라는 순서를 남기는 편이 최종 실패 화면만 보내는 것보다 판단에 도움이 됩니다. 문제가 해결되면 임시로 내보낸 진단 파일을 삭제하고 Log 기록 범위를 일상적인 수준으로 되돌리세요.

Chapter 06

Widget 및 iCloud 동기화: 빠른 동작과 설정 마이그레이션

Widget은 빠른 진입점이며 독립적인 연결이 아닙니다

Widget은 시스템 화면에서 자주 사용하는 상태를 확인하거나 동작을 트리거하는 빠른 방법을 제공하지만, Shadowrocket에 이미 존재하는 서버, Config와 연결 권한에 의존합니다. Widget 표시가 이상하면 먼저 Shadowrocket을 열어 Home이 정상적으로 로드되고 수동 연결이 가능한지 확인한 뒤 시스템이 Widget을 새로 고칠 수 있는지 점검하세요. 클라이언트가 최초 연결 권한 설정을 완료하지 않았다면 Widget만 조작해 이 단계를 건너뛸 수 없습니다.

Widget에는 자주 사용하고 의미가 명확한 동작만 배치하세요. 이름이 비슷한 서버나 Config를 여러 개 배치하면 빠른 동작에서 잘못 선택하기 쉽습니다. 항목 이름은 용도를 알 수 있게 정하되 비밀번호, 주소 인증 정보나 기타 민감한 내용을 포함하지 마세요. Shadowrocket 내부 항목을 변경한 뒤에도 Widget에 이전 상태가 표시된다면 먼저 클라이언트에서 저장이 완료되었는지 확인한 다음 시스템에서 Widget을 새로 고치세요. 현재 작동하는 설정을 반복해서 삭제할 필요는 없습니다.

Widget 상태와 실제 상태가 일치하지 않음

시스템은 배터리와 리소스 관리 때문에 Widget 갱신을 지연시킬 수 있으므로 화면 표시와 Home의 실시간 상태 사이에 잠시 차이가 생길 수 있습니다. 연결 설정 여부는 Shadowrocket을 연 뒤 Home에 표시되는 상태와 실제 요청 결과를 기준으로 판단하세요. Widget을 눌러도 예상한 동작이 없으면 기기가 방금 재시작되었는지, 시스템이 클라이언트 권한을 다시 확인하도록 요구하는지, 현재 네트워크를 사용할 수 있는지와 On Demand가 다른 연결 동작을 동시에 트리거했는지를 먼저 확인하세요.

문제 해결 순서는 다음과 같습니다. 먼저 Home에서 수동으로 한 번 연결하고, Widget으로 돌아가 같은 동작을 실행합니다. Home은 성공하지만 Widget이 실패하면 시스템의 Widget을 제거한 뒤 다시 추가하세요. 둘 다 실패한다면 문제는 Widget에 있지 않으므로 서버 정보, DNS 또는 네트워크 테스트로 이동해야 합니다. Widget 장애가 발생했다고 Proxy 포트나 Rule을 변경하지 마세요. 이 항목들은 일반적으로 시스템 빠른 진입점의 갱신과 직접 관련이 없습니다.

iCloud 동기화의 적용 범위

iCloud 동기화는 조건을 충족하는 Apple 기기 사이에서 앱 데이터를 저장하거나 동기화하는 기능이며, 실제로 동기화되는 내용과 표시 방식은 현재 Shadowrocket 화면을 기준으로 합니다. 모든 데이터를 실시간 양방향으로 충돌 없이 복제한다는 뜻이 아니며 수동 백업을 대신해서도 안 됩니다. 활성화하기 전에 기기에서 사용하는 iCloud 상태를 확인하고 어느 기기의 설정을 현재 기준으로 삼을지 정하세요. 여러 기기에서 같은 이름의 Config를 동시에 편집하면 새 내용이 이전 내용으로 덮어써지거나 구분하기 어려운 복사본이 생길 수 있습니다.

“주 기기에서 수정하고 다른 기기에서 확인”하는 순서를 권장합니다. 먼저 주 기기에서 Config를 변경하고 작동 여부를 확인한 뒤 설정 이름과 주요 Rule을 기록하세요. 동기화가 완료될 때까지 기다린 다음 다른 기기에서 Shadowrocket을 열어 서버 항목, Config 내용과 Global Routing이 예상과 일치하는지 확인합니다. 업데이트가 보이지 않는다고 두 번째 기기에서 같은 항목을 바로 다시 편집하지 마세요. 새로운 충돌이 생길 수 있습니다. 먼저 iCloud 상태, 네트워크와 클라이언트 로드 완료 여부를 확인하세요.

가져오기, 동기화와 Subscribe 업데이트의 차이

Import from Cloud JSON은 한 번 실행하는 가져오기이며, iCloud 동기화는 기기 간 데이터 동기화 방식이고, Subscribe 업데이트는 사용자가 보유한 Subscribe 주소에 따라 해당 항목을 새로 고치는 기능입니다. 세 가지를 혼동하지 마세요. JSON을 가져오면 가져온 시점의 데이터 복사본이 생성되며 이후 변경 여부는 사용자가 어떻게 관리하는지에 따라 달라집니다. Subscribe 업데이트는 일반적으로 출처에 따라 관련 항목을 다시 생성하므로 수동으로 수정한 필드가 유지되는지는 실제 결과를 기준으로 확인해야 합니다. iCloud는 로컬 변경 사항을 다른 기기로 전달할 수 있습니다.

대량 변경을 실행하기 전에 작동하는 Config를 보존하고 현재 선택한 서버를 기록하세요. 업데이트 후에는 이전 항목을 바로 삭제하지 말고 새 항목의 프로토콜, 주소, 포트와 이름이 완전한지 확인한 뒤 Ping 또는 Connectivity Test를 실행하고 마지막으로 Config에서 Rule을 확인하세요. 중복 항목이 발견되면 먼저 출처를 확인한 뒤 어느 항목을 남길지 결정하세요. 이름이 같다는 이유만으로 일괄 삭제하면 Config에서 참조 중인 항목을 잘못 지울 수 있습니다.

기기 간 사용 확인 목록

iPhone과 iPad 사이에서 마이그레이션한 뒤에는 최소 다섯 가지를 확인하세요. Home의 현재 서버, Global Routing 모드, Config가 존재하고 열리는지, On Demand가 해당 기기의 네트워크 환경에 맞는지, Widget이 유효한 항목을 가리키는지입니다. 기기 용도가 다르면 On Demand 조건도 반드시 같아야 하는 것은 아닙니다. 예를 들어 자주 이동하는 iPhone과 고정 Wi‑Fi에 오래 연결된 iPad는 기본 Config를 공유하되 자동 연결 조건은 각각 관리할 수 있습니다.

Mac, Apple TV와 Apple Vision의 호환성 정보는 동일한 App Store 제품 페이지에서 확인할 수 있으며, 구체적인 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 데이터가 동기화되더라도 각 기기에서 네트워크 권한, 화면에 제공되는 항목과 실제 연결 결과를 별도로 확인해야 합니다. 동기화가 완료되었다는 것은 데이터가 도착했을 가능성을 의미할 뿐 연결 환경까지 완전히 같다는 뜻은 아닙니다.

Chapter 07

Proxy 포트: 로컬 리스닝, 로컬 네트워크 접근과 충돌 확인

Proxy 포트의 의미

Settings의 Proxy 포트는 로컬 앱이 지정된 HTTP 또는 SOCKS5 진입점을 통해 연결을 Shadowrocket으로 전달하도록 하는 값입니다. 포트는 기기에서 로컬로 수신 대기하는 번호이며 원격 서버 포트나 프로토콜 설정의 서비스 포트가 아닙니다. 두 숫자가 우연히 같아도 의미는 다릅니다. Proxy 포트를 변경해도 서버 비밀번호, UUID나 전송 파라미터 오류가 해결되지 않으며 Config의 Rule 매칭 순서도 바뀌지 않습니다.

평소 시스템 연결 스위치만 사용한다면 로컬 Proxy 포트를 자주 조정할 필요가 없습니다. 특정 앱이 HTTP 또는 SOCKS5 Proxy를 직접 입력하는 기능을 지원하거나 로컬 디버깅이 필요할 때만 이 값을 확인하세요. 입력할 때는 Shadowrocket의 현재 Settings에 표시된 주소와 포트를 기준으로 하고 다른 기기의 숫자를 그대로 사용하지 마세요. 포트는 유효한 범위에 있어야 하며 기기에서 이미 수신 대기 중인 다른 서비스와 충돌하지 않아야 합니다.

로컬 주소와 로컬 네트워크 주소의 차이

로컬 앱이 로컬 Proxy에 연결할 때는 보통 루프백 주소나 Settings에 표시된 로컬 진입점을 사용합니다. 루프백 주소는 현재 기기만 가리키므로 다른 기기에서 자신의 루프백 주소를 이 iPhone 또는 iPad로 사용할 수 없습니다. 로컬 네트워크의 다른 관리 대상 기기에서 접근하려면 Shadowrocket에 해당 로컬 네트워크 리스닝 기능이 켜져 있는지, 시스템이 로컬 네트워크 접근 권한을 부여했는지 확인하고 서비스를 제공하는 기기의 현재 로컬 네트워크 주소를 사용해야 합니다.

로컬 네트워크 접근은 리스닝 범위를 넓히므로 명확한 필요가 있고 네트워크 환경을 통제할 수 있으며 접근 기기를 알고 있을 때만 활성화하세요. 디버깅이 끝나면 원래 상태로 복구합니다. 공용 Wi‑Fi나 같은 네트워크의 기기를 확인할 수 없는 환경은 장기 공유 진입점으로 적합하지 않습니다. 리스닝을 켜도 다른 기기는 서비스를 제공하는 기기와 연결 가능한 네트워크에 있어야 하며, 네트워크 격리, 게스트 네트워크와 라우터 정책이 연결을 막을 수 있습니다.

포트 충돌의 증상과 처리

포트 충돌은 리스닝을 시작할 수 없거나, 앱 연결이 즉시 거부되거나, 주소를 올바르게 입력해도 접근할 수 없는 형태로 나타날 수 있습니다. 문제를 해결할 때는 먼저 Shadowrocket의 기존 포트로 복구하고 다시 연결하세요. 기존 값은 작동하지만 새 값이 작동하지 않는다면 새 포트가 사용 중이거나 입력값이 일치하지 않을 가능성이 있습니다. 변경 후에는 해당 로컬 Proxy를 사용하는 모든 앱도 함께 업데이트해야 하며, 이전 설정은 자동으로 따라오지 않습니다. HTTP와 SOCKS5 포트를 동시에 변경하지 마세요. 어느 포트에서 충돌이 발생했는지 확인하기 어려워집니다.

프로토콜 유형을 확인하는 것도 중요합니다. 앱이 HTTP Proxy를 요구하면 HTTP에 해당하는 진입점을 입력하고, SOCKS5를 요구하면 SOCKS5 진입점을 입력해야 합니다. 유형과 포트를 서로 바꾸어 입력하면 연결 설정에 실패하거나 요청 동작이 이상해질 수 있습니다. 앱이 인증 필드를 지원하지만 Shadowrocket의 현재 로컬 진입점이 같은 방식을 요구하지 않는다면 클라이언트의 실제 설정에 맞춰 입력하고 원격 서버 인증 정보를 임의로 추가하지 마세요.

로컬 네트워크 디버깅의 최소 단계

먼저 서비스를 제공하는 기기에서 Shadowrocket 수동 연결이 정상인지 확인합니다. 그런 다음 필요한 로컬 네트워크 접근 설정만 켜고 현재 네트워크 주소와 해당 Proxy 포트를 기록하세요. 같은 관리 네트워크의 다른 기기에서 이 주소, 포트와 올바른 HTTP 또는 SOCKS5 유형을 입력하고 테스트 대상 하나에만 접근합니다. 실패하면 두 기기가 실제로 같은 네트워크에 있는지, 시스템의 로컬 네트워크 권한, 라우터의 기기 격리 여부와 포트 입력이 일치하는지를 순서대로 확인하세요.

다른 기기가 포트에는 연결되지만 대상 요청이 실패한다면 Shadowrocket의 Log로 돌아가 요청이 도착했는지, 어떤 Rule과 매칭되었는지, 어떤 정책을 사용했는지 확인하세요. Log에 해당 시간의 요청이 전혀 없다면 로컬 네트워크 경로나 입력 오류에 가깝고, 요청은 나타나지만 이후 타임아웃된다면 DNS, 서버 또는 규칙을 계속 점검해야 합니다. 테스트가 끝나면 더 이상 필요하지 않은 로컬 네트워크 리스닝을 끄고 다른 기기의 임시 Proxy 설정을 삭제하세요.

Proxy 포트를 변경하지 않아야 하는 경우

Subscribe 업데이트 실패, 서버 Ping 타임아웃, 특정 DOMAIN-SUFFIX의 잘못된 매칭, On Demand 미트리거 또는 DNS 해석 실패가 문제라면 로컬 Proxy 포트는 대개 우선 확인할 항목이 아닙니다. 포트 설정은 해당 진입점을 통해 연결하는 앱에만 영향을 주며 모든 네트워크 문제를 한 번에 해결하지 않습니다. 먼저 장애 상황에서 실제로 로컬 HTTP 또는 SOCKS5 진입점을 사용했는지 확인한 뒤 조정 여부를 결정하세요.

iPhone 또는 iPad에서 Shadowrocket을 정상적으로 사용하려는 것뿐이라면 Home 연결, Global Routing, Config와 실제 접속 확인을 우선 완료하세요. Proxy 포트는 명확한 수동 Proxy 요구가 있을 때 사용하는 확장 설정입니다. 무작위 숫자를 시도하기보다 현재 작동하는 값을 유지하는 편이 안전합니다. 반드시 변경해야 한다면 기존 값을 기록하고 확인이 끝난 뒤 계속 사용할지 결정하세요.

Chapter 08

Config 관리: 규칙 순서, 백업과 전체 문제 해결 과정

Config의 역할 범위

Config는 General 설정, Rule, 프록시 그룹과 기타 연결 동작을 구성하는 데 사용됩니다. 요청을 분류하고 PROXY, DIRECT 또는 REJECT로 전달할 방식을 결정하지만 잘못된 서버 정보를 자동으로 수정하지는 않습니다. Config를 관리할 때는 “서버에 연결할 수 있는가”와 “규칙이 예상한 정책을 선택하는가”를 나누어 확인해야 합니다. 먼저 Proxy 모드에서 현재 서버가 작동하는지 확인한 뒤 Config 모드로 돌아가 Rule을 점검하세요. Proxy 자체가 실패하는 상태에서 DOMAIN-SUFFIX나 GEOIP를 계속 조정해도 진단에 도움이 되지 않습니다.

규칙은 위에서 아래 순서로 매칭됩니다. DOMAIN은 정확한 도메인에, DOMAIN-SUFFIX는 지정된 접미사와 하위 도메인에, DOMAIN-KEYWORD는 도메인 안의 키워드에, USER-AGENT는 요청 특성에, GEOIP는 주소의 지역 정보에, IP-CIDR과 IP-CIDR6은 주소 범위에 따라 매칭됩니다. 범위가 넓은 규칙은 요청을 먼저 가로채기 쉬우므로 일반적으로 명확하고 구체적인 규칙을 넓은 규칙보다 앞에 배치하고, FINAL은 규칙 마지막에 두어 기본 처리를 담당하게 합니다.

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

예시는 키워드와 순서를 보여 주기 위한 것이며 사용자의 기존 Config를 그대로 덮어써서는 안 됩니다. 예시 주소는 문서용이므로 실제 관리에서는 자신의 대상과 서비스 정보에 맞춰 작성하세요. DOMAIN-SUFFIX,example.com,PROXY가 더 넓은 DOMAIN-KEYWORD,example,DIRECT보다 앞에 있으므로 해당 접미사는 먼저 PROXY를 사용합니다. 순서를 바꾸면 키워드 규칙이 먼저 매칭되어 결과가 달라질 수 있습니다. 따라서 Log를 확인할 때 “어떤 규칙과 매칭되었는가”를 기록해야 합니다.

Config, Subscribe와 수동 항목의 관계

사용자가 보유한 Subscribe는 해당 서버 항목을 제공하고, Config는 규칙과 정책을 설명합니다. 서로 연결될 수 있지만 같은 내용은 아닙니다. Subscribe를 업데이트하면 항목 이름, 순서 또는 사용 가능 여부가 바뀔 수 있으므로 Config가 특정 이름을 참조한다면 해당 참조가 여전히 존재하는지 확인하세요. 수동으로 추가한 Add Server 항목은 사용자가 입력한 프로토콜 파라미터에 의존합니다. 출처와 관계없이 업데이트 후에는 프로토콜, 주소, 포트와 필수 필드를 먼저 확인한 뒤 테스트해야 합니다.

유일하게 작동하는 Config를 바로 광범위하게 다시 작성하는 것은 권장하지 않습니다. 먼저 테스트용 복사본을 만들고, 복사본에서 관련 규칙을 한 그룹씩 수정하며 원본 파일은 복구용으로 보존하세요. 설정이 사용자가 신뢰하고 직접 선택한 출처에서 온 것이라면 업데이트 시각과 로컬 수정 위치를 기록하여 다음 업데이트가 수동 변경 사항을 덮어써도 알아볼 수 있게 하세요. 이 사이트는 Shadowrocket의 가져오기와 관리 방법만 설명하며 서버 정보나 Subscribe 내용을 제공하지 않습니다.

최소 설정에서 단계적으로 복구

복잡한 Config에서 원인을 찾기 어려운 문제가 발생하면 테스트 설정을 복사하고 필요한 General, 소수의 명확한 규칙과 FINAL만 남기세요. 먼저 DOMAIN 규칙 하나를 확인한 뒤 DOMAIN-SUFFIX를 추가하고, 이어서 GEOIP 또는 주소 범위 규칙을 추가합니다. 그룹을 추가할 때마다 다시 연결하고 Log를 확인하세요. 이렇게 하면 수백 개 규칙 사이에서 위치를 무작위로 옮기는 대신 어떤 규칙 그룹, 원격 리소스 또는 General 설정이 문제를 일으켰는지 확인할 수 있습니다.

최소 설정은 정상인데 원래 설정이 실패한다면 두 설정의 DNS, Rule 순서, 프록시 그룹 참조와 중복 섹션을 비교하세요. 최소 설정도 실패한다면 Proxy 모드로 돌아가 서버를 확인한 뒤 Direct에서 로컬 네트워크를 확인합니다. 전체 과정은 항상 환경에서 연결로, 연결에서 설정으로, 설정에서 단일 대상 순서로 진행해야 하며 최종 페이지만 보고 거꾸로 판단해서는 안 됩니다.

전체 문제 해결 순서

1. 로컬 네트워크 확인: Direct에서 서로 관련 없는 여러 대상에 접속하여 Wi‑Fi 또는 셀룰러 네트워크에 기본 연결이 가능한지 판단합니다.
2. 서버 확인: Proxy로 전환하고 서버 하나를 고정한 뒤 Ping, Connectivity Test와 실제 요청으로 교차 확인합니다.
3. Config 확인: Config로 돌아가 대상 요청과 매칭된 Rule 및 최종 정책을 확인합니다.
4. DNS 확인: 도메인이 해석되지 않으면 시스템 경로로 기준을 설정한 뒤 Config의 재정의 설정을 확인합니다.
5. 자동 트리거 확인: 수동 연결이 안정된 뒤 On Demand를 활성화하고 네트워크 전환 테스트를 실행합니다.
6. 확장 기능 확인: 마지막으로 Widget, iCloud 동기화와 Proxy 포트를 확인하여 보조 기능이 기본 진단을 방해하지 않게 합니다.

위 단계를 완료해도 판단하기 어렵다면FAQ에서 “규칙 및 문제 해결”을 기준으로 구체적인 증상을 찾아보세요. 문제를 전달할 때는 최소 재현 조건, 실패 단계와 정리된 Log를 제공하고 서버 인증 정보는 공개하지 마세요. 처음 사용하는 경우빠른 시작 튜토리얼로 돌아가 Add Server, Subscribe, Global Routing과 연결 확인 순서를 다시 점검하는 것이 좋습니다. 이 안내서는 설정 세부 사항을 설명하며 최초 작업 순서를 대신하지 않습니다.

관리 후 마무리 확인

큰 폭의 조정을 마칠 때마다 Home의 현재 서버, Global Routing, Config, On Demand, DNS, Widget과 로컬 Proxy 포트를 확인하여 임시 테스트 값이 복구되었는지 확인하세요. Config는 검증된 복사본을 하나 보존하고 정식 설정과 테스트 설정을 알아보기 쉬운 이름으로 구분합니다. Subscribe를 업데이트하거나 Import from Cloud JSON으로 데이터를 가져온 뒤에는 참조 관계를 다시 확인하고 이전 이름이 반드시 유지된다고 가정하지 마세요.

Shadowrocket 앱 업데이트는 App Store에서 제공합니다. iPhone, iPad와 스토어 호환성 항목에 표시된 기타 Apple 기기의 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 구매, 구입 항목 복원 또는 기기 정보를 다시 확인해야 한다면 이 사이트의App Store 다운로드 안내를 통해 제품 페이지로 이동하세요. 설정 관리의 목표는 각 파라미터의 용도를 설명할 수 있고 재현 및 복구가 가능하도록 하는 것이며, 이해할 수 없는 스위치와 규칙을 장기간 쌓아 두는 것이 아닙니다.