한눈에 보기

Shadowrocket은 일반적으로 Config로 사용하는 것이 좋습니다. 단, 설정을 선택하고 확인한 상태여야 합니다. Proxy는 프록시 경로를 임시로 확인할 때, Direct는 로컬 네트워크와 비교할 때 사용합니다. 서버나 구독을 이미 보유한 사용자를 대상으로, 세 모드가 요청 경로를 어떻게 바꾸는지와 여러 설정을 한꺼번에 변경하지 않고 문제를 찾는 방법을 설명합니다. 여기서 ‘모두’란 Shadowrocket의 처리 범위에 들어온 트래픽을 뜻하며, 기기의 모든 통신이 반드시 처리된다는 의미는 아닙니다.

1. 먼저 모드 선택: Config·Proxy·Direct의 처리 범위

Home → Global Routing에서 모드를 선택합니다. 이 설정은 요청에 적용할 라우팅 방식을 결정하며, 서버를 선택하거나 연결을 시작하는 설정은 아닙니다. 관련 트래픽이 Shadowrocket의 처리 범위에 들어와야 선택한 모드가 적용됩니다. 연결이 꺼져 있으면 여기서 모드만 바꿔도 프록시 연결이 설정되지 않습니다.

Config: 설정 규칙에 따라 경로 선택

권장

현재 설정의 트래픽 분기 규칙을 적용합니다. 요청에 따라 PROXY, DIRECT, REJECT 또는 설정에 정의된 정책 그룹을 사용할 수 있습니다. 앞선 규칙에 일치하지 않는 요청의 처리는 FINAL 등의 기본 규칙에 따라 달라지며, 반드시 직접 연결되는 것은 아닙니다.

적합한 경우: 신뢰할 수 있고 확인을 마친 설정을 보유했으며, 일상적으로 목적지별 트래픽 분기가 필요할 때.

Proxy: 프록시 경로로 통일

처리 범위에 들어온 트래픽을 프록시 경로로 통일하며, 일반적인 분기 규칙에 따라 요청별 경로를 결정하지 않습니다. 사용 가능한 서버가 필요합니다. 모드를 바꿔도 프로토콜, DNS, 대상 서비스 자체의 문제는 자동으로 해결되지 않습니다.

적합한 경우: 프록시 접속을 임시로 사용하거나 Config와 비교해 규칙 및 정책 선택을 점검할 때.

Direct: 직접 연결 경로로 통일

처리 범위에 들어온 트래픽을 선택한 프록시 서버를 거치지 않고 직접 연결합니다. VPN 상태가 계속 연결된 것으로 표시될 수 있으므로, 상태 표시만으로 특정 요청이 프록시를 거쳤는지 판단할 수 없습니다.

적합한 경우: 로컬 네트워크에서 대상에 직접 접속할 수 있는지 확인하고 비교 결과를 얻을 때.

Global Routing에는 Scene도 표시될 수 있습니다. 미리 설정한 조건에 따라 해당 설정을 적용하는 기능이므로, 고정된 네 번째 네트워크 경로로 보면 안 됩니다. Scene 조건을 확인하지 않았다면 먼저 이 문서에서 다루는 세 가지 명확한 모드로 테스트한 뒤 Scene 설정을 별도로 점검하세요.

2. 세 가지 설정 구분: 라우팅 모드, 구성 파일, 연결 스위치

‘구독을 가져왔다’는 것은 서버 정보가 있다는 뜻일 뿐, 규칙 설정이 올바르다는 의미는 아닙니다. 서버 구독은 주로 연결 매개변수를 제공하고, 구성 파일에는 규칙과 기타 설정이 포함될 수 있습니다. 두 항목은 각각 업데이트될 수 있으며 이름이 비슷해도 현재 같은 내용을 사용한다는 뜻은 아닙니다.

3가지
이 문서에서 비교하는 모드: Config / Proxy / Direct
2단계
모드 선택 위치: Home → Global Routing
4가지
아래 규칙 예시: DOMAIN-SUFFIX / GEOIP / IP-CIDR / FINAL
  1. 먼저 Home 확인: 선택한 서버가 사용자가 보유한 대상 서버인지, 연결 정보가 완전한지 확인합니다. Global Routing을 바꿔도 서버 주소, 포트 또는 인증 정보가 수정되지는 않습니다.
  2. 다음으로 Config 확인: 현재 선택된 구성 파일을 확인합니다. 파일을 저장하거나 가져온 것만으로 활성화되었다고 볼 수 없습니다. 목록으로 돌아가 현재 선택 상태를 확인하세요.
  3. 마지막으로 연결 스위치 확인: 연결이 설정되었는지 확인한 뒤 새 요청을 보냅니다. 기존 장기 연결은 방금 변경한 모드를 판단하는 데 적합하지 않습니다.

보유 중인 구독이 업데이트되었다면 먼저 서버 목록에 기존에 선택한 항목이 여전히 있는지 확인한 다음 실제 연결 대상을 점검하세요. 구독 업데이트와 Global Routing 변경은 별개의 작업입니다. 같은 라우팅 모드라도 선택한 서버가 바뀌면 결과가 달라질 수 있습니다.

3. Config의 경로 결정 방식: 규칙 순서와 FINAL 기본 처리

Config의 핵심은 ‘일부는 프록시, 나머지는 직접 연결’이라는 요약이 아니라 실제 규칙 내용입니다. 일반적인 트래픽 분기 규칙은 순서대로 확인하며, 앞쪽 규칙이 일치하면 뒤쪽 규칙이 적용되지 않을 수 있습니다. 아래는 문법을 이해하기 위한 예시입니다. 도메인은 설명용이며 접속 테스트 주소가 아니므로 구성 파일 전체를 대체하는 데 사용하면 안 됩니다.

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

따라서 Config가 자동으로 프록시 트래픽을 줄이거나 특정 사이트를 반드시 직접 연결하는 것은 아닙니다. 설정의 PROXY가 현재 서버 또는 정책 그룹 선택에 영향을 받을 수도 있으므로 정책 대상도 확인해야 합니다. 더 자세한 문법은 규칙 참조에서 확인하세요. 특정 대상 하나를 해결하려고 모든 규칙을 삭제하지 마세요.

4. 사용 상황별 선택: 일상적인 분기와 임시 진단

일상적으로 사용할 때는 설정을 이해하기 쉽게 유지하고, 문제를 진단할 때는 변수를 줄이세요. 구독 업데이트, 서버 변경, 네트워크 변경, 규칙 수정을 동시에 하지 마세요. 접속이 복구되더라도 어떤 변경이 영향을 미쳤는지 알 수 없습니다. 아래 두 방법은 같은 대상, 같은 기기, 같은 네트워크를 기준으로 비교합니다.

선택 방법: 평소에는 Config, 문제 진단 시에는 잠시 전환

일상적인 접속
  • Config에서 현재 구성 파일을 확인한 뒤 Home → Global Routing을 Config로 설정합니다.
  • 직접 연결될 것으로 예상되는 대상 하나와 프록시를 사용할 것으로 예상되는 대상 하나를 각각 확인합니다.
  • 특정 대상에 문제가 있으면 도메인과 발생 시간을 먼저 기록하고, 구성 파일 전체를 바로 교체하지 마세요.
임시 문제 진단
  • 서버와 네트워크는 그대로 유지하고 Config에서 Proxy로 전환한 뒤 새 요청을 보냅니다.
  • 로컬 네트워크와 비교해야 한다면 Direct로 바꾸고 같은 대상에 다시 접속합니다.
  • 각 모드와 결과를 기록하고, 진단이 끝나면 Config로 되돌린 뒤 실제 적용된 정책을 확인합니다.

한 번에 변수 하나만 변경하세요. 특정 모드에서 웹페이지가 열린 것은 진단에 참고할 단서일 뿐, 한 번의 결과만으로 원인을 단정할 수 없습니다.

자동 재연결도 별도로 확인해야 합니다. Settings → On Demand에서는 필요에 따른 연결 조건을 관리하며, 특정 도메인에 PROXY 또는 DIRECT를 적용하는 설정은 아닙니다. 연결이 자동으로 다시 설정된다면 먼저 On Demand를 확인한 다음 스위치 동작을 판단하세요. ‘자동 연결’과 ‘자동 트래픽 분기’를 혼동하지 마세요.

5. 연결되지 않을 때 재현 가능한 순서로 점검

먼저 로컬 네트워크를 확인한 다음 서버를 점검하고 마지막으로 규칙을 확인하세요. Connectivity Test는 연결 확인 도구이며, 결과는 앱에서 선택한 테스트 방식과 함께 해석해야 합니다. 테스트에 성공해도 모든 웹사이트, 모든 규칙 또는 각 프로토콜을 사용하는 트래픽까지 확인된 것은 아닙니다.

  1. 기준 정보 기록: 현재 네트워크, 대상 도메인, 선택한 서버, Global Routing 모드, 연결 설정 여부를 기록합니다. 암호나 전체 구독 주소와 같은 민감한 정보는 기록하거나 공유하지 마세요.
  2. 로컬 네트워크 확인: Direct로 평소 직접 연결되는 대상을 접속해 보세요. 여기서도 실패한다면 분기 규칙을 먼저 바꾸지 말고 Wi-Fi 연결, 모바일 네트워크, 대상 자체를 확인하세요.
  3. 프록시 경로 확인: 같은 서버를 유지한 채 Proxy로 새 요청을 보내고 Home에서 Connectivity Test를 실행합니다. 실패하면 사용 중인 연결 정보의 주소, 실제 포트, 인증 항목을 확인하세요.
  4. Config와 비교: Proxy에서는 성공하고 Config에서는 실패한다면 규칙 순서, 일치하는 정책 그룹, FINAL 및 이름 해석 관련 설정을 먼저 확인하세요. 이는 점검 방향일 뿐 서버나 DNS가 완전히 정상이라는 증거는 아닙니다.
  5. 재검사 후 원래 설정으로 복원: 한 곳을 수정한 뒤 같은 대상에 다시 요청합니다. 필요하면 연결을 끊었다가 다시 연결해 기존 연결의 영향을 배제하세요. 결과를 기록한 다음 평소 사용하던 모드로 복원하고, 임시 진단 설정을 그대로 두지 마세요.

예를 들어 같은 대상이 Proxy에서는 접속되지만 Direct에서는 시간 초과되고 Config에서도 시간 초과된다면, Config가 해당 요청을 DIRECT로 보내는지 또는 다른 정책을 선택했는지 중점적으로 확인해야 합니다. 이는 재현 가능한 판단 방법이지 미리 정해진 테스트 결과가 아닙니다. 기기에서 실제로 발생한 요청과 결과를 기준으로 판단하세요.

서버가 Shadowsocks, VMess, VLESS, Trojan, Hysteria2 또는 WireGuard를 사용하더라도 세 모드의 기본 역할은 달라지지 않습니다. 프로토콜 매개변수는 해당 연결을 설정할 수 있는지에 영향을 주고, Global Routing은 적용할 처리 경로를 결정합니다. 포트는 사용자가 보유한 서비스 설정에 지정된 실제 값을 사용해야 하며, 모든 프로토콜에 통용되는 포트 하나로 대체할 수 없습니다.

6. Global Routing 자주 묻는 질문

Proxy로 전환하면 모든 웹페이지에 접속할 수 있나요?

아닙니다. 먼저 Home에서 서버가 선택되어 있는지 확인하고 연결을 시작한 뒤 Connectivity Test를 실행하세요. Proxy는 프록시 경로를 통일할 뿐입니다. 서버 연결 불가, 인증 오류, 대상의 접속 거부, 이름 해석 문제는 각각 따로 확인해야 합니다.

Direct를 선택했는데 상태 표시줄에 VPN 표시가 남아 있는 이유는 무엇인가요?

Direct는 요청의 경로를 나타내며 VPN 세션을 끄는 설정은 아닙니다. Home으로 돌아가 연결 스위치를 확인하세요. 세션을 종료하려면 연결을 끄고 Settings → On Demand에 자동 연결 조건이 설정되어 있는지도 확인하세요.

Config에서 로컬 기기에 접속할 수 없으면 어디를 수정해야 하나요?

먼저 대상의 실제 주소를 기록한 뒤 현재 설정에 해당 주소 범위를 포함하는 IP-CIDR 규칙이 있는지, 더 앞선 규칙이 먼저 일치하는지 확인하세요. 위의 192.168.0.0/16은 하나의 주소 범위만 포함하며 모든 로컬 네트워크를 나타내지는 않습니다. 실제 네트워크 범위를 확인하고 예시를 그대로 복사하지 마세요.

규칙을 수정했는데 같은 웹페이지에 변화가 없어 보이는 이유는 무엇인가요?

먼저 수정한 파일이 현재 선택된 구성인지 확인한 다음 연결을 다시 설정하고 새 요청을 보내세요. 브라우저 캐시나 기존 장기 연결 때문에 겉으로 보이는 상태가 그대로일 수 있습니다. 같은 대상으로 다시 테스트하면서 화면 표시만 보지 말고 실제 요청에 적용된 정책도 확인하세요.

기존 구독을 업데이트한 뒤 Config를 Proxy로 바꿔야 하나요?

반드시 그럴 필요는 없습니다. 업데이트 후 서버 목록과 현재 선택 항목을 확인하고 Connectivity Test로 연결을 점검하세요. 일상적인 규칙은 계속 Config에서 사용할 수 있습니다. 프록시 경로와 규칙 문제를 구분해야 할 때만 Proxy로 잠시 전환해 비교하세요.

최종 선택은 세 단계로 정리할 수 있습니다. 명확한 트래픽 분기 요구가 있고 설정을 확인했다면 Config, 프록시 경로를 임시로 확인하려면 Proxy, 로컬 네트워크와 비교하려면 Direct를 사용하세요. 최초 연결 방법은 시작하기에서, 모드 설정은 라우팅 모드에서 확인할 수 있습니다.