Shadowrocket Global Routing 사용법: Config·Proxy·Direct 차이

이 글 미리보기

Shadowrocket에서 직접 가져온 구독을 사용 중이지만 Global Routing에서 어떤 항목을 선택해야 할지 모르겠는 분을 위한 안내입니다. 먼저 연결 여부, 사용할 서버, 트래픽 라우팅의 차이를 구분한 뒤 같은 조건에서 Config·Proxy·Direct의 동작을 비교합니다. 평소에는 규칙을 확인한 Config를 사용하고, Proxy는 일시적으로 모든 트래픽을 프록시로 보내거나 라우팅 문제를 확인할 때, Direct는 직접 연결을 점검할 때 선택합니다. 전환 후 새 요청으로 결과를 확인하고 점검이 끝나면 기존 설정으로 되돌리세요.

1. 연결 스위치, 서버, Global Routing 구분하기

Global Routing은 Shadowrocket이 처리하는 연결에 적용할 라우팅 방식을 정합니다. 서버를 제공하는 기능도, 연결 스위치도 아닙니다. Home에서 서버를 선택해도 모든 요청이 그 서버를 경유하는 것은 아닙니다. Config를 선택한 경우 각 요청의 경로는 현재 설정의 규칙과 정책에 따라 결정됩니다.

먼저 Home에서 Global Routing을 찾아 현재 선택 항목을 확인합니다. 그런 다음 Config에서 사용 중인 설정 파일을 확인하세요. Settings의 기능 설정은 별도 항목입니다. 예를 들어 Settings → On Demand는 조건에 따라 연결을 요청하는 동작을 관리하며, 도메인에 DIRECT나 PROXY를 지정하는 기능은 아닙니다.

3가지 모드

비교 대상: Config / Proxy / Direct

2단계

먼저 연결 상태를 확인한 다음 요청의 라우팅을 점검합니다

테스트 대상 1개

매 테스트에서 같은 도메인과 네트워크를 사용합니다

일부 화면에는 Scene도 표시됩니다. Scene은 상황별로 라우팅 선택을 구성하는 기능이며, 네 번째 고정 트래픽 경로로 단순하게 볼 수는 없습니다. Scene을 사용한다면 현재 장면에 적용된 설정도 확인해야 합니다. 이 글에서는 장면 전환으로 변수가 늘어나지 않도록 수동으로 선택하는 세 가지 모드를 기준으로 설명합니다.

2. Config·Proxy·Direct의 트래픽 흐름

Config: 현재 설정에 따라 처리

권장

요청은 현재 설정의 규칙과 정책에 따라 처리됩니다. DIRECT에 매칭되면 직접 연결하고, PROXY에 매칭되면 프록시를 사용하며, REJECT에 매칭되면 요청을 거부합니다. 앞선 규칙에 매칭되지 않으면 일반적으로 FINAL이 경로를 결정합니다. Config가 일부 도메인만 프록시로 보낸다는 뜻은 아닙니다.

적합한 경우: 규칙과 FINAL을 확인한 뒤 평소 트래픽을 라우팅할 때

Proxy: 모든 트래픽을 프록시로 라우팅

클라이언트가 처리하는 연결을 Config의 라우팅 규칙에 따라 하나씩 분기하지 않고 모두 프록시 경로로 보냅니다. 실제 접속 가능 여부는 사용 중인 서버, 프로토콜 설정, DNS, 대상 서비스에도 영향을 받습니다.

적합한 경우: 일시적으로 모든 트래픽을 프록시로 보내거나 Config의 규칙과 정책을 비교 점검할 때

Direct: 모든 트래픽을 직접 연결

클라이언트가 처리하는 연결을 직접 연결 경로로 보내며, 선택한 프록시 서버를 거치지 않습니다. 클라이언트의 연결 상태가 유지되거나 DNS 등의 처리가 계속될 수 있으므로 Direct가 연결을 완전히 끄는 것은 아닙니다.

적합한 경우: 현재 네트워크에서 대상에 직접 접속할 수 있는지 확인하거나 일시적으로 프록시 경유를 피할 때

여기서 ‘모든 트래픽’은 클라이언트가 실제로 처리하는 범위에 한정되며, 기기의 모든 통신을 보장한다는 뜻은 아닙니다. 시스템 동작, 제외 항목, 기존 연결이 관찰 결과에 영향을 줄 수 있습니다. Proxy를 선택했다고 해서 DNS 요청이 모두 동일한 프록시 경로를 거친다고 단정할 수도 없습니다.

3. 네 줄의 규칙으로 이해하는 Config의 라우팅 방식

아래는 규칙을 읽기 위한 예시입니다. 설정의 [Rule] 섹션에 있는 규칙을 이해할 때 참고하세요. example.com은 설명용 도메인이며, 평소 접속을 위해 이 정책을 추가하라는 뜻은 아닙니다. 테스트 목적으로 현재 사용 중인 설정 전체를 덮어쓰지 마세요.

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

DOMAIN-SUFFIX,example.com,DIRECT: example.com과 그 하위 도메인에 매칭되어 DIRECT로 연결됩니다. notexample.com에는 매칭되지 않습니다.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: 해당 주소 범위에 매칭되는 연결에 DIRECT를 사용합니다. no-resolve는 이 규칙의 매칭을 위해 도메인 조회를 별도로 시작하지 않는다는 뜻입니다.
GEOIP,CN,DIRECT: 클라이언트가 사용하는 GeoIP 데이터로 대상 IP가 CN에 속하는지 판단합니다. 웹페이지 언어, 도메인 접미사 또는 사용자의 위치를 기준으로 판단하는 것은 아닙니다.
FINAL,PROXY: 앞선 규칙에 매칭되지 않은 요청에 PROXY를 사용합니다. FINAL,DIRECT로 변경하면 기본 경로도 달라집니다.

규칙은 순서대로 확인하며 먼저 매칭된 규칙이 해당 정책을 결정합니다. 테스트 도메인이 앞에서 DIRECT에 매칭되면 뒤에 PROXY 규칙이 있어도 프록시 경로로 바뀌지 않습니다. 정책이 설정의 정책 그룹을 가리킬 수도 있습니다. 이 경우 규칙의 마지막 항목만 보지 말고 정책 그룹에서 현재 선택된 항목까지 확인해야 합니다.

4. 평소 라우팅과 임시 점검을 위한 설정 방법

평소 Config를 사용하려면 설정의 출처와 규칙 범위, FINAL 처리 방식을 알고 있어야 합니다. 설정 내용을 확인하지 않았다면 ‘권장’이라는 말만으로 현재 네트워크에 적합하다고 판단할 수 없습니다. 구독에는 보통 서버 항목이 포함되고, 설정 파일에는 규칙과 기타 매개변수가 들어갈 수 있으므로 둘을 같은 것으로 볼 수 없습니다.

안정적인 일상 사용과 변수를 하나씩 확인하는 점검 절차

평소에는 Config 사용

Config에서 현재 파일을 확인하고 DIRECT, PROXY, FINAL을 점검합니다.
Home에서 사용할 수 있는 서버를 확인한 뒤 Global Routing → Config를 선택합니다.
직접 연결될 것으로 예상되는 대상과 프록시를 사용할 것으로 예상되는 대상을 각각 확인합니다.
자동 연결이 필요하면 Settings → On Demand도 별도로 확인합니다.

Proxy / Direct로 임시 전환

기존 라우팅 모드, 설정 파일, 선택한 서버를 기록합니다.
네트워크와 테스트 대상을 그대로 둔 채 Global Routing만 전환합니다.
기존 요청을 끝낸 뒤 다시 접속해 새 연결의 결과를 확인합니다.
점검 결과를 기록하고 Config로 되돌린 다음 자주 사용하는 서비스가 정상인지 확인합니다.

한 번에 변수 하나만 바꾸세요. 라우팅 전환, 구독 업데이트, 서버 변경, DNS 수정을 한꺼번에 하지 마세요.

모드를 전환해도 기존 장기 연결이 즉시 다시 만들어지지는 않을 수 있습니다. 음악 재생, 메시지 앱, 브라우저의 연결 재사용이 기존 연결을 계속 쓸 수 있습니다. 해당 요청을 먼저 중지한 뒤 대상을 다시 여세요. 클라이언트 연결을 끊었다가 다시 연결해야 한다면 유지해야 할 세션이 없는지 먼저 확인하세요.

5. 증상별 점검: Proxy는 되지만 Config는 안 될 때

이 증상은 라우팅 경로를 확인할 필요가 있음을 시사하지만, 특정 규칙이 잘못됐다고 바로 단정할 수는 없습니다. 경로에 따라 출구, DNS 조회 결과, 대상 주소가 달라질 수 있습니다. 아래 순서대로 확인하면 원인 범위를 좁히고 서버 문제를 규칙 문제로 오인하는 일을 줄일 수 있습니다.

조건을 동일하게 유지합니다. 대상 도메인, 현재 Wi-Fi 또는 셀룰러 네트워크, 선택한 서버, 연결 상태를 기록합니다. 같은 대상을 새로 요청해 Config와 Proxy의 결과를 각각 기록하세요. 지연 시간 테스트 결과를 웹페이지 접속 결과로 간주하지 마세요.
Config에서 실제로 매칭된 항목을 찾습니다. 클라이언트에서 확인할 수 있는 요청 또는 연결 기록을 열어 대상 도메인, 대상 IP, 매칭된 규칙과 정책을 확인합니다. DIRECT나 REJECT에 매칭됐는지, 다른 서버를 가리키는 정책 그룹을 사용했는지 중점적으로 살펴보세요.
기본 경로를 확인합니다. 앞선 규칙에 매칭되지 않을 때 적용되는 FINAL 정책을 확인하세요. 프록시를 예상했는데 실제 경로가 DIRECT라면 모든 규칙을 바로 수정하지 말고, 먼저 설정 의도에 따른 동작인지 누락인지 확인합니다.
도메인과 IP의 차이를 확인합니다. 대상이 다른 도메인으로 리디렉션되거나 여러 리소스 도메인을 불러올 수 있습니다. 홈페이지 도메인에만 규칙을 추가하면 로그인 API, 이미지, 미디어 요청까지 처리되지 않을 수 있습니다.
변경을 최소화합니다. 먼저 현재 설정을 백업하고 대상과 관련된 규칙이나 정책만 수정한 뒤 새 연결로 확인합니다. 원인을 찾은 후에는 불필요한 임시 설정을 되돌립니다.

Proxy와 Config 모두 접속할 수 없지만 Direct는 된다면 규칙을 다시 작성하기 전에 프록시 경로와 선택한 서버를 먼저 확인하세요. 세 가지 모드에서 모두 실패한다면 현재 네트워크, 대상 서비스의 상태, DNS 등 공통 조건을 점검해야 합니다. Direct에서도 클라이언트의 DNS 설정이 적용될 수 있습니다. 시스템 네트워크의 기본 상태와 비교하려면 중요한 세션이 없는지 확인한 뒤 클라이언트 연결을 끄고 별도로 테스트하세요.

6. Global Routing 자주 묻는 질문

Proxy를 선택했는데 특정 앱이 열리지 않는 이유는 무엇인가요?

먼저 Home에서 선택한 서버와 연결 상태를 확인한 다음 같은 대상을 새로 요청해 테스트하세요. 프록시 경로가 작동해도 대상 서비스가 해당 경로를 허용하지 않을 수 있습니다. DNS, 대상 서비스의 제한, 프로토콜 매개변수도 점검해야 합니다. 구체적으로 실패한 요청을 확인하지 않은 채 모드만 반복해서 전환하지 마세요.

Direct를 선택했는데 연결 표시가 계속 뜨는 이유는 무엇인가요?

Direct는 트래픽 라우팅을 바꾸는 설정이지 클라이언트를 끄는 설정이 아닙니다. 연결을 중지하려면 Home의 연결 스위치를 사용하세요. 이후 자동으로 다시 연결되면 Settings → On Demand에서 실행 조건을 확인합니다. 시스템의 연결 표시만으로 요청이 프록시 서버를 거쳤는지 판단하지 마세요.

구독을 업데이트하면 내게 맞는 Config 규칙도 자동으로 적용되나요?

그렇게 단정할 수 없습니다. 서버 구독 업데이트와 설정 파일의 규칙 관리는 따로 확인해야 합니다. 업데이트 후 Home에서 서버 항목을 확인하고 Config에서 현재 파일과 규칙을 점검하세요. 구독 링크는 서비스 제공자에게서 받으세요. 인증 정보가 포함된 링크를 공개 기록에 붙여 넣지 마세요.

Config를 더는 확인하지 않고 Proxy만 계속 사용해도 되나요?

필요에 따라 선택할 수 있지만, 모든 트래픽을 프록시로 보내면 직접 연결할 수 있었던 요청의 경로도 바뀌어 로컬 네트워크 리소스, 접속 지연 시간, 대상 서비스의 판단에 영향을 줄 수 있습니다. 트래픽을 분리해야 한다면 Config로 되돌리고 필요한 DIRECT 규칙을 명확히 설정하세요. Proxy를 설정 오류를 장기간 가리는 방법으로 사용하지 마세요.

iPad로 바꾸면 라우팅 선택을 다시 확인해야 하나요?

네. 새 기기에서 Home → Global Routing, Config의 현재 파일, Settings → On Demand를 각각 확인하세요. 설정 파일을 옮겼더라도 현재 네트워크에서 실제 동작을 확인해야 합니다. 기기마다 네트워크 환경과 연결 조건이 다를 수 있습니다.

마지막으로 작업 목적을 한 문장으로 확인할 수 있습니다. 평소 규칙에 따라 처리하려면 Config, 일시적으로 모두 프록시를 사용하거나 규칙을 비교하려면 Proxy, 직접 연결을 점검하려면 Direct를 선택합니다. 판단의 기준은 모드 이름이 아니라 새 요청이 실제로 어떤 규칙에 매칭되어 최종적으로 어떤 경로를 사용하는지입니다.