SETTINGS REFERENCE · 공식 가이드

Shadowrocket 설정 가이드Settings 항목별 설명

설정이 어디에 적용되는지 먼저 확인한 뒤 변경 여부를 결정하세요. 장별로 항목의 의미와 기본 상태 확인 방법, 권장 설정 및 복원 방법을 살펴봅니다.

이 페이지는 설정을 체계적으로 확인하기 위한 안내이며, 최초 연결 절차를 대신하지 않습니다. 아직 가져오기와 연결을 완료하지 않았다면 먼저 사용 안내를 읽고, 완료한 뒤 이 페이지에서 설정을 확인하세요. 아래 절차는 사용자가 자신의 구독 또는 서버 정보를 보유하고 있음을 전제로 합니다.

기본값은 현재 앱에 표시된 값을 기준으로 확인 한 번에 한 종류의 설정만 변경 App Store 정품 확인

01 / SCOPE

설정 적용 범위, 기본 상태 및 변경 순서

Shadowrocket의 작동 결과는 여러 요소가 함께 결정합니다. 시스템 네트워크는 서버에 연결할 수 있는지, 서버 항목은 연결 매개변수, Config는 규칙과 관련 설정, Global Routing은 현재 분기 처리 방식을, Settings는 앱 수준의 옵션을 결정합니다. 요청이 실패했을 때 특정 스위치의 위치만 보고 원인을 단정할 수는 없습니다. 먼저 어느 단계에서 실패했는지 파악한 다음 해당 설정을 확인하세요.

앱 설정, Config 및 서버 매개변수 구분하기

Settings의 옵션이 현재 Config의 전체 내용을 뜻하는 것은 아닙니다. 일부 동작은 사용 중인 Config, 프로토콜 기능 및 시스템 권한에도 영향을 받습니다. 이름이 같거나 비슷한 옵션이 여러 위치에 있더라도 항상 서로 덮어쓴다고 가정하면 안 됩니다. 먼저 현재 Config 이름, 서버 이름, 선택된 Global Routing 항목을 기록한 뒤 설정 세부 내용을 확인하세요. 비교할 때는 현재 앱에 실제로 표시되는 항목을 기준으로 삼으세요.

서버 정보에는 보통 주소, 포트, 인증 정보 및 프로토콜별 항목이 포함됩니다. 이는 연결 대상에 관한 정보이므로 분기 처리 결과를 바꾸려고 임의로 수정해서는 안 됩니다. Config의 규칙은 요청을 어떤 정책으로 처리할지 결정합니다. 서버 포트를 로컬 Proxy 포트로 바꾸거나 구독 주소를 Config 파일 주소처럼 사용하는 것은 데이터 종류를 혼동하는 일입니다. 화면에서 저장되더라도 정상적으로 연결된다는 뜻은 아닙니다.

설정 화면의 항목 이름과 순서는 현재 앱 인터페이스에 따라 달라질 수 있습니다. 이 가이드에서는 DNS, On Demand, Ping, Log 등의 영문 이름을 그대로 사용하며, 확인되지 않은 초기 상태를 일률적인 기본값으로 제시하지 않습니다. 이미 사용한 기기에는 이전에 변경한 값이나 동기화 상태가 남아 있을 수 있으므로 ‘현재 표시된 값’과 ‘최초 설치 시 기본값’은 다릅니다. 문제를 해결할 때는 기억에 의존해 기본값으로 되돌리기보다 실제 값을 기록하는 편이 정확합니다.

기본값을 모를 때 권장 설정을 정하는 방법

일반적인 권장 사항은 이미 정상 작동이 확인된 설정을 유지하고, 원인이 분명한 문제에 필요한 항목만 수정하는 것입니다. 서버에서 제공한 프로토콜 매개변수는 보유한 정보와 하나씩 대조하세요. On Demand, 동기화, 로컬 리스닝 같은 선택 기능은 용도와 적용 범위를 먼저 확인한 뒤 사용할지 결정하세요. 권장 설정은 모든 사용자가 그대로 입력해야 하는 숫자 목록이 아니라, 이유를 설명하고 반복 검증할 수 있는 선택입니다.

설정 출처	기본 상태 확인	권장 조치
Settings	현재 앱에 표시된 값 확인	먼저 기록한 뒤 항목별로 변경
Config	현재 선택된 파일 확인	복원할 수 있도록 사본 보관
Add Server	서버 항목과 프로토콜에 따라 결정	보유한 서버 정보와 일치
시스템 권한	시스템 설정에서 확인	시스템 안내에 따라 실제 권한 확인

변경 전에 간단한 기록을 남기세요. 네트워크 종류, 연결 가능 여부, 실패한 대상, 현재 설정을 포함하면 됩니다. 기록에 비밀번호 평문이나 전체 구독 링크를 저장하지 마세요. 특정 Wi-Fi에서만 문제가 발생하면 먼저 다른 사용 가능한 네트워크에서 다시 테스트하세요. 한 대상에서만 실패한다면 우선 일치하는 규칙을 확인합니다. 이렇게 하면 전체 문제와 특정 대상의 문제를 구분할 수 있어 모든 요청에 영향을 주는 설정으로 국소적인 문제를 해결하려는 일을 피할 수 있습니다.

되돌릴 수 있는 변경 절차 만들기

한 번에 한 종류의 변수만 바꾸고 같은 대상을 다시 테스트하세요. 예를 들어 DNS를 테스트할 때는 서버, 라우팅 방식, 규칙을 그대로 유지하고, 서버 매개변수를 테스트할 때는 Config를 동시에 업데이트하지 마세요. 매번 변경 후 저장되었는지 확인하고, 필요하면 연결을 끊었다가 다시 연결해 새 상태를 적용합니다. 결과가 나빠지면 검증되지 않은 변경을 계속 더하기보다 방금 기록한 값으로 먼저 되돌리세요.

백업에는 실제로 복원해야 하는 내용이 포함되어야 합니다. Config만 저장해도 서버 인증 정보까지 보존되는 것은 아니며, 서버 항목을 남겨도 모든 규칙이 보존되는 것은 아닙니다. 내보내거나 복사할 수 있는 내용은 현재 앱의 기능과 출력 범위를 확인한 뒤 직접 관리할 수 있는 위치에 저장하세요. 백업 파일에는 민감한 정보가 들어 있을 수 있으므로 도움을 받기 위해 공개하지 마세요. 동기화 기능도 별도로 확인한 백업을 대신할 수 없습니다.

복원도 가까운 단계부터 차례로 진행하세요. 먼저 최근 변경을 취소하고, Config가 선택되어 있는지 확인한 다음 서버와 로컬 네트워크를 점검합니다. 모든 데이터를 삭제하는 것을 첫 조치로 삼지 마세요. 재정리가 꼭 필요하다면 백업을 읽을 수 있는지, 필요한 정보가 모두 있는지 확인하고 구매 계정의 App Store 상태도 기록해 두세요. 이 설정 가이드의 목적은 모든 옵션을 보기 좋게 맞추는 것이 아니라, 매번 근거를 갖고 변경하도록 돕는 것입니다.

02 / ROUTING

Global Routing: Config, Proxy 및 Direct

Global Routing은 현재 요청에 적용할 전체 처리 방식을 정합니다. 구성, 프록시, 직접 연결은 인터페이스에서 각각 Config, Proxy, Direct로 표시됩니다. 일상적인 규칙 분기에는 검토가 끝난 Config를 사용하는 것이 좋습니다. Proxy와 Direct는 짧은 시간 동안 비교 점검할 때 활용할 수 있지만, 서버 매개변수 문제를 해결하거나 모든 앱 트래픽이 같은 네트워크 조건을 갖는다는 것을 증명하지는 않습니다.

라우팅 방식을 먼저 확인한 다음 규칙 결과 해석하기

Config는 현재 Config 파일의 규칙에 따라 요청을 처리한다는 뜻입니다. Config 파일이 정상이어야 하고, 선택되어 있어야 하며, 규칙에서 참조하는 정책도 올바르게 해석되어야 합니다. 파일을 목록에 가져왔다고 해서 실제로 사용 중인 것은 아닙니다. ‘규칙을 작성했는데 적용되지 않는다’면 먼저 Global Routing이 실제로 Config인지 확인하고, 현재 선택된 파일 이름을 점검한 다음 규칙의 철자와 순서를 확인하세요.

Proxy는 전반적으로 프록시 방향으로 처리하고, Direct는 전반적으로 직접 연결 방향으로 처리합니다. 여기서 ‘전반적’이라는 표현은 라우팅 방식을 뜻하며 시스템의 모든 트래픽에 예외 없이 적용된다는 보장은 아닙니다. 시스템 자체의 연결, 특수한 네트워크 제한, 프로토콜 처리도 결과에 영향을 줄 수 있습니다. 테스트가 끝나면 원래의 Config 상태로 되돌리세요. 그렇지 않으면 이후 규칙 로그를 확인할 때 라우팅 방식의 차이를 규칙 오류로 오해할 수 있습니다.

인터페이스의 영문 이름	한국어 의미	권장 용도
Config	구성	확인된 규칙에 따라 일상적으로 트래픽 분기
Proxy	프록시	프록시 경로가 작동하는지 잠시 비교
Direct	직접 연결	로컬 직접 연결이 가능한지 잠시 비교

현재 선택된 방식은 앱에 표시된 내용을 기준으로 확인하세요. 이 가이드에서는 새로 설치한 기기의 기본 선택 항목을 추정하지 않습니다. 전환 후 특정 대상에 다시 접속할 수 있게 되었더라도 처리 방향 변경이 결과에 영향을 주었다는 뜻일 뿐입니다. DNS, 규칙 일치 여부, 서버 연결도 함께 분석하세요. 모든 요청을 다른 방식으로 계속 처리하도록 바로 바꾸지 마세요. 원래 정상적으로 접속되던 로컬 리소스, 도메인 확인 경로, 연결 출구도 함께 달라질 수 있습니다.

규칙이 적용되는 순서 이해하기

일반적인 규칙은 위에서 아래로 확인하며 앞에서 일치한 규칙에 따라 이후 규칙의 적용 여부가 달라집니다. DOMAIN은 도메인 전체와 정확히 일치시키고, DOMAIN-SUFFIX는 도메인 접미사를, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치시킵니다. IP-CIDR 및 IP-CIDR6는 주소 범위에 적용됩니다. 규칙 유형은 가능한 한 정확하게 선택하세요. 대상 하나를 맞추려고 범위가 너무 넓은 키워드를 사용하면 관련 없는 요청까지 같은 정책으로 처리될 수 있습니다.

GEOIP는 주소의 지역 정보를 바탕으로 판단하며 사용자의 위치를 확인하는 기능은 아닙니다. 특정 웹사이트의 모든 리소스가 해당 지역에 있다고 보장하지도 않습니다. 한 페이지가 여러 도메인과 다양한 지역의 주소에 동시에 요청을 보낼 수 있으므로 ‘주요 페이지가 직접 연결된다’고 해서 ‘모든 하위 리소스도 직접 연결된다’고 볼 수 없습니다. FINAL은 앞선 규칙으로 처리되지 않은 요청에 적용되는 기본 처리입니다. 최종 결과를 확인할 때는 눈에 띄는 앞부분뿐 아니라 기본 처리 정책도 기록하세요.

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

위 조각은 규칙 순서와 정책 작성 방법을 보여주는 예시이며 모든 상황에 적용할 수 있는 완전한 Config가 아닙니다. example.com은 설명용 도메인이고 PROXY와 DIRECT는 규칙 키워드이므로 그대로 둡니다. 기존 Config의 사본에서 해당 부분을 확인하고 같은 섹션을 중복으로 추가하거나 이 조각을 서버 정보처럼 가져오지 마세요. 저장한 뒤 선택된 파일을 다시 확인하고 Log에서 대상이 예상한 규칙에 일치하는지 확인하세요.

특정 요청을 바탕으로 규칙 문제 추적하기

문제 해결을 시작할 때는 같은 문제가 재현되는 대상을 하나 선택하고 실행한 동작과 시간을 기록한 다음 해당 요청의 도메인, 주소, 정책을 확인하세요. Log에서 예상과 다른 상위 규칙이 적용되었다면 해당 규칙의 범위나 순서를 조정합니다. 계속 FINAL에 도달한다면 대상 도메인과 입력한 값이 일치하는지 확인하세요. 리디렉션, 이미지 리소스, API가 서로 다른 도메인을 사용하는 것은 ‘페이지 주소는 맞는데 규칙이 적용되지 않는’ 흔한 원인입니다.

REJECT는 일치하는 요청을 거부한다는 뜻이며 페이지의 모든 콘텐츠를 식별한다는 뜻은 아닙니다. 범위가 너무 넓은 도메인 접미사를 REJECT에 지정하면 로그인, 이미지, API까지 차단될 수 있습니다. 수정 전 원래 규칙을 기록하고, 수정 후에는 페이지가 열리는지만 확인하지 말고 주요 기능을 각각 테스트하세요. 일치 범위와 오차단, 복원 방법은 REJECT 규칙 작성법과 적용 범위에서 확인할 수 있습니다.

권장하는 복원 방법은 원본 파일을 보관하고 사본에서 규칙 하나씩 검증한 뒤 Log를 바탕으로 반영 여부를 결정하는 것입니다. 규칙이 많다고 분기 처리가 자동으로 정확해지는 것은 아닙니다. 용도를 설명할 수 없는 중복 규칙은 오히려 관리 부담을 키웁니다. 테스트를 마친 뒤 Global Routing, 현재 Config, 선택된 서버가 여전히 예상한 조합인지 확인하고 다음 문제 해결의 기준으로 기록하세요.

03 / NAME RESOLUTION

DNS: 확인 경로, 캐시 및 주소 차이

DNS는 도메인을 주소로 변환합니다. 연결 실패는 이름 확인 전이나 확인 도중, 또는 주소를 얻은 후에 발생할 수 있으며 DNS 변경은 그중 일부에만 영향을 줍니다. 우선 현재 정상 작동이 확인된 설정을 사용하고 Config에서 DNS 관련 항목을 확인하세요. 기본값과 선택 가능한 방식은 현재 앱에 표시된 내용을 기준으로 합니다. 특정 공용 DNS 주소가 모든 네트워크에 적합하다고 단정하지 마세요.

DNS 확인 실패와 연결 실패 구분하기

요청에 사용할 주소를 얻지 못했다면 DNS 서버에 연결할 수 있는지, 도메인이 유효한지, 현재 네트워크에서 접속 인증을 먼저 완료해야 하는지 확인하세요. 주소를 얻었는데 연결이 시간 초과된다면 규칙 방향, 서버 상태, 대상 서비스에 원인이 있을 수 있습니다. 브라우저의 ‘페이지를 열 수 없음’ 메시지만으로는 상황을 구분할 수 없습니다. Log에서 비슷한 시각의 DNS 확인 및 연결 정보를 살펴 실패 지점을 파악하세요.

도메인을 확인하는 경로와 이후 연결되는 경로는 서로 연관되어 있지만 별개의 문제입니다. 요청에 PROXY가 적용된다고 해서 모든 DNS 확인 단계도 같은 전송 경로를 사용하는 것은 아닙니다. DIRECT가 적용되어도 정책 이름만으로 DNS 서버의 출처를 판단할 수 없습니다. 실제 동작은 현재 Config와 앱 옵션에 따라 달라집니다. 점검할 때는 ‘어디에서 이름을 확인했는지’와 ‘어디로 연결했는지’를 따로 기록해 두세요.

DNS 설정에는 앱 옵션과 Config 파일 내용이 함께 관여할 수 있습니다. 먼저 현재 Config를 열어 DNS 관련 항목을 확인한 다음 Settings에서 사용할 수 있는 DNS 옵션과 설명을 살펴보세요. 여러 위치에 서로 다른 값을 동시에 입력하고 결과만으로 우선순위를 추측하지 마세요. 설정 출처가 충돌한다면 Config 사본에서 항목을 하나씩 단순화하고 다시 연결해 테스트하면서 어떤 변경이 결과에 영향을 주었는지 확인하세요.

DNS 방식 선택 및 캐시 확인

일반 DNS와 암호화 DNS는 전송 조건이 다릅니다. 암호화 전송은 네트워크 경로에서 DNS 요청을 보호하는 방식을 바꿀 수 있지만, 속도나 정확도가 더 높거나 현재 네트워크에서 접속 가능하다는 보장은 없습니다. 현재 앱에서 DNS 서버를 입력할 수 있다면 형식, 프로토콜 지원 여부, 실제 접속 가능성을 확인하세요. 정상 작동하는 방식을 우선 유지하고, 명확한 필요가 있으며 검증할 수 있을 때만 바꾸는 것이 좋습니다.

캐시 때문에 설정을 바꾼 뒤에도 결과가 달라지지 않은 것처럼 보일 수 있습니다. 앱, 시스템, 브라우저 또는 대상 서비스 관련 과정에 캐시가 남을 수 있어 한 번 새로고침해도 모든 DNS 확인이 다시 이루어지지는 않습니다. 테스트할 때는 기존 페이지를 닫거나 연결을 종료한 다음 현재 앱에서 제공하는 캐시 작업을 수행하고, 필요하면 다시 연결하세요. 캐시 한 번을 지우려고 Config 전체를 삭제하지 마세요. 검증하지 않은 설정 변경 덕분에 우연히 복구되었다고 단정하지도 마세요.

IPv4와 IPv6도 확인 결과에 영향을 줍니다. 도메인에 두 종류의 주소 기록이 모두 있을 수 있지만 로컬 네트워크가 두 연결 방식을 똑같이 지원하는 것은 아닙니다. 일부 대상에서만 문제가 생기면 실제로 사용된 주소 유형과 실패 단계를 확인하세요. 현재 경로를 네트워크와 서버가 지원하는지 먼저 확인한 뒤 관련 옵션을 검토하는 것이 좋습니다. 한 주소 체계를 바로 끄면 문제를 일시적으로 우회할 수는 있어도 근본 원인이 해결된 것은 아닙니다.

로컬 네트워크 이름과 접속 인증

가정용 기기, 사내 리소스 또는 특정 네트워크에서만 사용할 수 있는 이름에 접속할 때는 로컬 DNS 환경이 필요할 수 있습니다. 모든 도메인을 같은 외부 DNS 경로로 보내면 원래의 확인 조건을 잃을 수 있습니다. 이런 문제를 확인하려면 기기가 올바른 로컬 네트워크에 연결되어 있는지 먼저 확인한 다음 Direct와 Config 결과를 비교하고, 해당 리소스에 특정 도메인, 주소 범위 또는 접근 권한이 필요한지 살펴보세요.

웹 인증이 필요한 Wi-Fi에서는 프록시 연결을 테스트하기 전에 네트워크 접속 절차를 완료해야 합니다. 시스템이 아직 정상적인 인터넷 접근 권한을 얻지 못했다면 DNS를 바꾸거나 서버를 반복해서 전환하는 것은 변수만 늘립니다. 시스템에 인증 페이지가 표시되는지 확인하고 정상적인 웹 요청을 통해 네트워크 연결을 점검하세요. 인증을 완료한 뒤 원래 Config를 복원하고 다시 연결해 인증 전후의 Log가 섞이지 않도록 합니다.

DNS가 정상인지 확인하려고 대상 도메인 대신 IP 주소로 직접 접속하지 마세요. 암호화 연결을 사용하는 웹사이트는 인증서 확인과 서비스 선택에 도메인을 사용하는 경우가 많으므로 IP 주소로 접속하면 다른 오류가 발생할 수 있습니다. DNS 확인 결과를 살펴본 다음 원래 도메인을 유지한 상태에서 연결을 점검하는 편이 정확합니다. 테스트 중 리디렉션이 발생하는지도 기록하세요. 이후 도메인에는 다른 DNS 경로나 규칙이 적용될 수 있습니다.

DNS 문제 해결의 마무리는 안정적이고 원인을 설명할 수 있는 상태로 되돌리는 것입니다. 유효한 설정은 유지하고 근거 없는 변경은 취소한 뒤 처음 실패한 대상과 원래 정상 작동하던 로컬 리소스를 다시 테스트하세요. 특정 대상에서만 문제가 계속되면 규칙과 대상 서비스를 확인하고, 연결은 유지되는데 모든 도메인 확인이 실패한다면 DNS 경로를 우선 점검하세요. 같은 옵션을 반복해서 무작정 바꾸는 일을 줄일 수 있습니다.

04 / CONNECTION LIFECYCLE

On Demand: 실행 조건과 연결 수명 주기

On Demand는 설정한 조건에 따라 연결을 시작하는 기능이며 서버 품질이나 규칙 우선순위를 변경하는 옵션이 아닙니다. 먼저 수동 연결이 안정적으로 작동하는지 확인한 뒤 실제 사용 환경에 맞춰 On Demand를 설정하세요. 기본 상태와 조건 종류, 구체적인 동작은 현재 앱에 표시된 내용을 기준으로 확인합니다. 활성화하기 전에 언제 연결하고 언제 연결을 끊을지, 네트워크가 바뀌면 어떻게 복구할지 설명할 수 있어야 합니다.

수동 연결 상태를 기준으로 먼저 확인하기

자동 실행 기능에 의존하지 말고 먼저 Home에서 선택된 서버, Global Routing, 현재 Config를 확인한 다음 연결을 수동으로 켜세요. 시스템에서 VPN 구성을 추가하라는 메시지가 나오면 출처를 확인하고 시스템 안내에 따라 승인합니다. 권한을 허용했다는 것은 시스템에서 해당 연결을 만들 수 있게 되었다는 뜻일 뿐, 서버 정보가 올바르거나 대상 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 실제 접속과 Log로 확인해야 합니다.

수동 연결이 안정적이지 않으면 On Demand는 불안정한 절차를 자동으로 반복할 뿐입니다. 먼저 인증 실패, DNS 확인 실패, 라우팅 문제를 해결한 뒤 실행 조건을 설정하세요. 그렇지 않으면 연결이 반복해서 켜지고 끊기는 현상을 On Demand 자체의 오류로 오해하기 쉽습니다. 네트워크 사용 가능 여부, 서버 정보 일치 여부, 수동 연결, 규칙 결과를 차례로 점검하고 마지막으로 자동 실행 조건을 확인하세요.

시스템 상태 표시줄의 아이콘만으로 연결 품질을 판단하지 마세요. 아이콘이나 앱 스위치는 연결 상태를 알려줄 수 있지만 모든 요청이 성공했는지는 보여주지 않습니다. 연결이 성립했는지, 특정 대상에 접속할 수 있는지, 새 요청이 Log에 기록되는지, 예상한 정책이 적용되는지를 각각 확인하세요. 결과를 나누어 기록하면 ‘연결이 시작되지 않음’과 ‘연결은 되었지만 접속 실패’를 구분할 수 있습니다.

실행 조건과 수동 연결 해제의 관계

현재 화면에서 네트워크 유형이나 조건별 동작을 설정할 수 있다면 각 조건의 의미를 읽고 실제로 사용하는 네트워크에 맞춰 지정하세요. 이름이 비슷한 Wi-Fi가 같은 신뢰 환경이라는 뜻은 아니므로 네트워크 이름만으로 보안을 판단해서는 안 됩니다. 먼저 명확하고 재현하기 쉬운 조건 몇 가지로 시작하고 겹치는 조건을 한꺼번에 많이 추가하지 마세요. 조건 간 일치 방식은 현재 앱에 표시된 설명과 실제 테스트를 기준으로 확인합니다.

수동으로 연결을 끊었는데 다시 연결된다면 On Demand에 유효한 실행 조건이 남아 있는지 확인하세요. 연결 스위치를 한 번 끄는 것만으로 자동 실행 규칙이 해제되지 않을 수 있습니다. 계속 연결을 끊어 두어야 한다면 관련 On Demand 조건을 먼저 처리한 뒤 연결 상태를 확인하세요. 테스트 후 일상 설정으로 되돌릴 때는 조건과 스위치를 모두 확인해 한쪽만 복원하는 일을 막으세요.

네트워크를 바꾸면 기존 연결이 끊겼다가 다시 설정될 수 있습니다. 진행 중인 작업은 새 네트워크에서 이어지지 않을 수 있으므로 잠시 실패했다고 규칙이 잘못되었다고 판단하지 마세요. 네트워크에서 정상적으로 접속할 수 있게 될 때까지 기다린 뒤 새 요청을 보내고 Log의 시간 흐름을 확인하세요. 네트워크를 바꿀 때마다 계속 실패한다면 먼저 수동으로 연결을 다시 설정해 자동 복구와 수동 복구의 차이를 비교한 뒤 점검 범위를 좁히세요.

화면 잠금, 백그라운드 및 시스템 제한

앱 화면이 전면에 있지 않다고 해서 연결이 반드시 중단되는 것은 아니며, 화면이 열려 있어도 시스템 네트워크 상태가 항상 같은 것은 아닙니다. 화면 잠금, 네트워크 변화, 시스템 리소스 관리가 결과에 영향을 줄 수 있습니다. 화면을 잠근 뒤 같은 대상에 다시 접속하는 등 재현 가능한 상황을 기준으로 테스트하고 다시 연결해야 하는지 기록하세요. 한 번의 백그라운드 동작만으로 모든 기기가 똑같이 작동한다고 일반화하지 마세요.

배터리 사용량은 사용 시간, 전송량, 신호 상태, 연결 재설정 빈도를 함께 고려해야 합니다. 지속적인 데이터 전송, 약한 신호, 잦은 재연결은 모두 전력 소비에 영향을 줄 수 있으므로 On Demand가 켜져 있는지만 보고 결론을 내릴 수 없습니다. 비교할 때는 네트워크, 서버, 사용 작업을 최대한 동일하게 유지하고 충분한 시간 동안 관찰하세요. 짧은 시간에 설정을 여러 번 바꾼 뒤 확인한 배터리 변화만으로는 원인을 찾기 어렵습니다.

연결이 다른 시스템 네트워크 설정과 영향을 주고받는다면 시스템 설정에서 현재 활성화된 연결과 관리 제한을 먼저 확인하세요. 관리 기기에는 조직이 설정한 제약이 있을 수 있으므로 구성을 임의로 삭제해 해결하려 해서는 안 됩니다. 직접 제어할 수 있는 범위에서 비교 테스트를 하고 원래 설정을 기록해 두세요. 익숙하지 않은 시스템 설정은 용도를 먼저 확인한 뒤 조정해야 기존에 필요한 네트워크 접속에 영향을 주지 않습니다.

On Demand 설정을 마친 뒤에는 세 가지 상태를 확인하세요. 정상적으로 시작했을 때 연결되는지, 네트워크가 바뀐 뒤 예상대로 동작하는지, 연결을 끊어야 할 때 원하는 상태를 유지하는지입니다. 어느 하나라도 예상과 다르면 보완 규칙을 더하기보다 조건을 먼저 단순화하세요. 정해진 시간에만 사용하는 경우 수동 연결도 명확한 선택입니다. 자동화의 목적은 반복 조작을 줄이는 것이지 설명하기 어려운 상태를 늘리는 것이 아닙니다.

05 / DIAGNOSTICS

Ping, Connectivity Test 및 Log

Ping과 Connectivity Test는 특정 테스트 조건에서 접속 가능성을 확인하고, Log는 실제 동작 과정을 기록합니다. 테스트 결과가 지속적인 접속 가능성을 보장하지 않으며 실제 전송 속도를 직접 측정하는 것도 아닙니다. 테스트는 문제를 좁히는 단서로 활용하세요. 먼저 대상과 방식을 확인한 다음 실제 접속 및 Log와 함께 분석합니다. 테스트 방식과 대상, 기본 옵션은 현재 앱에 표시된 내용을 기준으로 확인하세요.

숫자만 보지 말고 테스트 대상을 파악하기

테스트에 따라 서버 포트의 접속 가능성을 확인할 수도 있고 Proxy를 거쳐 특정 대상에 접속하는 전체 과정을 확인할 수도 있습니다. 두 결과를 바로 비교해서는 안 됩니다. 전자가 성공해도 이후 인증이나 대상 연결 단계에서 실패할 수 있고, 후자가 실패해도 테스트 대상이 일시적으로 응답하지 않는 것일 수 있습니다. 시작하기 전에 현재 테스트 방식과 설명을 확인하세요. 지연 시간으로 표시된 모든 숫자가 같은 네트워크 계층의 왕복 시간을 뜻한다고 가정하지 마세요.

테스트 시간이 짧다고 다운로드가 더 빠른 것은 아닙니다. 실제 속도는 로컬 신호, 사용 가능한 대역폭, 서버 부하, 전송 프로토콜, 대상 서비스의 제한에 따라 달라집니다. 같은 네트워크와 테스트 방식, 비슷한 시간대에 횟수를 제한해 비교하고 결과가 안정적인지 살펴보세요. 한 번 가장 빨랐던 결과만으로 장기 사용 항목을 선택하거나 한 번의 시간 초과만으로 서버 항목을 삭제하지 마세요. 같은 현상이 반복되는지 먼저 확인하세요.

특히 메모가 비슷하거나 중복 항목이 있을 때는 테스트 전에 올바른 서버 항목을 선택했는지 확인하세요. 구독을 업데이트하면 항목 목록이 바뀔 수 있으므로 예전 메모만 보고 현재 매개변수를 판단하지 마세요. 목록의 테스트는 성공했지만 실제 연결을 켰을 때 실패한다면 두 동작의 시간과 대상을 기록하고 같은 항목, 라우팅 방식, 네트워크를 사용했는지 확인하세요. 테스트 기능이 부정확하다고 바로 단정하지 마세요.

Log로 한 번의 실패 요청 추적하기

Log는 페이지 전체보다 재현 가능한 동작 한 번을 기준으로 읽는 것이 효과적입니다. 먼저 시간을 기록하고 명확한 요청 하나를 보낸 다음 비슷한 시각의 도메인, 주소, 규칙, 오류 정보를 찾으세요. 어떤 항목이 표시되는지는 현재 앱 화면을 기준으로 확인합니다. Log가 길다면 테스트 동작을 단순화하세요. 같은 시간에 여러 페이지를 열면 백그라운드 요청과 하위 리소스가 섞여 주요 이벤트를 찾기 어려워집니다.

실패가 어느 단계에서 발생했는지 먼저 확인하세요. 도메인이 확인되었는지, 적용할 정책을 찾았는지, 서버 연결이 성립했는지, 인증이 통과했는지, 대상이 응답했는지 살펴봅니다. 오류 문구는 원문 그대로 기록하고 모든 시간 초과를 같은 원인으로 해석하지 마세요. 시간 초과는 여러 단계에서 발생할 수 있고 연결 거부와 인증 실패도 각각 다른 조치가 필요합니다. 마지막 한 줄만 떼어내지 말고 주변 이벤트와 대상을 함께 살펴보세요.

관찰된 현상	바로 단정할 수 없는 내용	다음 단계
테스트 시간이 짧음	실제 전송도 반드시 빠름	조건을 동일하게 유지하고 실제 작업 테스트
DNS 확인 결과가 없음	서버가 반드시 사용할 수 없음	DNS와 로컬 네트워크부터 확인
규칙이 예상대로 일치함	이후 연결도 반드시 성공	연결 및 인증 단계 계속 확인
대상 하나에서만 실패	모든 설정이 잘못됨	대상 도메인, 규칙, 응답 확인

Log에 주소나 도메인이 표시되어도 해당 콘텐츠가 성공적으로 전송되었다는 뜻은 아닙니다. DNS 확인, 연결 시도, 규칙 일치 기록일 수 있습니다. 반대로 예상한 Log가 보이지 않는다고 해서 앱이 요청을 처리하지 않은 것도 아닙니다. 필터나 기록 범위의 영향이 있거나 요청 자체가 전송되지 않았을 수 있습니다. 먼저 Log 화면의 필터 상태를 확인한 뒤 명확한 새 요청을 보내 기록이 갱신되는지 확인하세요.

진단에 필요한 최소한의 자료만 보관하기

도움을 요청하기 전에 비밀번호, 인증 토큰, 전체 구독 주소, 개인의 사용 습관을 드러낼 수 있는 기록을 삭제하세요. 서버 주소, 메모, 접속 도메인도 민감한 정보를 노출할 수 있으므로 문제 해결에 필요한 최소한만 남기세요. ‘같은 네트워크에서 수동 연결이 실패하고 인증 단계에서 오류가 발생한다’고 설명한 뒤 관련된 일부 행만 가려서 첨부할 수 있습니다. 전체 Config와 모든 Log를 공개할 필요는 없으며, 구독 원문은 특히 그대로 보내지 마세요.

상세 기록은 저장 공간을 차지하고 진단에 불필요한 정보를 늘릴 수 있습니다. 필요할 때만 현재 화면에서 제공하는 방법으로 활성화하고 문제 해결 후에는 원래 상태로 되돌리세요. Log 수준과 초기 상태는 앱에 표시된 값을 기준으로 확인하고 ‘정보가 많을수록 좋다’는 이유로 모든 세부 기록을 계속 남겨 두지 마세요. 정리하기 전에 문제 해결에 필요한 부분을 보관하고, 정리 후 다시 테스트해 이전 오류를 새로운 실패로 오해하지 않도록 합니다.

속도가 느리다면 로컬 네트워크, 프로토콜 매개변수, 회선 상태, 서버 부하를 단계별로 확인하세요. 각 단계에서 조건 하나만 바꾸고 실제 작업 결과를 기록합니다. 더 자세한 비교 순서는 연결 후 속도가 느릴 때 단계별로 점검하기를 참고하세요. 테스트 결과는 당시 조건만 보여줄 뿐 향후 안정성을 예측할 수 없으며 어떤 연결 서비스의 평가나 추천 근거로 사용해서도 안 됩니다.

진단을 마친 뒤에는 문제 해결 조건을 명확히 기록하세요. 무엇을 바꿨는지, 원래 값이 무엇이었는지, 어떤 대상으로 확인했는지, 두 번째 네트워크에서도 테스트했는지 적습니다. 효과가 없었던 변경은 되돌리고 임시로 바꾼 Global Routing도 복원하세요. 이렇게 하면 비슷한 문제가 다시 발생했을 때 기록 없는 임의 조정을 반복하지 않고 확인된 기준점에서 시작할 수 있습니다. Log의 목적은 조작 횟수를 늘리는 것이 아니라 변수를 줄이는 것입니다.

06 / CONFIGURATION DATA

Subscribe, Add Server 및 Config의 데이터 구분

Subscribe는 사용자가 보유한 구독 정보를 관리하고, Add Server는 서버 항목을 추가하며, Config는 구성 파일을 관리합니다. 서로 연관되어 있지만 같은 기능은 아닙니다. 먼저 받은 정보가 어떤 종류인지 확인한 다음 해당 메뉴를 선택하세요. 링크처럼 보인다는 이유만으로 모든 자료를 같은 방식으로 가져오지 마세요. 기본 항목과 가져오기 옵션은 현재 앱에 표시된 내용을 기준으로 확인하고, 서버 매개변수는 사용자가 보유한 정보를 따르세요.

구독 업데이트와 실행 Config를 따로 확인하기

구독은 보통 서버 항목을 가져오거나 업데이트하지만, 완전한 분기 규칙까지 반드시 포함한다고 볼 수는 없습니다. 가져온 뒤 실제로 생성된 내용을 확인하세요. 항목 수가 바뀌었는지, 메모가 예상과 맞는지, 구문 오류가 있는지 살펴봅니다. 이어서 Config에서 사용 중인 파일과 Global Routing을 별도로 확인하세요. 목록에 서버가 있다는 사실은 연결 정보가 있다는 뜻일 뿐 규칙을 선택했다는 뜻은 아닙니다.

구독 주소에는 사용자를 식별할 수 있는 매개변수가 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관하세요. 복사할 때 공백, 줄바꿈, 설명 문구가 섞이지 않도록 하고 전체 주소를 메모에 붙여 넣지 마세요. 업데이트에 실패하면 주소가 유효한지 확인하고 현재 네트워크 환경에서 접속 결과를 살펴보세요. 테스트를 위해 출처를 알 수 없는 웹페이지에 주소를 제출하지 마세요. 업데이트 방식이나 내용이 분명하지 않다면 사용자가 보유한 서비스 정보의 안내를 확인하세요.

업데이트 전에 현재 사용 중인 항목을 기록하고 업데이트 후 예상한 서버를 계속 가리키는지 확인하세요. 항목이 추가·삭제되거나 이름이 바뀌면 기존 선택에 영향을 줄 수 있습니다. 항목의 출처를 식별할 수 있는 메모는 유지하되 이름에 비밀번호를 적지 마세요. 중복 항목이 있다면 출처와 실제 매개변수를 확인한 뒤 정리 여부를 결정합니다. 이름이 같다는 이유만으로 같은 연결 대상이라고 단정할 수 없습니다.

Add Server 매개변수는 경험으로 추측하지 마세요

직접 추가할 때 주소, 포트, 인증 정보는 보유한 정보와 정확히 일치해야 합니다. Shadowsocks, VMess, VLESS, Trojan, WireGuard, Hysteria2 등의 프로토콜은 필요한 항목이 서로 다르므로 한 프로토콜의 입력 방식을 다른 프로토콜에 그대로 적용할 수 없습니다. 현재 선택한 프로토콜의 필수 항목을 하나씩 확인하고 영문 항목 이름은 그대로 유지하면서 보유한 정보와 대조하세요. 매개변수가 부족하다면 임의로 입력하지 말고 먼저 필요한 정보를 확인하세요.

전송 방식, 암호화 연결 관련 항목, 인증서 이름은 핸드셰이크 결과에 영향을 줄 수 있습니다. 서버 주소에 연결할 수 있다고 해서 해당 항목까지 올바른 것은 아닙니다. 오류를 피하려고 인증서 검증을 함부로 끄거나 접속 실패를 모두 비밀번호 문제로 돌리지 마세요. 원래 오류를 기록한 다음 도메인, 시간 설정, 인증 정보, 프로토콜 요구 사항이 서로 일치하는지 확인하세요. 보안 검증 실패는 원인을 찾아야 하며, 스위치가 연결 상태로 바뀌는 것만을 목표로 삼아서는 안 됩니다.

QR 코드로 가져온 뒤에도 결과를 확인해야 합니다. Scan QR Code를 사용하면 직접 입력을 줄일 수 있지만 매개변수 확인을 대신하지는 않습니다. 출처를 신뢰할 수 있더라도 정보가 여전히 유효하다는 보장은 없습니다. 가져온 뒤 프로토콜, 주소, 포트, 메모를 살펴보고 올바른 항목을 선택했는지 확인한 다음 연결을 시도하세요. 현재 메뉴에서 지원하지 않는 데이터라면 반복해서 스캔하지 말고 서버 정보, 구독 주소, 기타 구성 중 어떤 종류인지 먼저 확인하세요.

Config 편집, 선택 및 복원

Config를 편집하기 전에 사본을 보관하고 사본에서 일부만 수정하세요. 하나의 Config에는 공통 설정, 규칙 및 기타 섹션이 포함될 수 있으므로 규칙 몇 줄을 추가하려고 기존 내용을 삭제하지 마세요. 저장 후 앱에서 형식 오류를 표시하는지 확인하고 실행 시 해당 파일이 선택되어 있는지도 살펴보세요. 목록의 위치, 최근 편집 시간, 표시 이름만으로 파일이 사용 중이라고 단정할 수 없습니다. 실제 선택 상태를 기준으로 확인하세요.

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

예시는 규칙 구문을 보여줄 뿐이며, 사설 주소 범위도 주소를 기준으로 일치시키는 방식을 설명하기 위한 것입니다. 실제 로컬 네트워크는 다른 범위를 사용할 수 있으므로 그대로 복사했다고 모든 로컬 리소스가 포함되는 것은 아닙니다. DOMAIN과 DOMAIN-SUFFIX는 일치 범위가 다르며 FINAL은 기본 처리로 이해해야 합니다. 먼저 명확한 대상 하나로 확인한 뒤 규칙 범위를 넓히세요. 변경 후에는 예상한 대상뿐 아니라 인접 기능도 확인해 오차단을 방지합니다.

원격 Config를 업데이트하면 규칙이 바뀔 수 있으므로 로컬 편집과 원격 업데이트의 역할을 분명히 나누세요. 업데이트 전에 보존할 내용을 확인하고, 업데이트 후 주요 규칙이 그대로 있는지 살펴봅니다. 계속 업데이트되는 원본과 기록되지 않은 로컬 변경을 뒤섞으면 변경 원인을 파악하기 어렵습니다. 중요한 수정 사항은 목적과 검증 방법을 기록하고 직전의 정상 상태로 복원할 수 있는 사본을 보관하세요.

구독을 여러 개 함께 사용할 때는 출처와 용도를 메모에 분명히 표시한 뒤 정리하세요. 구독을 삭제했을 때 생성된 항목에 어떤 영향이 있는지는 현재 앱의 확인 메시지를 따르며 확인하기 전에 연속으로 여러 항목을 삭제하지 마세요. 더 자세한 정리 순서는 여러 구독의 그룹화·정렬 및 중복 항목 정리를 참고하세요. 이 가이드는 보유한 정보를 관리하는 방법만 설명하며 서버나 구독을 제공·판매·추천하지 않습니다.

이 장의 마지막 점검에서는 세 종류의 데이터를 올바른 위치에 두어야 합니다. Subscribe에서 기존 항목을 업데이트할 수 있고, Add Server의 매개변수가 보유한 정보와 일치하며, Config가 선택되어 예상한 규칙 결과를 내는지 확인하세요. 한 단계에서 문제가 발생하면 모든 내용을 반복해서 가져오지 말고 해당 단계에서 해결합니다. 처음부터 전체 절차를 진행하려면 빠른 시작 안내로 돌아가 가져오기, 선택, 연결, 확인 순으로 진행하세요.

07 / CONTINUITY

Widget은 상태를 확인하거나 동작을 실행하기 편리한 시스템 진입점이며, iCloud 관련 기능은 현재 앱이 지원하는 범위에서 데이터를 이어서 사용할 수 있도록 합니다. 둘 다 주 화면에서 실제 상태를 확인하는 일을 대신하지 않으며 연결 성공을 보장하지도 않습니다. 먼저 앱에서 정상 작동을 확인한 뒤 빠른 실행이나 동기화 기능을 설정하세요. 사용 가능한 기능, 동기화 범위, 기본 상태는 현재 앱과 시스템에 표시된 내용을 기준으로 확인하며 모든 데이터가 동기화된다고 가정하지 마세요.

Widget 표시와 실제 연결을 따로 확인하기

Widget을 추가할 때는 시스템의 위젯 관리 절차를 사용하고 현재 기기에서 선택할 수 있는 Shadowrocket 위젯과 크기를 확인하세요. 위젯 종류와 조작 방식은 시스템 화면을 기준으로 하며 다른 기기의 배치에서 추측하지 마세요. 추가한 뒤 앱에서 실제 연결 상태와 선택된 항목을 확인하고 Widget 표시와 비교합니다. Widget이 바로 바뀌지 않으면 앱으로 돌아가 실제 상태를 확인하고 연결을 여러 번 전환할 수 있도록 연속해서 누르지 마세요.

시스템이 Widget의 새로고침 시점을 관리할 수 있어 표시 내용이 매 순간 앱과 완전히 일치하지 않을 수 있습니다. 앱에서는 정상적으로 연결되는데 Widget에 문제가 있다면 먼저 표시 및 새로고침 단계로 범위를 좁혀 확인하세요. 연결 또는 연결 해제 동작을 한 번 실행해 비교하고 시스템이 표시를 갱신할 시간을 두세요. 서버를 반복해서 바꾸거나 Config를 삭제해도 Widget 자체의 새로고침 문제는 대개 해결되지 않습니다.

잠금 화면이나 홈 화면에 표시되는 메모를 통해 사용 정보가 드러날 수 있습니다. 서버와 Config의 이름은 쉽게 구분할 수 있으면서도 개인정보를 보호하도록 정하고, 전체 주소나 인증 정보, 구독 링크를 표시될 수 있는 위치에 적지 마세요. 공유 기기라면 다른 사용자가 내용을 보거나 동작을 실행할 수 있는지도 고려해야 합니다. 민감한 자격 정보를 포함하지 않으면서 용도를 구분할 수 있는 짧은 이름을 사용하고 Widget을 추가한 뒤 앱 목록뿐 아니라 실제 화면에 어떻게 표시되는지도 확인하세요.

iCloud 동기화 전에 데이터 범위 확인하기

동기화를 활성화하기 전에 시스템 계정과 iCloud 사용 가능 여부, 현재 앱에 관련 옵션이 있는지 확인하세요. 동기화 범위는 항목별로 확인해야 합니다. ‘iCloud가 켜져 있음’이 서버, Config, Log, 연결 상태, 모든 환경설정이 완전히 저장되었다는 뜻은 아닙니다. 먼저 민감한 정보가 없는 식별 가능한 변경 하나로 동기화를 확인한 다음 기기 간 정리에 사용할지 결정하세요. 기본 상태는 현재 앱에 표시된 값을 기준으로 확인합니다.

동기화는 데이터 상태를 이어주는 기능이지 과거 백업 보관소가 아닙니다. 실수로 삭제하거나 잘못 수정한 내용이 다른 기기에도 반영될 수 있으므로 중요한 데이터는 별도 사본으로 보관하세요. 사본에는 용도와 포함 범위를 표시하고 직접 관리할 수 있는 위치에 저장합니다. 두 번째 기기에서 파일 이름이 보인다는 이유만으로 전체 내용이 동기화되었다고 판단하지 마세요. 주요 항목을 열어 확인하고 실제 연결에 사용할 수 있는지 점검하세요.

여러 기기에서 동시에 편집하면 데이터 출처를 파악하기 어려워질 수 있습니다. 한 기기에서 먼저 정리한 다음 다른 기기에서 예상한 결과가 나타날 때까지 기다리고 다음 작업을 진행하세요. 같은 이름의 사본이나 내용 차이가 발견되면 먼저 각각 보관한 뒤 주요 항목을 비교하고 어느 한쪽을 바로 삭제하지 마세요. 파일 이름만 보지 말고 규칙 순서, 서버 매개변수, 메모와 항목의 대응 관계를 확인하세요. 이름이 같다고 내용까지 같다는 뜻은 아닙니다.

파일 가져오기와 지속적인 동기화 구분하기

Import from Cloud JSON은 현재 앱이 제공하는 메뉴와 안내에 따라 사용하세요. 파일에서 한 번 데이터를 가져오는 것은 지속적인 동기화를 설정하는 것과 다릅니다. 파일을 성공적으로 읽었다고 해서 모든 항목이 현재 기기에 적합하다는 뜻도 아닙니다. 진행 전에 파일 종류와 출처를 확인하고 완료 후 실제로 생성되거나 변경된 내용을 살펴보세요. 확장자만 보고 서버 항목이 들어 있다고 추측하지 말고 출처를 모르는 데이터를 정상 작동 중인 Config에 바로 덮어쓰지 마세요.

시스템 네트워크 권한은 각 기기에서 확인해야 합니다. 다른 기기에서 연결 권한을 허용했다고 현재 기기도 이미 승인되었다고 볼 수 없습니다. 새 기기에서 처음 연결할 때는 시스템 안내를 따라 권한을 확인하고 로컬 네트워크, 서버, 규칙을 다시 점검하세요. 앱 구매 적용 범위와 호환성은 App Store 페이지에 표시된 내용을 기준으로 확인합니다. 동기화된 내용이 보이는지와 기기가 실행 조건을 충족하는지도 각각 확인해야 합니다.

동기화 결과가 나타나지 않으면 먼저 두 기기의 시스템 계정과 네트워크 상태를 확인하고, 앱 안의 관련 옵션을 살펴본 뒤 다시 가져올 필요가 있는지 판단하세요. 사본을 보관하기 전에 iCloud 데이터를 끄거나 삭제하지 말고, 동기화를 여러 번 켰다 끄며 결과를 기대하지 마세요. 한 번에 한 단계만 변경하고 다른 기기에 실제로 어떤 변화가 나타나는지 기록해야 전송 지연, 범위 차이, 내용 충돌을 구분할 수 있습니다.

설정을 마친 뒤에도 Widget과 동기화는 보조 기능으로 사용하고 유일한 제어 수단으로 삼지 마세요. 일상 사용 중 문제가 생기면 앱으로 돌아가 연결, Global Routing, 현재 Config, 서버 선택을 확인하세요. 백업을 실제로 열 수 있는지, 민감한 정보가 표시되는 메모에 포함되어 있지 않은지, 사용하지 않는 사본을 정리할 필요가 있는지도 정기적으로 점검합니다. 편의성을 유지하면서 기기 상태를 명확하고 확인 가능하게 관리할 수 있습니다.

08 / LOCAL LISTENING & REVIEW

Proxy 포트, 로컬 리스닝 및 설정 점검

Proxy 관련 포트는 특정 프록시 서비스가 연결을 기다리는 위치를 뜻하며 원격 서버 포트와 혼동해서는 안 됩니다. HTTP, SOCKS5 또는 다른 로컬 리스닝 옵션을 제공하는지, 기본값과 적용 조건이 무엇인지는 현재 앱에 표시된 내용을 기준으로 확인하세요. 분명한 필요가 없다면 기존 설정을 유지하고 고정 포트를 추측하거나 속도를 높이려고 리스닝 매개변수를 임의로 바꾸지 마세요.

원격 포트와 로컬 리스닝 포트 구분하기

Add Server의 포트는 보통 사용자가 보유한 원격 서버에 연결할 때 사용하므로 서버 정보와 일치해야 합니다. 로컬 Proxy 포트는 조건에 맞는 요청을 기기에서 제공하는 프록시 진입점에 연결하는 데 사용됩니다. 두 포트는 설정 위치와 역할이 다릅니다. 로컬 포트를 변경해도 원격 서비스의 리스닝 포트는 바뀌지 않고 원격 인증 오류도 자동으로 해결되지 않습니다. 문제를 확인하기 전에 어떤 포트를 편집하는지 확인하고 해당 주소도 함께 기록하세요.

프록시 진입점은 주소, 포트, 프로토콜이 함께 맞아야 합니다. 포트 번호만 알아서는 연결할 수 없습니다. SOCKS5만 지원하는 진입점에 HTTP 방식으로 연결하거나 원격 주소와 로컬 리스닝 포트를 조합하면 연결에 실패할 수 있습니다. 현재 앱이 지원하는 기능과 보유한 요구 사항을 기준으로 설정하세요. 웹페이지에서 자주 본 숫자를 기본값으로 간주하거나 포트 번호의 크기로 성능을 판단하지 마세요.

리스닝 주소는 어떤 기기에서 진입점에 접근할 수 있는지 결정합니다. 로컬 기기만 대상으로 하는 주소와 로컬 네트워크를 대상으로 하는 주소의 적용 범위는 다릅니다. 현재 화면에 관련 옵션이 있다면 설명을 먼저 읽고 선택하세요. 더 넓은 범위로 열면 같은 네트워크의 다른 기기에서도 연결을 시도할 수 있으므로 접근 범위와 인증 기능을 확인해야 합니다. 기기 간 접근이 꼭 필요한 것이 아니라면 필요한 최소 범위를 유지하고 임시로 열었다면 테스트가 끝난 뒤 다시 제한하세요.

적용 조건, 충돌 및 접속 가능성 확인

로컬 리스닝은 앱 연결 상태, 현재 활성화된 기능, 시스템 네트워크 조건에 따라 사용할 수 있는지가 달라질 수 있습니다. 먼저 앱이 예상한 상태로 작동 중인지 확인한 다음 프록시를 사용하려는 쪽에서 주소와 프로토콜을 점검하세요. 설정 화면에 포트를 저장했다고 언제든 리스닝 중이라고 단정할 수 없으며, 기기 자체에서 사용할 수 있다고 다른 기기에서도 접속 가능하다는 뜻은 아닙니다. 두 테스트는 서로 다른 경로를 확인합니다.

포트가 이미 사용 중이거나 바인딩할 수 없다는 메시지가 나오면 원래 오류를 저장하고 같은 리스닝 위치를 중복으로 사용하고 있지 않은지 확인하세요. 포트 번호가 유효 범위에 있다고 해서 현재 용도에 모두 적합한 것은 아닙니다. 시스템 제한이나 기존 서비스도 바인딩에 영향을 줄 수 있습니다. 분명한 필요에 따라 사용할 수 있는 값을 선택한 뒤 저장 및 적용 여부를 다시 확인하세요. 충돌 원인을 찾는 대신 숫자를 무작위로 반복 입력하지 마세요.

로컬 네트워크에서 접속하려면 두 기기가 서로 통신할 수 있는 같은 네트워크에 연결되어 있고, Wi-Fi에서 기기 간 통신을 차단하지 않으며, 주소가 변경되지 않았는지 확인해야 합니다. 게스트 네트워크는 인터넷 접속은 허용하면서 기기 간 직접 통신은 막을 수 있습니다. 문제를 확인할 때는 먼저 기본적인 통신이 가능한지 살펴본 뒤 Proxy 진입점을 점검하세요. 모든 실패를 Shadowrocket 문제로만 돌리지 마세요. 공유 네트워크에서는 주의하고 임시 테스트가 끝나면 원래 접근 범위로 복구하세요.

점검 항목	기본값 처리	권장 설정 기준
원격 서버 포트	보유한 서버 정보 기준	원격 서비스의 실제 포트와 일치
로컬 Proxy 포트	현재 앱에 표시된 값 확인	용도에 적합하고 리스닝 충돌이 없는 값
리스닝 주소	현재 앱에 표시된 값 확인	필요한 최소 접근 범위
진입점 프로토콜	현재 지원되는 기능 확인	사용 측 설정과 일치

변경 후 전체 점검 및 복원 방법

포트를 변경한 뒤에는 단계별로 확인하세요. 진입점에 접속할 수 있는지, 프로토콜이 맞는지, 요청이 앱에 전달되는지, 라우팅 결과가 예상과 일치하는지, 대상이 응답하는지 점검합니다. 앞 단계가 성공해도 다음 단계의 성공을 보장하지 않습니다. 예를 들어 요청이 앱에 전달되었는데 대상이 시간 초과되면 서버 연결과 규칙을 계속 확인하세요. 진입점에 전혀 접속할 수 없다면 원격 서버를 바로 바꾸지 말고 리스닝 상태와 네트워크 범위를 먼저 점검합니다.

모든 Settings 변경에 같은 점검표를 사용할 수 있습니다. 원래 값을 기록하고 변경 목적을 적은 뒤 변수 하나만 바꾸고 고정된 대상으로 테스트하며 Log를 확인합니다. 원래 정상이던 기능도 점검하고 유효한 변경은 유지하되 나머지는 되돌리세요. 명확한 개선이 없는 변경은 원래 값으로 복구하는 것이 좋습니다. 설정을 적고 설명할 수 있는 소수 항목으로 유지하면 효과가 불분명한 스위치를 쌓아 두는 것보다 장기적으로 관리하기 쉽습니다.

앱이 업데이트되었다고 모든 설정을 기계적으로 다시 구성할 필요는 없지만 자주 쓰는 옵션과 주요 절차가 여전히 예상대로 작동하는지는 확인해야 합니다. 업데이트는 App Store에서 관리하며 구체적인 변경 사항은 App Store 페이지와 앱 내 표시를 기준으로 확인하세요. 오래된 스크린샷만으로 새 인터페이스를 추측하지 마세요. 일상적인 연결, Config 선택, 필요한 On Demand 동작을 먼저 테스트합니다. 차이가 생기면 기존 데이터를 보존하고 항목별로 확인하세요. 바로 데이터를 모두 지우고 처음부터 시작하지 마세요.

마지막으로 유지 관리 기록을 재현 가능한 상태 설명으로 정리하세요. 어떤 네트워크, Config 파일, 서버 항목, Global Routing을 사용했는지와 어떤 Settings를 변경했는지 기록합니다. 실제 인증 정보는 포함하지 않아도 되지만 같은 환경을 다시 만들 수 있을 만큼 구체적이어야 합니다. 해결되지 않은 문제는 해당 장으로 돌아가 계속 확인하고, 최초 사용 절차는 사용 안내에서, 구매 및 기기 요구 사항은 다운로드 페이지에서 확인하세요. 각 페이지는 명확히 구분된 정보를 제공합니다.