Shadowrocket은 적절한 Config를 선택하고 확인한 뒤 일상적으로 사용하는 것이 좋습니다. Proxy는 모든 연결을 일시적으로 프록시로 보내거나 문제를 비교 점검할 때, Direct는 직접 연결과 비교할 때 사용합니다. 본인에게 서비스 제공업체와 구독이 이미 있다는 전제하에 전환 방법, 규칙 순서, 연결 기록 확인법, Global Routing과 On Demand의 차이를 설명합니다.
라우팅 모드를 선택한 뒤 실제 적용된 정책 확인하기
Global Routing은 Shadowrocket이 처리하는 연결에 적용할 라우팅 방식을 정합니다. 노드 프로토콜을 선택하거나 구독을 업데이트하는 기능은 아닙니다. Home에서 노드를 선택하고, Config에서 구성을 선택하고, Global Routing에서 라우팅 모드를 선택하는 것은 서로 관련은 있지만 별개의 작업입니다. 하나만 바꾸면 원하는 결과를 얻지 못할 수 있습니다.
Config
권장현재 적용된 구성의 규칙에 따라 정책을 선택합니다. 결과는 DIRECT, PROXY, REJECT 또는 구성에 정의된 정책 그룹이 될 수 있습니다. 앞선 규칙에 일치하지 않으면 최종 처리 방식은 FINAL에 따라 결정됩니다.
적합한 경우: 구성을 확인했고 대상별로 처리 방식을 나눠 일상적으로 사용하려는 경우
Proxy
처리 대상 연결을 모두 프록시 경로로 보냅니다. Config의 일반적인 분기 규칙에 따라 직접 연결과 프록시를 선택하지 않습니다. 연결 가능 여부는 현재 프록시, 대상 서비스, 네트워크 환경에 따라 달라집니다.
적합한 경우: 모든 연결을 일시적으로 프록시로 보내거나 Config와 비교해 규칙 문제를 확인할 때
Direct
처리 대상 연결을 직접 연결하며 선택한 프록시 노드를 통해 전달하지 않습니다. Shadowrocket의 연결 스위치를 끄는 것과는 다르며, 관련 네트워크 설정이 모두 초기화된다는 뜻도 아닙니다.
적합한 경우: 현재 네트워크에서 대상에 접속할 수 있는지 확인하거나 잠시 직접 연결과 비교할 때
여기서는 자주 쓰는 라우팅 모드 세 가지를 비교합니다. Global Routing에 선택지가 세 개뿐이라는 뜻은 아닙니다. Scene은 조건에 따라 라우팅 선택을 적용합니다. 처음 문제를 점검할 때는 Config, Proxy, Direct 중 하나를 고정해 사용하면 Scene 조건 변화로 판단이 흐려지는 것을 막을 수 있습니다.
전환 순서: Home에서 확인하고 연결을 새로 설정하기
전환하기 전에 현재 라우팅 모드, 선택한 노드, 적용 중인 구성을 기록해 둡니다. 구독과 노드는 서비스 제공업체에서 받아야 합니다. 앱을 구매해도 사용할 수 있는 회선이 제공되지는 않습니다. Home에 사용할 수 있는 노드가 없다면 Global Routing을 반복해서 바꾸기보다 기존 구독을 가져오고 업데이트해야 합니다.
-
노드 확인
Home으로 이동해 현재 선택한 노드가 본인의 구독에서 가져온 것인지 확인합니다. 노드 주소, 포트, 인증 정보가 빠짐없이 입력되었는지 점검합니다. 연결 테스트 결과는 해당 테스트 조건에서만 유효하며, 대상 웹사이트에 실제로 접속할 수 있는지를 대신 확인해 주지는 않습니다.
-
구성 확인
Config로 이동해 현재 적용 중인 구성을 확인하고, 대상 도메인 규칙과 FINAL을 중점적으로 점검합니다. 구독을 가져왔다고 해서 일상적으로 사용하기에 적합한 분기 구성이 자동으로 선택되는 것은 아닙니다.
-
라우팅 모드 선택
Home → Global Routing → Config에서 규칙 기반 처리를 선택합니다. 일시적으로 비교하려면 같은 위치에서 Proxy 또는 Direct를 선택하고, 노드와 구성은 동시에 바꾸지 마세요.
-
다시 테스트
대상 앱으로 돌아가 요청을 새로 보냅니다. 기존 연결 상태가 유지될 수 있으므로 필요한 경우 대상 앱을 완전히 종료한 뒤 다시 엽니다. 그래도 결과가 불분명하면 Shadowrocket 연결을 끊었다가 다시 연결한 후 테스트합니다.
-
일상 설정으로 복원
각 라우팅 모드에서의 접속 결과와 연결 기록을 남깁니다. 점검을 마친 뒤 Home → Global Routing → Config로 돌아가 현재 구성과 정책 그룹이 의도한 대로 선택되어 있는지 확인합니다.
전환한 뒤 새 요청이 보이지 않으면 대상 앱에서 실제로 네트워크 요청을 보냈는지 먼저 확인하세요. 캐시된 페이지, 버퍼링된 동영상, 재사용 중인 장기 연결 때문에 화면에 변화가 없어 보일 수 있습니다. 이를 근거로 Global Routing이 적용되지 않았다고 단정할 수는 없습니다.
Config의 핵심: 순서대로 규칙을 적용하며 모든 것을 자동으로 판별하지는 않음
Config의 실제 동작은 규칙 내용에 따라 달라집니다. 일반적으로 규칙을 순서대로 확인해 먼저 일치하는 규칙의 정책을 적용하므로, 구체적인 예외 규칙은 더 포괄적인 규칙보다 앞에 두고 FINAL은 마지막에 배치합니다. Config를 선택했다고 해서 특정 지역은 직접 연결되고 나머지는 프록시로 연결되는 것은 아닙니다. 분류되지 않은 모든 대상이 프록시를 사용한다고 보장되지도 않습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY위 내용은 설명을 위한 규칙 예시이며 완전한 구성이나 구독 주소가 아닙니다. 첫 번째 규칙에는 예시 도메인을 사용했습니다. PROXY의 실제 출구는 현재 프록시 선택과 구성의 정책을 함께 확인해야 합니다. 이 내용을 현재 사용 중인 전체 구성에 그대로 붙여 넣지 마세요.
| 키워드 | 일치 대상 | 이 예시의 의미 |
|---|---|---|
DOMAIN-SUFFIX | 도메인 접미사 | example.com과 그 하위 도메인에는 PROXY를 적용합니다. 전체 URL 경로와 일치시키는 규칙은 아닙니다. |
IP-CIDR | IPv4 대역 | 대상이 192.168.0.0/16에 속하면 DIRECT를 적용합니다. no-resolve는 이 규칙과 일치시키기 위해 별도로 도메인을 확인하지 않는다는 뜻입니다. |
GEOIP | IP 지리 위치 분류 | CN으로 분류된 대상 IP에는 DIRECT를 적용합니다. 분류 결과는 사용하는 데이터에 따라 달라집니다. |
FINAL | 앞선 규칙에 일치하지 않은 연결 | 이 예시에서는 마지막에 PROXY를 적용합니다. DIRECT로 설정하면 앞선 규칙에 일치하지 않은 트래픽은 직접 연결됩니다. |
따라서 Config를 선택했는데도 대상이 직접 연결된다면 노드가 작동하지 않는다고 바로 판단하기보다 일치한 규칙과 FINAL부터 확인하세요. 연결 기록에서 앞쪽의 포괄적인 규칙이 적용된 것으로 나타나면 규칙 순서를 조정하거나 일치 범위를 수정합니다. 정책 그룹에 진입한 것으로 표시된다면 해당 그룹에서 현재 선택된 출구도 확인해야 합니다.
일상 사용과 문제 점검: 변수를 고정한 뒤 비교하기
사용 방법: 평소에는 규칙 기반으로, 문제가 생기면 한 번에 하나씩 비교
일상적으로 Config 사용
- 확인된 구성을 유지하고 FINAL의 처리 방식을 점검합니다.
- 프록시가 필요한 대상에는 프록시 정책을, 로컬 접속이 필요한 대상에는 DIRECT를 적용합니다.
- 구독을 업데이트한 뒤 노드 이름이 바뀌어 정책 그룹 참조에 영향을 주는지 확인합니다.
문제가 생기면 전환해 비교
- 같은 네트워크, 같은 노드, 같은 대상을 유지하고 라우팅 모드만 바꿉니다.
- 먼저 Config와 Proxy를 비교하고, 필요하면 Direct와도 비교합니다.
- 전환할 때마다 새 연결을 만들고 오류와 실제 적용된 정책을 기록합니다.
Proxy에서는 접속되지만 Config에서는 접속되지 않는다면 규칙, 정책 그룹, 관련 구성의 차이로 점검 범위를 좁힐 수 있습니다. 이 현상만으로 원인을 하나로 단정할 수는 없습니다.
예를 들어 같은 대상에 Proxy로 새 연결을 만들면 접속되지만 Config에서는 실패하고, 기록에 Config가 DIRECT를 선택했다고 표시된다면 먼저 대상 도메인의 규칙이 빠졌거나 앞선 규칙과 일치했는지 확인합니다. 두 라우팅 모드가 같은 프록시 출구를 사용하는데도 모두 실패한다면 서버 매개변수, 네트워크 연결 상태, 대상 서비스 상태를 추가로 점검해야 합니다.
Direct는 직접 연결의 기준으로 사용할 수 있지만 여전히 Shadowrocket이 연결을 처리하는 환경입니다. 연결을 활성화하지 않았을 때의 네트워크 동작을 확인하려면 연결 스위치를 끈 상태에서도 별도로 테스트하고, On Demand가 다시 연결을 시작하지 않는지 확인해야 합니다. 이 두 가지 테스트 조건을 한데 묶어 기록하지 마세요.
On Demand와 Scene: 연결 조건은 분기 규칙과 다름
Settings → On Demand에서는 조건에 따라 연결을 설정하는 옵션을 확인합니다. Global Routing은 연결이 이루어진 뒤 트래픽을 처리하는 방식을 결정합니다. 하나는 ‘언제 연결할지’, 다른 하나는 ‘연결 후 어떤 경로를 사용할지’를 정합니다. On Demand를 켜도 DOMAIN-SUFFIX 규칙이 추가되거나 구독에 포함된 노드 매개변수가 자동으로 수정되지는 않습니다.
- 연결이 자동으로 다시 설정됨: Settings → On Demand에서 활성화 상태와 조건을 확인하고 현재 테스트 의도에 맞는지 점검합니다.
- 네트워크를 바꾼 뒤 결과가 달라짐: Scene을 사용 중인지 확인하고, 현재 네트워크 조건에서 해당 Scene이 어떤 라우팅 선택을 적용하는지 점검합니다.
- 라우팅 모드를 고정해 점검: Home → Global Routing에서 Config, Proxy, Direct 중 하나를 명시적으로 선택해 일시적으로 Scene 조건이 결과를 결정하지 않도록 합니다.
- 테스트 후 설정 복원: 테스트를 위해 On Demand 또는 Scene을 조정했다면 변경 내용을 기록하고 필요한 원래 조건으로 복원합니다. 노드 선택만 되돌리는 것으로 끝내지 마세요.
On Demand를 켠다고 사용할 수 없는 네트워크가 연결 가능한 상태로 바뀌지는 않습니다. Wi-Fi와 셀룰러 네트워크를 전환하면 출구 주소, DNS 결과, 네트워크의 전송 프로토콜 제한이 달라질 수 있습니다. 라우팅 모드의 영향을 확인하려면 먼저 같은 네트워크에서 비교 테스트를 마친 뒤 다른 네트워크에서도 반복하세요.
점검 기록: 라우팅, 포트, 프로토콜 구분하기
Global Routing은 노드 자체의 프로토콜을 바꾸지 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 인증과 전송 요구 사항이 서로 다르므로 노드 매개변수는 서비스 제공업체가 안내한 정보를 따라야 합니다. Config를 Proxy로 바꿔도 누락된 인증 정보가 채워지거나 프로토콜이 다른 프로토콜로 변환되지는 않습니다.
대상 포트와 프록시 서버 포트는 서로 다른 항목입니다. HTTPS 웹사이트에 접속할 때 대상 포트는 보통 443이지만, 노드 연결에 사용하는 서버 포트는 서비스 제공업체가 안내한 매개변수대로 입력해야 합니다. 웹사이트가 443을 사용한다는 이유로 노드 포트까지 함께 변경하면 안 됩니다. DNS도 별도로 확인해야 합니다. 도메인 확인에 실패하면 대상 연결이 아직 설정되지 않은 것이므로 라우팅 모드를 바꿔도 해결되지 않을 수 있습니다.
| 관찰된 현상 | 먼저 확인할 항목 | 다음 단계 |
|---|---|---|
| Proxy 성공, Config 실패 | 일치한 규칙, 정책 그룹 선택, FINAL | 실패한 연결이 실제로 다른 출구나 DIRECT를 사용했는지 확인합니다. |
| Direct 성공, Proxy 실패 | 현재 프록시의 매개변수, 연결 가능 여부, 출구에 대한 대상 서비스의 제한 | 규칙을 바꾸지 않은 상태에서 현재 노드를 확인하고 서비스 제공업체에 매개변수를 문의합니다. |
| 세 가지 라우팅 모드 모두 실패 | 로컬 네트워크, DNS, 대상 서비스 상태 | 같은 네트워크에서 다른 대상에 접속할 수 있는지 먼저 확인한 뒤 연결 기록에 표시된 구체적인 오류를 살펴봅니다. |
| 이전 페이지에서만 정상으로 표시됨 | 캐시와 이미 설정된 연결 | 새 요청을 보낸 뒤 결과를 기록합니다. 캐시된 내용을 연결 성공의 증거로 간주하지 마세요. |
이러한 현상은 문제를 점검할 단서일 뿐 속도나 연결을 보장하지 않습니다. 기록에는 최소한 네트워크 유형, 대상 도메인, Global Routing 모드, 일치한 규칙, 선택한 출구를 적어 두세요. 전체 구독 링크, 인증 정보, 개인 접속 기록이 포함된 로그는 공개하지 마세요.
자주 하는 질문: Config 권장에 필요한 조건
구성을 확인하지 않았는데도 Config를 바로 선택해야 하나요?
먼저 현재 구성을 확인해야 합니다. Config는 규칙을 적용하는 라우팅 모드일 뿐입니다. 규칙이 불완전하거나 순서가 적절하지 않거나 FINAL이 예상과 다르면 결과에 영향을 줍니다. 일상적으로 Config를 권장하는 전제는 현재 어떤 구성이 적용 중인지 알고, 그 안에서 프록시와 직접 연결이 어떻게 구분되는지 이해하는 것입니다.
Proxy가 Config보다 항상 빠른가요?
그렇게 판단할 수는 없습니다. 두 모드가 최종적으로 같은 프록시 출구를 선택한다면 주요 전송 경로가 같을 수 있습니다. Config에서 대상에 DIRECT를 적용한다면 경로가 달라집니다. 속도는 네트워크, 서버 부하, 대상 서비스의 영향을 받으므로 모드 이름만 비교하지 말고 실제 출구를 확인해야 합니다.
구독을 업데이트하면 분기 규칙이 모두 자동으로 수정되나요?
아닙니다. 노드 구독 업데이트와 Config의 규칙 관리는 별개의 작업입니다. 업데이트 후 노드가 여전히 작동하는지, 정책 그룹 참조가 올바른지 확인하고 적용 중인 구성을 따로 점검해야 합니다. 새 구독이나 노드 정보가 필요하면 서비스 제공업체에서 받으세요.
Direct를 선택하면 연결 스위치를 확인하지 않아도 되나요?
아닙니다. Direct는 라우팅 선택이고 연결 스위치는 별도의 상태입니다. 활성화 전후의 네트워크 동작을 제대로 비교하려면 Direct 상태와 연결을 끈 상태의 결과를 각각 기록하세요. 자동 연결로 테스트 조건이 바뀌지 않도록 Settings → On Demand도 확인해야 합니다.