Shadowrocket 설정 자세히 알아보기

01 / Scope

설정 범위, 기본값 및 변경 전 기준

Settings, Config, 서버 항목의 차이

Shadowrocket의 설정은 모든 항목이 한꺼번에 적용되는 단일 목록이 아닙니다. Settings의 앱 설정, Config의 구성 파일, 서버 편집 화면의 연결 매개변수는 서로 다른 영역을 다룹니다. 예를 들어 DNS는 Config와 앱 설정 양쪽에 관련 항목이 있을 수 있지만, 서버 주소는 연결 종단점에 해당합니다. 문제를 진단하기 전에 어느 영역을 편집하는지 확인하세요. 저장에 성공해도 실제 요청을 처리하는 설정이 바뀌지 않을 수 있습니다.

Home에서는 현재 연결 상태와 서버 선택을 확인하고, Config에서는 구성 파일을 관리하거나 선택하며, Settings에서는 앱 설정을 살펴봅니다. 이 글에서는 인터페이스 항목을 영어 그대로 표기합니다. 구체적인 메뉴 위치와 표시되는 항목은 기기의 실제 화면을 기준으로 확인하세요. 같은 이름의 설정을 찾으면 주변 설명과 현재값, 선택 가능한 범위를 먼저 읽고 조작하세요. 다른 기기의 스크린샷에서 본 위치만으로 스위치를 찾지 마세요. Config에 없는 항목을 중국어 설명만 보고 임의로 만들어 입력해서도 안 됩니다.

‘기본값’은 새 Config의 초기 내용, 앱을 처음 실행할 때의 설정, 구독이나 구성 파일을 가져온 뒤의 값 등 여러 의미로 쓰입니다. 이 값들은 서로 같지 않습니다. 기기를 복원하면 이전 기기의 설정이 이어질 수 있고, Config를 다시 선택하면 다른 파일이 적용될 수도 있습니다. 이 페이지에서 기록할 값은 ‘변경 전 실제 적용값’입니다. 확인되지 않은 기본값보다 복구 기준으로 적합하며, 문제가 이번 변경으로 발생했는지도 판단할 수 있습니다.

기록을 남겨 되돌릴 기준 만들기

시작하기 전에 현재 Global Routing, 선택된 서버, 활성 Config를 기록하세요. 문제가 발생했을 때 Wi-Fi를 사용했는지 셀룰러 네트워크를 사용했는지도 적어 두세요. 서버 이름은 개인 기록에서 구분할 수 있으면 충분하며, 다른 사람에게 공개할 필요는 없습니다. 변경할 Config의 사본도 저장하고, ‘지정한 도메인이 예상한 정책을 따르는지 확인’처럼 변경 목적을 적어 두세요. 이 기록은 앱 로그가 아니라 문제 해결 과정에서 처음 상태를 잊지 않도록 남기는 테스트 조건입니다.

한 번에 하나의 변수만 바꾸세요. DNS, 서버, 라우팅 방식, 테스트 방법을 동시에 변경하면 연결이 복구되어도 무엇이 영향을 미쳤는지 알 수 없습니다. 다음에 같은 문제가 생기면 다시 처음부터 확인해야 합니다. 한 차례 점검은 변경 전 테스트, 단일 항목 변경, 연결 재설정, 같은 대상으로 재테스트, 기록 확인, 유지 또는 되돌리기로 진행합니다. Config를 수정했다면 저장한 파일이 현재 활성 Config로 선택되어 있는지도 확인하세요.

‘권장값’도 사용 조건에 따라 달라집니다. 정상 작동하는 기기라면 검증된 설정을 유지하는 것이 일반적입니다. 문제가 있는 기기라면 설명할 수 있는 최소한의 설정으로 돌아간 뒤 기능을 하나씩 복구하세요. 숫자를 높이거나 시간 제한을 늘리고 더 많은 옵션을 켠다고 안정성이 저절로 향상되지는 않습니다. 특히 네트워크 연결 가능 여부와 관련된 설정은 클라이언트의 요청 처리 방식만 바꿀 뿐, 서버 상태와 인증 정보의 유효성, 현재 네트워크의 접속 조건을 대신할 수 없습니다.

Config 예시의 example.com은 설명용 도메인이며 연결 가능한 서비스를 뜻하지 않습니다. PROXY와 DIRECT는 정책 키워드입니다. 인터페이스의 Global Routing에 표시되는 Proxy, Direct와 표기 및 적용 범위를 구분해야 합니다. 예시에 포함된 예약 주소는 매칭 동작을 설명하기 위한 것이므로 그대로 복사할 필요가 없습니다. 기존 Config에 사용자 지정 정책이 있다면 정의를 먼저 확인한 뒤 참조하세요. 해석할 수 없는 정책 이름을 입력하지 않도록 주의해야 합니다.

아직 첫 연결도 완료하지 못했다면 복잡한 설정을 조정하기 전에 시작 가이드의 전체 절차를 따라 진행하세요. 오류 메시지가 명확하다면 자주 묻는 질문을 참고해 문제 범위를 좁힐 수 있습니다. 다음 장에서는 DNS, 라우팅, 연결 트리거, 테스트, 관찰, 동기화, 복구 순서로 살펴봅니다. ‘설정이 맞아 보이는 상태’를 ‘실제 요청으로 확인한 상태’로 바꾸는 것이 이 순서의 목적입니다.

02 / DNS

DNS 설정과 도메인 확인 경로

DNS가 해결하는 문제

DNS는 도메인을 주소로 변환하지만, ‘이름 확인 성공’이 곧 ‘연결 성공’을 뜻하지는 않습니다. 주소를 확인한 뒤 서버 연결, 암호화 세션 설정, 요청 처리 단계에서 실패할 수 있습니다. 반대로 Proxy 서버 주소가 도메인이라면 Proxy에 연결하기 전부터 주소 확인이 필요할 수도 있습니다. 따라서 대상 웹사이트의 이름 확인 실패와 Proxy 서버 주소의 이름 확인 실패를 구분해야 합니다. 두 문제는 서로 다른 단계에서 발생하므로 같은 설정을 바꿔도 모두 해결되지 않을 수 있습니다.

Config에서 현재 활성 파일의 [General]을 열어 dns-server가 있는지 확인하세요. 아래 예시의 system은 시스템에서 제공하는 DNS 설정을 사용한다는 의미로, 이해를 돕기 위한 시작점입니다. 모든 파일에 이 행이 자동으로 포함된다는 뜻은 아닙니다. 실제 동작은 현재 네트워크 환경의 영향을 받습니다. 앱에 DNS 관련 옵션이 있다면 함께 기록하세요. 파일의 한 줄만 보고 모든 요청이 같은 경로로 DNS 확인을 한다고 단정할 수 없습니다.

[General]
bypass-system = true
dns-server = system

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

이 예시는 앱 수준의 처리, DNS 확인 출처, 규칙 매칭을 함께 보여주지만, 각 설정 행은 서로 다른 역할을 합니다. bypass-system은 별도의 Config 옵션이지 DNS 문제를 해결하는 범용 스위치가 아닙니다. dns-server는 DNS 설정을 지정하고, [Rule]은 요청이 규칙과 일치한 뒤 적용할 정책을 정합니다. 행을 복사하기 전에 원본 파일에서의 위치, 중복 항목, 기존 규칙과 충돌하는지 확인하세요. 필요한 다른 섹션도 유지해야 합니다.

기본값과 권장값 판단 방법

DNS 초기값은 현재 Config와 앱 화면에서 확인하세요. 이 페이지에서는 모든 네트워크에 적합한 공용 DNS 주소를 지정하거나 특정 DNS 서비스를 일률적으로 권장하지 않습니다. DNS 문제가 없는 기기라면 검증된 설정을 유지하세요. 특정 네트워크에서만 문제가 발생하면 먼저 해당 네트워크와 다른 네트워크의 결과를 비교하세요. 문제가 DNS 확인 단계에 있다고 판단될 때만 DNS 출처를 바꾸고, 같은 도메인으로 반복 테스트하세요.

기존 Config에서 암호화 DNS를 사용한다면 DNS 종단점에 연결할 수 있는지, 도메인 확인이 먼저 필요한지, 현재 라우팅에서 어떤 경로로 연결되는지 확인하세요. DNS 방식을 다른 프로토콜로 바꿔도 선행 조건이 자동으로 없어지지는 않습니다. 문제가 생기면 먼저 단순하고 관찰하기 쉬운 조건으로 기본 경로를 확인한 다음 기존 DNS 설계를 복구하세요. 종단점을 계속 추가하면 실패 시 실제로 어느 종단점이 요청에 관여하는지 구분하기 어려워집니다.

도메인 규칙과 주소 규칙도 관찰 결과에 영향을 줍니다. DOMAIN-SUFFIX는 도메인 접미사로 매칭하고, IP-CIDR은 주소 범위로 매칭합니다. 주소 기반 판정에는 DNS 확인이 관여할 수 있습니다. 네트워크에 따라 같은 도메인이 서로 다른 주소로 확인되면 이후 주소 규칙의 결과도 달라질 수 있습니다. ‘왜 이 규칙이 적용됐는지’ 확인할 때는 마지막 정책만 보지 말고 요청 도메인, DNS 결과, 규칙 순서를 함께 확인하세요.

캐시와 로컬 네트워크 이름의 범위

DNS 캐시는 앱, 시스템, 상위 네트워크 등 여러 곳에 존재할 수 있습니다. DNS를 바꿔도 이전 결과가 모두 바로 사라지는 것은 아니며, 웹페이지가 기존 연결을 재사용할 수도 있습니다. 검증할 때는 Config를 저장하고 연결을 다시 설정한 뒤 새 요청을 보내세요. 캐시의 영향을 확인해야 한다면 재현 가능한 절차로 테스트하세요. 데이터를 무작정 지우면 로그인 상태나 다른 문제의 증거까지 함께 사라질 수 있습니다.

로컬 네트워크 기기 이름, 내부 도메인, 공개 도메인은 같은 DNS 조건을 사용하지 않을 수 있습니다. 외부 DNS로 바꾸면 내부 이름이 기존처럼 확인되지 않을 수 있습니다. 가정이나 사무실 네트워크의 기기에만 문제가 생긴다면 해당 네트워크의 DNS 요구 사항, 주소 범위, 직접 연결 규칙을 먼저 확인하세요. 공개 웹사이트 접속이 된다고 내부 이름 설정도 올바르다는 뜻은 아닙니다. 내부 이름 하나를 고치려고 모든 요청의 라우팅을 바꾸지 마세요.

수정 후에는 이전에 정상 작동한 대상, 실패했던 대상, 실제로 필요한 로컬 네트워크 대상을 각각 하나 이상 확인하세요. 주소 확인 여부, 연결 성립 여부, 콘텐츠 반환 여부를 기록합니다. DNS 확인은 성공했는데 콘텐츠가 계속 실패한다면 DNS를 계속 바꾸지 말고 라우팅, 서버 매개변수, 대상 서비스 쪽을 확인하세요. 단계별 결과를 기록해 두면 이후 Log를 분석할 때 명확한 맥락을 확보할 수 있습니다.

03 / Routing & Proxy

Global Routing, 규칙 및 Proxy 포트

세 가지 모드는 서버 설정 세 종류를 뜻하지 않습니다

Global Routing은 요청을 전반적으로 처리할 방식을 정합니다. Config는 Config를 따르고, Proxy는 Proxy 경로를 사용하며, Direct는 직접 연결합니다. Config에서는 활성 Config의 규칙에 따라 정책을 배정합니다. Proxy는 일반적으로 해당 라우팅 설정이 처리할 요청을 Proxy 경로로 보냅니다. Direct는 직접 연결을 사용합니다. 시스템 트래픽, 제외 항목, 개별 Config에 따라 적용 범위가 달라질 수 있으므로 어느 모드도 기기의 모든 네트워크 동작을 절대적으로 설명하지는 않습니다.

Config에서 DIRECT로 표시된 규칙 매칭은 Config에 맞는 정상 결과일 수 있으며, 서버 장애를 뜻하지 않습니다. 반대로 Proxy로 바꾼 뒤 대상이 정상화됐더라도 처리 경로 변경이 결과에 영향을 줬다는 사실만 확인할 수 있습니다. 특정 규칙이 잘못됐다고 단정할 수는 없습니다. Config로 돌아가 대상에 적용된 행, 앞에 더 넓은 범위의 규칙이 있는지, 정책이 실제로 어디를 가리키는지 확인한 뒤 규칙을 변경하세요.

일상적으로 사용할 모드는 사용자가 명확히 정한 Config 목적에 따라 선택하세요. 확인된 분기 규칙이 있다면 Config를 사용하고, Proxy 경로를 잠깐 비교할 때는 Proxy로 전환할 수 있습니다. 직접 연결 조건을 확인할 때는 Direct를 임시로 사용하세요. 테스트가 끝나면 원래 모드로 돌리고 연결을 다시 설정하세요. 잘못된 규칙을 가리려고 테스트용 모드를 계속 사용하지 마세요. 로컬 네트워크와 다른 대상의 연결 경로까지 함께 바뀔 수 있습니다.

규칙 순서와 정책의 의미

규칙은 일반적으로 위에서 아래 순서로 검사하며, 구체적인 규칙은 기본 처리 규칙보다 앞에 두어야 합니다. 아래 예시는 샘플 도메인과 사설 주소를 먼저 처리하고, 일치하는 규칙이 없는 요청은 마지막의 FINAL로 처리합니다. 여기의 FINAL,PROXY는 기본 경로로 Proxy를 사용하도록 의도한 예시이지 모든 사용자가 그대로 복사해야 하는 기본값이 아닙니다. FINAL,DIRECT로 바꾸면 일치하지 않은 요청의 경로가 달라지므로 단일 도메인보다 훨씬 넓은 범위에 영향을 줍니다.

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

같은 규칙을 반복 추가해 ‘우선순위를 높이려’ 하지 마세요. 앞선 규칙이 이미 일치하면 뒤에 있는 동일 대상 규칙은 검사되지 않을 수 있습니다. 먼저 매칭 기록을 확인한 뒤 규칙을 이동하거나 적용 범위를 좁히고, 저장 후 다시 검증하세요. REJECT는 일치하는 요청을 거부한다는 뜻이지 요청을 복구한다는 뜻이 아닙니다. 구체적인 적용 범위는 REJECT 규칙의 순서와 한계를 참고하세요.

원격 서버 포트와 로컬 수신 포트 구분

서버 편집 화면의 포트는 원격 서버가 연결을 받는 위치이므로 사용자가 보유한 서버 정보와 일치해야 합니다. Settings에서 로컬 Proxy 포트를 제공한다면 이는 기기 내 로컬 Proxy 진입점이 연결을 기다리는 포트입니다. 두 값이 우연히 같아도 서로 대신 사용할 수 있는 것은 아닙니다. 로컬 포트를 원격 서버 항목에 입력하거나 원격 서버 포트를 로컬 수신 설정에 넣으면 연결 대상이 완전히 달라집니다.

로컬 포트의 현재값, 프로토콜 종류, 활성화 조건은 실제 화면을 기준으로 확인하세요. 이 페이지에서는 고정 포트 번호를 지정하지 않습니다. 포트 번호가 유효한 것만으로는 충분하지 않습니다. 실제로 서비스가 수신 중인지, 요청을 보내는 쪽이 어떤 Proxy 프로토콜을 사용하는지, 수신 범위가 기기 내부에 한정되는지, 네트워크에서 접근을 허용하는지 확인해야 합니다. 일반적인 iPhone이나 iPad에서 시스템 VPN 설정으로 연결할 때는 ‘속도를 높이기 위해’ 로컬 수신 포트를 임의로 바꾸지 마세요.

로컬 Proxy를 실제로 사용해야 한다면 기존 설정을 먼저 보관하고 요청이 같은 기기에서 오는지, 로컬 네트워크의 다른 기기에서 오는지 확인하세요. 앱이 실제로 지원하는 방식 중 알맞은 것을 선택해야 합니다. HTTP와 SOCKS5 클라이언트 설정을 임의로 섞어 입력하지 마세요. 웹 주소의 경로는 포트 입력란에 넣는 값이 아닙니다. 테스트에 실패하면 포트 번호만 비교하지 말고 수신 기능이 켜져 있는지, 프로토콜이 일치하는지부터 확인하세요.

라우팅이나 포트를 조정한 후에는 일반 네트워크 요청과 특정 로컬 진입점을 각각 검증해 두 테스트 결과를 혼동하지 않도록 하세요. 포트를 바꿔도 일반 연결이 달라지지 않는다면 기존 연결이 애초에 해당 진입점을 사용하지 않았을 수 있습니다. 실제 요청 경로를 기준으로 설정을 확인하세요. 요청을 보낸 주체, 연결 대상, 사용 프로토콜, 적용된 정책을 확인한 다음에야 값을 바꿀 필요가 있는지 판단할 수 있습니다.

04 / On Demand

On Demand 트리거 조건과 중지 방법

자동 트리거는 서버 문제를 해결하지 않습니다

On Demand는 설정한 조건에 따라 VPN 연결을 시작합니다. 이는 ‘언제 연결을 시도할지’를 정하는 기능이지 서버 검증, 구독 업데이트, 라우팅 설정을 대신하지 않습니다. 수동 연결이 안정적으로 작동하고 활성 Config와 서버 선택을 확인한 뒤에 자동 트리거를 설정하세요. 그렇지 않으면 같은 실패 경로를 반복해서 실행해 앱이 설정을 계속 바꾸는 것처럼 보일 수 있지만, 실제로는 조건이 계속 충족되고 있을 뿐입니다.

실제 On Demand 옵션으로 이동해 현재 켜져 있는지, 어떤 조건이 설정되어 있는지, 시스템의 VPN 구성이 남아 있는지 확인하세요. 기본 상태는 현재 기기에 표시된 내용을 기준으로 합니다. 이전 데이터 복원, 앱 재설치, 권한 재승인 뒤에도 처음 사용할 때와 같다고 가정하지 마세요. 시스템과 앱의 상태가 다르면 자동 트리거 설정을 조정하기 전에 수동 연결로 돌아가 기본 Config가 작동하는지 확인하세요.

권장 설정은 ‘모두 켜기’가 아니라 설명 가능한 조건만 남기는 것입니다. 앱에서 네트워크 유형이나 네트워크 식별자별 옵션을 제공한다면 실제 필요에 따라 하나씩 설정하세요. 다른 사람의 네트워크 이름을 그대로 복사하지 마세요. 자동 연결이 당장 필요하지 않다면 수동 제어를 유지해야 상태를 관찰하기 쉽습니다. 네트워크를 자주 바꾸는 기기라면 자주 사용하는 각 네트워크에서 트리거 동작을 따로 확인하세요. 현재 Wi-Fi에서만 테스트해서는 충분하지 않습니다.

자동 연결을 재현 가능한 테스트로 나누기

먼저 같은 네트워크에서 수동 연결을 설정하고, 확인에 사용할 수 있는 대상으로 접속해 실제 적용 정책을 확인하세요. 다음으로 연결을 끊어 정상적으로 중지되는지 살펴봅니다. 세 번째로 필요에 따라 On Demand를 설정한 뒤 실제 네트워크 상태 변화에 따른 트리거 결과를 확인하세요. 테스트 중 서버를 바꾸거나 구독을 업데이트하거나 Config를 변경하지 마세요. 다른 작업이 연결에 영향을 줄 수 있어 트리거 조건이 올바른지 확인하기 어렵습니다.

결과를 관찰할 때는 네 가지를 구분하세요. 조건이 충족됐는지, 시스템이 연결을 시작했는지, 연결이 성립했는지, 연결 후 요청이 정상 작동했는지 확인합니다. 자동 트리거는 시작됐지만 이후 연결에 실패했다면 서버나 네트워크를 확인하세요. 연결 시도 자체가 없다면 트리거 조건과 시스템 설정을 점검해야 합니다. 상태 막대의 VPN 아이콘은 특정 연결 상태만 나타낼 뿐, 대상 콘텐츠가 예상대로 반환된다는 증거는 아닙니다.

네트워크를 전환하면 IP 주소를 다시 받거나 DNS 조건이 바뀌고 기존 연결이 끊길 수 있습니다. 잠깐 다시 연결되는 현상과 연결 실패가 계속 반복되는 현상은 다릅니다. 전환 전후의 네트워크, 트리거 발생 순서, 실패 단계를 기록하는 편이 계속 켜고 끄는 것보다 유용합니다. 새 네트워크에 웹페이지 인증이 필요하다면 먼저 정상적으로 네트워크에 접속한 뒤 On Demand를 확인하세요. 클라이언트의 트리거 설정은 네트워크 자체의 인증 절차를 대신하지 않습니다.

연결을 끊었는데 다시 연결되는 이유

On Demand 조건이 계속 충족되면 한 번 수동으로 연결을 끊어도 자동 트리거 기능은 계속 작동할 수 있습니다. 자동 연결을 확실히 중지하려면 해당 설정에서 먼저 On Demand를 끄고 연결을 해제한 뒤 시스템 상태를 확인하세요. 곧바로 모든 Config를 삭제하지 마세요. 트리거 규칙, 시스템 권한, 서버 매개변수 중 어느 항목에 문제가 있는지 나중에 구분하기 어려워집니다. 중지된 것을 확인한 뒤 기록해 둔 기준에 따라 필요한 설정을 복구하세요.

기기에 다른 VPN 구성이 있거나 조직에서 네트워크 제한을 관리한다면 시스템에서 허용하는 연결 방식도 확인해야 합니다. 이름이 비슷한 Config를 반복해서 만들면 앱이 어떤 Config를 사용하는지 확인하기 어려워집니다. 조직에서 관리하는 기기는 해당 관리 요구 사항을 따라야 하며, 이 페이지의 일반적인 절차로 정식 관리 절차를 대신할 수 없습니다. 개인 기기도 모든 연결 실패를 앱 설정 탓으로 돌리지 말고 시스템에 표시되는 안내를 먼저 확인하세요.

On Demand를 검증할 때는 기기를 잠근 뒤 정상적으로 사용하는 과정도 한 번 확인하세요. 다만 백그라운드 상태 변화만으로 배터리 소모나 성능을 단정하지 마세요. 네트워크 활동, 시스템 정책, 다른 앱도 작동에 영향을 줄 수 있습니다. 임시 테스트를 마친 뒤에는 원래 설정을 복구하세요. 장기간 사용하려면 Config나 네트워크 조건이 바뀐 뒤 다시 확인해 자동 연결이 여전히 명확한 사용 목적에 부합하는지 살펴보세요.

05 / Ping & Connectivity Test

Ping, Connectivity Test 및 결과 해석

먼저 테스트 대상 구간 확인

Ping은 일반적으로 지연 시간 테스트를 뜻하지만, 실제 테스트 방식은 다를 수 있습니다. 네트워크 탐지, 전송 연결 설정, Proxy를 통한 대상 요청은 서로 다른 경로를 확인합니다. 테스트 전에 방식과 대상 설정을 읽고, 버튼 이름만 보고 전체 Proxy 경로를 검증한다고 추측하지 마세요. 방식이 다르면 같은 대상을 테스트해도 결과를 직접 비교하거나 순위를 매겨서는 안 됩니다.

화면에서 ICMP, TCP 또는 요청 방식의 테스트를 제공한다면 각 방식의 한계를 구분하세요. ICMP 탐지는 Proxy 프로토콜 인증을 확인하지 않습니다. TCP 연결은 암호화와 앱 요청을 검증하지 않을 수 있습니다. 요청 방식 테스트는 대상에 실제로 접속하는 상황에 더 가깝지만 대상 서비스와 DNS의 영향을 받습니다. 앱에서 제공하는 방법과 필드는 현재 화면을 기준으로 확인하세요. 이 페이지의 설명에 맞추려고 없는 스위치를 찾을 필요는 없습니다.

Connectivity Test는 선택된 테스트 절차에서 연결이 가능한지 확인합니다. 모든 웹사이트, 모든 프로토콜, 전체 사용 시간에 대한 보증은 아닙니다. 한 번 성공하면 해당 시점의 테스트 조건에서 성공했다는 의미입니다. 한 번 실패해도 테스트 대상에 연결할 수 없었던 것일 수 있으며, 서버 전체가 사용할 수 없다는 뜻은 아닙니다. 먼저 검증된 테스트 방법을 사용하고 대상과 경로를 확인하세요. 문제를 진단할 때만 테스트 방법이나 대상을 변경하세요.

테스트 대상, 시간 제한 및 기본값

테스트 대상의 초기값, 대기 시간, 기타 매개변수는 Settings의 현재 화면에서 확인하세요. 이 페이지에서는 공통 시간 제한(초)을 지정하거나 시간 제한을 계속 늘리는 것을 권장하지 않습니다. 너무 짧게 기다리면 일시적인 지연을 실패로 오인하고, 너무 오래 기다리면 실제 연결 불가 상태가 늦게 확인됩니다. 적절한 값은 같은 조건에서 비교하는 데 도움이 되어야 합니다. 변경 전후의 결과를 기록하고 테스트 목록에 모두 숫자가 표시되는 것만 목표로 삼지 마세요.

테스트 대상을 지정할 수 있다면 사용자가 접근할 권한이 있고 검증에 안정적으로 쓸 수 있는 주소를 선택하세요. 화면에서 요구하는 형식도 확인해야 합니다. 도메인 입력란, 전체 URL 입력란, 서버 주소 입력란은 서로 바꿔 쓸 수 없습니다. 로그인 정보나 비공개 매개변수가 포함된 주소를 공개 문제 해결 자료에 사용하지 마세요. 테스트 대상에서 리디렉션, 인증, 접근 제한이 발생하면 결과에 이런 조건이 포함됩니다. 이를 Proxy 서버의 전송 지연만으로 해석할 수는 없습니다.

여러 대상을 한꺼번에 테스트하면 새로운 변수가 생길 수 있습니다. 동시에 보낸 탐지 요청은 현재 네트워크 자원을 공유하고, 대상의 응답 정책에도 영향을 받을 수 있습니다. 목록의 결과는 변하지 않는 서버 속성이 아닙니다. 특정 대상에 문제가 있으면 해당 항목을 따로 반복 테스트하고 실제 요청 결과와 비교하세요. 대용량 파일을 다운로드하면서 테스트 결과의 차이를 서버 탓으로 돌리지 마세요. 한 번의 순위 비교로 라우팅과 프로토콜 매개변수 확인을 대신해서도 안 됩니다.

지연 시간, 대역폭, 안정성을 각각 확인

응답 시간이 짧다고 지속 전송 속도가 빠르거나 장시간 연결이 안정적이라는 뜻은 아닙니다. 응답 시간은 한 번의 상호작용에 걸리는 시간을 중심으로 봅니다. 지속 전송에는 대역폭, 혼잡, 대상 콘텐츠 서비스, 프로토콜 동작도 영향을 줍니다. 동영상이 끊기거나 파일 전송이 중단되는 문제라면 발생 상황과 지속 시간을 기록하고 관련 요청 로그를 확인하세요. Ping을 반복하는 것만으로는 이런 문제의 원인을 충분히 파악할 수 없습니다.

테스트는 실패했지만 실제 접속이 정상이라면 테스트 대상의 응답 조건이 특별한지 확인하고, 정상 접속 결과를 비교 자료로 남기세요. 테스트는 성공했지만 실제 접속이 실패한다면 서비스 대상의 DNS, 규칙 매칭, 연결 단계, 반환 결과를 확인해야 합니다. 어느 경우든 곧바로 구독을 삭제하지 마세요. 테스트 절차의 실패와 실제 서비스 절차의 실패를 구분해야 테스트 Config를 바꿀지 연결 Config를 바꿀지 판단할 수 있습니다.

Hysteria2처럼 특정 전송 조건에 의존하는 연결은 TCP 탐지로 실제 전송을 대신 검증할 수 없습니다. 프로토콜 작동 조건은 Hysteria2 및 QUIC 기본 안내를 참고하세요. VMess와 VLESS의 항목 확인은 UUID, 암호화 및 전송 방식 안내에서 확인할 수 있습니다. 테스트 옵션으로 잘못 입력한 프로토콜 항목을 보완할 수는 없습니다.

마지막에는 테스트를 많이 남기기보다 구체적인 질문에 답할 수 있는 테스트만 남기세요. 문제가 확인되면 임시 대상과 시간 제한 변경을 일상적으로 검증된 값으로 되돌리고, 특정 방식을 유지하는 이유를 기록하세요. 나중에 같은 문제가 생기면 동일한 조건으로 재현한 뒤 진단 범위를 넓힐지 결정할 수 있어 매번 다른 테스트부터 시작하는 일을 줄일 수 있습니다.

06 / Log & Data

Log, Data 및 단계별 문제 기록

한 번의 요청으로 관찰 범위 설정

Log에서는 요청과 연결 과정을 확인하고, Data에서는 앱이 제공하는 트래픽 등의 기록을 확인할 수 있습니다. 구체적으로 표시되는 내용, 보관 방식, 메뉴 위치는 실제 화면을 기준으로 확인하세요. 트래픽 수치가 늘어도 대상 페이지가 정상적으로 로드됐다는 뜻은 아닙니다. 연결 기록이 있다고 해서 콘텐츠 반환까지 성공한 것도 아닙니다. 로그의 핵심 가치는 문제 발생 단계를 알려주는 데 있으며, 기록 수만 보고 앱이 ‘정상 작동’하는지 판단할 수는 없습니다.

문제 해결을 시작하기 전에 시간 순서에 따라 현재 네트워크, Global Routing, 활성 Config, 선택된 서버, 접속하려는 대상을 기록하세요. 알아보기 쉬운 요청을 한 번 또는 몇 차례만 보내세요. 여러 앱을 동시에 열고 계속 새로고침하면 시스템 활동, 백그라운드 요청, 재시도가 로그에 섞입니다. 가장 최근에 표시된 행만 보면 관련 없는 요청 실패를 현재 확인 중인 서비스의 문제로 오인할 수 있습니다.

로그 상세 수준이나 저장 관련 옵션이 있다면 기본값은 현재 기기 화면에서 확인하세요. 문제를 확인하는 데 필요한 최소한의 기록 수준으로 시작하고, 필요할 때만 일시적으로 높이는 것이 좋습니다. 문제 해결이 끝나면 평소 설정으로 되돌리세요. 상세 기록이 많을수록 처리할 정보가 늘어 저장 공간이나 처리 자원을 더 사용할 수 있습니다. 상세 기록을 항상 유지하는 것을 연결 품질 향상 설정처럼 취급하지 마세요.

요청 단계별로 기록 읽기

먼저 요청 대상이 올바른지 확인하고, DNS 확인이 완료됐는지, 적용된 규칙과 정책은 무엇인지, 어느 서버에 연결됐으며 이후 결과가 어땠는지 살펴보세요. 로그 형식에 따라 모든 항목이 표시되지 않을 수 있지만 확인 순서는 동일하게 유지할 수 있습니다. 특정 단계의 정보가 없다면 증거가 부족한 상태임을 인정하고 해당 테스트를 보완하세요. 포괄적인 오류 한 줄만 보고 전체 연결 경로를 추정하지 마세요.

예를 들어 ‘연결 시간 초과’는 서로 다른 종단점에서 발생할 수 있습니다. 시간 초과 대상이 Proxy 서버인지, DNS 종단점인지, 대상 서비스인지 확인해야 합니다. ‘인증 실패’라면 사용자가 보유한 정보의 인증 항목과 예상한 서버를 선택했는지부터 확인하세요. 인증서 관련 안내가 표시되면 주소, 이름, 서버 설정을 검토하세요. 오류를 없애려고 검증을 무작정 완화하지 마세요. 오류가 보이지 않게 하는 것과 연결을 제대로 복구하는 것은 다릅니다.

로그의 DIRECT, PROXY, REJECT는 적용된 규칙과 함께 해석해야 합니다. DIRECT가 표시되면 의도한 분기 방식인지 먼저 확인하세요. REJECT가 표시되면 앞선 규칙의 범위가 너무 넓은지 살펴보세요. 예상과 다른 요청을 모두 PROXY로 바꾸지 마세요. 잘못된 도메인, 대상 서비스 상태, 앱 자체의 인증 절차가 문제일 수도 있습니다.

Data 수치와 개인정보 보호

Data의 통계를 해석하기 전에 집계 범위와 시간 범위를 확인하세요. 연결 시간, 누적 트래픽, 개별 요청에 걸린 시간은 서로 다른 지표입니다. 다시 연결하거나 기록을 정리하거나 화면을 전환한 뒤에는 표시 기준도 다시 확인해야 합니다. 앱에 표시된 수치를 통신사 요금 청구서와 같은 것으로 보거나 업로드량이 늘었다는 사실만으로 이상 현상을 단정할 수 없습니다. 정상적인 백그라운드 통신, 재시도, 테스트 동작을 먼저 구분하세요.

로그에 도메인, 주소, 서버 식별자, 요청 정보가 포함될 수 있습니다. 내보낸 파일에는 더 많은 맥락이 담길 수도 있습니다. 공유하기 전에 비밀번호, 구독 링크, 토큰, 개인 주소 및 신원과 연결될 수 있는 정보를 삭제하세요. UUID가 무작위 문자열처럼 보여도 연결 인증 정보일 수 있으므로 공개 게시물에 그대로 붙여 넣지 마세요. 필요한 오류 유형, 발생 순서, 개인정보를 가린 항목만 남기는 편이 전체 데이터를 제공하는 것보다 유용합니다.

로그를 정리하기 전에 문제와 직접 관련된 일부 기록, 특히 변경 전후의 비교 자료를 보관하세요. 실패할 때마다 모든 기록을 지우고 기억에 의존해 설명하지 마세요. 다시 기록을 수집해야 한다면 새로운 시작점을 분명히 정하고 한 번만 재현하세요. 문제가 쉽게 재현되지 않는 경우 표시 없는 로그를 계속 쌓는 것보다 트리거 조건과 마지막 정상 조건을 기록하는 편이 결론을 내리는 데 도움이 됩니다.

기본 연결은 성공했지만 특정 서비스만 실패한다는 기록이 있다면 해당 서비스의 규칙과 응답 조건을 확인하세요. 서버 연결 전에 기록이 끊긴다면 DNS와 네트워크로 돌아가야 합니다. 결과를 ‘조건, 작업, 증상, 근거, 되돌린 뒤 결과’ 다섯 항목으로 정리하면 이 페이지의 각 장에 맞춰 확인할 수 있습니다. 자주 묻는 질문의 분류별 문제 해결을 함께 참고해 범위를 좁힐 수도 있습니다.

07 / Widget & iCloud

Widget, iCloud 동기화 및 Config 백업

Widget은 바로가기이며 별도의 연결 설정이 아닙니다

Widget은 빠른 진입이나 상태 표시를 제공하지만, 추가할 수 있는 유형과 조작 방식, 표시 내용은 앱과 시스템에서 현재 지원하는 기능에 따라 달라집니다. Widget은 별도의 서버 설정이 아니며 백그라운드 연결의 성공 여부를 판단하는 유일한 근거로 사용할 수 없습니다. Widget 표시와 Home에서 확인한 내용이 다르면 먼저 앱을 열어 연결 상태를 확인한 뒤 시스템에서 화면이 갱신됐는지 살펴보세요. 곧바로 DNS나 서버 포트를 바꾸지 마세요.

Widget을 추가하기 전에 앱에서 연결과 연결 해제가 정상적으로 이루어지는지 확인하세요. 그런 다음 시스템의 추가 및 편집 절차에서 Shadowrocket이 제공하는 항목을 선택하면 됩니다. 선택 가능한 항목이 있다면 필요한 것만 골라 추가하세요. 기본 표시 항목은 현재 화면에서 확인할 수 있는 내용을 기준으로 합니다. 시스템 차이를 설정 누락으로 오해하지 않도록 이 페이지에서는 Widget의 크기, 레이아웃, 버튼 개수를 고정해 안내하지 않습니다.

Widget에서 작업을 실행한 뒤 Home이나 실제 접속 결과로 상태를 확인하세요. 기기 잠금, 시스템 갱신 시점, 앱 상태에 따라 표시가 바뀌는 시점이 달라질 수 있습니다. 따라서 ‘Widget 문구가 바뀌지 않음’과 ‘연결이 성립하지 않음’은 따로 확인해야 합니다. 앱에서는 정상인데 Widget만 갱신되지 않으면 Widget과 시스템 표시 조건을 점검하세요. 앱에서도 연결이 실패하면 앞서 설명한 네트워크와 로그 확인 절차를 따르세요.

iCloud 동기화는 별도 백업과 다릅니다

iCloud 동기화는 계정과 시스템 조건이 충족되면 앱에서 지원하는 데이터를 동기화합니다. 이름만 보고 동기화 항목을 추측하지 마세요. 실제 설정에서 어떤 항목을 동기화하는지, 기능이 켜져 있는지, 두 기기에서 요구 조건에 맞는 iCloud 계정을 사용하는지 확인하세요. App Store 구매에 사용하는 계정과 시스템의 iCloud 계정은 서로 다른 계정 개념일 수 있습니다. 앱을 다시 받을 수 있다고 해서 Config도 동기화됐다고 볼 수는 없습니다.

데이터가 온전한 기기 한 대에서 기준을 먼저 확인한 뒤 다른 기기를 설정하세요. 양쪽 기기에서 같은 이름의 Config를 동시에 대폭 수정하면 최종 내용이 어느 기기에서 왔는지 판단하기 어렵습니다. 한 기기가 일시적으로 오프라인이었다면 다시 연결된 뒤 동기화 결과를 재확인해야 합니다. 동기화가 완료됐는지는 동기화 옵션이 켜져 있는지만 보지 말고 파일 내용, 서버 정보, 실제 연결로 확인하세요.

동기화는 변경 사항을 전파하므로 변하지 않는 과거 기록을 보관하는 기능으로 간주할 수 없습니다. 실수로 삭제하거나 수정한 내용도 동기화되어 다른 기기에 영향을 줄 수 있습니다. 규칙을 크게 바꾸기 전에 현재 Config를 별도로 저장하고, 본인만 관리하는 위치에 용도를 기록하세요. 백업 파일은 알아보기 쉽게 표시하되 비밀번호나 전체 구독 링크를 파일명에 쓰지 마세요. 파일도 민감한 Config로 취급하고 공개된 위치에 함부로 업로드하지 마세요.

내보낸 내용과 기기 이전 후 재검증

Config를 내보낸 뒤에는 파일을 열어 실제로 포함된 섹션을 확인하세요. 하나의 파일에 모든 Settings, 서버, 시스템 권한이 포함된다고 가정해서는 안 됩니다. 구독 내용, 직접 추가한 서버, 로컬 규칙은 서로 다른 저장 범위에 있을 수 있으며 실제 내보내기 결과를 기준으로 확인해야 합니다. 기기를 바꾸기 전에 원본 구독 정보, 필요한 서버 매개변수, 로컬 규칙 사본을 각각 보관하고 용도를 구분해 두세요.

복구 후에는 파일 내용이 온전한지 확인하고 활성 Config, Global Routing, 현재 서버를 점검하세요. 시스템 VPN 권한은 시스템 수준에서 진행해야 하므로 새 기기의 안내에 따라 설정해야 합니다. 텍스트 Config로 이 과정을 대신할 수는 없습니다. 다음으로 수동 연결을 확인한 뒤 On Demand와 Widget을 검증하세요. 이 순서대로 진행하면 데이터 복구 문제와 자동 트리거 문제를 구분할 수 있어 모든 기능을 동시에 복구한 뒤 막연한 오류만 확인하는 일을 피할 수 있습니다.

기존 기기에서는 정상 작동하지만 새 기기에서는 작동하지 않는다면 기존 기기를 비교 기준으로 그대로 유지하세요. 두 기기의 네트워크, 활성 Config, 인증 항목, 동기화 결과를 하나씩 비교해 차이를 찾은 뒤 새 기기를 수정합니다. ‘동기화를 강제로 실행’하려고 기존 기기의 데이터를 먼저 지우지 마세요. 가장 중요한 정상 기준이 사라집니다. 앱을 받는 데 사용한 계정 문제는 구매 항목 복구 안내를 확인하고 Config 이전과는 따로 처리하세요.

자료 정리 방법과 구체적인 절차는 iCloud 동기화, Config 내보내기 및 기기 이전을 참고하세요. 구매 항목 복구에 필요한 계정 확인은 기기 변경 후 앱 재설치와 구매 항목 안내를 살펴보세요. 이 절차를 구분하면 동기화 문제를 구매 문제로 오인하지 않고 불필요한 중복 편집도 줄일 수 있습니다.

08 / Verification & Recovery

설정 확인, 문제별 진단 및 되돌리기

영향 범위에 따라 확인 시작점 선택

문제가 생기면 먼저 ‘모든 대상이 실패하는지, 일부 대상만 실패하는지’를 확인하세요. 모든 대상에 실패한다면 기기의 기본 인터넷 연결, 시스템 VPN 구성, 현재 서버, 인증 조건을 먼저 확인해야 합니다. 일부 대상만 실패한다면 해당 도메인의 DNS, 규칙 매칭, 대상의 응답을 우선 확인하세요. ‘DNS를 바꿀지 포트를 바꿀지’를 먼저 결정하는 것보다 이 구분이 중요합니다. 다음에 어떤 증거를 수집할지 정해 주기 때문입니다.

문제가 처음 발생한 것인지, 설정을 바꾼 뒤 생긴 것인지, 네트워크를 전환한 뒤 생긴 것인지도 확인하세요. 첫 연결에 실패했다면 보유한 서버 정보와 프로토콜 항목을 점검합니다. 변경 후 실패했다면 가장 최근의 변경 한 가지를 먼저 되돌립니다. 네트워크 전환 후 실패했다면 Config를 그대로 두고 새 네트워크 접속과 DNS 조건을 따로 확인하세요. 이 세 상황을 무작위 조정 절차 하나로 처리하면 이미 확인된 인과관계를 놓치기 쉽습니다.

연결이 되던 기기에서 Settings를 조정한 뒤에만 문제가 생겼다면, 설정을 더 추가하기보다 기록한 기준으로 돌아가는 편이 효과적입니다. 임시 On Demand 조건을 끄고 원래 Global Routing을 복구한 다음 기존 활성 Config를 선택하고 원래 서버로 수동 연결하세요. 단계마다 결과를 기록해야 모든 항목을 한꺼번에 복구한 뒤 ‘이제 정상’이라는 사실만 알고 원인을 놓치는 일을 피할 수 있습니다.

Config 예시를 안전하게 대조하는 방법

아래 예시는 읽기 쉬운 Config 일부를 구성하는 방법을 보여줍니다. [General]에는 관련 기본 옵션을, [Rule]에는 순서가 있는 규칙을 둡니다. 기존 파일 전체를 덮어쓰라는 뜻이 아니며 서버 연결에 필요한 정보도 모두 포함하지 않습니다. 실제로 편집할 때는 사본에서 해당 섹션을 찾고 같은 이름의 항목을 중복으로 만들지 마세요. 조각을 붙여 넣다가 기존 정책이나 필요한 설정을 삭제하지 않도록 주의하세요.

[General]
dns-server = system

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

규칙을 확인할 때는 새 규칙과 실제로 관련된 요청을 골라 적용 결과를 확인하세요. 예시 도메인은 문법을 설명하기 위한 것으로, 해당 콘텐츠 결과로 자신의 서버 사용 가능 여부를 판단할 수 없습니다. 새 규칙이 적용되지 않으면 활성 파일과 앞선 규칙을 먼저 확인하세요. 규칙이 적용됐는데 연결이 실패하면 정책에 따른 연결 경로를 계속 점검합니다. 규칙 문법이 올바른지, 정책이 적용됐는지, 최종 콘텐츠가 정상 반환됐는지는 각각 별개의 검증 결과입니다.

최소 복구와 장기 유지 기준

최소 복구란 모든 데이터를 삭제하는 것이 아니라, 원인을 설명할 수 있고 반복해서 성공하는 수동 연결 경로를 먼저 확보하는 것입니다. 유효한 서버 정보는 유지하고, 명확한 라우팅 모드와 활성 파일을 사용하며, 자동 트리거와 불필요한 테스트 옵션은 일시적으로 줄이세요. 그래도 실패하면 로그를 바탕으로 문제를 좁힙니다. 연결이 성공하면 기능을 한 번에 하나씩 복구하고 매번 같은 대상으로 검증하세요.

장기간 유지할 설정은 각각 다음 세 질문에 답할 수 있어야 합니다. 어떤 요구를 해결하는가, 어떻게 적용됐는지 확인하는가, 문제가 생기면 어떻게 되돌리는가. 답을 모른다면 계속 조정하기보다 기존 값을 유지하는 편이 낫습니다. 특히 DNS 종단점, 로컬 Proxy 수신 설정, 자동 연결 조건은 관리해야 할 조건을 늘립니다. 다른 사람이 사용한다는 이유만으로 자신의 기기에 추가하지 마세요.

복구 과정에서 앱을 다시 받는 일을 첫 단계로 삼지 마세요. 앱은 App Store에서 제공되지만 재설치에는 구매 항목 다시 받기, 앱 데이터, 시스템 권한 등 여러 절차가 관련되어 문제 해결에 필요한 상태가 사라질 수 있습니다. 해결할 문제가 명확하고 필요한 자료를 저장했으며 복구 절차를 이해한 경우에만 이 방법을 고려하세요. 정품 개발자 이름은 Shadow Launch Technology Limited이며 앱 ID는 932747118입니다. 확인 방법은 정품 확인 세 가지 항목 안내를 참고하세요.

추가로 문제를 진단받기 위해 정리할 때는 간단한 기록을 남기세요. 어떤 네트워크에서 어떤 Global Routing 및 활성 Config를 사용했는지, 어떤 작업을 했는지, 어떤 증상이 나타났는지, 로그가 어느 단계에서 멈췄는지, 변경을 되돌린 뒤 복구됐는지 적으면 됩니다. 실제 구독 정보나 인증 항목은 공개하지 마세요. 이런 기록은 클라이언트 설정, 사용자가 보유한 서버 조건, 대상 서비스 문제를 구분하는 데 도움이 되며 ‘안내대로 다 했는데 안 된다’는 말보다 진단 가치가 높습니다.

문제 해결을 마치면 임시 테스트 대상을 정리하고 일상적인 로그 수준으로 되돌리세요. On Demand와 Widget이 필요한 방식대로 작동하는지 확인하고 최종 Config 사본을 보관하세요. 나중에 구독을 업데이트하거나 네트워크를 바꾸면 영향을 받는 항목만 다시 테스트하면 됩니다. 전체 연결 절차를 다시 진행해야 한다면 시작 가이드로 돌아가세요. 증상별 확인이 필요하면 자주 묻는 질문을 참고하세요. 이 페이지의 모든 설정을 다시 변경할 필요는 없습니다.