Official Manual › Settings Reference

Shadowrocket
설정 항목 안내

설정 적용 범위, 연결 경로, 검증 결과를 기준으로 확인하세요. 먼저 현재 설정값을 확인한 뒤 한 번에 하나씩 변경하세요. 기본값을 일률적으로 확인하기 어려운 항목은 앱에 표시된 값을 기준으로 합니다.

설정 의미
기본값 확인
권장 설정
규칙 문제 해결

이 페이지는 Shadowrocket 공식 매뉴얼의 설정 항목 안내입니다. 아직 처음 연결을 완료하지 않았다면 먼저 튜토리얼의 빠른 시작 과정을 따라 기존 서버 또는 구독을 가져오고, 서버를 선택한 다음 연결을 확인하세요. 그런 뒤 이 페이지에서 필요한 항목을 찾아보면 됩니다. 연결은 되지만 DNS 조회, 자동 연결, 테스트 또는 동기화에 문제가 있다면 목차에서 해당 항목으로 바로 이동하세요.

이 안내는 사용자가 이미 자신의 구독 또는 서버 정보를 보유한 경우를 전제로 합니다. 앱의 일회성 구매는 회선 요금제가 아닙니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. Shadowrocket은 폐쇄형 상용 앱이며 App Store에서만 받을 수 있습니다. 구매, 호환성 및 시스템 요구 사항은 정품 확인 및 다운로드 안내에서 확인하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다.

Settings, Home, Config 등의 메뉴 이름은 영어로 표기합니다. 일부 옵션은 현재 설정, 기기 및 앱 상태에 따라 달라질 수 있습니다. 이 페이지의 권장 사항은 문제 해결을 시작할 때 참고할 내용이며 모든 환경에 적용되는 고정값은 아닙니다. 변경 전에 사용 중인 Config를 저장하고 Global Routing, 선택한 서버 및 관련 스위치 상태를 기록해 두세요. 그래야 기존 동작과 변경 후 결과를 혼동하지 않습니다.

Home › Global Routing

Global Routing과 설정 적용 범위

Global Routing은 연결에 적용할 전체 처리 방식을 결정합니다. Settings를 살펴보기 전에 먼저 확인해야 할 항목입니다. 화면의 Config, Proxy, Direct는 각각 구성에 따른 처리, 프록시 처리, 직접 연결을 뜻합니다. 이 설정은 상단 연결 스위치와 다릅니다. 스위치는 클라이언트 연결이 실행 중인지 나타내고, Global Routing은 실행 중인 연결을 어떻게 처리할지 정합니다. 시스템에 VPN 상태가 표시된다고 해서 특정 대상이 선택한 서버를 거친다고 단정할 수는 없습니다.

전체 처리 방식과 개별 규칙 구분하기

Config는 현재 활성화된 구성의 규칙에 따라 처리 방식을 정하므로 대상별로 연결 경로를 나눠야 할 때 적합합니다. Proxy는 프록시 처리를 우선 적용하며, 기존 서버가 특정 대상에 연결할 수 있는지 확인할 때 사용할 수 있습니다. Direct는 직접 연결을 우선 적용하므로 비교 확인에 적합합니다. 실제로 어떤 연결이 유지되는지는 현재 구성과 앱 안내를 함께 확인해야 합니다. 처리 방식 이름만으로 모든 시스템 트래픽이 똑같이 처리된다고 단정하지 마세요.

화면 표시	의미	권장 용도
Config	현재 구성의 규칙에 따라 처리 방식을 선택	일상적인 트래픽 분리와 규칙 일치 여부 확인
Proxy	프록시 처리 우선	규칙 영향을 배제하고 서버 경로 확인
Direct	직접 연결 우선	로컬 네트워크와 대상 연결 가능 여부 비교

Proxy로 바꾼 뒤 접속이 복구되더라도 전체 연결 경로의 변화가 결과와 관련 있다는 점만 알 수 있을 뿐, 특정 규칙이 잘못됐다고 바로 단정할 수는 없습니다. 서버를 함께 바꾸지는 않았는지, 기존 연결을 재사용하지는 않았는지, 도메인을 다시 조회했는지도 확인해야 합니다. 반대로 Direct에서 대상이 열린다고 해서 프록시 설정이 올바르다는 뜻은 아닙니다. 비교 테스트에서는 대상, 네트워크, 서버를 고정하고 한 번에 하나의 처리 방식만 바꾼 뒤 새 연결을 만들어 확인하세요.

Settings, Config, 서버 설정의 적용 범위 확인

같은 증상에 Settings의 앱 전체 옵션, Config의 규칙 및 DNS 설정, 서버 편집 화면의 프로토콜 설정 등 세 가지 계층이 관여할 수 있습니다. 한 곳에 어떤 값이 표시된다고 해서 다른 위치의 같은 이름 설정을 덮어쓴다고 볼 수는 없습니다. 먼저 실제로 활성화된 Config를 확인하고 관련 항목이 있는지 살펴보세요. 파일을 가져온 뒤 앱 전체 설정이 계속 적용되는지는 파일이 존재한다는 사실만으로 판단하지 말고 실제 동작과 Log로 확인해야 합니다.

기본값도 설정 계층별로 확인해야 합니다. 처음 설치했을 때, 데이터를 복원한 뒤, 구성을 가져온 뒤의 값은 서로 다를 수 있습니다. 정확한 기본값을 일률적으로 확인하기 어려운 항목은 이 안내에서 ‘현재 앱에 표시된 값’을 기준으로 합니다. 설정 이름과 메뉴 위치, 변경 전 값, 예상되는 영향을 기록해 두세요. 예를 들어 ‘서버는 바꾸지 않고 DNS 방식만 비교’라고 적어 두면 맥락이 없는 화면을 저장하는 것보다 원래 상태를 복원하기 쉽습니다.

재현 가능한 기준 상태 만들기

문제 해결을 시작할 때는 먼저 사용자가 직접 관리하는, 정상 작동이 확인된 서버를 선택하고 Home에서 선택 표시를 확인하세요. 그런 다음 Global Routing과 현재 Config를 기록합니다. 자동 구독 업데이트와 재연결을 유발할 수 있는 조건은 잠시 중지하고 테스트 중에는 환경을 안정적으로 유지하세요. 테스트가 끝나면 원래 설정으로 복원합니다. 상태를 확인할 수 있는 테스트 대상을 사용하고, 서로 다른 웹사이트의 접속 결과를 한데 섞어 비교하지 마세요.

매 테스트마다 연결 해제, 설정 한 가지 변경, 재연결, 새 요청 생성, 관련 기록 확인 순서를 적어 두세요. 결과가 예상과 다르면 이전 상태로 되돌린 뒤 다시 테스트해 문제가 재현되는지 확인합니다. 브라우저 캐시, 진행 중인 다운로드, 백그라운드의 장기 연결은 이전 결과를 재사용할 수 있으므로 페이지를 새로고침해도 항상 새 연결이 만들어지는 것은 아닙니다. 필요하면 대상 페이지를 닫았다가 다시 여세요. 한 번 실패했다고 앱 데이터를 전부 지울 필요는 없습니다.

Settings › DNS

DNS: 조회 방식과 연결 경로

DNS는 도메인 이름을 연결에 사용할 수 있는 주소로 변환합니다. 도메인으로는 열리지 않지만 주소를 직접 입력하면 결과가 다를 때 DNS를 확인해야 합니다. 그렇다고 모든 DNS 옵션을 바로 바꿔야 하는 것은 아닙니다. DNS 조회 성공 여부, 반환된 주소가 현재 네트워크에 적합한지, 이후 연결이 어떤 정책을 따르는지는 서로 다른 문제입니다. 도메인 조회에 응답이 왔다는 사실만으로 대상 포트 연결, TLS 핸드셰이크 또는 페이지 로드까지 정상이라고 볼 수는 없습니다.

시스템 DNS, 사용자 지정 DNS, 암호화된 DNS

시스템 DNS는 현재 시스템과 네트워크의 DNS 설정을 사용하므로 기준 상태를 확인할 때 적합합니다. 사용자 지정 DNS는 다른 조회 대상을 지정해 DNS 응답 출처를 제어할 수 있지만, 해당 대상에 현재 환경에서 연결할 수 있어야 합니다. DNS over HTTPS는 HTTPS로 DNS 요청을 전송하므로 DNS 서비스 주소, 인증서, 연결 경로에 따라 결과가 달라질 수 있습니다. 이 방식을 선택해도 이후 모든 트래픽이 같은 정책을 따른다는 뜻은 아니므로 각각 따로 확인해야 합니다.

현재 정상 작동하는 DNS 방식부터 기준으로 삼으세요. 방식을 바꿔야 한다면 기존 항목과 순서를 기록하고 DNS 출처 하나만 변경한 뒤 재연결하여 같은 도메인을 테스트합니다. 성공 가능성을 높이겠다며 여러 출처를 한꺼번에 추가하지 마세요. 응답 결과와 순서, 캐시가 섞여 문제 재현이 더 어려워질 수 있습니다. DNS 진입점 자체에 도메인 조회가 필요한 경우에는 첫 연결 때 해당 주소를 먼저 얻을 수 있는지도 확인해 순환 의존을 피해야 합니다.

방식	확인할 항목	권장 설정
시스템 DNS	현재 네트워크에서 제공하는 DNS 조회가 정상인지	초기 비교 기준으로 사용하고 고정 서비스 주소로 간주하지 않기
사용자 지정 DNS	주소 형식, 연결 가능 여부, 조회 결과	사용자가 사용 가능하다고 확인한 DNS 대상 사용
DNS over HTTPS	전체 주소, 인증서, 접속 경로	필요한 경우에만 변경하고 복구할 수 있도록 기존 값 보관

설정 덮어쓰기, 캐시, 주소 유형 확인

Config에 DNS 관련 항목이 포함될 수 있으므로 Settings만 확인해서는 충분하지 않습니다. 변경 후에도 동작이 전혀 달라지지 않으면 활성화된 파일의 관련 설정을 확인하고 테스트 요청이 캐시를 계속 사용하고 있지는 않은지 살펴보세요. 서로 다른 계층에서 각각 결과를 캐시할 수 있어 웹페이지를 다시 열어도 DNS를 새로 조회하지 않을 수 있습니다. 새 조회 기록이 Log에 나타나는지 확인하는 편이 새로고침을 반복하는 것보다 유용합니다. 캐시된 응답을 새 DNS 응답으로 오인하지 마세요.

같은 도메인에서 IPv4와 IPv6 주소가 모두 반환될 수 있습니다. 한쪽 네트워크 경로에 연결할 수 없다면 성공할 때까지 오래 기다리거나 일부 요청만 실패할 수 있습니다. 이때는 먼저 반환된 주소 유형과 연결 오류를 확인하세요. 바로 DNS 서비스 문제라고 단정해서는 안 됩니다. 관련 옵션의 사용 여부는 현재 네트워크, 서버 기능, 대상에 따라 결정하고 기본값은 현재 앱에 표시된 값을 기준으로 합니다. 변경한 뒤에는 기존에 접속되던 대상에 영향이 없는지도 확인하세요.

실패 단계에 따라 다음 조치 결정

DNS 응답을 받지 못했다면 우선 DNS 진입점의 형식, 네트워크 연결 가능 여부, 설정이 적용된 위치를 확인하세요. 주소는 받았지만 연결 시간이 초과되면 라우팅 정책과 서버를 살펴봐야 합니다. 연결은 되지만 인증서 오류가 나타나면 접속 도메인, 기기 시간, 서버 설정을 확인하세요. 인증서 문제를 반복적인 DNS 변경으로 가리지 마세요. 웹사이트에서 서비스 오류 페이지를 반환한다면 네트워크 연결은 이미 완료됐을 수 있으므로 DNS 설정을 계속 바꾸는 것은 대개 도움이 되지 않습니다.

기기 이름이나 LAN 서비스를 이용할 때는 이름 조회 범위도 고려해야 합니다. 공용 DNS는 가정이나 사무실 네트워크의 내부 이름을 알지 못할 수 있습니다. 모든 조회를 같은 외부 DNS로 보내면 기존에 되던 로컬 접속이 달라질 수 있습니다. 기존 구성을 보관한 뒤 로컬 대상 하나와 일반 도메인 하나를 각각 테스트하세요. 목적은 설정에 프로토콜 이름을 더 많이 추가하는 것이 아니라 실제 필요에 맞는 조회 결과를 얻는 것입니다.

Settings › On Demand

On Demand: 실행 조건과 자동 연결

On Demand는 설정된 조건에 따라 연결을 시작하는 기능입니다. 서버를 자동으로 복구하거나 구독을 업데이트하는 기능은 아닙니다. 조건을 충족하면 시스템이 정해진 방식으로 연결을 시도할 수 있지만, 실제 연결 여부는 현재 서버, 구성, 네트워크에 따라 달라집니다. 연결을 수동으로 끈 뒤 다시 실행된다면 상단 스위치가 고장 났거나 앱 상태 표시가 잘못됐다고 판단하기 전에 적용 중인 조건이 남아 있는지 확인하세요.

자동화할 상황부터 정하기

설정하기 전에 원하는 동작을 구체적으로 정하세요. 특정 유형의 네트워크에서만 실행할지, 네트워크가 바뀐 뒤에도 연결을 유지할지 등을 먼저 결정합니다. 그런 다음 현재 앱에서 제공하는 조건 유형과 일치 방식을 확인하세요. 다른 화면의 필드 이름을 그대로 적용하지 마세요. Wi‑Fi 네트워크 이름으로 환경을 구분해야 한다면 공백과 비슷한 문자를 포함해 이름을 정확히 확인해야 합니다. 같은 이름의 네트워크가 다른 장소에도 있을 수 있으므로 이름만으로 네트워크를 식별할 수는 없습니다.

기본 스위치와 초기 조건은 현재 앱에 표시된 값을 기준으로 합니다. 첫 연결을 확인하는 중이라면 먼저 On Demand를 일시 중지하고 서버 하나를 수동으로 연결해 정상 작동을 확인하세요. 그런 다음 자동 조건을 추가합니다. 그렇지 않으면 연결 실패와 조건의 반복 실행이 겹쳐 Log에 비슷한 기록이 여러 번 남고, 어떤 수동 조작의 결과인지 파악하기 어려워질 수 있습니다. 자동 연결을 다시 설정할 때는 목적이 분명한 조건을 한 번에 하나씩 추가하세요.

시스템 권한과 네트워크 전환

처음 연결할 때 시스템에서 VPN 구성을 추가하도록 허용해 달라는 메시지가 표시될 수 있습니다. 앱 이름을 확인하고 시스템 안내에 따라 진행하세요. 이미 허용했더라도 모든 자동 조건이 활성화된 것은 아니며, 조건이 켜져 있어도 시스템 권한이 완전히 설정됐다고 볼 수 없습니다. 앱에서는 켜진 것으로 보이지만 시스템에서 연결을 설정하지 못한다면 권한 상태와 연결 오류를 각각 확인하세요. 시스템 요구 사항과 기기 호환성은 App Store 페이지에 표시된 내용을 기준으로 하며, 이전 기기에서의 경험으로 현재 상태를 추측하지 마세요.

Wi‑Fi와 셀룰러 네트워크 사이를 전환하면 연결 경로가 달라지고 기존 연결이 끊길 수 있습니다. On Demand를 테스트할 때는 먼저 네트워크를 고정하고 조건이 실행되는지 확인한 다음, 네트워크를 한 번 전환해 전후 상태를 기록하세요. 서버와 Config를 동시에 바꾸면 연결이 복구되어도 자동 조건이 올바른지 알 수 없습니다. 웹 로그인 절차가 필요한 네트워크라면 먼저 네트워크에 로그인한 뒤 프록시 연결을 확인하세요.

증상	먼저 확인할 항목	다음 단계
연결을 끈 뒤 다시 연결됨	자동 실행 조건이 남아 있는지	조건을 중지한 뒤 수동 연결 해제를 다시 테스트
네트워크 전환 후 연결되지 않음	새 네트워크가 조건과 일치하는지	새 네트워크에서 서버에 수동으로 연결할 수 있는지 테스트
연결을 반복해서 시도함	서버 오류와 네트워크 접속 상태	자동 실행을 중지하고 연결 실패만 따로 재현

자동 동작과 수동 동작의 차이 확인

수동 연결은 정상인데 자동 연결이 예상대로 작동하지 않는다면 프로토콜 설정을 바꾸기 전에 실행 조건부터 확인하세요. 조건이 저장됐는지, 현재 네트워크가 실제로 조건에 맞는지, 다른 조건이 다른 동작을 유발하는지, 시스템 구성이 여전히 유효한지 살펴봅니다. 수동 연결도 실패한다면 서버와 DNS 문제 해결로 돌아가세요. 두 경우를 나누면 자동 실행 문제 하나 때문에 기존 데이터를 전부 다시 만들 필요가 없습니다.

앱이 전면에 표시되지 않을 때 사용자는 연결이 끊겼다고 생각하지만 시스템 연결은 계속 유지되는 경우도 있습니다. 앱이 화면에 열려 있는 상태와 시스템 네트워크 확장이 실행되는 상태는 서로 다릅니다. 판단할 때는 시스템 연결 상태와 앱을 다시 열었을 때의 표시를 함께 확인하세요. 백그라운드 앱 목록만으로 연결 스위치 상태를 판단하지 마세요. 자동 연결을 중지하려면 먼저 적용 중인 On Demand 조건을 처리한 다음 연결을 끊고 결과를 확인해야 조건이 즉시 다시 실행되는 일을 막을 수 있습니다.

장기간 사용하기 전에 최소한 세 가지를 확인하세요. 조건을 충족하면 연결되는지, 조건을 충족하지 않을 때 예상대로 동작하는지, 서버에 연결할 수 없을 때 오류를 구분할 수 있는지 테스트합니다. 자동 연결은 반복 조작을 줄여야지 장애를 감춰서는 안 됩니다. 조직에서 관리하는 기기라면 시스템 설정에 관리 제한이 있을 수 있으므로 기기에 표시된 안내를 확인하세요. 조건과 권한을 점검하는 대신 구성을 반복해서 삭제하고 추가하지 마세요.

Settings › Ping · Connectivity Test

Ping과 Connectivity Test: 테스트 결과의 한계

Ping과 Connectivity Test는 연결 상태를 확인하는 기능이지만 테스트 방식마다 측정 대상이 다릅니다. 서버 주소에 응답이 온다고 해서 프록시 프로토콜 인증까지 성공한 것은 아닙니다. 프록시로 테스트 대상에 접속할 수 있다고 해서 모든 서비스 대상이 작동하는 것도 아닙니다. 결과를 해석하기 전에 선택한 테스트 방식, 테스트 대상, 테스트할 서버를 확인하세요. 일부 측정값이나 실패 메시지를 전체 네트워크 상태를 나타내는 결과로 확대 해석하지 마세요.

네트워크 연결 가능 여부와 프록시 사용 가능 여부 구분

Ping 관련 설정은 서버 목록에서 사용하는 테스트 방식을 바꿀 수 있습니다. 선택 가능한 항목과 기본값은 현재 앱에 표시된 내용을 기준으로 합니다. 네트워크 계층 응답을 이용하는 테스트는 주소 경로의 상태를 주로 보여주고, 포트 연결 테스트는 해당 포트에 접속할 수 있는지를 주로 확인합니다. 프록시를 통해 대상에 접속하는 테스트에는 프로토콜, 인증, DNS 조회, 대상 서비스도 영향을 줍니다. 테스트 계층이 많을수록 실패 원인도 늘어나므로 실패 표시 하나만으로 어느 계층에 문제가 있는지 단정할 수 없습니다.

예를 들어 서버 주소에 연결할 수 있어도 비밀번호나 TLS 이름이 잘못됐다면 단순 연결 테스트와 실제 접속 결과가 다를 수 있습니다. 반대로 일부 네트워크에서는 특정 탐색 응답을 반환하지 않아도 실제 요청은 완료될 수 있습니다. 이런 차이가 있으면 두 결과를 모두 기록하고 실제 연결 기록을 더 확인하세요. 서버 설정을 바꿔 서버 목록을 모두 성공으로 표시하려 해서는 안 됩니다. 설정값은 사용자가 보유한 서버 정보와 일치해야 하며 테스트 결과가 설정 사실을 대신하지는 않습니다.

안정적이고 명확한 테스트 대상 선택

용도와 상태를 직접 확인할 수 있는 주소를 테스트 대상으로 사용하세요. URL을 입력할 수 있다면 프로토콜, 도메인, 경로가 모두 포함됐는지 확인합니다. 대상의 리디렉션, 로그인 요구, 일시적인 접근 제한도 결과에 영향을 줄 수 있습니다. 자주 바뀌는 서비스 페이지 하나만을 기준으로 삼지 마세요. 테스트 대상을 바꿀 때는 대상만 변경하고 제한 시간이나 서버는 동시에 바꾸지 않아야 결과 변화의 원인을 알 수 있습니다.

제한 시간이 너무 짧으면 연결 설정에 시간이 걸리는 정상 경로도 실패로 처리될 수 있고, 너무 길면 대기 시간이 늘어 일괄 테스트에서 문제를 알아보기 어려워집니다. 기본값은 현재 앱에 표시된 값을 기준으로 합니다. 먼저 기존 값을 유지하고 같은 조건에서 여러 번 테스트했을 때 제한 시간에 가까운 결과가 반복되는 경우에만 조정을 고려하세요. 제한 시간을 늘려도 잘못된 인증 정보, 포트, 만료된 인증서는 수정되지 않으며 연결할 수 없는 대상에 접속할 수 있게 되지도 않습니다. 먼저 오류 유형을 확인하세요.

관찰 결과	알 수 있는 내용	추가 확인이 필요한 내용
주소 또는 포트에 연결 가능	일부 연결 계층에서 응답이 있음	프로토콜, 인증, 실제 대상
Connectivity Test 성공	이번 테스트 조건에서 대상에 접속 가능	실제 요청과 규칙 경로
테스트 시간 초과	제한 시간 안에 테스트가 완료되지 않음	DNS 조회, 연결, 인증, 대상 상태

비교 가능한 테스트 만들기

먼저 현재 선택한 서버를 따로 테스트한 뒤 같은 대상을 사용해 다른 기존 서버와 비교하세요. 테스트 중에는 네트워크, Global Routing, Config를 고정하고 구독을 새로고침하지 마세요. 일괄 테스트는 여러 요청을 동시에 만들 수 있어 단일 요청과 부하 조건이 다릅니다. 일괄 테스트는 선별 용도로만 사용하고 이상 항목은 따로 다시 테스트하세요. 한 번의 정렬 결과만으로 설정을 자주 바꾸지 마세요.

처음 연결을 확인할 때는 실제 접속도 테스트해야 합니다. Home에서 서버를 선택하고 연결 스위치를 켠 다음 대상을 방문하고 Log를 확인하세요. 목록 테스트는 특정 항목을 대상으로 할 수 있지만 실제 요청은 현재 선택한 다른 서버를 사용할 수 있으므로 두 항목이 일치하는지 확인해야 합니다. 전체 절차는 첫 연결 및 Connectivity Test 확인을 참고하세요. 테스트는 성공했지만 페이지가 열리지 않으면 테스트 설정을 초기화하기 전에 대상과 규칙을 비교하세요.

결과를 기록할 때는 테스트 방식, 대상, 네트워크 유형, 선택한 서버, 오류 문구만 적어도 충분합니다. 구독 전체를 공개할 필요는 없습니다. 짧은 시간 안에 반복한 테스트는 그 시간대의 상태만 보여줍니다. 네트워크 조건이 바뀌면 다시 확인하세요. 막연히 더 낮은 수치를 목표로 하기보다 ‘이 포트에 연결할 수 있는가?’처럼 구체적인 질문에 테스트를 활용하면 다음 조치를 정하기 쉽습니다.

Settings › Log · Data

Log와 Data: 실패 단계에 따라 기록 확인

Log는 연결 과정을 파악하는 데, Data는 트래픽 관련 정보를 확인하는 데 사용합니다. 둘 다 명확한 시간 범위를 정해 해석해야 합니다. 통계량이 증가했다는 것은 해당 집계 범위에 데이터가 포함됐다는 뜻일 뿐, 특정 페이지가 정상적으로 로드됐다는 증거는 아닙니다. 연결 기록이 있다고 해서 요청 전체가 완료된 것도 아닙니다. 문제를 해결할 때는 먼저 대상과 작업 시점을 정한 뒤 기록에서 DNS 조회, 정책 선택, 연결 설정, 오류 단계를 차례로 확인하세요.

기록 범위를 줄인 다음 문제 재현

Log 사용 여부, 상세 수준, 보관 방식은 현재 앱에 표시된 내용을 기준으로 합니다. 문제를 재현하는 동안에는 위치를 파악하는 데 필요한 범위만 기록하고, 끝난 뒤에는 일상 설정으로 되돌리는 것이 좋습니다. 기록이 상세할수록 백그라운드 앱, 페이지의 부가 리소스, 반복 연결이 섞일 수 있습니다. 대상을 먼저 좁히지 않으면 기록이 많아져 오히려 판단하기 어려워집니다. 시작하기 전에 관련 없는 테스트와 구독 업데이트를 중지하고 현재 상태를 기록한 뒤, 대상 작업만 한 번 실행하세요.

화면에서 기록을 지울 수 있다면 필요한 정보를 저장했는지 먼저 확인한 뒤 이번 관찰 범위의 기록을 정리하세요. 지우지 않는 경우에는 시작 위치나 작업 시간을 기록해 두면 됩니다. 그런 다음 대상 연결을 새로 만들어 브라우저가 이전 연결을 재사용해 일치하는 새 기록이 남지 않는 일을 피하세요. 한 번의 재현 과정에서 관련 없는 여러 페이지를 동시에 열지 마세요. 페이지의 주요 요청과 다른 리소스 요청을 구분하기 어려워지고, 끝부분에 나타난 오류를 현재 대상의 오류로 잘못 판단할 수 있습니다.

DNS 조회, 연결, 인증, 서비스 응답 구분

DNS 단계에서 결과를 얻지 못했다면 DNS 설정을 다시 확인하세요. 주소를 받은 뒤 연결이 시간 초과되면 네트워크, 포트, 선택한 경로를 확인해야 합니다. 인증 또는 핸드셰이크 오류가 나타나면 서버 설정 항목이 기존 정보와 일치하는지 살펴보세요. TLS 관련 오류는 이름, 인증서 조건, 기기 시간도 확인해야 합니다. 대상 서비스에서 거부 또는 서비스 응답을 받았다면 앞선 네트워크 단계는 이미 통과했을 가능성이 높으므로 응답 자체를 중심으로 다음 단계를 정하세요.

규칙 문제를 확인할 때 중요한 것은 ‘기록에 이 도메인이 나타났는가’만이 아닙니다. 어떤 규칙과 일치했는지, 어떤 정책을 선택했는지, 최종적으로 어디에 연결하려 했는지 확인해야 합니다. 웹페이지 하나에 여러 도메인이 포함될 수 있으므로 기본 도메인이 정상이라고 해서 다른 리소스에도 같은 정책이 적용됐다고 볼 수 없습니다. 먼저 실제로 실패한 요청을 찾고 그 요청의 일치 결과를 확인하세요. Log에 필요한 항목이 없다면 누락된 정보를 추측하지 말고 규칙 하나씩 비교하거나 반복 테스트해 가설을 검증하세요.

실패 단계	먼저 확인할 항목	피해야 할 오판
DNS 조회	DNS 출처와 진입점 연결 가능 여부	곧바로 서버 비밀번호 문제라고 단정
연결 설정	주소, 포트, 네트워크, 정책	시간 초과만으로 규칙 구문 오류라고 판단
인증 또는 핸드셰이크	프로토콜 항목, TLS 이름, 기기 시간	값 불일치를 제한 시간 연장으로 해결하려 하기
서비스 응답	대상 서비스와 실제 요청	모든 오류 페이지를 연결 실패로 취급

트래픽 통계와 개인정보 보호

Data의 집계 범위, 누적 시작 시점, 표시 단위는 현재 화면의 안내에 따라 해석해야 합니다. 연결 중에는 다른 앱에서도 트래픽이 발생할 수 있고 페이지 캐시로 인해 이번에 추가된 데이터가 거의 없을 수도 있으므로, 총량만으로 특정 요청의 전체 크기를 계산할 수 없습니다. 비교하려면 관찰 시간을 고정하고 명확한 작업을 한 번만 실행한 뒤 전후 변화를 기록하세요. 통계가 초기화되거나 기기를 다시 연결했다면 집계 범위가 달라졌음을 결론에 적어 두세요.

Log에는 대상 도메인과 주소, 서버 이름 등 사용 상황을 드러낼 수 있는 정보가 포함될 수 있습니다. 공유하기 전에 구독 주소, 인증 정보, 개인 식별 정보, 문제와 관계없는 접속 기록을 제거하고 문제 해결에 필요한 최소한의 내용만 남기세요. 일반적인 주소처럼 보여도 접속 정보가 포함돼 있을 수 있습니다. 전체 내보내기 파일을 공개 게시물에 올리지 마세요. 예시를 만들 때는 실제 도메인을 example.com으로 바꾸되 오류 유형과 필드 구조는 유지할 수 있습니다.

문제 해결이 끝나면 변경한 설정을 복원하거나 명확한 새 기준 상태로 저장하고, 더 이상 필요하지 않은 상세 기록은 끄세요. 원인을 파악하지 못했다면 ‘예상 동작, 실제 동작, 고정 조건, 변경한 항목 하나, 관련 오류’ 다섯 가지를 정리해 범위를 더 좁히세요. 이렇게 하면 같은 시도를 반복하지 않으면서 필요한 맥락을 남길 수 있습니다. ‘연결할 수 없음’이라는 한 줄이나 오류가 잘린 화면만으로는 어떤 설정을 바꿔야 할지 판단하기 어렵습니다.

Settings › Widget · iCloud

Widget, iCloud 동기화, 기존 구독 관리

Widget은 빠른 실행 경로나 상태 표시를 제공하고, iCloud 옵션은 지원 범위에서 앱 데이터를 저장하거나 동기화합니다. 둘 다 연결 경로 설정은 아닙니다. 홈 화면 표시가 바로 바뀌지 않아도 시스템 연결에 문제가 있다고 단정할 수 없습니다. 다른 기기에 구성이 나타나더라도 해당 기기에서 같은 서버를 선택하고 같은 Global Routing을 사용하는 것은 아닙니다. 편의 기능과 실제 연결 상태는 따로 확인해야 합니다.

Widget 표시와 실제 연결 상태

Widget의 제공 형태, 표시 항목, 기본 동작은 현재 시스템과 앱에 표시된 내용을 기준으로 합니다. 시스템에서 위젯을 갱신하는 시점에 따라 표시 내용이 앱을 열었을 때의 상태와 다를 수 있습니다. 상태가 맞지 않으면 먼저 Shadowrocket을 열어 연결 스위치, 선택한 서버, 현재 구성을 확인한 다음 시스템 연결 상태를 살펴보세요. 위젯에 이전 내용이 남아 있다고 연결 조작을 반복하지 마세요. 상태를 추적하기가 더 어려워질 수 있습니다.

Widget을 추가하거나 조정한 뒤에는 실제로 앱 열기, 상태 표시, 기능 실행 중 어떤 동작을 제공하는지 테스트한 다음 사용하세요. 관련 설정이 보이지 않는다면 같은 이름의 구성 필드를 찾기보다 기기의 시스템 지원 여부와 앱 안내를 먼저 확인하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. Widget은 필요한 메뉴를 빠르게 여는 데 유용하지만 특정 도메인이 프록시를 거쳤는지 판단하는 근거로는 적합하지 않습니다.

동기화 범위, 충돌, 복원 순서

iCloud 동기화의 기본 스위치와 적용 범위는 현재 앱에 표시된 값을 기준으로 합니다. 사용하기 전에 시스템 계정과 앱의 iCloud 권한을 확인하고 현재 정상 작동하는 구성을 따로 보관하세요. 동기화가 전체 백업을 뜻하는 것은 아닙니다. 모든 서버, 기록, 시스템 권한, 연결 상태가 함께 옮겨진다고 단정하지 마세요. 앱에서 실제로 제공하는 동기화 항목을 기준으로 구성 파일, 서버 목록, 관련 옵션이 각각 제대로 반영됐는지 확인해야 합니다.

여러 기기에서 같은 내용을 동시에 편집하면 변경 순서를 파악하기 어려울 수 있습니다. 한 기기에서 먼저 수정하고 다른 기기에 반영된 것을 확인한 뒤 계속 편집하세요. 이전 내용이 다시 나타나면 반복 수정을 멈추고 양쪽에서 보존할 내용을 각각 저장한 다음 차이를 비교해 어떤 내용을 유지할지 결정합니다. 동기화를 강제로 맞추려고 한쪽 데이터를 바로 지우지 마세요. 동기화가 삭제나 덮어쓰기 결과를 계속 전파할 수 있습니다.

동작	해결하는 문제	단정해서는 안 되는 내용
iCloud 동기화	지원 범위 내에서 앱 데이터 교환	시스템 권한과 연결 상태가 모두 동일함
구독 새로고침	사용자가 보유한 구독 내용 다시 가져오기	다른 기기에서 같은 항목이 자동으로 활성화됨
Config 수동 가져오기	구성 파일 추가 또는 업데이트	가져온 파일이 현재 활성 구성으로 설정됨

구독 업데이트는 앱 데이터 동기화와 다릅니다

Subscribe에 저장된 기존 구독은 해당 업데이트 방식에 따라 내용을 다시 가져와야 합니다. iCloud에 구독 항목이 나타나더라도 구독 주소가 현재 유효하다거나 내용이 새로고침됐다는 뜻은 아닙니다. 수동 업데이트, 앱을 열 때 자동 업데이트, 항목별 업데이트의 차이는 구독 업데이트 방식 안내에서 확인하세요. 문제를 해결하는 동안에는 먼저 항목 하나만 업데이트해 내용이 달라졌는지 확인하세요. 일괄 작업은 개별 항목의 오류를 가릴 수 있습니다.

업데이트가 성공하면 완료 메시지만 보지 말고 항목 수와 선택 상태가 예상과 일치하는지 확인하세요. 선택해 둔 서버가 원본의 새 내용으로 바뀌었을 수 있으므로 이름이 비슷하다고 설정도 같다고 볼 수는 없습니다. 목록이 비어 있거나 파싱 오류가 표시되면 기존에 사용할 수 있는 내용을 먼저 보존한 뒤 주소 전체, 원본 상태, 반환된 내용을 확인하세요. 자세한 순서는 구독 파싱 오류 또는 빈 목록 자가 점검에서 확인할 수 있습니다. 같은 주소를 반복해서 삭제하고 다시 추가하지 마세요.

기기를 바꿔 복원할 때는 먼저 앱을 설치하고 시스템 권한을 설정한 다음 동기화 데이터와 현재 선택을 확인하고 실제 연결을 테스트하세요. App Store 구매 복원과 iCloud 데이터 동기화는 별도의 절차입니다. 구매 내역만으로 앱 구성이 복원됐다고 볼 수 없습니다. 관련 구매 절차는 구입 항목 복원 안내를 참고하세요. 복원이 끝난 뒤 자동 업데이트와 On Demand를 설정하면 여러 백그라운드 동작이 동시에 발생해 혼동되는 일을 줄일 수 있습니다.

Settings › Proxy · Add Server

Proxy 포트와 서버 설정: 로컬과 원격 구분

Proxy 포트는 먼저 어느 위치의 포트인지 구분해야 합니다. Add Server에 입력하는 포트는 사용자가 보유한 원격 서버의 설정이므로 해당 서비스 정보와 일치해야 합니다. Settings에 로컬 프록시 수신 옵션이 있다면 그 포트는 기기의 로컬 진입점입니다. 두 포트의 용도는 다르므로 숫자가 같아도 서로 바꿔 쓸 수 없습니다. 변경하기 전에 메뉴 이름, 주소, 해당 포트를 사용하는 대상을 기록하고 ‘누가 이 포트에 연결하는가?’부터 확인하세요.

로컬 수신 주소, 포트, 접근 범위

로컬 HTTP 또는 SOCKS5 진입점의 제공 여부와 활성화 상태, 기본 포트는 현재 앱에 표시된 내용을 기준으로 하며 고정된 숫자로 가정하지 않습니다. 현재 기기의 프로그램만 사용한다면 필요한 최소 범위로 제한하는 것이 좋습니다. LAN 접근을 허용하면 접속 가능한 사용자 범위가 달라지므로 인증, 네트워크 신뢰도, 실제 용도를 함께 고려해야 합니다. 웹페이지 오류 하나를 확인하려고 추가 수신 기능을 켜서 관련 없는 변수를 늘리지 마세요.

포트 사용 중 문제와 포트 오류는 서로 다른 문제입니다. 수신 기능을 시작할 수 없다면 다른 기능이 해당 포트를 사용 중인지, 옵션이 실제로 적용됐는지 확인하세요. 원격 서버에 연결할 수 없다면 서버 주소, 원격 포트, 네트워크 경로를 확인해야 합니다. 원격 포트를 로컬 수신 포트로 바꿔도 서버 설정은 수정되지 않습니다. 시스템 네트워크 환경이 바뀌면 접근 가능한 로컬 주소도 달라질 수 있으므로 이전 네트워크에서 사용하던 주소만으로 현재 상태를 판단하지 마세요.

프로토콜 항목은 기존 서버 정보와 일치해야 합니다

Add Server에서 먼저 프로토콜 유형을 확인한 뒤 해당 프로토콜에 필요한 항목을 점검하세요. Shadowsocks의 암호화 방식과 비밀번호, VMess 또는 VLESS의 식별 정보와 전송 설정, Trojan의 비밀번호와 TLS 관련 항목은 각각 의미가 다릅니다. 이름이 비슷한 항목도 서로 바꿔 쓸 수 있는 것은 아닙니다. 사용자가 보유한 서버 정보를 기준으로 하나씩 입력하고, 임의로 프로토콜을 바꾸거나 다른 항목의 설정을 복사해 연결을 시도하지 마세요.

서버 주소, TLS에 사용할 이름, 특정 전송 방식의 Host는 서로 다른 항목일 수 있습니다. 주소는 최초 연결 대상을 결정하고 이름 관련 항목은 해당 핸드셰이크나 요청 처리에 사용되므로 기존 서버 구성과 대조해야 합니다. 인증서 오류가 발생했다고 인증서 검증을 끄는 것을 일반적인 해결책으로 권장해서는 안 됩니다. 먼저 이름이 일치하는지, 기기 시간이 정확한지, 구성 원본이 완전한지 확인한 뒤 서버 인증서 상태를 점검하세요. 설정 항목의 오류를 검증 완화로 감추지 마세요.

항목 위치	의미	값의 출처
로컬 Proxy 포트	기기에서 프록시에 접속하는 위치	현재 앱과 로컬 사용 목적
Add Server 포트	원격 서버에 접속하는 위치	사용자가 보유한 서버 정보
TLS 이름 관련 항목	핸드셰이크 및 이름 일치에 필요한 정보	해당 서버의 실제 설정
전송 경로 및 Host	특정 전송 방식에서 사용하는 요청 설정	해당 전송 방식의 기존 설정값

전송 지원 여부를 기준으로 오류 확인

TCP 요청은 정상인데 다른 유형의 요청이 실패하면 프로토콜, 서버, 네트워크가 해당 전송 방식을 지원하는지 확인하세요. 웹페이지가 열린다고 해서 모든 UDP 또는 실시간 서비스도 연결된다고 볼 수는 없습니다. WireGuard, Hysteria2 등의 프로토콜에도 각각 주소, 인증, 전송 요건이 있으므로 실제 설정 항목을 확인해야 합니다. 여기서는 확인 방법만 안내하며 연결에 사용할 인증 정보를 제공하거나 서버에 특정 기능이 활성화됐다고 가정하지 않습니다.

구독을 가져오면 수동 입력을 줄일 수 있지만 파싱된 항목이 원본 정보와 일치하는지 확인해야 합니다. 구독으로 생성된 항목을 수정하기 전에 다음 새로고침에서 변경 내용이 덮어써지는지 확인하세요. 테스트가 필요하면 기존 항목을 보존하고 테스트용 사본을 구분해 두세요. 그래야 다음 업데이트 뒤 앱이 변경 사항을 저장하지 않았다고 오해하지 않습니다. 수동 추가 절차는 Add Server 튜토리얼에서, 기존 구독 가져오기는 Subscribe 튜토리얼에서 확인할 수 있습니다.

확인 순서는 주소와 포트, 프로토콜과 인증, TLS 및 전송 항목, 실제 대상 접속입니다. 각 단계를 확인할 때마다 새 연결로 다시 테스트하고 Log에서 실패 단계가 바뀌었는지 살펴보세요. 오류가 시간 초과에서 인증 실패로 바뀌었다면 확인 범위가 달라졌다는 뜻이지, 문제가 해결됐다는 뜻은 아닙니다. 설정값이 기존 서버 정보와 일치하고 실제 요청까지 완료된 뒤에야 해당 항목을 이후 규칙 문제 해결의 기준으로 삼을 수 있습니다.

Config › Rule

Config 규칙과 단계별 문제 해결 절차

Config는 규칙과 관련 설정을 함께 관리합니다. 파일 가져오기, 사용할 파일 선택, 새 연결에 해당 파일 적용은 각각 확인해야 하는 별도의 단계입니다. 문제를 해결하기 전에 Config에서 실제 활성 항목을 확인한 뒤 Home으로 돌아가 Global Routing이 Config인지 확인하세요. Proxy 또는 Direct가 선택되어 있으면 전체 처리 방식이 달라진 상태이므로 규칙에서 예상한 정책만으로 모든 접속 결과를 설명할 수 없습니다. 먼저 조건을 동일하게 맞춘 뒤 개별 규칙을 살펴보세요.

규칙은 위에서 아래로 확인하며 먼저 일치한 규칙이 적용됩니다

규칙 순서도 결과의 일부입니다. 범위가 넓은 규칙이 앞에 있으면 뒤의 구체적인 규칙이 일치할 기회를 얻지 못할 수 있습니다. DOMAIN은 지정된 도메인, DOMAIN-SUFFIX는 도메인 접미사와 그 범위, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치합니다. IP-CIDR과 IP-CIDR6은 주소 대역을 설명하고, GEOIP는 주소의 지역 분류 정보를 기준으로 합니다. 앞선 규칙과 일치하지 않은 경우에는 FINAL이 후속 처리를 담당합니다. 규칙 유형을 선택하기 전에 도메인과 주소 중 무엇을 대상으로 할지 먼저 정하세요.

키워드	일치 대상	확인할 항목
DOMAIN	지정된 도메인	도메인 철자가 실제 요청과 일치하는지
DOMAIN-SUFFIX	도메인 접미사 범위	범위가 지나치게 넓지 않은지, 앞에 규칙이 있는지
DOMAIN-KEYWORD	도메인에 포함된 키워드	다른 대상까지 잘못 포함하는지
IP-CIDR / IP-CIDR6	해당 주소 대역	주소 유형, 네트워크 대역, 조회 결과
GEOIP	주소 지역 분류	사용 중인 데이터와 실제 주소
FINAL	앞선 규칙과 일치하지 않은 연결	규칙의 마지막에 있는지, 정책이 올바른지

최소한의 규칙 조각으로 정책 확인

아래는 규칙 구문 예시이며 모든 환경에 맞는 완전한 구성은 아닙니다. example.com은 예시 도메인입니다. PROXY, DIRECT, REJECT는 정책 키워드이며 서버 프로토콜이 아닙니다. 사용할 때는 현재 정상 작동하는 Config를 복사해 사본에서 조정하고 원본 파일을 보관하세요. 필요한 다른 내용이 포함된 구성 위에 예시 조각을 그대로 덮어쓰지 마세요. 예시에 GEOIP가 있다고 해서 반드시 해당 방식으로 트래픽을 분리해야 한다고 생각해서도 안 됩니다.

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

각 줄은 먼저 일치 유형, 다음으로 일치 값, 마지막으로 정책을 확인하세요. DIRECT는 대상에 직접 연결하고, PROXY는 해당 프록시 경로로 전달하며, REJECT는 일치하는 연결을 거부합니다. 특정 도메인의 정책을 테스트하려면 범위가 명확한 테스트 규칙을 이를 가릴 수 있는 광범위한 규칙보다 앞에 두고 새 연결을 만들어 일치 결과를 확인하세요. 테스트가 끝나면 임시 규칙을 오래 유지해 다른 접속 동작을 바꾸지 않도록 원래 순서로 복원하세요.

GEOIP와 주소 대역 규칙은 대상 주소를 기준으로 하고 도메인 규칙은 요청의 도메인 정보에 의존합니다. 요청 형태와 DNS 조회 단계에 따라 규칙이 사용할 수 있는 정보가 달라질 수 있으므로 같은 웹사이트라도 접속할 때마다 동일한 기록이 남는 것은 아닙니다. 주소 규칙과 일치했다면 DNS 반환값을 함께 고려하세요. 키워드 규칙이 다른 대상을 잘못 포함한다면 광범위한 예외를 계속 추가하기보다 DOMAIN 또는 적절한 접미사 규칙으로 범위를 좁히세요.

설정 변경을 검증 가능한 결론으로 마무리하기

문제 해결은 증상 설명부터 시작합니다. 실패한 대상, 현재 네트워크, 선택한 서버, Global Routing, 활성 Config를 구체적으로 정리하세요. 그런 다음 문제가 DNS 조회, 연결, 인증, 규칙 중 어느 단계에서 발생하는지 판단하고 근거가 가장 분명한 항목 하나만 변경합니다. 다시 연결해 새 요청을 만들고 결과가 일관되게 달라지는지 확인하세요. 변화가 없다면 두 번째, 세 번째로 관련 없는 항목을 더하지 말고 원래 값으로 되돌려 설정이 실제로 적용됐는지 확인하세요.

문제를 해결한 뒤에는 원래 정상 작동하던 대상 하나와 로컬 접속 환경 하나도 확인해 수정의 영향 범위가 커지지 않았는지 살펴보세요. 최종 설정과 변경 이유를 개인 구성 안내에 기록하고 테스트 사본에서 민감한 정보를 삭제한 뒤 필요한 구독 업데이트와 On Demand를 다시 활성화합니다. 다음에 문제가 생기면 모든 Settings를 처음부터 다시 시도하기보다 이 기준 상태와 비교하세요. 앱 업데이트와 구독 업데이트의 영향도 각각 따로 기록해야 합니다.

자주 발생하는 문제는 이 페이지의 항목별로 확인할 수 있습니다. DNS 조회 오류는 DNS, 자동 연결 문제는 On Demand, 테스트 결과와 실제 접속의 차이는 Ping, 상태 확인은 Log, 데이터 불일치는 동기화, 핸드셰이크 오류는 서버 설정, 정책 불일치는 규칙 순서를 살펴보세요. 구매 및 복원 문제는 가격 및 일회성 구매 안내와 구입 항목 복원에서 확인하세요. App Store 구매 절차를 네트워크 설정 변경으로 해결하려 하지 마세요.