Shadowrocket Settings 설정 가이드

1. Settings, Config, 실행 상태의 적용 범위

설정을 변경하기 전에 문제가 어느 계층에서 발생하는지 확인하세요. Settings의 앱 환경설정, Config에서 선택한 구성 파일, Home에서 선택한 서버와 연결 스위치는 서로 다른 상태입니다. 서버는 연결 대상과 프로토콜 매개변수를 결정하고, 구성 파일은 규칙과 관련 처리 방식을 결정합니다. Global Routing은 현재 적용할 라우팅 방식을 정합니다. 한 항목을 변경해도 다른 계층까지 함께 바뀌는 것은 아니므로, 문제를 해결할 때는 각 항목을 따로 기록하세요.

Global Routing의 세 가지 방식

일상적으로 규칙에 따라 요청을 처리하려면 Config를 사용하고, Config 화면에서 현재 선택된 파일을 확인하세요. Proxy는 프록시 경로를 임시로 확인할 때, Direct는 직접 연결 결과를 비교할 때 적합합니다. 두 방식 모두 잘못된 구성을 고치는 대안은 아닙니다. 특히 Proxy로 전환한 뒤 웹페이지가 열린다고 해서 DNS와 규칙이 모두 올바르다고 단정할 수 없습니다. 테스트 당시 선택한 프록시 경로로 해당 요청이 처리되었다는 점만 확인할 수 있습니다.

기본값, 현재값, 권장값

기본값은 앱에서 관련 설정을 변경하기 전에 제공되는 초기 상태입니다. 현재값은 사용자의 편집, 구성 가져오기 또는 복원으로 바뀌었을 수 있습니다. 스위치가 켜져 있다는 사실은 현재 켜져 있다는 뜻일 뿐, 처음부터 켜져 있었다는 근거는 아닙니다. 용도를 모르는 옵션은 그대로 두고, 문제를 설명할 수 있고 검증 방법을 알고 있을 때만 변경하는 것이 좋습니다. 서버 프로토콜 관련 항목은 기존 서비스 정보를 따르고, 이른바 범용 매개변수로 대체하지 마세요.

기준을 설정하기 위해 데이터를 지울 필요는 없습니다. 먼저 Global Routing, 현재 Config 파일 이름, 선택한 서버와 관련 스위치를 기록하세요. 구성을 편집할 예정이라면 로컬 사본을 보관합니다. 그런 다음 안정적으로 반복 접속할 수 있는 대상을 선택하고 현재 네트워크에서 나타나는 현상을 기록하세요. 매번 조건 하나만 변경하세요. 예를 들어 DNS만 바꾸거나, 서버만 전환하거나, On Demand만 끄면 어떤 변경이 영향을 줬는지 확인하기 쉽습니다.

문제 해결에서 구성 파일의 역할

구성 파일에는 전역 매개변수, 규칙, 로컬 매핑이 포함될 수 있습니다. 아래 예시는 구조를 설명하기 위한 것으로, 기존 파일을 덮어쓰라는 뜻이 아닙니다. 예시 도메인은 설명용이며, PROXY가 현재 환경에서 사용할 수 있는 프록시를 가리켜야 합니다. 기존 파일에서 구체적인 정책 이름을 사용하고 있다면 유효한 참조를 유지하세요. 가져온 뒤에는 파일이 선택되어 있는지 확인하고, 텍스트가 저장되었는지만 보지 말고 요청 기록에서 실제 규칙 적용 결과를 확인하세요.

[General]
dns-server = system

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

[Host]
localhost = 127.0.0.1

변경 사항은 세 가지를 확인해야 합니다. 대상 요청이 성공하는지, 예상한 정책이 적용되는지, 다른 자주 쓰는 대상도 정상인지 살펴보세요. 실패하면 방금 변경한 항목을 먼저 되돌리고 결과를 비교합니다. 원래대로 돌려도 문제가 계속되면 테스트 중 네트워크, 구독 또는 서버가 바뀌었는지 확인하세요. 구성 섹션의 자세한 구조는 구성 파일 구조 자세히 보기를 참고하세요. 최초 가져오기 절차는 사용법 페이지를 확인하세요.

2. DNS: 해석 경로, 구성 재정의, 캐시 확인

DNS는 도메인 이름을 연결 가능한 주소로 변환하지만, 이름 해석에 성공했다고 연결까지 성공하는 것은 아닙니다. 웹페이지가 열리지 않는 원인은 도메인 해석, 프록시 서버 연결, 대상 서버 연결 또는 이후 암호화 통신 단계에 있을 수 있습니다. DNS를 변경하기 전에 장애가 발생한 단계를 확인하세요. 해석 실패가 기록되었는지, 대상 주소가 확인되었는지, 서버 자체가 작동하는지 살펴봅니다. 브라우저의 연결 실패 메시지만으로 DNS 문제라고 단정할 수는 없습니다.

dns-server와 system의 의미

구성 파일의 dns-server = system은 시스템에서 제공하는 DNS 해석 경로를 사용한다는 뜻입니다. 현재 네트워크와 비교하기 편리한 권장 기준이지, 모든 기기의 출고 시 기본값을 의미하지는 않습니다. 시스템 DNS 환경은 연결된 네트워크에 따라 달라지므로 같은 구성도 Wi-Fi와 셀룰러 네트워크에서 다르게 작동할 수 있습니다. 기존 구성에서 다른 해석 경로를 명시하고 있다면, 먼저 지정한 이유를 확인한 뒤 되돌릴지 결정하세요.

DNS 서버를 지정하려면 직접 확인할 수 있고 현재 네트워크 조건에 맞는 주소와 형식을 사용하세요. 일반 DNS와 암호화 DNS는 연결 조건이 다릅니다. 암호화 DNS는 서비스 도메인, 인증서, DNS 서비스까지의 네트워크 경로도 확인해야 합니다. 주소를 입력했다고 해서 반드시 작동하는 것은 아닙니다. 저장 후 앱이 형식을 받아들이는지 확인하고 새 요청으로 검증하세요. DNS 주소를 프록시 서버 주소로 입력하지 마세요.

구성과 Host를 먼저 확인한 뒤 DNS 서버 변경

특정 도메인만 문제가 있다면 현재 구성의 [Host]에 해당 매핑이 있는지 먼저 확인하세요. 명시적 매핑이 요청을 고정 주소로 보내고 있을 수 있으므로 DNS 경로를 바꿔도 결과가 달라지지 않을 수 있습니다. 해당 도메인에 예상과 다른 정책이 적용되는지도 확인하세요. 규칙 적용과 DNS 조회는 별개의 과정입니다. 프록시 접속이 실패했다는 사실만으로 도메인이 잘못된 주소로 해석되었다고 판단할 수는 없습니다.

캐시 때문에 변경 직후의 첫 테스트 결과가 명확하지 않을 수 있습니다. 시스템, 앱, 대상 웹사이트의 연결에 기존 상태가 남아 있을 수 있으며, DNS 경로를 전환해도 이미 설정된 연결은 다시 해석되지 않을 수 있습니다. 테스트 중인 페이지를 닫고 새 요청을 시작하세요. 필요하면 앱에서 제공하는 캐시 삭제 기능을 사용한 다음 다시 연결합니다. 문제 해결과 무관한 로그인 정보가 사라질 수 있으므로 모든 웹사이트 데이터를 일괄 삭제하는 것을 정해진 절차로 삼지 마세요.

IPv6, 네트워크 연결, DNS 장애의 범위

일부 대상은 IPv4와 IPv6 주소를 모두 제공하지만 현재 네트워크에서 두 주소 계열에 대한 연결 가능성이 다를 수 있습니다. 기록에 해석 성공이 표시되더라도 특정 주소 계열의 연결이 계속 실패한다면 해당 설정을 하나씩 비교해 볼 수 있습니다. 관련 기능을 바로 끄면 현상이 잠시 달라질 수 있지만 원인이 해결되었다는 뜻은 아닙니다. 변경 전 기록을 보관하고, 해당 주소 계열에 의존하는 다른 접속에도 영향이 있는지 확인하세요.

권장 점검 순서는 현재 Config 확인, dns-server와 Host 항목 확인, 기록 검토, DNS 조건 하나를 바꿔 비교하는 것입니다. 테스트 중에는 서버와 Global Routing을 그대로 유지하세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 시스템 DNS와 인증 상태를 먼저 기록합니다. 네트워크를 바꿔도 실패하면 구성 자체를 확인하세요. 검증 후 개선되지 않은 변경은 되돌려 임시 테스트 설정이 구성에 남지 않도록 합니다.

3. On Demand: 자동 연결의 실행 및 중지 조건

On Demand는 지정한 조건에 따라 연결을 시작합니다. 올바른 규칙을 선택하거나 서버 정보를 대신 입력해 주지는 않습니다. 켜기 전에 수동 연결이 작동하는지 확인하세요. 등록된 서버에 연결할 수 있고, 현재 Config가 정상적으로 작동하며, 시스템 VPN 구성이 승인되어 있어야 합니다. 수동 연결부터 실패한다면 서버, DNS 또는 규칙 문제를 먼저 해결하세요. 그렇지 않으면 자동 연결도 같은 오류를 반복합니다.

활성화하기 적절한 경우

특정 네트워크에서 자동 연결을 시작하는 등 사용 조건이 명확할 때 On Demand를 설정하는 것이 적절합니다. 처음 설정할 때는 비활성 상태를 유지하고 수동 연결을 확인한 뒤 별도로 켜는 것을 권장합니다. 비활성 상태는 문제 해결을 위한 권장 기준이며, 앱의 공통 기본값을 의미하지 않습니다. 이미 켜져 있다면 기존 규칙과 조건을 먼저 기록하세요. 특정 네트워크를 위해 설정한 예외가 있을 수 있으므로 바로 삭제하지 마세요.

Settings에서 On Demand를 찾아 현재 화면에 표시되는 조건을 하나씩 확인하세요. 여러 조건 사이에 일치 여부와 순서가 영향을 줄 수 있으므로 각 규칙의 동작과 적용 범위를 살펴봐야 합니다. 네트워크 이름을 조건으로 사용한다면, 이름은 일치 여부를 확인하기 위한 정보일 뿐 네트워크가 안전하다는 증거가 아닙니다. 여러 액세스 포인트가 같은 이름을 사용할 수 있고, 이름이 바뀌면 기존 조건이 더는 적용되지 않을 수도 있습니다.

시스템 VPN 승인과 앱 스위치의 차이

처음 연결할 때 시스템에서 VPN 구성을 추가하도록 요청할 수 있습니다. 이 승인은 시스템이 해당 연결을 설정할 수 있도록 허용하는 것이며, 서버를 가져왔거나 앱 설정을 모두 마쳤다는 뜻은 아닙니다. 승인 절차가 중단되면 앱으로 돌아가 연결 상태를 확인하고 시스템 안내에 따라 처리하세요. 무작정 구성을 반복해서 만들지 마세요. 기존 구성이 앱과 연결되어 있는지 먼저 확인하고, 관리 정책이나 다른 연결 설정이 영향을 주는지 점검하세요.

On Demand를 켠 뒤에는 수동 연결 해제와 자동 실행 중지가 서로 다른 작업입니다. 연결을 끊어도 새로운 네트워크 활동이 조건에 맞으면 시스템이 다시 연결을 시작할 수 있어 스위치가 저절로 켜진 것처럼 보일 수 있습니다. 이 경우 On Demand를 잠시 끄고 연결을 해제해 비교하세요. 다시 연결되지 않는다면 자동 실행 조건을 확인해야 합니다. 자동 재연결을 곧바로 앱 오류로 판단하지 마세요.

자동 실행을 처음부터 끝까지 테스트하는 방법

테스트는 조건 진입, 연결 유지, 조건 이탈의 세 단계를 확인해야 합니다. 먼저 연결된 네트워크와 현재 연결 상태를 기록한 다음 On Demand를 켜고 조건에 맞게 네트워크를 전환해 일반 요청을 한 번 실행하세요. 시스템 연결 상태와 앱 기록을 살펴 연결이 예상한 조건으로 시작되었는지 확인합니다. 그다음 해당 조건에서 벗어나 설정대로 동작하는지 확인하세요. 첫 실행 성공만 확인하고 테스트를 끝내지 마세요.

로그인이 필요한 공용 Wi-Fi는 별도로 테스트하세요. 네트워크 인증을 완료하기 전에는 DNS와 서버 연결이 제한될 수 있습니다. 자동 연결은 네트워크 인증을 대신하지 않습니다. 인증 페이지가 열리지 않는다면 현재 작업을 정확히 이해한 상태에서 자동 실행을 잠시 끄고 인증을 완료한 뒤 원래 설정으로 되돌릴 수 있습니다. 인증 중 발생한 실패 기록과 정상 연결 후 결과를 함께 비교하지 마세요.

기기가 조직의 관리 대상이라면 일부 VPN 동작이 시스템 정책에 제한될 수 있으며, 이 페이지의 개인 기기 안내로 이러한 제한을 해결할 수는 없습니다. 원래 상태로 복구하려면 On Demand를 끈 다음 기존 조건과 연결 선택을 되돌리고 수동으로 다시 검증하세요. ‘연결을 끊어도 다시 연결됨’ 또는 ‘특정 네트워크에서만 실행됨’이 궁금하다면 자주 묻는 질문을 참고하세요. 당시 네트워크 조건도 함께 기록해야 스위치 상태만으로 판단하는 일을 피할 수 있습니다.

4. Ping 및 Connectivity Test: 테스트 결과의 범위

Ping과 Connectivity Test는 연결 조건을 살펴보는 도구이며 실제 서비스 품질을 완전히 판정하지는 않습니다. 테스트 성공은 당시 사용한 방법으로 해당 상호작용이 가능했다는 뜻입니다. DNS, 규칙, 대상 서비스 또는 프로토콜 조건이 다르면 웹페이지, 동영상 및 다른 요청은 계속 실패할 수 있습니다. 테스트 전에 방법, 대상, 시간 초과 조건을 확인하고 의미가 다른 수치를 그대로 비교하지 마세요.

테스트 방법에 따라 수치의 의미가 달라집니다

Settings에서 Ping 관련 설정을 찾아 현재 선택된 테스트 방법을 확인하세요. TCP 유형의 테스트가 제공된다면 대상 포트까지 연결 가능한지를 주로 확인합니다. 프록시를 통해 HTTP 요청을 보내는 테스트가 있다면 프록시 협상, 테스트 주소, 응답 처리도 영향을 줍니다. 측정하는 단계가 다르므로 표시 단위가 같더라도 숫자가 낮을수록 모든 접속에 적합하다고 볼 수는 없습니다.

기본 테스트 방식, 테스트 주소, 시간 초과 값은 현재 앱에 표시된 내용을 기준으로 하며, 이 페이지에서는 특정 숫자를 지정하지 않습니다. 기존 설정으로 반복 가능한 기준을 먼저 만들고, 테스트 대상에 연결할 수 없거나 테스트 방법이 문제 해결 목적에 맞지 않을 때만 변경하세요. 사용자 지정 테스트 주소를 쓰기 전에 주소가 안정적이며 접근 권한이 있는지 확인합니다. 로그인이 필요하거나 리디렉션이 잦은 페이지, 자동 요청을 제한하는 페이지는 일반적인 연결 테스트 대상으로 사용하지 마세요.

시간 초과가 모든 요청의 실패를 뜻하지는 않습니다

시간 초과는 지정된 시간 안에 테스트가 완료되지 않았다는 뜻이며, 서버가 완전히 작동하지 않는다고 단정할 근거는 아닙니다. 포트에 연결할 수 없거나, 프로토콜 매개변수가 맞지 않거나, 테스트 대상에 제한이 있거나, 테스트 중 네트워크가 바뀌었을 수 있습니다. 반대로 빠른 응답이 대용량 전송의 안정성을 보장하지도 않습니다. 시간 초과가 발생하면 같은 조건에서 다시 테스트한 뒤 일반적인 서비스 요청으로 확인하고 두 결과를 따로 기록하세요.

등록된 서버를 비교하는 방법

비교할 때는 연결된 네트워크, 테스트 방법, 테스트 대상, 기타 설정을 동일하게 유지하세요. 네트워크 전환이 안정될 때까지 기다린 다음 보유한 서버 몇 개를 반복해서 테스트해 결과가 계속 비슷한지 확인합니다. 우연히 나온 최솟값만 골라서는 안 됩니다. 테스트 자체가 네트워크 요청을 발생시키므로 순위를 정하려고 짧은 간격으로 반복할 필요는 없습니다. 특정 시점의 순서를 장기적인 신뢰도 순위로 해석하지 마세요.

프로토콜 필드가 잘못되어 주소에 연결되지만 사용할 수 없는 경우도 있습니다. 예를 들어 포트 연결 성공은 해당 포트가 응답했다는 뜻일 뿐, 인증 정보, 암호화 방식, 서버 이름 등의 매개변수가 올바르다는 뜻은 아닙니다. Add Server로 돌아가 기존 서비스 정보를 확인하고, 복사할 때 공백과 포트, 필드 위치에 유의하세요. 테스트를 성공으로 표시하려고 인증서 확인을 끄거나 프로토콜 보안 설정을 임의로 바꾸지 마세요.

테스트 결과를 실제 접속과 연결하기

Connectivity Test를 마친 뒤 검증에 사용할 서버를 명시적으로 선택하고 Global Routing과 현재 Config를 확인하세요. 테스트 목록의 한 항목이 성공해도 현재 연결이 그 서버로 전환되었다는 뜻은 아닙니다. 목록 순서가 바뀌었다고 전환 성공을 판단할 수도 없습니다. 반복 가능한 대상에 요청을 보내고 기록에서 실제 경로를 확인해야 테스트 결과를 실제 접속과 연결할 수 있습니다.

스위치가 켜져 있지만 접속할 수 없다면 모든 항목을 반복 테스트하기보다 네트워크, 서버, 모드, DNS, 규칙 순서로 확인하는 편이 원인을 찾기 쉽습니다. 자세한 절차는 연결 스위치는 켜져 있지만 접속되지 않을 때 점검 목록을 참고하세요. 문제를 설명할 때는 테스트 방법과 실패 단계를 함께 적고 시간 초과 화면만 보내지 마세요. 테스트 대상의 오류를 서버 문제로 오해할 가능성을 줄일 수 있습니다.

5. Log 및 Data: 요청 기록, 트래픽 통계, 개인정보 보호

Log는 발생한 일을 확인하는 기록이고, Data는 앱 통계 범위의 데이터 변화를 보여줍니다. 두 기능의 목적은 다릅니다. 연결 스위치가 켜져 있다는 사실은 연결을 시도했다는 뜻일 뿐, 모든 요청이 예상대로 처리되었다는 보장은 아닙니다. 이상이 발생하면 재현 가능한 요청 하나를 기준으로 발생 시간, 대상 도메인, 적용된 정책, 오류 정보를 연결해 살펴보세요. 관련 있어 보이는 과거 기록을 한꺼번에 뒤지는 방식은 피하세요.

로그 상세 수준 선택하기

Settings에서 Log 관련 옵션과 현재 기록 수준을 확인하세요. 상세 수준을 선택할 수 있다면 평소에는 문제를 살펴보기에 충분한 수준을 유지하고, 구체적인 장애를 진단할 때만 일시적으로 상세도를 높이세요. 실제 상태는 현재 선택된 항목을 기준으로 하며, 이 페이지는 특정 수준을 공통 기본값으로 지정하지 않습니다. 상세 로그는 저장 공간과 처리 부담을 늘릴 수 있으므로 문제 해결이 끝나면 원래 설정으로 되돌리고 필요에 따라 기록을 정리하세요.

재현하기 전에 시간을 기록하세요. 필요하면 이번 문제 해결과 무관한 오래된 기록을 정리한 다음 대상 하나만 접속합니다. DNS 해석이 발생했는지, 주소를 받았는지, 정책이 선택되었는지, 연결이 시작되었는지, 어느 단계에서 실패했는지 순서대로 확인하세요. 여러 기록 행은 동시에 발생한 요청일 수 있으므로 행이 서로 인접해 있다는 이유만으로 같은 연결이라고 단정하지 마세요. 대상, 시간, 앱에서 제공하는 관련 정보를 함께 살펴야 합니다.

규칙 적용 기록으로 설정 확인하기

특정 도메인을 PROXY로 보내려 했는데 기록에는 DIRECT가 표시된다면 먼저 Global Routing이 Config인지 확인한 뒤 규칙 순서와 현재 파일을 살펴보세요. 아래 예시는 ‘지정한 도메인은 먼저 프록시로 보내고 나머지는 직접 연결’하는 구조입니다. 규칙은 순서대로 확인하며 FINAL은 마지막에 둡니다. 이 예시는 규칙 적용 원리를 설명하기 위한 것이며, 기존 구성을 덮어쓰라는 뜻은 아닙니다. 편집 후 새 요청을 보내야 합니다. 이미 연결된 요청에는 변경된 규칙이 바로 적용되지 않을 수 있습니다.

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

앞쪽의 더 넓은 범위 규칙이 이미 대상과 일치하면 뒤에 더 구체적인 규칙을 써도 자동으로 우선 적용되지 않습니다. 새로 추가한 두 줄만 보지 말고 전체 목록을 확인하세요. DOMAIN, DOMAIN-SUFFIX, IP-CIDR은 서로 다른 대상을 일치시킵니다. DNS에서 얻은 주소도 원래 도메인과 같은 개념이 아닙니다. 규칙의 기본 사항은 규칙 키워드와 일치 순서를 참고하세요.

Data 수치를 바로 청구 내역으로 볼 수 없는 이유

Data를 확인할 때는 화면에 표시된 범위가 현재 세션인지, 특정 항목인지, 누적 수치인지 먼저 확인하고 이전에 초기화했는지도 살펴보세요. 앱 통계와 서비스 제공자의 청구 내역은 집계 기간과 기준이 다를 수 있습니다. 프로토콜 오버헤드, 통계 범위, 시간 구간도 영향을 줍니다. 수치가 완전히 같지 않다고 바로 이상으로 판단하지 말고, 비교 구간을 통일한 뒤 기존 서비스의 트래픽 산정 기준을 확인하세요.

연결 후에도 소량의 데이터가 변하는 것은 연결 유지, DNS 해석 또는 다른 앱 요청 때문일 수 있습니다. 수치가 증가한다는 이유만으로 특정 대상이 계속 데이터를 전송한다고 판단할 수는 없습니다. 발생 경로를 확인하려면 요청 기록과 함께 살펴보세요. 통계를 초기화하기 전에 기존 수치와 시간을 기록합니다. 초기화는 새로운 관찰 기준점을 만드는 기능이며, 이미 발생한 서비스 사용량을 바꾸거나 연결 문제를 해결하지 않습니다.

내보내거나 공유하기 전에 확인할 사항

로그에는 방문한 도메인, 서버 주소, 요청 경로, 인증 관련 정보가 포함될 수 있으며 구독 정보에는 개인 식별 정보가 들어 있을 수 있습니다. 공유하기 전에 필요한 부분만 복사하고 비밀번호, 전체 구독 주소, 토큰, 개인을 식별할 수 있는 정보를 삭제하세요. 화면에서 가장 눈에 띄는 한 줄만 가리고 다른 위치에 있는 같은 정보는 남겨두지 마세요. 오류가 발생한 단계와 최소한의 관련 내용만으로 설명할 수 있다면 전체 기록을 공개할 필요가 없습니다.

유효한 기록에는 테스트 시간, 네트워크, 사용한 모드, 결과가 담겨 있어야 합니다. 원인을 찾았다면 임시 상세 기록을 끄고 필요에 따라 내보낸 사본을 정리한 뒤 통계 관찰 기준을 복구하세요. 다음에 문제가 생기면 같은 방식으로 새 최소 재현 자료를 수집하는 편이 민감 정보가 포함된 기록을 장기간 보관하는 것보다 판단에 도움이 됩니다.

6. Widget: 빠른 실행, 상태 갱신, 시스템 제한

Widget은 시스템에서 허용하는 범위 내에서 빠른 실행이나 상태 표시를 제공하며, 앱의 전체 설정을 대신하지 않습니다. 갱신 속도와 제공되는 동작은 앱이 지원하는 위젯과 시스템 작동 방식에 따라 달라집니다. 설정 전에 Shadowrocket에서 수동 연결을 확인한 다음 시스템에서 사용할 수 있는 위젯을 추가하세요. 위젯이 표시된다는 사실만으로 서버 가져오기, 구성 선택, 시스템 승인까지 완료되었다고 판단하지 마세요.

추가하기 전에 앱의 기본 상태 확인

먼저 Home을 열어 현재 선택된 서버와 연결 상태를 확인한 다음 Config에서 유효한 파일을 확인하세요. 규칙과 라우팅을 사용하려면 Global Routing이 Config인지도 확인해야 합니다. 이어서 Settings에서 현재 제공되는 Widget 관련 옵션을 살펴보고 기기에서 실제로 확인할 수 있는 항목만 조정하세요. 이 페이지는 위젯 개수, 크기, 버튼 배치를 정해진 값으로 지정하지 않으며, 특정 표시 방식을 모든 기기의 공통 기본값으로 간주하지 않습니다.

시스템의 위젯 추가 화면에서 Shadowrocket을 찾아 현재 사용할 수 있는 스타일을 선택하세요. 위젯 항목이 보이지 않는다면 먼저 앱을 한 번 실행했는지 확인하고 시스템의 현재 추가 절차에 따라 살펴보세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. 현재 화면에 없는 스타일을 찾으려고 앱 데이터를 전부 초기화하지 마세요. 먼저 앱으로 돌아가 기본 기능이 정상인지 확인하세요.

표시된 상태와 실제 연결 비교하기

위젯에는 마지막 갱신 시점의 상태가 표시될 수 있으며 앱 화면과 실시간으로 완전히 일치하지 않을 수 있습니다. 상태가 바로 바뀌지 않는다면 앱을 열고 실제 요청을 보내 확인하세요. 시스템 연결 표시도 여러 확인 방법 중 하나일 뿐입니다. 특정 대상에 어떤 규칙이 적용되는지, 서버에서 모든 대상에 접속할 수 있는지를 알려주지는 않습니다. 위젯, 앱, 요청 기록은 각각 구분해 살펴보세요.

빠른 실행과 On Demand의 상호작용

빠른 실행으로 연결을 끊은 뒤 다시 연결된다면 먼저 On Demand를 확인하세요. 위젯 동작과 자동 연결 규칙이 차례로 실행될 수 있으므로 방금 한 번 누른 동작만으로 최종 상태를 설명할 수 없습니다. 자동 연결을 잠시 중지하려면 앱에서 자동 실행 조건을 먼저 처리한 뒤 연결을 끊으세요. 반복해서 누르면 동작이 겹쳐 결과를 이해하기 어려워질 수 있으므로 한 번 조작한 뒤 상태가 안정될 때까지 기다리세요.

기기가 잠겨 있거나 시스템의 백그라운드 활동 제한이 적용되거나 추가 확인이 필요한 경우 빠른 실행은 앱에서 직접 조작할 때와 다르게 완료될 수 있습니다. 시스템의 실제 안내를 따르세요. 백그라운드 권한, 저전력 모드, 새로고침 설정을 모두 해제해야 한다고 일괄적으로 판단하지 마세요. 특정 시스템 제한이 현재 기능에 영향을 주는 상황을 재현할 수 있을 때만 항목별로 비교하고, 확인이 끝나면 불필요한 변경을 되돌리세요.

표시 내용과 기기 개인정보 보호

다른 사람이 쉽게 볼 수 있는 위치에 위젯을 두면 표시 이름을 통해 서버 용도나 개인 사용 습관이 노출될 수 있습니다. 보유한 항목의 이름은 쉽게 구분할 수 있으면서 개인정보를 과도하게 포함하지 않도록 설정하세요. 비밀번호, 구독 토큰, 전체 서비스 주소를 이름에 적지 마세요. 이름은 항목을 식별하기 위한 것으로 서버 인증 정보에는 영향을 주지 않으며 프로토콜 구성이 올바른지도 알려주지 않습니다.

권장 기준은 먼저 앱 내부 절차를 안정화한 뒤 실제로 필요한 빠른 실행만 남기는 것입니다. 시스템 위젯을 삭제해도 보통 앱의 서버나 구성이 삭제되는 것은 아니지만, 정리하기 전에 작업 대상을 구분해야 합니다. 위젯에서만 문제가 발생한다면 앱에서 같은 동작을 반복해 보세요. 앱에서도 실패하면 위젯 배치를 더 조정하지 말고 연결 문제를 확인하세요. 이렇게 하면 시스템 표시 문제와 네트워크 처리 문제를 분리할 수 있습니다.

7. iCloud 동기화: 데이터 범위, 충돌, 복원 순서

iCloud 기능은 현재 지원 범위에서 앱 데이터를 저장하거나 동기화하는 용도이며 모든 실행 상태가 자동으로 복사된다는 뜻은 아닙니다. 서버 항목, 구성 파일, 앱 환경설정, 시스템 VPN 승인은 서로 다른 대상입니다. 어떤 항목을 지원하는지는 현재 앱에서 제공하는 기능과 안내를 기준으로 확인하세요. 처음 사용하기 전에 사용할 수 있는 로컬 사본을 보관하면 동기화 방향을 모르는 상태에서 유일하게 작동하는 구성을 덮어쓰는 일을 막을 수 있습니다.

동기화, 가져오기, 구매 복원을 구분하기

App Store 구매 복원은 앱을 이용할 수 있는 권한을 복원하는 기능이며 사용자의 서버와 구성을 복원하지 않습니다. 같은 Apple 계정으로 앱을 다시 받은 뒤에도 로컬 데이터가 있는지 확인하고 적절한 복원 방법을 선택해야 합니다. 구매 절차는 기기 변경 및 구매 복원 안내를 참고하세요. 일반적인 구매 가능 여부는 App Store 페이지에 표시된 내용을 기준으로 합니다. 한 기기에 앱이 설치되어 있다고 해서 모든 기기의 데이터가 같다고 볼 수는 없습니다.

동기화는 여러 위치의 데이터가 서로 갱신되는 관계를 말하고, 가져오기는 선택한 항목을 현재 앱에 추가하는 작업인 경우가 많습니다. 두 작업은 같지 않습니다. Import from Cloud JSON이 표시되면 해당 기능에서 요구하는 형식을 선택하세요. 일반 구성 텍스트나 구독 주소를 같은 종류의 파일로 취급하지 마세요. 가져오기 전에 출처, 콘텐츠 유형, 저장 위치를 확인하고, 작업 후 중복 항목이 생겼는지와 실제 선택된 항목이 올바른지 살펴보세요.

기본 상태와 권장 활성화 조건

iCloud 스위치의 현재 상태는 기기 시스템 설정, 앱 환경설정, 복원 기록의 영향을 받을 수 있으므로 이 페이지에서는 공통 기본값을 지정하지 않습니다. 한 기기에서 먼저 데이터가 유효한지 확인한 뒤 필요에 따라 동기화를 켜세요. 한 기기만 사용하고 동기화가 필요하지 않다면 현재 방식을 유지하면 됩니다. 켜기 전에 시스템에서 Shadowrocket의 해당 iCloud 기능 사용을 허용하는지, 계정과 저장 공간 상태가 정상인지 확인하세요.

동기화 후 ‘클라우드에 정말 저장되었는지’ 확인하려고 로컬 사본을 바로 삭제하지 마세요. 사용 조건을 갖춘 다른 기기에서 데이터가 보이는지 확인하고 파일 내용, 항목 수, 필요한 필드를 점검하는 편이 안전합니다. 동기화 완료 안내가 표시되어도 실제 연결 테스트를 대신할 수는 없습니다. 해당 기기에서 시스템 승인, 현재 서버 선택, 네트워크 환경을 각각 확인해야 합니다.

여러 기기에서 편집하다 충돌이 발생한 경우

두 기기에서 중요한 구성 하나를 동시에 수정한 뒤 시스템이 올바르게 자동 병합해 줄 것이라고 기대하지 마세요. 네트워크 지연이나 오프라인 편집으로 서로 다른 사본이 다른 순서로 도착할 수 있으며, 수정 시간이 더 최근이라고 해서 내용이 더 적합한 것도 아닙니다. 변경할 때는 편집할 기기 하나를 먼저 정하고 사본을 저장한 뒤 수정과 검증을 마치고 다른 기기를 확인하세요. 차이가 있으면 전체를 덮어쓰기 전에 내용을 비교하세요.

구독 업데이트와 클라우드 동기화는 다릅니다

구독 업데이트는 사용자가 보유한 구독 출처에서 내용을 가져오고, iCloud 동기화는 앱이 지원하는 데이터 항목을 대상으로 합니다. 로컬 구성이 동기화되었다고 구독이 업데이트된 것은 아닙니다. 구독 업데이트에 성공해도 다른 기기에 최신 사본이 도착했다고 볼 수 없습니다. 문제를 확인할 때 두 작업을 각각 기록해 ‘업데이트 후 항목이 바뀜’을 클라우드 덮어쓰기 탓으로 잘못 판단하지 않도록 하세요. 보존할 로컬 메모나 편집 내용이 있다면 업데이트가 영향을 주는지도 먼저 확인하세요.

내보낸 데이터에는 서버 인증 정보가 포함될 수 있으므로 저장하거나 전달할 때 민감 데이터로 취급하세요. 삭제하기 전에 대상이 로컬 사본인지 동기화된 항목인지 확인하고, 현재 기기에서만 삭제된다고 가정하지 마세요. 전체 복원 순서는 앱 받기, 데이터 복원, 필드 확인, 구성 선택, 시스템 승인 처리, 수동 검증, 마지막으로 On Demand 복원입니다. 이 순서대로 진행하면 문제를 찾기 쉽고 자동 연결 때문에 데이터 복원이 끝나지 않은 사실을 놓치지 않습니다.

8. Proxy 포트: 로컬 리스닝, 접근 범위, 복구 검증

Proxy 포트 설정을 다룰 때는 두 종류의 주소를 구분해야 합니다. 서버 항목의 원격 포트와 기기에서 프록시 진입점을 제공할 때 사용하는 로컬 리스닝 포트입니다. 전자는 사용자가 보유한 서비스 정보이고 후자는 현재 기기의 접속 설정입니다. 로컬 리스닝 포트를 바꿔도 원격 서버 포트의 입력 오류나 원격 인증 매개변수는 해결되지 않습니다. 문제를 확인하기 전에 어떤 종류의 필드를 편집하는지 살펴보고 같은 숫자를 모든 위치에 입력하지 마세요.

로컬 포트를 변경해야 하는 경우

일반적인 시스템 VPN 연결에서는 ‘최적화’를 위해 로컬 Proxy 포트를 임의로 바꿀 필요가 없습니다. 앱이 제공하는 로컬 프록시 진입점을 통해 연결해야 하거나 리스닝 충돌이 확인된 경우에만 관련 설정을 살펴보세요. 실제 기준은 현재 앱에 표시된 프로토콜 유형, 리스닝 주소, 포트이며 이 페이지는 고정 기본값을 지정하지 않습니다. 화면에서 제공하지 않는 기능을 다른 자료만 보고 임의로 설정 항목을 만들어내지 마세요.

포트는 유효한 숫자여야 하며 연결하려는 쪽에 입력한 값과 일치해야 합니다. HTTP와 SOCKS5는 서로 다른 접속 방식이므로 둘 다 프록시라고 해서 설정을 바꿔 쓸 수는 없습니다. 연결이 거부되면 먼저 리스닝이 시작되었는지, 주소와 포트가 올바른지, 선택한 프로토콜이 일치하는지 확인한 뒤 원격 경로를 점검하세요. 요청이 로컬 프록시 진입점에 도달하기도 전에 DNS를 바꾸지 마세요.

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

127.0.0.1은 연결을 시작한 기기 자신을 가리킵니다. 다른 기기에서 이 주소를 입력해도 Shadowrocket을 실행 중인 기기를 가리키지 않습니다. 기기 간 연결이 필요하다면 앱에서 해당 접근 기능을 실제로 제공하고 활성화했는지, 올바른 로컬 네트워크 주소를 사용했는지, 두 기기가 서로 통신할 수 있는지 확인하세요. 액세스 포인트 격리, 서로 다른 서브넷, 기기 잠자기 상태 때문에 포트에 연결하지 못할 수 있습니다.

접근 범위를 넓히면 누가 해당 진입점을 사용할 수 있는지도 달라집니다. 한 번 테스트하려고 허용 범위를 넓힌 뒤 계속 유지하지 마세요. 앱에서 접근 제한이나 인증 옵션을 제공한다면 실제 필요에 맞게 설정하세요. 공유할 필요가 없다면 기기 내부로 접근을 제한하고 추가 접근 기능은 끄는 것을 권장합니다. 이는 보안 점검을 위한 기준이지 앱의 출고 시 기본값을 의미하지 않습니다. 제어할 수 없는 네트워크에 로컬 프록시 진입점을 노출하지 마세요.

중복 전달과 잘못된 연결 경로 방지

로컬 프록시 진입점을 현재 연결 경로의 원격 서버로 다시 사용하지 마세요. 중복 전달이나 연결 루프가 생길 수 있습니다. 변경 후 반복 연결, 지속적인 시간 초과, 비정상적인 트래픽이 발생하면 테스트를 즉시 중단하고 기존 서버 선택과 리스닝 설정을 복원한 뒤 참조 관계를 확인하세요. 진단할 때는 포트를 계속 바꾸기보다 ‘요청이 어디서 들어와 어떤 정책을 거쳐 어디로 연결되는지’를 먼저 정리하는 편이 효과적입니다.

규칙 파일은 별도로 검증해야 합니다. 지정한 도메인만 프록시로 보내려면 포트 설정에 의존하지 말고 Config 모드와 DOMAIN-SUFFIX 등의 규칙을 확인하세요. 구체적인 예시는 지정한 웹사이트만 프록시로 보내는 규칙 작성법을 참고하세요. 로컬 진입점에 연결되는지와 대상에 PROXY가 적용되는지는 서로 다른 단계이므로 테스트 결과도 각각 기록해야 합니다.

변경 사항의 공통 확인 및 복구 순서

Settings를 변경한 뒤에는 먼저 직접 영향을 받는 기능을 검증하고 자주 사용하는 다른 접속도 그대로인지 확인하세요. 변경 전후 값, 네트워크 조건, 결과를 기록하고 명확한 개선이 없는 변경은 되돌립니다. 동기화와 자동 연결을 함께 다룬다면 로컬 구성을 먼저 안정화하고 동기화된 내용을 확인한 다음 마지막으로 On Demand를 켜세요. 구성이 계속 바뀌는 중에 자동 실행 결과를 최종 검증으로 오해하지 않도록 하는 순서입니다.

계속 문제를 확인해야 한다면 이 페이지의 적용 범위, DNS, 테스트, 로그 순서로 살펴보고 빠른 시작 가이드를 통해 최소한의 정상 작동 절차를 다시 구성하세요. 구매, 복원, 기기 요구 사항은 구매 안내를 확인하고 계정 문제를 네트워크 설정 변경으로 해결하려 하지 마세요. 이 가이드의 권장 사항은 현재 앱 화면과 함께 적용해야 합니다. 변경 목적을 설명할 수 있고, 결과를 재현해 검증하며, 되돌릴 방법까지 확보해야 설정 변경이 완료된 것입니다.