Shadowrocket Settings 설정 가이드

01 · Settings의 현재 값과 Global Routing

Shadowrocket 하단의 Settings를 열어 목록의 그룹과 항목 이름을 확인한 뒤 해당 세부 항목으로 이동하세요. 설정 항목의 위치와 표시 내용은 현재 앱을 기준으로 합니다. 특정 옵션이 보이지 않는다면 이름이 비슷한 항목을 대체 항목으로 간주하지 마세요. Home에서는 현재 서버와 연결 기능을, Config에서는 구성 파일과 그 안의 규칙을 관리합니다. Settings에는 앱 동작 및 도구 관련 설정이 모여 있습니다. 이 세 영역은 모두 연결에 영향을 주지만 같은 단계의 제어 기능은 아니므로, 문제를 확인할 때 각각 따로 기록하세요.

변경 전에 복구 가능한 기준 상태 기록

먼저 현재 네트워크가 Wi-Fi인지 셀룰러인지, Home에서 선택한 서버, Global Routing 상태, Config에서 사용 중인 파일 이름을 적어 두세요. 그런 다음 변경할 항목과 기존 값, 예상 결과를 기록합니다. 예를 들어 막연히 “네트워크가 더 빨라짐”이라고 적기보다 “지정한 Wi-Fi로 다시 연결했을 때 자동 연결이 더 이상 시작되지 않음”처럼 구체적으로 작성하세요. 기존 값이 자동, 빈 값 또는 상속 상태라면 그대로 기록합니다. 빈 값이 반드시 꺼짐을 뜻하지는 않으며 구성 파일이나 시스템에 처리를 맡긴 상태일 수 있습니다.

‘기본값’은 세 가지 출처를 구분해야 합니다. 처음 사용할 때 앱이 설정한 초기값, 가져온 구성 파일에 명시된 값, 이전에 저장되어 동기화되었을 수도 있는 값입니다. 화면에 표시된 현재 값만으로는 어느 출처인지 알 수 없습니다. 여러 기기에서 일관되게 확인할 수 없는 항목은 이 가이드에서 ‘현재 정상 작동하는 값 유지’를 권장합니다. 특정 포트, 테스트 주소 또는 스위치 상태가 모든 기기에 적합하다고 단정하지 않습니다. 이렇게 하면 기존 요구 사항을 덮어쓰지 않고, 각 변경과 실제 결과의 관계를 확인할 수 있습니다.

Global Routing의 세 가지 모드

Home에서 Global Routing을 확인하세요. Config, Proxy, Direct는 각각 구성 규칙에 따른 라우팅, 프록시 경유, 직접 연결을 뜻합니다. Config는 현재 구성 파일의 규칙에 따라 정책을 선택합니다. Proxy는 문제가 라우팅 선택과 관련 있는지 임시로 확인할 때 적합합니다. Direct는 선택한 프록시 서버를 거치지 않을 때의 접속 상태를 살펴보는 데 사용합니다. 세 가지는 라우팅 동작을 선택하는 모드이지 연결 품질 등급이 아니며, 올바른 서버 매개변수를 대신하지도 않습니다. 비교 테스트 후에는 원래 필요한 모드로 되돌려 임시 진단 상태를 계속 사용하지 않도록 하세요.

한 번에 한 가지를 바꾸고 결과 확인

한 번에 변수 하나만 변경한 뒤 같은 요청을 다시 실행하세요. DNS, 서버, Global Routing을 동시에 바꾸면 페이지가 다시 열리더라도 어떤 항목이 영향을 주었는지 알 수 없습니다. 테스트에는 새 페이지를 열거나 연결을 다시 설정하는 과정이 포함되어야 합니다. 이미 로드된 콘텐츠만 확인하면 안 됩니다. 브라우저 캐시, 기존 연결, 앱의 백그라운드 상태가 변화를 가릴 수 있습니다. 새 세션을 시작해야 변경 사항이 적용된다면 먼저 연결을 중단한 뒤 다시 시작하고, Home에 표시된 현재 항목이 여전히 올바른지 확인하세요.

첫 연결에 필요한 시스템 VPN 구성 승인과 Config 파일의 프록시 규칙은 서로 다릅니다. 시스템 승인은 앱이 해당 네트워크 연결을 만들 수 있도록 허용할 뿐, 서버 정보가 올바르거나 구독을 가져왔음을 뜻하지 않습니다. 스위치는 켤 수 있지만 페이지가 열리지 않는다면 첫 연결 확인 안내에 따라 선택 항목과 테스트 절차를 점검하세요. 목적이 분명하지 않은 고급 스위치는 현재 상태로 유지하는 것이 좋습니다. 기존 값과 변경 이유, 복구 방법을 설명할 수 있어야 관리 가능한 설정 변경이 완료된 것입니다.

02 · DNS: 해석 출처, 구성 범위 및 문제 진단

먼저 Settings에서 DNS 관련 항목을 살펴본 다음 Config에서 현재 구성 파일을 열어 DNS 설정이 있는지 확인하세요. 구체적인 항목은 실제 화면을 기준으로 합니다. 각 메뉴가 DNS 동작과 구성 내용을 따로 제어할 수도 있습니다. DNS는 도메인 이름을 주소로 변환하며, 그다음에 연결 대상 주소와 경로 선택, 상위 요청 처리가 이어집니다. 따라서 ‘도메인이 해석된다’와 ‘웹페이지가 열린다’는 서로 다른 결과이며, 하나만으로 다른 하나를 입증할 수 없습니다.

먼저 설정의 출처 확인

구성 파일의 General 영역에서 DNS 서버를 지정할 수 있습니다. 아래 예시는 시스템 DNS를 사용하는 방식이며, 모든 구성의 기본값을 나타내거나 기존 파일을 바꾸라는 의미가 아닙니다. 현재 파일에 해당 항목이 있는지 먼저 확인하세요. 같은 매개변수를 중복으로 추가하면 관리와 문제 확인이 어려워집니다. 원격 콘텐츠가 갱신되는 파일이라면 직접 수정한 내용이 다음 업데이트에서 바뀔 수 있습니다. 별도의 복사본을 저장한 다음, 어떤 파일을 일상적으로 사용할지 결정하세요.

[General]
# 예시: 시스템 DNS 사용. 기본값을 뜻하지 않음
dns-server = system

[Rule]
# 예시 도메인은 PROXY를 통해 연결
DOMAIN-SUFFIX,example.com,PROXY
# 사설 주소 범위는 DIRECT를 통해 연결
IP-CIDR,192.168.0.0/16,DIRECT
# 그 외 요청은 PROXY를 통해 연결
FINAL,PROXY

화면에서 설정 항목을 편집할 수 있다고 해서 Config의 모든 내용을 반드시 덮어쓴다고 가정하지 마세요. 화면에 설명, 상속 상태 또는 적용 범위가 표시된다면 이를 우선 기준으로 삼으세요. 명확한 안내가 없다면 현재 구성 파일의 복사본으로 변수 하나씩 테스트하고 요청 기록을 확인하세요. 권장 값은 특정 DNS 주소가 아니라 현재 네트워크와 구성 요구를 충족하고 반복 테스트로 작동이 확인된 출처입니다. 이미 DNS 해석이 정상이라면 추상적인 지표를 높이기 위해 모든 설정을 바꿀 필요는 없습니다.

DNS 문제와 연결 문제 구분

진단할 때는 평소 접속할 수 있는 도메인 하나를 선택해 해석 결과가 반환되는지 기록하고, 연결이 시간 초과되는지 확인하세요. 모든 도메인이 해석되지 않는다면 현재 네트워크, DNS 출처의 접근 가능 여부, 구성 항목의 오타를 우선 확인합니다. 특정 도메인만 문제라면 도메인 레코드, 캐시 또는 해당 도메인에 적용되는 규칙을 확인하세요. DNS 해석은 정상이지만 연결에 실패한다면 선택한 서버, 대상 서비스, 라우팅을 계속 확인하세요. DNS 문제와 무관한 오류를 해결하려고 DNS를 계속 바꾸지 마세요.

일부 규칙은 도메인 정보를 사용하고, 다른 규칙은 목적지 주소를 기준으로 판단합니다. 도메인 해석 결과로 여러 주소가 반환될 수 있고, 접속 과정에서 여러 도메인을 거칠 수도 있습니다. 따라서 페이지를 한 번 열었을 때 서로 다른 정책이 나타나더라도 설정이 반드시 실패한 것은 아닙니다. 확인할 때는 페이지 이름만 보지 말고 같은 새 요청의 도메인, 목적지 주소, 일치한 규칙을 대조하세요. IPv6도 현재 네트워크와 대상이 지원하는지 먼저 확인한 뒤 관련 해석 및 주소 규칙을 살펴보세요. 특정 주소 유형을 끄는 것을 일반적인 첫 단계로 권장하지 않습니다.

캐시, 네트워크 전환 및 권장 방법

DNS 출처를 바꾼 뒤에도 이전 캐시나 이미 설정된 연결이 계속 사용될 수 있습니다. 기존 요청을 종료하고, 필요하면 다시 연결한 뒤 새 페이지에 접속하세요. 현재 화면에 캐시 삭제 도구가 있다면 해당 도구의 안내에 따라 사용합니다. 특정 도메인 문제를 해결하려고 모든 구성을 삭제하지 마세요. Wi-Fi와 셀룰러 네트워크를 전환하면 시스템이 사용하는 DNS 출처와 접근 가능성도 달라질 수 있습니다. 한 네트워크에서의 결과가 다른 네트워크에도 그대로 적용되지는 않으므로 테스트 기록에 네트워크 환경을 항상 포함하세요.

추가 연결 절차가 필요한 DNS 방식을 사용한다면 해당 DNS 서비스로 연결되는 경로도 고려해야 합니다. 주소를 얻기 위해 먼저 특정 도메인에 접속해야 하는 방식은 초기 DNS 해석을 복잡하게 만들 수 있습니다. 시간 초과가 발생하면 대상 웹사이트만 확인하지 말고 이 의존 관계도 점검하세요. 검증된 간단한 구성으로 시작한 다음 실제 요구에 따라 옵션을 추가하는 것이 좋습니다. 복구할 때는 기존 DNS 항목을 되돌리고 연결을 다시 설정하세요. 중복된 구성이 남아 있지 않은지도 확인해야 변경 전 상태로 돌아왔는지 판단할 수 있습니다.

03 · On Demand: 조건 트리거와 수동 연결

Settings에서 On Demand로 이동해 전체 스위치를 확인한 다음 현재 구성의 네트워크 조건과 각 조건에 지정된 동작을 살펴보세요. On Demand는 조건에 따라 연결 동작을 관리하는 기능이지 서버 속도를 높이거나 누락된 서버 정보를 자동으로 채우는 기능이 아닙니다. 설정 전에 같은 서버가 수동 연결에서 정상 작동하는지 확인하세요. 그렇지 않으면 조건 트리거와 서버 오류가 겹쳐 자동 연결 실패 원인을 파악하기 어려워집니다.

조건을 먼저 정하고 동작 선택

일반적인 조건은 Wi-Fi, 지정된 SSID 또는 셀룰러 네트워크 등 네트워크 환경을 기준으로 합니다. 실제 화면에서 선택할 수 있는 항목을 기준으로 일치 대상과 동작을 하나씩 확인하세요. ‘특정 네트워크 포함’을 ‘그 외 모든 네트워크 제외’로 해석하지 마세요. SSID는 Wi-Fi 네트워크 이름이지 서버 이름이 아닙니다. 입력할 때 대소문자, 공백, 기기에 표시되는 전체 문구를 확인하세요. 이름이 같아도 실제 환경이 다른 네트워크는 이름만으로 차이를 모두 표현할 수 없으므로 수동으로 연결을 점검하는 습관을 유지하세요.

먼저 검증하기 쉬운 조건 하나만 설정하는 것이 좋습니다. 예를 들어 셀룰러 네트워크에서 자주 사용하는 Wi-Fi로 전환했을 때 예상한 동작이 나타나는지 확인한 뒤 다음 조건을 추가하세요. 처음부터 서로 영향을 주는 조건을 여러 개 설정하면 예상치 못한 연결이 발생했을 때 어떤 조건이 작동했는지 알기 어렵습니다. 목록의 항목이 생각한 순서대로 모두 누적 적용된다고 가정하지 마세요. 현재 화면의 안내를 읽고 우선순위를 파악한 뒤 실제 네트워크 전환으로 확인하세요. 설명되지 않은 동작은 추측으로 보완하지 않는 편이 좋습니다.

중지 후 다시 연결되는 이유

수동으로 중지한 뒤 연결이 다시 시작되면 시스템에서 VPN 구성을 반복해서 삭제하기보다 먼저 On Demand로 돌아가 적용 가능한 조건이 남아 있는지 확인하세요. 시스템은 활성화된 On Demand 조건에 따라 새 네트워크 요청에 응답할 수 있으므로, 한 번 연결을 중지하는 것과 자동 트리거를 끄는 것은 다릅니다. 잠시 수동으로만 점검하려면 먼저 On Demand를 비활성화한 다음 연결을 중지하고, 새 요청이 다시 트리거되는지 확인하세요. 점검이 끝나면 기록한 조건을 원래대로 복원합니다.

네트워크 전환은 순간적으로 완료되지 않습니다. 기기가 기존 연결을 끊고 주소와 DNS 정보를 받은 다음 새 연결을 설정할 수 있습니다. 이 중간에 잠시 접속할 수 없더라도 조건 설정이 잘못되었다고 단정하지 마세요. Wi-Fi 또는 셀룰러 네트워크가 안정된 뒤 요청을 다시 실행하고, Home에서 현재 선택된 서버가 예상한 항목인지 확인하세요. On Demand는 연결을 트리거하는 기능이지 네트워크를 전환할 때마다 다른 서버를 대신 선택하는 기능이 아닙니다.

화면 잠금, 백그라운드 및 복구 확인

잠금 화면과 백그라운드 실행은 시스템 스케줄링 및 네트워크 상태의 영향을 받습니다. 앱이 계속 전면에 표시되는지 여부만으로 연결 상태를 판단하지 마세요. 오랫동안 화면을 잠근 뒤에만 문제가 발생한다면 잠금 해제 시점의 네트워크, 연결 상태, 첫 새 요청을 기록하고 일반적인 네트워크 전환 테스트와 비교하세요. 백그라운드 동작을 확인하려고 스위치를 빠르게 연속해서 바꾸지 마세요. 상태 변화가 늘어나 트리거 경로를 파악하기 더 어려워집니다. 한 번의 테스트에는 네트워크가 안정되고 요청이 완료될 때까지 시간을 두세요.

기본 상태와 관련해 이 페이지는 현재 보이는 On Demand 스위치를 새로 설치한 모든 기기의 공통 초기값으로 간주하지 않습니다. 기기에 기존 구성이 남아 있을 수 있기 때문입니다. 자동 연결이 필요하지 않다면 수동 제어를 유지하는 것이 좋습니다. 필요하다면 명확한 상황을 다루는 최소한의 조건만 설정하고 비활성화 방법도 기록하세요. 예상하지 못한 동작이 발생하면 먼저 전체 스위치를 끄고 수동 연결이 정상인지 확인한 다음 조건을 하나씩 다시 활성화하세요. 여러 예외를 한꺼번에 설정한 뒤 충돌을 찾는 것보다 이 복구 경로를 유지하는 편이 안전합니다.

04 · Ping 및 Connectivity Test: 테스트 대상과 결과의 한계

먼저 Settings에서 Ping 관련 설정을 확인해 현재 제공되는 테스트 방법과 대상을 살펴보세요. 그런 다음 Home으로 돌아가 서버 목록의 테스트 결과를 확인합니다. 구체적인 옵션은 앱에 실제로 표시되는 내용을 기준으로 하며, 숫자 하나만 보고 어떤 테스트가 사용되었는지 단정할 수 없습니다. 일상적인 설명에서는 Ping을 지연 시간 테스트 전반을 가리키는 말로 쓰기도 하지만, 방법마다 측정하는 단계가 다를 수 있습니다. 주소 접근 가능 여부, 포트 연결 여부, 지정된 대상에 요청을 보내는 과정 등을 측정할 수 있으므로 결과를 한데 섞어 순위를 매기지 마세요.

수치가 의미하는 것

한 번의 테스트는 해당 시점, 네트워크, 방법에서의 일부 상태만 보여 줍니다. 테스트 대상, DNS, 프로토콜 핸드셰이크, 서버 응답이 결과에 영향을 줄 수 있으므로 수치가 낮다고 웹페이지가 더 빨리 열린다고 보장할 수 없고, 수치가 높다고 연결을 사용할 수 없는 것도 아닙니다. 특정 탐지 방식에서 응답이 없더라도 실제 페이지가 정상적으로 열린다면 먼저 그 방식의 적용 범위를 고려하세요. 반대로 포트 연결에 성공해도 인증, 상위 프로토콜, 최종 대상 요청이 모두 성공한다고 볼 수는 없습니다.

테스트 매개변수를 변경하기 전에 기존 방법과 대상을 기록해 이전 결과와 새 결과를 같은 데이터로 잘못 비교하지 않도록 하세요. 테스트 대상을 직접 입력한다면 지속적으로 접근할 수 있고 테스트 방식에 적합한 주소를 사용하세요. 구독 주소를 테스트 대상으로 쓰거나 접근 자격 증명이 포함된 링크를 입력하지 마세요. 테스트 주소는 탐지를 위한 것이지 서버를 가져오기 위한 것이 아닙니다. 시간 초과 설정은 우선 현재 값을 유지하는 것이 좋습니다. 너무 짧으면 정상적인 변동을 실패로 기록할 수 있고, 너무 길면 응답이 없을 때 대기 시간이 늘어납니다.

목록 테스트와 실제 요청 교차 확인

Home에서 현재 서버 옆의 선택 표시를 확인하고 연결을 켠 뒤 Connectivity Test를 실행하세요. 테스트가 끝나면 실제로 이용하려는 페이지에서 새 요청을 보내세요. 이렇게 하면 ‘목록 탐지 결과’, ‘앱 테스트 완료’, ‘대상 서비스 사용 가능’이라는 세 단계를 구분할 수 있습니다. 목록의 숫자만 확인하고 서버를 선택하지 않으면 이후 요청에 다른 항목이 사용될 수 있습니다. 시스템 VPN 표시만 확인해서도 상위 단계의 접속이 완료되었는지 알 수 없습니다.

서버 두 개를 비교할 때는 같은 네트워크, 같은 테스트 방법, 같은 대상을 유지하고 가능한 한 비슷한 시간에 테스트하세요. 셀룰러 네트워크로 전환하면서 테스트 주소도 바꾼 뒤 그 결과를 서버 자체의 차이로 돌리지 마세요. 결과 변동이 크다면 가장 좋은 결과 하나만 남기기보다 몇 번 반복해 안정적으로 완료되는지 확인하세요. 선택 방법은 지연 시간, 지역 및 프로토콜 유형 판단 안내를 참고하세요. 이 안내에서도 수치와 실제 사용 경험을 구분합니다.

권장 테스트 기준 설정 방법

이 가이드는 모든 기기에서 공통으로 사용할 테스트 대상이나 시간 초과 값을 지정하지 않으며, 현재 저장된 값을 앱의 기본값이라고 부르지도 않습니다. 실제 목적을 확인할 수 있는 방법을 선택하세요. 최종 웹페이지 요청을 확인하려면 더 앞 단계의 연결 테스트에 그치지 말고 실제 접속도 검증해야 합니다. 장기간 사용할 테스트 기준을 하나 정해 두면 네트워크 변화를 파악하기 쉽습니다. 대상을 자주 바꾸면 이전 기록과 비교하기 어려워집니다.

Connectivity Test 결과와 실제 페이지 상태가 다르면 두 요청이 같은 라우팅을 거치는지, 서로 다른 도메인에 접속하는지, 테스트 대상이 응답하는지 확인하세요. 특정 대상의 점검이나 일시적인 장애가 모든 접속의 실패를 뜻하지는 않습니다. 복구할 때는 테스트 방법과 대상을 원래대로 돌리고 서버를 다시 선택한 다음 같은 요청을 실행하세요. 시간, 네트워크, 방법, 대상, 결과를 함께 기록하면 지연 시간 하나만 저장하는 것보다 문제를 판단하는 데 도움이 됩니다.

05 · Log 및 Data: 요청 기록으로 설정 문제 파악

Settings에서 Log 관련 설정을 확인한 뒤 현재 화면에 제공되는 메뉴를 통해 로그 또는 요청 기록을 여세요. Data에 표시되는 데이터도 실제 화면을 기준으로 확인합니다. Log는 요청이 어떤 처리를 거쳤는지 파악하는 데 적합하고, Data는 연결 및 트래픽 상태를 살펴보는 데 도움이 됩니다. 둘 다 청구 내역이나 서비스 제공업체의 통계와 혼동하지 마세요. 문제를 확인하기 전에 발생 시간과 요청 대상을 먼저 정한 다음 관련 기록을 열어야 방대한 과거 기록에서 추측으로 원인을 찾는 일을 피할 수 있습니다.

구분하기 쉬운 새 요청부터 만들기

기록을 시작한 뒤 점검할 페이지나 기능 하나만 사용하고 대략적인 시간을 적어 두세요. 여러 앱을 동시에 열면 백그라운드 요청이 빠르게 늘어나 다른 도메인의 오류를 현재 페이지 문제로 오인하기 쉽습니다. 페이지를 불러오는 과정에서 여러 도메인을 사용할 수 있으므로 주 페이지가 성공해도 리소스 요청이 실패하면 콘텐츠가 불완전하게 보일 수 있습니다. 실패 기록 하나를 발견하자마자 모든 설정을 바꾸기보다 같은 작업과 관련된 요청들을 함께 살펴보세요.

기록을 읽을 때는 도메인, 목적지 주소, 일치한 규칙과 정책, 연결 단계의 오류 여부를 차례로 확인할 수 있습니다. 현재 기록에 실제로 표시된 필드만 근거로 삼으세요. 특정 필드가 보이지 않는다고 시스템이 해당 단계를 실행하지 않았다고 추론하지 마세요. 요청이 REJECT에 일치했다면 규칙 의도에 맞는지 먼저 확인하세요. 예상은 PROXY인데 DIRECT에 일치했다면 서버 암호나 테스트 시간 초과를 바로 바꾸기보다 규칙 순서와 Config 선택 여부를 확인하세요.

로그 수준과 보관 범위

로그 수준에 따라 기록의 상세 정도가 달라집니다. 각 수준에 포함되는 구체적인 내용은 앱의 안내를 기준으로 확인하세요. 일상적으로는 기본적인 확인에 충분한 현재 수준을 유지하고, 반복 가능한 문제가 발생했을 때만 잠시 상세 수준을 높인 뒤 점검을 마치면 원래대로 되돌리는 것이 좋습니다. 기록이 많다고 연결이 더 정확해지는 것은 아니며 오히려 필요한 내용을 찾기 어려울 수 있습니다. 상세 기록은 성능 향상 스위치가 아니라 근거를 수집하는 기능이며, 잘못된 규칙이나 서버 매개변수를 수정하는 일을 대신하지 않습니다.

[General]
# 예시: 로그 수준. 앱의 기본값을 뜻하지 않음
loglevel = notify

[Rule]
# 구체적인 도메인 규칙은 더 포괄적인 규칙보다 앞에 배치
DOMAIN-SUFFIX,ad.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
# 그 외 요청은 PROXY 사용
FINAL,PROXY

위 예시에서는 더 구체적인 도메인 규칙을 앞에 배치해 더 넓은 일치 범위에 먼저 가려지지 않도록 했습니다. 규칙은 위에서 아래로 확인되며 일치한 규칙의 정책이 적용됩니다. 따라서 점검할 때는 ‘파일에 이 규칙이 있는가’뿐 아니라 ‘실제로 어느 줄이 적용되었는가’를 확인해야 합니다. REJECT의 적용 범위와 잘못 차단된 요청 처리 방법은 REJECT 규칙 안내에서 확인하세요. 예시 도메인은 문법 설명용이며 실제로 사용할 수 있는 서비스를 의미하지 않습니다.

Data 수치와 민감 정보 처리

Data를 확인할 때는 먼저 통계 범위와 집계 시작 조건을 살펴보세요. 연결 재설정, 앱 재실행, 통계 초기화에 따라 표시 범위가 달라질 수 있습니다. 범위가 서로 다른 두 수치를 단순히 빼서 특정 앱의 사용량이라고 해석하지 마세요. 소량의 트래픽은 데이터 교환이 있었다는 뜻일 뿐, 대상 페이지가 완전히 열렸다는 증거는 아닙니다. 눈에 띄는 변화가 없더라도 요청 캐시가 원인일 수 있습니다. Data는 로그 및 실제 요청과 함께 판단하는 보조 자료로 사용하세요.

로그에는 도메인, 주소, 요청 경로, 구독 정보 또는 기타 접속 세부 정보가 포함될 수 있습니다. 문제 해결 자료를 저장할 때는 먼저 원본을 로컬에 보관하고, 접근 자격 증명과 관련 없는 내용을 삭제한 검토용 사본을 만드세요. 구독 링크 전체를 그대로 공개하지 마세요. 로그를 지우기 전에 필요한 시간과 일치 결과를 기록했는지 확인하세요. 문제를 재현할 수 없다면 기록 수준을 계속 올린 채 무기한 기다리지 마세요. 먼저 정상 설정으로 되돌리고, 다음에 문제가 발생하면 같은 절차로 필요한 최소 범위의 근거를 수집하세요.

06 · Widget: 빠른 조작, 표시 상태 및 시스템 새로고침

먼저 Settings에서 Widget 관련 설정을 살펴본 다음 시스템 위젯 관리 화면에서 기기에 추가할 수 있는 Shadowrocket 위젯을 확인하세요. 선택할 수 있는 크기, 표시 내용, 상호작용 방식은 앱과 시스템에 실제로 제공되는 항목을 기준으로 합니다. 다른 기기의 배치를 이 기기에서도 사용할 수 있다고 가정하지 마세요. Widget은 상태나 빠른 실행 기능을 제공하며 별도의 서버 구성이 아니고, Home의 현재 항목 확인과 연결 점검을 대신하지도 않습니다.

추가 전에 앱 상태 확인

먼저 Home에서 사용할 서버를 선택하고 Global Routing을 확인한 뒤 실제 요청으로 연결을 검증하세요. 그런 다음 Widget을 추가하는 것이 좋습니다. 이렇게 하면 위젯 표시가 예상과 다를 때 서버 설정까지 동시에 의심하지 않고 표시나 빠른 조작 문제로 범위를 좁힐 수 있습니다. 위젯에서 표시 대상을 선택할 수 있다면 현재 항목, 특정 항목 또는 다른 그룹 중 무엇을 가리키는지 확인하세요. 선택 기능이 없다면 지연 시간 결과에 따라 서버를 자동 선택한다고 추측하지 마세요.

추가한 뒤 표시되는 문구가 앱 내부 상태와 일치하는지 확인하고 위젯이 명시적으로 지원하는 동작을 테스트하세요. 일부 메뉴는 먼저 앱을 연 다음 앱에서 후속 동작을 수행할 수 있습니다. 다른 동작을 바로 실행할 수 있는지는 현재 시스템과 위젯의 기능에 따라 다릅니다. 탭했을 때의 반응만 보지 말고 최종 상태를 확인하세요. 대상 서버로 바뀌었는지 확인해야 한다면 Home으로 돌아가 선택 표시를 살펴본 뒤 새 요청을 실행하세요. 앱이 열렸다는 사실만으로 연결 전환이 완료되었다고 판단하지 마세요.

표시가 즉시 갱신되지 않을 수 있는 이유

시스템이 위젯 새로고침과 백그라운드 실행을 관리하므로 Widget은 초 단위로 갱신되는 실시간 모니터링 화면이 아닙니다. 네트워크 전환, 연결 중지, 서버 변경 직후에는 이전 상태가 계속 표시될 수 있습니다. 오래된 표시를 보고 반복해서 누르기보다 Shadowrocket을 열어 먼저 확인한 다음 위젯이 갱신될 때까지 기다리세요. 연결과 중지를 계속 반복하면 실제 상태가 바뀌어 앱과 위젯 표시가 더 자주 어긋날 수 있습니다.

앱 내부 상태와 실제 요청은 정상인데 위젯만 오랫동안 변화를 반영하지 않는다면 표시 문제로 점검하세요. 위젯이 Shadowrocket 위젯인지 확인하고 위젯 설정을 살펴본 뒤 앱에 다시 들어가거나 위젯을 다시 추가해 보세요. 서버와 Config 파일을 첫 단계에서 삭제하지 마세요. 앱에서도 연결할 수 없다면 Home, On Demand, 네트워크 점검 절차로 돌아가야 합니다. 위젯을 다시 추가해도 서버 인증이나 DNS 오류가 해결되지는 않습니다.

On Demand와 함께 사용할 때의 동작

Widget의 수동 조작과 On Demand의 조건 트리거가 차례로 발생할 수 있습니다. 예를 들어 빠른 메뉴로 연결을 중지한 뒤 시스템이 적용 가능한 조건에 따라 다시 연결할 수 있습니다. 이때는 위젯이 고장 났다고 판단하기보다 On Demand를 확인하세요. 빠른 조작을 테스트할 때는 On Demand를 잠시 비활성화해 수동 동작을 확인한 다음 조건을 복원해 함께 테스트하는 것이 좋습니다. ‘빠른 메뉴가 동작했는지’와 ‘이후 다른 조건이 상태를 바꾸었는지’를 구분해야 원인을 파악할 수 있습니다.

잠금 화면에 표시되는 정보는 개인 정보 보호 측면도 고려해야 합니다. 위젯에 서버 이름이나 연결 상태가 표시된다면 다른 사람에게 공개하고 싶지 않은 정보가 이름에 포함되어 있는지 확인하세요. 서버 메모는 항목을 구별하는 데 도움이 되지만 암호, 전체 구독 주소 또는 다른 접근 자격 증명을 적지 마세요. 이름은 로컬 관리용 표시일 뿐이며 메모를 바꿔도 서버 주소나 프로토콜 매개변수는 바뀌지 않습니다. 수정한 뒤에는 Home에서 선택 항목을 다시 확인해 이름이 같은 항목을 혼동하지 않도록 하세요.

기본값과 권장 사항으로 특정 위젯 크기나 레이아웃을 지정하지 않으며, 위젯이 보이지 않는다고 설치 실패로 간주하지 않습니다. 실제로 필요한 표시 기능이나 빠른 실행 항목만 추가하고 앱 내부에서 확인하는 경로를 유지하세요. 시스템 요구 사항과 지원 여부는 App Store 페이지에 표시된 내용 및 기기의 실제 화면을 기준으로 확인하세요. Widget 설정을 되돌릴 때는 먼저 위젯을 제거하고 앱 구성을 그대로 둔 상태에서 일상 연결이 정상인지 확인한 뒤 하나씩 다시 추가할 수 있습니다. 이처럼 범위를 나누면 앱 전체를 초기화하는 것보다 기존의 정상 환경을 보존하기 쉽습니다.

07 · iCloud 및 Config: 동기화 범위, 백업 및 파일 업데이트

먼저 Settings에서 iCloud 관련 항목을 확인하고 동기화 범위에 관한 현재 화면의 설명을 읽으세요. 그런 다음 Config에서 이 기기의 파일을 확인합니다. 동기화 가능 여부는 시스템 iCloud 상태, 앱 접근 권한, 네트워크 조건에도 영향을 받습니다. 스위치를 켰다고 모든 데이터가 즉시 다른 기기로 전송된다고 생각하지 마세요. Home, Config, 통계 기록, 시스템 승인이 같은 범위로 동기화된다고 가정해서도 안 됩니다. 화면에 명시된 내용을 기준으로 확인하세요.

동기화 전에 확인 가능한 복사본 저장

동기화를 켜거나 조정하기 전에 현재 파일 이름을 정리하고, 어떤 파일을 사용 중인지 기록하세요. 앱에서 제공하는 저장 또는 내보내기 기능으로 복구 가능한 복사본을 보관하는 것이 좋습니다. 파일 이름에 ‘일상 규칙’ 또는 ‘점검용 복사본’처럼 용도를 표시할 수 있지만 검증되지 않은 효과를 암시해서는 안 됩니다. 파일을 복사하는 것만으로 백업이 완료된 것은 아닙니다. 복사본을 다시 열어 General, Rule 등 필요한 영역이 제대로 들어 있는지 확인하세요.

동기화와 백업은 목적이 다릅니다. 동기화는 연결된 기기에서 해당 내용을 공유하도록 하며 잘못된 수정도 함께 전파될 수 있습니다. 백업은 수정 전 상태를 복원하기 위한 것입니다. 따라서 두 기기에서 같은 파일을 동시에 편집하기 전에 어느 파일을 기준으로 삼을지 먼저 정하세요. 충돌 안내가 뜨거나 같은 이름의 복사본이 있다면 각각 저장하고 규칙 내용을 비교하세요. 파일 이름만 보고 덮어쓰기를 선택하지 마세요. 이름이 같아도 내용이 같다는 보장은 없으며 기기에서 마지막으로 연 파일이 남기려는 버전이라고 단정할 수도 없습니다.

Config 업데이트와 로컬 수정의 범위

Config에서 현재 활성화된 파일을 확인한 뒤 원격 콘텐츠에서 가져온 파일인지, 업데이트 메뉴가 있는지 살펴보세요. 원격 구성 업데이트와 Home의 Subscribe 업데이트는 대상이 다릅니다. 전자는 규칙과 구성 내용을, 후자는 가져온 서버 정보를 다룹니다. 둘 다 연결에 영향을 줄 수 있지만 각각 따로 확인해야 합니다. 구독 링크는 서비스 제공업체에서 받으세요. 가져온 뒤에는 일반 웹 주소처럼 공개적으로 공유하지 말고 동기화 편의를 위해 공개 메모에 적지도 마세요.

원격 구성을 직접 수정하기 전에 다음 업데이트에서 수정 내용이 덮어써질 수 있는지 고려하세요. 장기간 유지할 사용자 규칙은 별도의 관리 가능한 복사본에 보관하고 업데이트 출처와 병합 방법을 명확히 기록하는 것이 좋습니다. 앱에서 다른 관리 방법을 제공한다면 안내에 따라 사용하세요. 모든 로컬 내용이 자동으로 유지된다고 경험에만 의존하지 마세요. 업데이트 후에는 주요 규칙과 최종 정책을 확인한 다음 실제 요청을 실행하세요. 업데이트 작업이 끝났는지만 확인해서는 안 됩니다.

기기 변경 및 동기화 문제 확인 순서

다른 기기에 예상한 내용이 나타나지 않으면 먼저 시스템 계정과 iCloud 사용 가능 여부를 확인하세요. 그런 다음 Shadowrocket 관련 권한과 앱 내부 스위치를 점검하고, 네트워크가 안정된 뒤 다시 확인합니다. 동기화를 반복해서 켜고 끈 다음 로컬 파일을 곧바로 삭제하지 마세요. 유일한 완전한 복사본이 사라질 위험이 있습니다. 두 기기에서 일부 내용만 다르다면 동기화 실패를 논하기 전에 해당 내용이 명시된 동기화 범위에 포함되는지 확인하세요. 범위에 포함되지 않는 항목은 앱에서 제공하는 방법으로 별도 처리해야 합니다.

앱을 다시 받는 절차와 앱 내부 데이터를 복원하는 절차도 구분해야 합니다. 구매한 앱은 App Store에서 다시 받을 수 있으며 구체적인 단계는 구매 항목 복원 안내를 확인하세요. 서버, 규칙, 시스템 연결 승인은 각각 다시 점검해야 합니다. 구독 그룹이 여러 개라면 여러 구독 관리 안내를 참고해 중복 항목을 정리할 수 있습니다. 새 기기의 확인이 끝날 때까지 기존 기기의 사용 가능한 구성을 보존하고 두 기기에서 동시에 편집하지 마세요. 기준 상태가 일치한 뒤 일상적인 동기화를 재개하는 것이 좋습니다.

08 · Proxy 포트: 수신 범위 및 설정 복원 확인

Settings에서 Proxy 관련 항목을 확인하고 로컬 프록시 수신, 연결 공유 또는 실제로 제공되는 다른 설정을 구분하세요. 항목 이름과 지원 범위는 현재 화면을 기준으로 합니다. 여기의 로컬 포트는 Add Server에 입력하는 원격 서버의 Port와 다릅니다. 전자는 이 기기의 프록시 진입점이 연결을 받는 방식을 나타내고, 후자는 클라이언트가 원격 서비스에 연결할 포트를 나타냅니다. 두 값을 같은 숫자로 바꾼다고 연결이 더 정확해지지는 않으며 기존 설정이 손상될 수 있습니다.

로컬 수신이 실제로 필요한지 먼저 판단

일상적으로 Home의 스위치로 Shadowrocket을 사용하고 별도의 로컬 프록시 사용 목적이 없다면 Proxy 항목이 보인다는 이유만으로 추가 수신을 켜지 마세요. 연결하는 쪽에서 어떤 프록시 프로토콜을 지원하는지, 어느 주소와 포트에 연결해야 하는지 명확히 알고 있을 때만 조정하는 것이 좋습니다. HTTP와 SOCKS5는 연결 방식이 다릅니다. 연결하는 쪽에서 프로토콜을 잘못 선택하면 포트에 접근할 수 있어도 요청을 완료하지 못할 수 있으므로 포트 숫자 하나만 확인해서는 안 됩니다.

로컬 루프백 주소는 일반적으로 기기 내부에서만 접근할 수 있음을 뜻합니다. 현재 화면에 로컬 네트워크 공개 옵션이 있다면 적용 범위와 위험이 달라집니다. 활성화하기 전에 네트워크를 신뢰할 수 있는지, 어떤 기기가 접속할 수 있는지, 화면에서 인증이나 접근 제한을 제공하는지 확인하세요. 같은 Wi-Fi에 연결된 기기를 모두 신뢰할 수 있다고 간주하지 말고, 점검을 편하게 하려고 공용 네트워크에서 수신 범위를 넓히지 마세요. 분명한 요구가 있다면 필요한 최소 범위만 사용하고 작업이 끝나면 원래대로 복원하세요.

포트, 주소 및 충돌 점검

포트는 유효한 숫자여야 하며 연결하는 쪽에 입력한 값과 일치해야 합니다. 수신을 시작할 수 없다면 스위치 상태, 입력 형식, 포트 충돌 여부를 확인한 뒤 앱에 표시되는 실제 안내를 살펴보세요. 포트를 무작위로 연속해서 바꾼 뒤 우연히 한 번 성공한 값만 남기지 마세요. 값을 바꿀 때마다 연결하는 쪽도 함께 수정하고 변경 전후의 값을 기록해야 합니다. 여러 기기에서 확인되지 않은 기본 포트 숫자는 추측해 제시하지 않습니다. 현재 화면과 관련 안내를 확인하고 검증 가능한 기존 값을 유지하세요.

주소도 사용 범위에 맞아야 합니다. 기기 내부에서 연결할 때와 다른 기기에서 연결할 때 사용하는 주소를 구분 없이 그대로 복사해서는 안 됩니다. Wi-Fi에서 기기가 할당받은 주소는 네트워크에 따라 바뀔 수 있어 어제 저장한 접속 주소가 오늘은 맞지 않을 수 있습니다. 네트워크를 전환한 뒤에만 문제가 생긴다면 원격 서버 매개변수를 바로 바꾸기보다 현재 주소와 네트워크 격리 조건을 확인하세요. 추가 수신을 끈 뒤 기존 수동 연결이 정상인지 확인하면 문제 범위를 좁히는 데 도움이 됩니다.

규칙과 전체 검증 경로로 돌아가기

연결이 앱에 들어온 뒤에도 현재 Global Routing과 Config에 따라 정책을 확인해야 합니다. 아래 예시는 규칙 순서를 설명합니다. 먼저 지정 도메인과 사설 주소를 처리하고, 다음으로 지역 규칙을 적용한 뒤 마지막에 FINAL을 사용합니다. GEOIP는 주소 및 관련 데이터에 따라 일치하므로 웹페이지의 언어나 서버 이름을 뜻하지 않습니다. 이 예시는 문법 교육용이며 전체 파일을 확인 없이 덮어쓰지 마세요. 특히 기존 구성에 필요한 예외 규칙이 있는지 점검해야 합니다.

[Rule]
# 지정 도메인은 PROXY 사용
DOMAIN-SUFFIX,example.com,PROXY
# 사설 주소 범위는 DIRECT 사용
IP-CIDR,192.168.0.0/16,DIRECT
# 해당 주소 데이터에 일치하면 DIRECT 사용
GEOIP,CN,DIRECT
# 앞선 규칙에 일치하지 않을 때 PROXY 사용
FINAL,PROXY

조정이 끝나면 현재 네트워크, Home의 선택 항목, Global Routing, Config, On Demand, 방금 수정한 Proxy 항목을 순서대로 확인한 뒤 새 요청을 실행하고 기록을 살펴보세요. 이 순서로 ‘진입점이 연결되지 않음’, ‘규칙 선택이 예상과 다름’, ‘원격 연결 실패’를 구분할 수 있습니다. 로컬 연결 요청 하나가 실패했다고 DNS, 동기화, 모든 서버를 동시에 초기화하지 마세요. 최근 변경한 범위로 영향을 한정해야 정상 작동하는 기준 상태를 보존할 수 있습니다.

결과를 계속 설명할 수 없다면 기록한 기존 값으로 되돌리고 이번에 추가한 수신이나 조건을 비활성화한 뒤 변경 전 경로를 다시 확인하세요. 복구되었다면 이번 변경과 문제가 관련 있다는 뜻이지만, 특정 매개변수 하나가 반드시 잘못되었다는 증거는 아닙니다. 변수 하나씩 다시 테스트해야 합니다. 따라서 일상적인 권장 설정은 고정된 숫자표가 아니라 재현 가능한 상태를 뜻합니다. 필요한 기능이 활성화되어 있고, 적용 범위가 분명하며, 기존 값을 복구할 수 있고, 실제 요청으로 검증할 수 있어야 합니다. 첫 연결 절차는 빠른 시작 가이드를, 구매 및 호환성 문제는 App Store 정품 안내를 확인하세요. 네트워크 설정으로 관련 없는 문제를 해결하려 하지 마세요.