Shadowrocket 사용법: 특정 사이트만 프록시로 연결하는 DOMAIN-SUFFIX 규칙

DOMAIN-SUFFIX와 FINAL,DIRECT를 사용해 지정한 도메인만 PROXY로 보내고 나머지는 DIRECT로 연결하는 방법을 실제 규칙과 함께 설명합니다. Config에서 수정하고 확인하는 단계도 안내합니다.

이 글의 핵심

이 글은 Shadowrocket에 직접 준비한 Config를 이미 가져왔으며, 일부 사이트만 프록시로 연결하려는 사용자를 위한 안내입니다. 대상 도메인을 DOMAIN-SUFFIX 규칙에 추가하고 마지막에 FINAL,DIRECT를 두는 것이 핵심입니다. Global Routing은 Config로 설정합니다. 이어서 최소 규칙, 편집 순서, 연결 확인 방법과 자주 발생하는 문제를 살펴봅니다. 예시 도메인은 문법 설명용이며 연결 서비스를 제공하지 않습니다.

1. 먼저 화이트리스트 라우팅의 범위 이해하기

여기서 ‘화이트리스트’는 프록시로 보낼 도메인 목록을 뜻합니다. 목록에 있는 도메인은 PROXY로, 나머지 요청은 DIRECT로 처리합니다. 접근 제어 목록이 아니므로 목록에 없는 사이트의 인터넷 연결을 차단하지는 않습니다. DIRECT는 대상에 직접 연결한다는 뜻이지 Shadowrocket을 끈다는 의미는 아닙니다. 연결은 여전히 로컬 터널과 규칙 처리를 거칠 수 있습니다.

규칙을 적용하려면 먼저 Home → Global Routing에서 Config를 선택합니다. Proxy나 Direct를 선택한 상태로는 도메인별 Config 설정을 확인할 수 없습니다. Scene은 상황별 라우팅을 선택하는 기능이므로 이번 점검의 기준으로 삼지 않습니다. 먼저 Config로 고정한 다음 규칙을 수정하면 모드 변경을 규칙 적용으로 착각하는 일을 피할 수 있습니다.

요청 시작 대상 확인 순서대로 규칙 확인 정책 결정 연결 설정

규칙은 순서대로 확인하며, 일치하는 규칙을 찾으면 해당 정책을 적용하고 이후 일반 규칙은 더 확인하지 않습니다. 따라서 앞쪽에 대상 도메인에 적용되는 DIRECT 규칙이 있으면 새로 추가한 프록시 규칙이 적용되지 않을 수 있습니다. 화이트리스트 라우팅에서는 규칙의 내용뿐 아니라 순서도 확인해야 합니다. 파일에 도메인이 있는지만 확인해서는 충분하지 않습니다.

2. DOMAIN-SUFFIX와 FINAL,DIRECT로 최소 규칙 작성하기

아래는 규칙 부분만 보여주는 최소 예시입니다. example.com과 example.net은 설명용 도메인이므로 실제로는 처리하려는 사이트의 도메인으로 바꿔야 합니다. 기존 Config에는 보통 다른 섹션도 포함되어 있습니다. 이 예시는 [Rule]만 보여주므로 전체 연결 Config로 그대로 교체하면 안 됩니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECT

DOMAIN-SUFFIX,example.com,PROXY는 example.com뿐 아니라 www.example.com, assets.example.com 같은 하위 도메인도 일치시킵니다. 아무 문자열이나 포함하는 방식은 아니므로 notexample.com이나 example.com.other.test에는 일치하지 않습니다. 규칙에는 도메인만 입력하고 https://, 경로, 쿼리 매개변수, 포트 번호는 넣지 않습니다.

2개
예시의 DOMAIN-SUFFIX 프록시 규칙
1개
마지막에 두는 FINAL,DIRECT 기본 규칙
443
HTTPS에서 자주 쓰는 대상 포트이며 도메인 매개변수에는 입력하지 않습니다

FINAL,DIRECT는 앞선 규칙과 일치하지 않은 요청을 처리하므로 판단에 필요한 모든 구체적인 규칙 뒤에 둬야 합니다. 첫 번째 줄에 있으면 뒤에 있는 도메인 규칙이 의도대로 작동하지 않습니다. PROXY는 서버 주소가 아니라 프록시 정책을 뜻합니다. 사용하기 전에 Home에서 직접 준비한 사용 가능한 서버를 선택했는지, 실제 아웃바운드 선택이 예상과 다르게 설정되어 있지 않은지 확인하세요.

정리: 최소 규칙으로 먼저 확인하기

처음 확인할 때는 대상 도메인 하나와 마지막 기본 규칙만 남겨 둡니다. 프록시와 직접 연결이 각각 예상대로 적용되는 것을 확인한 뒤 목록을 하나씩 늘리세요.

3. Config에서 규칙을 수정하고 적용하기

편집하기 전에 Home에서 선택된 서버, Global Routing 모드, Config에서 사용 중인 파일을 기록해 둡니다. 유일한 파일을 바로 덮어쓰기보다 Config를 복사해 수정하는 편이 되돌리기 쉽습니다. 원본이 원격 주소로 관리된다면 로컬 사본을 보관하세요. 이후 원격 Config를 업데이트하면 로컬 변경 사항이 덮어써질 수 있습니다.

  1. 기존 Config 보관하기

    Config에서 현재 사용하는 파일을 찾은 다음 파일 작업 메뉴를 통해 사본을 저장하거나 백업을 내보냅니다. 사본을 알아볼 수 있는지 확인한 뒤 편집을 시작하세요. 노드 구독 업데이트를 규칙 파일 백업으로 간주하면 안 됩니다.

  2. 규칙 섹션 편집하기

    Config에서 수정할 파일의 텍스트 편집 기능을 열고 기존 [Rule]을 찾습니다. 대상 DOMAIN-SUFFIX 규칙을 해당 섹션에 추가하고, 같은 이름의 섹션을 새로 만들지 마세요. 규칙 줄에는 영문 쉼표를 사용합니다.

  3. 기본 규칙 확인하기

    규칙 섹션 전체의 순서를 확인하고 FINAL,DIRECT를 맨 아래에 둡니다. ‘지정한 도메인만 프록시로 연결’하려면 기존 GEOIP, IP-CIDR, 규칙 모음 참조와 다른 프록시 규칙도 점검해 프록시 적용 범위가 의도치 않게 넓어지지 않도록 해야 합니다.

  4. 파일 선택하기

    저장한 뒤 Config로 돌아가 방금 수정한 파일이 선택되어 있는지 확인합니다. 이름이 비슷한 원격 파일이 선택되어 있지 않은지도 살펴보세요. 파일을 저장하는 것과 실제로 사용할 파일로 선택하는 것은 별개의 단계이므로 각각 확인해야 합니다.

  5. Config 적용하기

    Home → Global Routing → Config로 돌아가 직접 준비한 서버를 선택한 뒤 연결합니다. 테스트 요청을 새로 실행하세요. 기존 연결이 재사용되는 경우 연결을 끊었다가 다시 연결하고 테스트 페이지를 새로 여세요.

수동으로 끈 연결이 다시 자동으로 켜진다면 Settings → On Demand의 현재 설정을 확인하세요. On Demand는 조건에 따른 연결 동작을 제어하며 사이트 도메인별 프록시 목록을 지정하지는 않습니다. 재현 가능한 테스트를 위해 기존 설정을 기록한 다음 관련 자동 연결 조건을 잠시 끄고, 테스트 후 원래대로 복원할 수 있습니다.

4. 하위 도메인 예외와 사이트 부속 리소스 처리하기

주 도메인의 대부분은 프록시로 보내야 하지만 특정 하위 도메인은 직접 연결해야 한다면, 더 구체적인 예외 규칙을 먼저 쓰고 범위가 넓은 접미사 규칙을 뒤에 둡니다. 예를 들어 status.example.com만 직접 연결하려면 아래 순서를 사용할 수 있습니다. DOMAIN은 정확히 해당 호스트 이름만 일치시키며 하위 도메인까지 자동으로 포함하지 않습니다.

[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

웹사이트가 하나의 도메인으로만 이루어진 것은 아닙니다. 메인 페이지, 로그인 API, 이미지, 글꼴, 동영상이 서로 다른 호스트에서 제공될 수 있습니다. 페이지 주소에 해당하는 주 도메인만 추가하면 텍스트는 보이지만 이미지가 표시되지 않거나, 페이지는 열려도 로그인이 실패할 수 있습니다. 이런 경우 실패한 요청의 실제 호스트 이름을 확인하고 목록에 추가할지 판단하세요. 누락된 규칙을 숨기려고 모든 트래픽을 프록시로 바꾸지는 마세요.

IP-CIDR을 추가할 때는 공유 IP 주소도 주의해야 합니다. 하나의 주소에서 여러 도메인이 운영될 수 있으므로 주소 기준으로 프록시를 적용하면 목록에 없는 다른 요청에도 영향을 줄 수 있습니다. 따라서 ‘지정한 사이트만’ 적용하려면 실제 호스트 이름부터 확인하고, 주소 대역의 범위와 영향을 정확히 이해한 경우에만 IP 규칙을 추가하세요.

5. 페이지 접속 여부가 아니라 규칙 일치 결과로 확인하기

페이지가 열린다는 사실만으로 PROXY를 사용했다고 판단할 수 없고, 페이지가 열리지 않는다고 규칙 오류라고 단정할 수도 없습니다. 확인할 때는 Shadowrocket의 연결 기록이나 로그에서 대상 호스트, 일치한 규칙, 최종 정책을 살펴보세요. 서버 지연 시간 테스트만 보는 대신 새로 설정된 연결을 확인해야 합니다.

  1. 목록에 포함된 실제 사이트 하나와 목록 밖에 있으면서 현재 네트워크에서 직접 접속할 수 있는 사이트 하나를 고르고, 각각의 전체 호스트 이름을 기록합니다. 예시 도메인은 문법 설명용이며 실제 테스트 대상을 대신할 수 없습니다.
  2. Config 모드로 연결한 뒤 목록에 있는 사이트를 다시 방문합니다. 대상이 해당 DOMAIN-SUFFIX 또는 DOMAIN 규칙과 일치하고 정책이 PROXY인지 확인한 다음, 실제로 사용된 프록시 아웃바운드도 확인하세요.
  3. 목록에 없는 사이트에 접속해 요청이 FINAL에 의해 처리되는지, 정책이 DIRECT인지 확인합니다. 다른 규칙과 일치한다면 Config로 돌아가 기존 규칙을 점검하세요.
  4. 메인 페이지와 실패한 리소스의 연결 기록을 각각 확인합니다. 한 페이지에서 PROXY와 DIRECT가 함께 적용되는 것 자체는 반드시 문제가 아닙니다. 각 호스트의 결과가 목록 설정과 일치하는지가 중요합니다.
  5. 한 번에 한 항목만 수정하고 연결을 새로 설정한 뒤 같은 테스트를 반복하세요. 수정 전후의 대상, 규칙, 결과를 기록해 어떤 변경이 영향을 주었는지 확인하기 쉽게 만드세요.
DNS와 연결 재사용이 확인 결과에 영향을 줄 수 있습니다

도메인 이름 확인에 실패하면 이후 연결이 시작되지 않을 수 있습니다. 앱에 내장된 암호화 DNS나 IP 주소로 직접 보내는 요청도 확인 가능한 도메인 정보에 영향을 줄 수 있습니다. 도메인 규칙을 고치려고 여러 DNS 설정을 동시에 바꾸지 마세요. 먼저 현재 설정을 유지한 채 이름 확인 결과를 점검하고, 별도의 DNS 문제를 해결하세요. 이미 연결된 장시간 연결은 다시 연결한 뒤 새 기록을 확인합니다.

6. 증상에 따라 규칙 문제와 연결 문제 구분하기

문제가 생기면 두 단계로 확인하세요. 첫째, 요청이 예상한 규칙과 일치했는지 확인합니다. 둘째, 선택된 아웃바운드가 연결을 완료할 수 있는지 살펴봅니다. 아래 두 문구는 네트워크 연결 중 나타날 수 있는 원문 오류입니다. 화면마다 똑같은 형태로 표시되는 것은 아니므로 기록된 대상 주소와 아웃바운드 방향을 함께 확인해야 합니다.

오류: Connection timed out

원인: 제한 시간 안에 연결이 완료되지 않았습니다. 프록시 서버에 연결하는 단계나 대상 사이트에 연결하는 단계에서 발생할 수 있으며, 이 문구만으로 DOMAIN-SUFFIX가 유효하지 않다고 판단할 수는 없습니다.

해결: 먼저 적용된 정책을 확인하세요. PROXY가 적용된 것이 맞다면 직접 준비한 서버의 연결 상태와 같은 대상에 접속할 수 있는지 확인해 프록시 아웃바운드 문제와 대상 사이트 접속 문제를 구분합니다.

오류: Connection refused

원인: 원격 장치가 연결을 거부했습니다. 대상 포트에서 서비스가 대기 중이지 않거나 서버 주소, 포트가 실제 서비스 설정과 일치하지 않을 때 흔히 발생합니다.

해결: 먼저 오류가 프록시 서버와 웹사이트 중 어느 쪽에서 발생했는지 확인하세요. 그런 다음 사용 중인 서비스 제공자에게 기존 Config의 주소와 포트를 확인합니다. 웹사이트의 HTTPS 포트인 443을 프록시 서버 포트로 그대로 입력하지 마세요.

정리: 규칙 일치 기록을 기준으로 다음 단계 결정하기

잘못된 규칙과 일치했다면 규칙 내용과 순서를 수정하고, 올바른 규칙과 일치했지만 연결에 실패했다면 해당 아웃바운드를 점검하세요. 두 문제를 나눠 처리해야 ‘목록은 프록시, 나머지는 직접 연결’이라는 설정 범위를 유지할 수 있습니다.

검증을 마친 로컬 Config와 목록 안팎의 고정 테스트 대상을 보관하세요. 이후 사이트를 추가하거나 구독을 조정하거나 원격 Config를 업데이트할 때도 같은 절차로 다시 확인합니다. Shadowrocket 앱 구매와 연결 서비스 이용은 별개이며, 이 안내는 사용자가 직접 서비스와 Config를 준비한 경우를 전제로 합니다.

App Store에서 보기