설정 범위와 기본 상태
먼저 설정의 적용 범위를 구분한 뒤 어디를 변경해야 할지 판단하세요. Settings는 앱 설정 메뉴지만, 실제 연결에는 Home에서 선택한 서버, Global Routing 모드, Config의 규칙과 시스템 네트워크 환경도 함께 영향을 줍니다. 스위치가 켜져 있다는 사실만으로 요청이 예상대로 처리된다고 볼 수는 없습니다. 확인할 때는 현재 서버, Config, 연결 상태를 함께 기록해 서로 다른 범위의 문제를 하나의 설정 항목 탓으로 돌리지 않도록 하세요.
앱 설정, Config 파일, 서버 매개변수
앱 설정은 보통 테스트 방식, 표시, 기록, 시스템 연동 등의 동작을 관리합니다. Config에는 규칙과 관련 네트워크 설정이 저장되고, 서버 항목에는 프로토콜, 주소, 포트, 인증 정보가 포함됩니다. 서로 다른 위치에 같은 ‘포트’라는 항목이 있어도 의미는 다를 수 있습니다. Add Server의 Port는 원격 서버의 포트이고, 로컬 Proxy 수신 포트는 기기에서 제공하는 서비스의 접속 지점입니다. 변경 전 현재 화면을 확인하고, 이름이 비슷하다는 이유로 값을 서로 옮겨 적지 마세요.
사용자가 이미 보유한 구독을 가져오면 주로 서버 항목과 업데이트 출처가 추가됩니다. 이 작업만으로 현재 규칙 파일도 바뀐다고 단정해서는 안 됩니다. 앱 업데이트, Config 재가져오기, 서버 전환은 각각 다른 작업입니다. 업데이트 후 값이 달라졌다면 먼저 어떤 항목이 업데이트됐는지 확인하고, 가져온 내용이 해당 값을 덮어썼는지 살펴보세요. 무작정 반복해서 가져오면 기존 항목과 새 항목이 섞여 원인을 찾기 더 어려워질 수 있습니다.
| 위치 또는 대상 | 주요 기능 | 확인 방법 |
|---|---|---|
| Settings | 앱 동작, 테스트 및 시스템 연동 | 해당 기능의 실제 동작 |
| Config | 규칙 및 Config 파일의 네트워크 설정 | 현재 활성화된 파일과 요청 기록 |
| Add Server | 원격 서버 연결 매개변수 | 원본 서버 정보와 연결 결과 |
| Global Routing | Config, Proxy 또는 Direct 모드 선택 | 실제 요청의 처리 경로 |
기본값은 모든 기기에서 같은 고정값이 아닙니다
이 매뉴얼은 특정 기기에 한 번 표시된 값을 영구적인 출고 기본값으로 간주하지 않습니다. 처음 설치한 상태, 이전 기기에서 옮겨 온 상태, Config를 가져온 뒤의 상태는 서로 다를 수 있습니다. 일부 옵션은 시스템 기능이나 앱 구현에 따라 달라질 수도 있습니다. 여기서 기본 상태 확인이란 변경 전에 현재 항목과 도움말, 활성 Config를 살펴보고 복원할 수 있도록 기록하는 것을 뜻합니다. 명확한 필요가 없다면 어떤 목록과 맞추려고 항목을 하나씩 바꾸기보다 현재 값을 유지하는 편이 좋습니다.
기록할 때는 옵션 이름, 변경 전 값, 변경 후 값, 변경 목적을 적어도 포함하세요. 값이 비어 있다고 해서 자동으로 꺼짐이나 무효 상태라고 판단하지 마세요. 빈 값은 시스템이 제공하는 정보를 사용하거나 Config 단계의 처리를 따른다는 뜻일 수 있으므로 해당 항목의 설명을 확인해야 합니다. 빈 값의 의미를 알 수 없다면 그대로 두고 통제된 테스트로 확인하세요. 추측한 공용 주소나 숫자를 모든 빈칸에 채우지 마세요.
변경과 복원을 반복할 수 있는 절차 만들기
먼저 안정적인 네트워크에서 기준 테스트를 진행하는 것이 좋습니다. 연결이 되는지 확인하고, 자주 이용하는 페이지를 열어 Global Routing과 현재 Config를 기록하세요. 그런 다음 변수 하나만 변경하고 같은 네트워크에서 같은 페이지로 다시 테스트합니다. DNS, 서버, 규칙을 한꺼번에 바꾸면 결과가 좋아져도 어떤 항목이 영향을 줬는지 알 수 없고, 나빠져도 무엇을 복원해야 할지 판단하기 어렵습니다. 하나씩 변경하는 편이 반복 초기화보다 문제 진단에 효과적입니다.
연결의 핵심 매개변수를 바꾼 뒤 화면에 재연결 안내가 표시되면 안내에 따르세요. 별도 안내가 없더라도 저장 후 연결을 끊었다가 다시 연결하면 이전 세션이 계속 사용되는 일을 방지할 수 있습니다. 기존 연결이 계속된다고 해서 새 값이 검증됐다고 볼 수는 없습니다. 되돌릴 때는 원래 항목과 Config를 복원한 뒤 같은 테스트를 반복하세요. 복원 후에도 문제가 지속된다면 네트워크 전환, 서버 상태 또는 시스템 수준의 변화를 추가로 확인해야 합니다.
DNS와 도메인 이름 확인
DNS는 도메인 이름을 이후 연결에 필요한 주소로 변환합니다. 규칙 판단과 관련은 있지만 규칙을 대신하지는 않으며, 서버 인증 실패를 해결해 주지도 않습니다. 문제를 확인하기 전에 증상을 구분하세요. 도메인 확인 오류, 주소를 얻었지만 연결 시간 초과, 연결은 됐으나 페이지가 완전히 표시되지 않는 상황은 각각 다른 단계에서 발생합니다. 첫 번째는 DNS 확인과 직접 관련이 있지만, 나머지는 라우팅, 전송, 서버 응답을 함께 살펴봐야 합니다. 모두 DNS 문제로 단정하지 마세요.
DNS 설정의 출처 확인
먼저 현재 활성화된 Config에 DNS 관련 내용이 있는지 확인한 다음 Settings에서 사용할 수 있는 DNS 옵션과 설명을 살펴보세요. 화면과 파일 양쪽에 관련 항목이 있더라도 위치만으로 어느 쪽이 우선한다고 단정해서는 안 됩니다. 해당 옵션이 전역 동작인지, Config를 보완하는지, 특정 DNS 방식의 매개변수인지 확인하세요. 이름에 DNS가 들어간다고 같은 역할을 하는 것은 아닙니다. 변경 후에는 저장 여부만 보지 말고 새 요청으로 결과를 확인하세요.
현재 정상적으로 작동하는 Config라면 기존 DNS 방식을 유지하는 것이 좋습니다. 재현 가능한 DNS 오류가 있거나, 직접 관리하는 DNS 서비스를 사용해야 하거나, 기존 Config가 특정 방식을 요구하는 경우에만 관련 항목을 조정하세요. 주소를 입력하기 전에 해당 항목이 단일 주소, 목록, 프로토콜을 포함한 주소 중 어떤 형식을 받는지 확인하세요. 브라우저에서 사용하는 전체 페이지 주소를 DNS 서버 주소로 입력해서는 안 됩니다. 프로토콜 접두사, 포트, 경로도 해당 항목에서 지원하는 형식을 따라야 합니다.
DNS 서비스에도 접속이 필요합니다. 암호화된 전송 방식의 DNS를 사용하더라도 서비스 이름의 주소를 먼저 알아야 할 수 있으며, 인증서 검증에는 올바른 이름과 시스템 시간이 필요합니다. 따라서 ‘암호화 DNS로 변경’한다고 이전의 네트워크 조건이 모두 중요하지 않게 되는 것은 아닙니다. 순환 의존이나 연결 오류가 발생하면 기존 DNS 방식으로 되돌리고 기본 네트워크가 복구됐는지 확인한 다음, 새 방식의 연결 가능 여부와 설정 형식을 점검하세요. DNS 주소를 계속 추가하지 마세요.
도메인 규칙과 주소 규칙의 차이
DOMAIN과 DOMAIN-SUFFIX는 요청에 포함된 도메인을 기준으로 판단할 수 있습니다. IP-CIDR, IP-CIDR6, GEOIP는 주소 조건을 기준으로 동작합니다. 주소 정보가 필요한 상황에서는 DNS 결과가 이후 판단에 영향을 주지만, 요청에서 도메인이 유지되는지와 앞선 규칙에 이미 일치했는지도 처리 과정에 영향을 줍니다. 규칙을 점검할 때는 위에서 아래로 읽으며 먼저 어떤 규칙이 적용됐는지 확인한 뒤 DNS가 관여했는지 살펴보세요. 목록 끝의 주소 규칙만 확인해서는 안 됩니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY위 예시는 규칙 순서만 보여 주며, 완전한 연결 설정이 아니고 기존 파일을 교체하라는 뜻도 아닙니다. example.com은 예시 도메인이고, 사설 주소 규칙은 주소 대역 일치 방식을 보여 줍니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 실제 Config에 추가하기 전 기존 규칙, 정책 이름, 예상 경로를 확인하세요. 예시를 저장할 수 있다고 해서 모든 네트워크에 적합하다고 볼 수는 없습니다. 특히 로컬 네트워크 리소스와 기존 서비스 규칙에 영향이 있는지 확인해야 합니다.
캐시, 네트워크 전환, 권장 확인 순서
DNS를 변경한 뒤에도 브라우저, 앱 또는 기존 연결에 이전 결과가 남아 있을 수 있습니다. 테스트 중인 페이지나 앱 세션을 종료하고, 필요한 경우 다시 연결한 뒤 같은 도메인으로 새 요청을 보내세요. 특정 DNS 결과가 반드시 고정된 주소를 반환해야 한다고 기대하지 마세요. 같은 서비스도 네트워크와 부하에 따라 다른 주소를 반환할 수 있습니다. 진단할 때는 주소 문자열이 다른 사람의 결과와 같은지보다 DNS 확인 성공 여부, 규칙에 맞는 요청 경로, 안정적으로 반복되는 연결 결과가 중요합니다.
특정 Wi-Fi에서만 실패한다면 먼저 해당 네트워크에서 필요한 웹 인증을 마쳤는지 확인한 뒤 로컬 네트워크의 DNS와 현재 DNS 설정이 충돌하는지 살펴보세요. 네트워크 전환 후 잠시 실패한다면 캐시가 아직 갱신되지 않은 경우와 터널이 아직 복구되지 않은 경우를 구분해야 합니다. 기존 설정으로 되돌린 뒤 문제가 사라졌다면 새로 추가한 항목을 하나씩 확인하세요. 기존 설정에서도 실패한다면 기본 네트워크와 현재 서버를 추가로 점검해야 하며, 같은 항목에서 DNS 주소만 계속 바꾸지 마세요.
On Demand 연결 조건
On Demand는 조건에 따라 시스템이 연결을 시작하거나 유지하는 방식을 관리합니다. 도메인별로 Proxy 또는 Direct를 선택하는 규칙 목록이 아닙니다. 전자는 ‘언제 연결을 만들지’를, 후자는 ‘연결된 뒤 요청을 어떻게 처리할지’를 다룹니다. 두 기능을 혼동하면 도메인 규칙만 설정하고 시스템이 자동으로 연결을 시작할 것으로 기대하거나, 네트워크 조건을 설정하면 모든 요청이 반드시 특정 서버를 거칠 것으로 오해할 수 있습니다.
수동 연결을 확인한 뒤 자동 조건 추가
처음 설정할 때는 현재 On Demand 상태를 유지하고 Home에서 수동으로 연결해 기존 서버 정보, Config, Global Routing이 정상 작동하는지 확인하는 것이 좋습니다. 수동 연결이 안정적이어야 자동 실행도 제대로 검증할 수 있습니다. 수동 연결부터 실패한다면 기본 연결 문제를 먼저 해결하세요. On Demand는 같은 연결 절차를 시작할 뿐, 잘못된 인증 정보나 접속할 수 없는 원격 주소를 보완하지는 않습니다.
On Demand 화면에서 제공하는 네트워크 유형, 네트워크 이름, 기타 일치 조건을 하나씩 확인하고 저장 후 적용되는 규칙도 살펴보세요. 다른 사람의 스크린샷에 나온 옵션이 내 기기에도 똑같이 있다고 가정하지 마세요. 네트워크 이름은 실제 표시되는 이름에 맞춰 입력해야 하며, 비슷한 이름이라고 같은 네트워크는 아닙니다. 여러 조건을 함께 설정한다면 일치 조건과 예외에 관한 화면 설명을 먼저 읽고 조합하세요. 예상보다 넓은 범위에 규칙이 적용되지 않도록 주의해야 합니다.
자동 연결이 꼭 필요하지 않다면 수동 제어를 유지하는 것이 좋습니다. 필요한 경우 반복해서 확인할 수 있는 조건 하나부터 시작하세요. 예를 들어 자주 사용하는 특정 네트워크 상태만 대상으로 테스트하고, 진입 및 이탈 시 동작을 확인한 뒤 다른 조건을 추가할 수 있습니다. 모든 네트워크를 한 번에 대상으로 삼으면 문제가 생겼을 때 조건 일치 문제인지 연결 단계 문제인지 구분하기 어렵고 일상적인 연결에도 영향을 줄 수 있습니다.
시스템 권한과 네트워크 전환의 범위
처음 연결을 설정할 때 시스템에서 VPN 구성을 추가하도록 허용할지 물을 수 있습니다. 이 권한은 시스템이 해당 네트워크 연결 구성을 만들도록 허용하는 것이며, 구독 내용이나 서버 매개변수가 유효하다는 뜻은 아닙니다. 권한을 허용한 뒤에도 실제 연결 테스트가 필요합니다. 이전에 허용을 거부했다면 시스템의 현재 안내에 따라 다시 허용하세요. 권한을 다시 받는 방법으로 On Demand를 반복해서 전환하거나, 다른 용도의 시스템 구성을 삭제해 보는 방식에 의존하지 마세요.
Wi-Fi에서 셀룰러 네트워크로 전환할 때 기존 연결이 끊기고 새 네트워크 환경에서 다시 연결해야 할 수 있습니다. 이때 페이지가 잠시 기다리는 것만으로 On Demand 규칙이 실패했다고 판단하지 마세요. 시스템의 네트워크 전환이 완료됐는지 확인하고, Shadowrocket의 연결 상태를 살펴본 뒤 새 요청을 보내세요. 네트워크 인증이 끝나지 않았거나 신호가 불안정하거나 새 네트워크에서 현재 서버에 연결할 수 없다면, 자동 연결이 시작돼도 대상 요청이 바로 완료되지는 않습니다.
시스템이 허용하는 백그라운드 동작과 앱이 앞에 표시된 상태의 동작은 완전히 같지 않습니다. 앱을 벗어난 뒤 화면이 실시간으로 갱신되지 않는다고 터널이 끊겼다고 단정할 수 없으며, 상태 아이콘이 계속 표시된다고 모든 요청이 성공했다고 볼 수도 없습니다. 현재 연결 상태와 실제 접속 결과를 함께 확인하세요. 다른 시스템 네트워크 관리 설정이 연결에 관여한다면 각 설정의 용도를 먼저 파악하고, 영향 범위를 모른 채 여러 자동 연결 조건을 동시에 변경하지 마세요.
연결 중지, 복원, 문제 확인
On Demand를 켠 상태에서 수동으로 연결을 끊었는데 다시 연결된다면 시스템이 트리거 조건을 다시 감지했을 수 있습니다. 버튼이 반응하지 않은 것으로 단정하지 마세요. 연결을 계속 중지하려면 먼저 On Demand가 연결을 요구하고 있는지 확인하고, 현재 화면에서 해당 트리거 규칙을 비활성화한 뒤 연결을 끊으세요. 조작 후 상태가 안정될 때까지 기다리고 일반 요청을 한 번 보내 확인하세요. 스위치를 빠르게 반복해서 누르면 연결과 해제 과정이 겹쳐 최종 상태를 판단하기 어려워집니다.
정해진 순서에 따라 문제를 확인할 수 있습니다. 먼저 On Demand 조건을 잠시 비활성화하고 수동 연결을 테스트한 다음, 조건을 하나만 복원해 트리거되는지 확인하세요. 트리거가 정상 작동하면 요청 경로를 확인합니다. 전혀 실행되지 않는다면 조건과 시스템 권한을 점검하세요. 실행은 되지만 접속에 실패한다면 서버, DNS, 규칙을 확인하세요. 자주 재연결된다면 자동 매칭 범위를 먼저 넓히기보다 발생 당시의 네트워크 유형과 전환 과정을 기록하세요.
Ping과 Connectivity Test
테스트 수치는 특정 시점에 특정 방식으로 확인한 결과일 뿐, 모든 서비스가 정상적으로 작동한다는 뜻은 아닙니다. Settings의 Ping 관련 옵션은 테스트 동작을 조정하고, Home의 Connectivity Test는 해당 확인을 실행합니다. 결과를 보기 전에 테스트 방식, 대상, 선택한 서버를 통과하는지 확인하세요. 방식마다 검사하는 네트워크 단계가 다르므로 서로 다른 결과를 단순 비교해 순위를 매기는 것은 대체로 의미가 없습니다.
테스트 방식별로 확인할 수 있는 내용
화면에 TCP 테스트가 있다면 주로 지정한 주소와 포트에 연결을 만들 수 있는지 확인합니다. 포트 연결에 성공해도 프로토콜 인증, 암호화 협상, 대상 접속까지 완료됐다는 뜻은 아닙니다. HTTP 테스트가 제공되는 경우에는 대상 주소와 요청이 Proxy 경로를 거치는지도 확인해야 합니다. 응답을 받으면 더 많은 단계를 확인한 셈이지만, 여전히 해당 대상과 해당 요청에만 해당합니다. 테스트 이름이 비슷하더라도 경로와 조건 확인을 생략해서는 안 됩니다.
시간 초과가 발생하면 테스트 대상에서 지연된 것인지 서버 연결 단계에서 발생한 것인지 먼저 확인하세요. 원격 서버에 연결할 수 있어도 테스트 대상이 일시적으로 응답하지 않을 수 있고, 대상이 정상이어도 현재 네트워크에서 서버까지의 경로가 실패할 수 있습니다. 한 번의 실패로 서버가 영구적으로 사용할 수 없다고 판단하지 마세요. 같은 방식으로 다시 테스트하고 기본 네트워크와 대상을 확인한 뒤 실제 요청 결과와 비교해야 일시적인 현상과 지속적인 장애를 구분할 수 있습니다.
| 관찰 결과 | 확인할 수 있는 내용 | 이 결과만으로는 알 수 없는 내용 |
|---|---|---|
| 포트 연결 성공 | 해당 전송 계층 연결을 만들 수 있음 | 프로토콜 인증과 페이지 접속 모두 성공 |
| 테스트 대상의 응답 | 해당 테스트 경로에서 응답을 받음 | 모든 대상과 모든 프로토콜이 사용 가능함 |
| 테스트 시간 초과 | 정해진 시간 안에 해당 테스트를 완료하지 못함 | 문제가 반드시 서버 측에서 발생함 |
대상, 시간 초과, 반복 횟수 선택
테스트 주소는 현재 검증할 수 있는 설정을 유지하거나, 안정적으로 접속할 수 있고 용도가 분명한 대상을 사용하는 것이 좋습니다. 수치를 낮추려고 대상을 계속 바꾸면 이전 결과와 비교할 수 없습니다. 테스트 대상이 도메인이라면 DNS 확인도 테스트 과정에 포함될 수 있습니다. 페이지가 다른 곳으로 이동하거나 인증을 요구한다면 단순 응답을 예상했을 때와 실제 동작이 다를 수 있으므로 해당 대상이 테스트 방식에 적합한지 먼저 확인하세요.
모든 네트워크에 맞는 단일한 최적 시간 초과 값은 없습니다. 너무 짧게 설정하면 지연은 크지만 여전히 사용할 수 있는 연결을 실패로 판단할 수 있고, 너무 길면 명백히 사용할 수 없는 경로를 확인하는 데 시간이 더 걸립니다. 처음 문제를 확인할 때는 현재 값을 유지하고 안정적인 네트워크에서 관찰한 다음, 실제 실패 양상을 바탕으로 조정하세요. 요청이 자주 제한 시간에 가까워진다면 시간을 늘려 문제를 감추기보다 네트워크와 서버를 먼저 확인하세요.
반복 테스트는 간격과 조건을 일정하게 유지하고, 기기에서 대량 업로드·다운로드가 진행 중이거나 네트워크가 전환될 때는 피하세요. 짧은 시간에 여러 항목을 집중 테스트하면 동시 부하가 생겨 평소 사용 환경과 다른 결과가 나올 수 있습니다. 이미 등록된 항목 몇 개를 골라 같은 네트워크에서 반복 확인하고, 실제 서비스가 안정적인지도 함께 살펴보는 편이 낫습니다. 한 번 낮게 나온 수치만으로 장기적인 우선 선택을 결정하지 마세요.
테스트는 통과했지만 실제 접속이 실패하는 경우
먼저 실제 요청에 적용되는 Global Routing을 확인하세요. 특정 서버를 테스트했다고 해서 실제 요청도 반드시 그 서버를 사용하는 것은 아닙니다. Config 모드에서는 요청이 DIRECT 규칙에 일치하거나 다른 정책으로 처리될 수 있습니다. 다음으로 Config에서 대상과 관련된 규칙을 살펴보고 DNS와 요청 기록을 확인하세요. 규칙 일치 여부를 확인하지 않고 서버만 바꾸면 해당 요청에 전혀 사용되지 않는 항목만 계속 비교할 수 있습니다.
프로토콜 매개변수 때문에 ‘기본 테스트는 정상인데 앱 요청은 실패하는’ 상황이 생길 수도 있습니다. 예를 들어 TLS 연결에는 올바른 서비스 이름과 인증서 검증이 필요하며, UDP를 사용하는 서비스는 TCP 연결 테스트 결과만으로 판단할 수 없습니다. 기존 서버 매개변수는 원본 정보와 대조하고, 테스트를 통과시키려고 검증을 함부로 끄지 마세요. Trojan 항목의 구체적인 설명은 Password, SNI, Allow Insecure 설정 안내를 참고하세요.
테스트 설정을 복원할 때는 대상, 방식, 시간 초과를 기록한 값으로 모두 되돌린 뒤 같은 항목을 다시 테스트하세요. 복원 후에도 결과가 달라진다면 네트워크 상태나 원격 응답도 변하고 있는 것이므로 모든 차이를 방금 바꾼 설정 탓으로 돌릴 수 없습니다. 네트워크 유형, 테스트 방식, 성공 여부, 실제 요청 결과를 간단히 기록해 두세요. 조건 설명이 없는 수치 스크린샷보다 이후 문제를 확인하는 데 도움이 됩니다.
Log와 Data 진단
Log는 이벤트와 오류를 확인하고 Data는 트래픽 통계를 살펴보는 기능입니다. 서로 보완하지만 대신 사용할 수는 없습니다. 통계 수치가 증가했다는 것은 해당 통계 기준에 따라 데이터가 오갔다는 뜻일 뿐, 페이지가 완전히 로드됐다는 보장은 아닙니다. Log에 연결이 만들어졌다고 기록돼도 이후 요청이 성공했는지는 알 수 없습니다. 진단을 시작하기 전에 ‘이 도메인이 DIRECT 규칙에 일치했는가?’처럼 구체적인 질문을 정한 뒤 관련 기록을 확인하세요. 목적 없이 상세 기록을 오래 켜 두지 마세요.
기록 범위와 권장 사용 방법
먼저 Settings에서 Log 관련 옵션을 확인하고 현재 활성화 여부, 기록 상세 수준, 확인할 수 있는 내용을 구분하세요. 실제로 제공되는 항목은 화면을 기준으로 하며, 특정 기기의 로그 수준을 모든 기기의 기본값으로 여기지 마세요. 평소에는 기본적인 문제 확인에 필요한 현재 상태를 유지하고, 재현 가능한 문제가 생겼을 때만 필요한 기록을 잠시 늘리세요. 점검이 끝나면 추가 기록량과 불필요한 민감 정보의 로컬 저장을 줄이도록 원래 상태로 복원하세요.
문제를 재현하기 전에 현재 시각과 접속할 대상을 기록한 뒤, 페이지 하나를 열어 결과를 기다리는 식으로 명확한 동작 한 가지를 수행하세요. 기록량이 많다면 화면에서 지원하는 방법으로 이전 기록을 정리한 다음 테스트를 시작할 수 있습니다. 증거를 보관해야 한다면 정리 전에 민감 정보를 가린 사본을 만드세요. 서버를 여러 개 한꺼번에 테스트하면서 페이지 오류를 재현하지 마세요. 테스트 요청과 실제 요청이 섞이면 어떤 오류가 대상 동작에서 발생했는지 파악하기 어렵습니다.
오류를 볼 때는 마지막 실패 문구만 찾기보다 발생 순서대로 확인하세요. DNS 확인 실패로 이후 연결이 시작되지 않을 수 있고, 인증 실패는 전송 연결이 만들어진 뒤 발생할 수 있으며, 원격 연결 종료는 앞서 발생한 오류의 결과일 수 있습니다. 기록에 간단한 분류만 표시된다면 앞뒤 이벤트를 함께 살펴보세요. 비슷해 보이는 오류를 모두 같은 항목의 문제로 단정하지 마세요. 변경 후 다시 테스트할 때도 동일한 동작 순서를 유지해야 합니다.
Data로 요청 경로 대조하기
Data의 업로드와 다운로드는 일정 시간 동안의 활동을 살펴보는 데 사용할 수 있지만, 현재 화면, 집계 범위, 초기화 상태를 고려해 읽어야 합니다. 화면마다 분류 기준이 같지 않을 수 있으므로 두 항목의 수치를 단순히 빼서 정확한 결론을 내려서는 안 됩니다. 테스트 전 기준값을 기록하고 대상 요청만 보낸 뒤 관련 수치가 변하는지 확인하세요. 오래 누적된 총량과 비교하는 것보다 판단하기 쉽습니다.
기기 안의 다른 앱이 동기화, 메시지 수신, 백그라운드 접속을 진행할 수 있으므로 테스트 중 전체 트래픽이 늘었다고 해서 방금 연 페이지에서 발생했다고 단정할 수 없습니다. 특정 서버의 사용 여부를 확인해야 한다면 해당 서버와 연결되는 통계나 요청 기록을 살펴보고 규칙 일치 결과와 대조하세요. 총량이 증가한 사실만으로 대상이 Proxy를 사용했다거나 규칙이 예상대로 적용됐다고 증명할 수는 없습니다.
페이지 접속은 실패했지만 데이터가 조금 늘어나는 경우도 모순이 아닙니다. 연결 설정, 인증 교환, 오류 응답, 재시도 과정에서도 데이터가 발생할 수 있습니다. 콘텐츠를 완전히 받았는지는 별개의 문제입니다. 반대로 로컬 캐시에서 페이지가 표시되면 화면은 열린 것처럼 보여도 새로운 네트워크 요청이 없을 수 있습니다. 규칙을 확인할 때는 실제로 새 요청이 발생했는지 확인하고, 필요하면 제어 가능한 다른 페이지를 사용하세요. 같은 캐시 내용을 반복해서 새로 고치지 마세요.
민감 정보 제거, 공유, 진단 마무리
Log와 Config에는 구독 주소, 인증 정보, 서버 주소, 접속 도메인, 요청 내용이 포함될 수 있습니다. 공유하기 전에 전체 인증 정보와 불필요한 개인정보를 삭제하세요. 특히 링크의 쿼리 부분에 인증 정보가 포함될 수 있습니다. 비밀번호 항목만 가리면 충분하다고 생각하지 말고 Config 전체를 그대로 공개하지 마세요. 구조를 보여 줘야 한다면 서비스 도메인을 example.com으로 바꾸고 오류 유형과 규칙 종류 등 필요한 맥락만 남기세요.
효과적인 문제 설명에는 예상 동작, 실제 증상, 네트워크 유형, Global Routing, 현재 Config, 시도한 단일 변경 사항을 포함해야 합니다. 민감 정보를 가린 관련 기록을 첨부할 수 있지만 과거 기록 전체를 제공할 필요는 없습니다. 앱을 받거나 시스템 호환성에 관한 문제라면 App Store 페이지에서 확인하세요. 원격 계정의 유효성 문제는 로그로 권한을 추측하지 말고 사용자가 이미 이용 중인 서비스의 관리 정보를 통해 확인해야 합니다.
Widget과 시스템 바로가기
Widget은 상태를 확인하거나 자주 쓰는 기능에 접근하는 시스템 진입점입니다. 구체적인 형태는 앱이 제공하는 구성 요소와 현재 시스템의 지원 기능에 따라 달라집니다. 별도의 Proxy 설정이 아니며 Home의 서버 및 Global Routing을 대신하지도 않습니다. 처음 사용할 때는 앱에서 연결을 먼저 검증한 다음 Widget을 추가하세요. 문제가 생겼을 때 Widget 표시 문제와 연결 자체의 문제를 구분할 수 있어 여러 진입점에서 같은 상태를 반복해서 바꾸지 않아도 됩니다.
Widget 설정과 시스템에 추가하는 작업은 별개입니다
Settings에 Widget 관련 옵션이 있다면 먼저 해당 옵션이 Widget 내용, 표시 방식, 빠른 동작 중 무엇에 영향을 주는지 확인하세요. 앱에서 관련 내용을 설정했더라도 시스템에서 제공하는 Widget 추가 절차를 거쳐 지원되는 위치에 추가해야 합니다. 반대로 시스템에 Widget이 보인다고 모든 기능이 초기화된 것은 아닙니다. 처음 사용하기 전에 앱을 열어 현재 Config와 시스템 권한이 모두 정상인지 확인하세요.
시스템 화면마다 표시되는 진입점 이름이 항상 같다고 가정하지 마세요. 시스템에서 제공하는 Widget은 크기나 위치가 다를 수 있고, 표시 정보와 허용되는 상호작용도 달라질 수 있습니다. 현재 기기에서 추가할 수 있는 항목을 기준으로 선택하고 일상적인 확인에 필요한 간단한 배치를 우선하세요. 기기에 특정 옵션이 보이지 않는다고 네트워크 매개변수를 바꾸지 마세요. 먼저 시스템 호환성과 앱에 실제로 제공되는 기능을 확인하세요.
먼저 기본 표시 내용을 유지하고 필요에 따라 불필요한 정보를 줄이는 것이 좋습니다. 다른 사람이 볼 수 있는 위치에 Widget을 둔다면 서버 이름, 상태 문구, 통계가 사용 습관을 드러낼지 고려하세요. 식별을 위해 이름을 사용자화할 수 있지만 비밀번호, 구독 주소, 인증 정보를 항목 이름에 넣지 마세요. 표시 항목은 편리한 접근을 위한 것이며 민감한 연결 정보를 저장하는 용도가 아닙니다.
상태 갱신과 동작 결과 확인
시스템 Widget의 표시가 앱 전면 화면과 항상 동시에 갱신되는 것은 아닙니다. 네트워크 전환, 연결 설정, 시스템 작업 중에는 이전 상태가 잠시 표시될 수 있습니다. 표시가 다르면 Shadowrocket을 열어 Home의 실제 연결 상태를 확인한 뒤 요청을 하나 보내 검증하세요. Widget 문구만으로 연결 성공을 판단하지 마세요. Widget이 아직 갱신되지 않았다고 서로 반대되는 동작을 연달아 실행해 상태를 반복해서 바꾸지도 마세요.
Widget에서 동작을 시작하면 시스템이 앱을 열거나 확인 화면을 표시할 수 있습니다. 중간 화면을 실패로 간주하지 말고 현재 안내에 따라 진행하세요. 완료 여부는 실제 연결 결과로 판단해야 합니다. On Demand가 계속 연결을 요구한다면 Widget에서 연결을 끊어도 다시 연결될 수 있습니다. 이때는 On Demand 규칙을 확인하세요. Widget을 반복해서 삭제하고 다시 추가해도 트리거 조건은 바뀌지 않습니다.
Widget에 예상한 내용이 표시되지 않는다면 먼저 올바른 Widget과 크기를 추가했는지 확인한 뒤 앱의 Widget 설정을 살펴보세요. 앱을 열고 초기화가 완료될 때까지 기다린 다음 시스템 방식에 따라 Widget을 다시 불러오세요. 앱에서 연결 자체에 문제가 있을 때만 DNS, 서버, 규칙을 점검하세요. 표시 문제와 네트워크 문제를 구분하면 정상적인 연결 매개변수를 잘못 바꾸는 일을 막을 수 있습니다.
백그라운드, 배터리 사용량, 시스템 권한의 범위
Widget이 표시되는 것, 앱이 백그라운드에 남아 있는 것, 시스템 네트워크 연결이 작동하는 것은 각각 다른 상태입니다. 앱이 전면에 표시되지 않는다고 연결이 중지됐다고 단정할 수 없으며, Widget을 갱신하려고 연결을 계속 새로 만들 필요도 없습니다. 시스템은 자체적인 방식으로 백그라운드 갱신을 관리하고, 앱의 네트워크 기록에는 실제 요청이 반영됩니다. 특정 시간대에 발생한 일을 확인하려면 Log와 Data를 함께 살펴보세요. 앱이 화면에 남아 있는지만으로 판단해서는 안 됩니다.
배터리 사용량도 특정 스위치 하나만으로 설명할 수 없습니다. 잦은 재연결, 많은 요청, 약한 신호, 상세 Log 기록 등이 활동량을 늘릴 수 있습니다. 비교하기 전에 네트워크와 사용 방식을 고정하고 한 번에 조건 하나만 바꾸세요. 네트워크가 계속 전환되거나 백그라운드 동기화가 활발한 상태에서는 Widget 또는 Ping 설정의 배터리 영향을 판단하지 마세요. 변경 뒤 문제가 생기면 우선 변경 사항을 되돌리고 다시 테스트한 다음 지속적인 연관성이 있는지 살펴보세요.
iCloud 동기화와 Config
동기화, 백업, 가져오기, 구독 업데이트는 서로 구분해야 합니다. 동기화는 지원되는 콘텐츠를 기기 간에 전달하고, 백업은 복원할 사본을 보관합니다. 가져오기는 외부 콘텐츠를 현재 앱에 넣으며, 구독 업데이트는 기존 출처에서 해당 항목을 새로 고칩니다. 비슷한 메뉴에 있더라도 같은 데이터를 덮어쓴다는 뜻은 아닙니다. 새 기기로 옮기기 전에 보관할 서버, Config, 로컬 설정을 정리한 뒤 각 항목에 맞는 방법을 선택하세요.
동기화 범위와 시스템 조건 확인
iCloud 기능을 사용하기 전에 기기에 예상한 Apple 계정으로 로그인했는지, 시스템에서 앱의 관련 클라우드 기능을 허용했는지, 현재 네트워크에서 동기화를 완료할 수 있는지 확인하세요. 그런 다음 Shadowrocket의 현재 메뉴에서 동기화 범위 설명을 읽으세요. 모든 Settings 값, 연결 상태, 시스템 VPN 권한, 과거 Log가 동기화된다고 가정하지 마세요. 범위에 명시되지 않은 항목은 새 기기에서 하나씩 확인해야 합니다.
동기화 스위치가 켜져 있다고 최신 내용이 클라우드에 저장됐다는 뜻은 아닙니다. 변경한 뒤 시스템이 내용을 전달할 시간을 주고 다른 기기에서 해당 항목이 표시되는지, 내용이 일치하는지 확인하세요. 시스템에서 저장 공간이나 네트워크 문제를 알리면 해당 조건을 먼저 해결하고 같은 파일을 반복해서 가져오지 마세요. 가져오기와 동기화를 동시에 반복하면 이름이 같은 항목이 생겨 어느 것이 최신이고 사용할 대상인지 판단하기 어려울 수 있습니다.
항목을 대량으로 편집하기 전에는 용도와 저장 당시 Config 상태를 알 수 있도록 이름을 붙인 백업을 만들어 두는 것이 좋습니다. 동기화는 과거 백업을 대신하지 않습니다. 잘못 삭제하거나 수정한 내용도 동기화될 수 있기 때문입니다. 백업에 인증 정보가 있다면 직접 관리하는 위치에 보관하고 공개 링크로 공유하지 마세요. 파일 이름에 전체 구독 주소를 넣지 마세요. 복원 테스트는 항목 몇 개부터 시작해 구조와 내용이 맞는지 확인한 뒤 계속 진행하세요.
Config 파일 선택과 가져온 뒤 확인
Config를 가져온 뒤 파일이 완전한지, 규칙을 읽을 수 있는지, 정책 참조가 현재 환경에 맞는지 확인한 다음 실제 사용 파일로 선택됐는지 살펴보세요. 파일이 목록에 보인다고 활성화된 것은 아닙니다. 이전 기기의 동작을 복원하려면 Global Routing이 Config 모드인지도 확인해야 합니다. 같은 파일을 선택했더라도 그렇지 않으면 실제 요청이 기존 규칙 판단을 거치지 않을 수 있습니다.
Config를 읽을 때는 전체 구조부터 세부 내용으로 살펴보세요. 먼저 규칙 순서와 최종 처리를 확인한 다음 도메인, 주소 대역, 관련 네트워크 설정을 확인합니다. 다른 곳에서 가져온 규칙 한 줄을 파일 맨 아래에 그대로 추가하지 마세요. FINAL 뒤에 놓이면 예상한 대로 동작하지 않을 수 있습니다. 편집 전 원본 파일을 복사해 복원용으로 보관하고, 편집 후에는 수정한 사본이 활성화됐는지 확인하세요. 이름이 같은 파일 사이에서 전환하며 변경이 적용되지 않았다고 오해하지 않도록 주의해야 합니다.
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY이 예시는 더 구체적인 규칙을 앞에 배치하는 방법을 보여 줍니다. example.com 자체는 DOMAIN으로 먼저 일치시키고 관련 하위 도메인은 DOMAIN-SUFFIX로 처리하며 나머지 요청은 FINAL에 넘깁니다. 이는 규칙 일부일 뿐 전체 서버 정보를 대신하지 않습니다. 실제 사용 전 각 규칙의 목적, 기존 정책, 도메인 범위를 확인하세요. Config가 사용자가 이미 보유한 출처에서 온 것이라면 파일 이름만 보고 용도를 판단하지 말고 변경 내용을 먼저 읽은 뒤 적용 여부를 결정하세요.
여러 기기에서 충돌이 발생했을 때 복원 순서
두 기기에서 같은 내용을 동시에 편집한다면 먼저 어느 쪽을 기준으로 보존할지 정한 뒤 동기화가 안정될 때까지 기다리세요. 양쪽에서 계속 편집하면서 반복해서 삭제하고 다시 만들면 최종 결과를 구분하기 더 어려워집니다. 다른 기기의 편집을 잠시 중단하고 한 기기에서 내용을 확인한 다음 다른 기기에서 대조할 수 있습니다. 복원할 때는 이름이 같은 서버도 표시 이름만 같다고 같은 항목으로 간주하지 말고 주소와 프로토콜 매개변수를 확인하세요.
새 기기로 옮길 때는 ‘앱 받기, 데이터 복원, 현재 Config 확인, 시스템 권한 설정, 실제 테스트’ 순서로 진행하세요. 앱 구매 자격과 Config 데이터는 별개입니다. 전자는 App Store의 구입 항목과 호환성에 따라 처리하고, 후자는 실제 백업이나 동기화 범위에 따라 복원해야 합니다. 복원 후에도 로컬 Settings와 On Demand를 확인하세요. 이전 기기의 모든 동작이 복사됐다고 가정해서는 안 됩니다. 구입 항목 복원 방법은 구입 항목 복원 안내에서 확인하세요.
구독을 업데이트한 뒤 항목이 달라졌다면 먼저 업데이트 출처와 항목의 소속을 확인하고 사용자 지정 편집 내용이 유지됐는지 살펴보세요. 원격 항목 갱신을 iCloud 충돌로 오해하지 말고, 로컬 이름을 유지하려고 인증 정보를 함부로 바꾸지 마세요. 정리가 필요하다면 먼저 백업한 뒤 기존 구독에서 관리하는 항목과 직접 관리하는 항목을 구분하세요. 역할을 명확히 해 두어야 다음 업데이트 이후에도 변경 사항을 추적할 수 있습니다.
Proxy 포트와 확인 절차
Proxy 포트는 먼저 로컬 포트와 원격 포트를 구분해야 합니다. 서버 항목의 Port는 원격 서버에 연결할 때 사용하는 포트이므로 사용자가 보유한 서버 정보와 일치해야 합니다. Settings에 로컬 HTTP 또는 SOCKS5 서비스 관련 포트가 있다면 기기에서 로컬 Proxy 서비스를 제공할 때 사용하는 수신 포트입니다. 두 포트가 같을 필요는 없으며 서로 대신할 수도 없습니다. 로컬 Proxy 서비스를 쓸 필요가 없다면 관련 기능의 현재 상태를 유지하고, 속도를 높이려는 목적으로 수신 포트를 함부로 열지 마세요.
수신 주소, 포트, 접근 범위
포트는 수신 주소와 함께 확인해야 합니다. 기기에서만 접근할 수 있는 포트와 로컬 네트워크의 다른 기기에서도 접근할 수 있는 포트는 노출 범위가 다릅니다. 설정 전에 바인딩 범위와 접근 권한에 관한 화면 설명을 읽고 다른 기기의 접속이 정말 필요한지 확인하세요. 포트 번호를 알고 있다고 다른 기기에서 반드시 접속할 수 있는 것은 아닙니다. 네트워크 격리, 주소 변경, 시스템 제한, 서비스 실행 여부도 결과에 영향을 줍니다.
로컬 포트를 직접 입력해야 한다면 화면에서 허용하고 다른 서비스가 사용하지 않는 값을 선택한 뒤 기존 값을 기록하세요. 원격 서버의 Port를 그대로 복사하지 말고, 모든 연결 오류를 숫자를 무작위로 바꿔 해결하려 하지 마세요. 저장한 뒤 서비스가 시작되는지 확인하고, 사용 예정 기기에서 올바른 프로토콜로 접속하세요. HTTP와 SOCKS5는 서로 다른 프로토콜이므로 포트만 맞바꾼다고 사용하는 쪽에서 자동으로 호환되는 것은 아닙니다.
로컬 서비스를 테스트할 때는 접근 범위를 최소로 설정해 작동 여부를 확인한 뒤 더 넓은 범위가 필요한지 판단하세요. 기기의 네트워크 주소가 바뀌면 접속 기기에 저장된 주소도 사용할 수 없게 될 수 있습니다. 주소 변경을 서버 장애로 오해하지 마세요. 접근 제어를 이해하지 못한 상태로 신뢰할 수 없는 네트워크에 서비스를 열어서도 안 됩니다. 사용을 마친 뒤 실제 진입점에서 서비스를 끄고 다른 기기가 계속 접속을 시도하는지 확인하세요.
Global Routing이 이후 요청 처리를 결정합니다
로컬 Proxy 진입점에서 연결을 받을 수 있다고 해서 이후 요청이 선택한 원격 서버를 거치는 것은 아닙니다. Global Routing과 현재 Config도 확인해야 합니다. Config, Proxy, Direct는 각각 설정 파일 기준 처리, Proxy 경유, 직접 연결을 뜻하는 서로 다른 모드입니다. 일상적인 분기 처리가 필요하다면 규칙이 올바른지 확인한 뒤 보통 Config를 사용합니다. Proxy와 Direct는 영향 범위를 이해한 상태에서 모든 요청에 같은 경로를 적용할 때나 임시 진단용으로 적합합니다.
| 화면 용어 | 설명 | 주요 확인 사항 |
|---|---|---|
| Config | Config 모드: 현재 Config에 따라 요청 처리 | 활성 파일, 규칙 순서, 정책 참조 |
| Proxy | Proxy 모드: Proxy 경로로 요청 처리 | 선택한 서버와 실제 연결 결과 |
| Direct | Direct 모드: 선택한 Proxy 서버를 거치지 않고 직접 연결 | 현재 네트워크에서 대상에 직접 연결할 수 있는지 |
특정 도메인을 진단할 때는 원래 상태를 기록한 뒤 Direct와 Proxy를 임시로 각각 적용해 비교하고, 마지막에 Config에서 규칙을 확인할 수 있습니다. 단, 비교 결과는 원인 범위를 좁히는 데만 사용하세요. 직접 연결은 성공하고 Proxy는 실패해도 Proxy 경로의 DNS, 인증, 대상 응답을 추가로 확인해야 합니다. 둘 다 실패한다면 대상 자체와 기본 네트워크도 점검해야 합니다. 테스트가 끝나면 원래 모드로 복원해 임시 진단 상태를 일상적인 분기 설정으로 사용하지 않도록 하세요.
모든 매개변수를 한꺼번에 바꾸지 말고 단계별로 확인
먼저 연결이 만들어지는지 확인하고, 다음으로 도메인 확인 여부, 규칙 일치 여부, 대상 응답을 차례대로 살펴보세요. 서버에 전혀 연결할 수 없다면 Address, Port, 프로토콜, 인증 정보를 먼저 확인합니다. 연결은 되지만 일부 도메인만 실패한다면 DNS와 규칙을 살펴보세요. 특정 서비스만 실패한다면 전송 유형과 서버 측 요구 사항을 함께 확인해야 합니다. WireGuard 항목은 일반적인 비밀번호 방식처럼 적용할 수 없습니다. Private Key, Peer, MTU 매개변수 안내를 참고하세요.
MTU, UDP 또는 특수 전송 매개변수는 기존 Config가 제공한 값을 유지하고, 문제가 분명하며 비교할 조건이 있을 때만 변경하는 것이 좋습니다. 값이 작거나 스위치가 많다고 자동으로 안정성이 높아지는 것은 아닙니다. 특정 네트워크에서 특정 요청만 실패하는지처럼 검증 가능한 가설에 따라 한 번에 하나씩 변경하세요. 개선되지 않으면 기존 값으로 되돌리세요. 여러 번 시험한 결과 출처를 설명할 수 없는 설정 조합을 남기지 마세요.
변경을 마친 뒤 일상적인 사용을 기준으로 마무리 점검을 진행하세요. 현재 서버와 Config, Global Routing, On Demand, 임시 Log 상태를 확인한 다음 자주 쓰는 페이지, 필요한 로컬 네트워크 리소스, 네트워크 전환을 각각 테스트합니다. 유효한 결론과 복원 기록은 남기고 불필요한 임시 사본은 정리하세요. 문제가 계속되면 원인을 찾지 못한 채 반복 초기화하지 말고, 민감 정보를 가린 증상과 테스트 조건을 정리해 분기 규칙 및 연결 문제 해결 FAQ를 확인하세요.