Shadowrocket
규칙 및 설정 참고

01 · 설정 파일 구조와 편집 범위

Config를 열고 목록에서 최근에 가져온 파일이 아니라 현재 선택된 설정을 먼저 확인하세요. 해당 파일의 편집 화면으로 이동해 설정 섹션과 기존 규칙이 표시되는지 확인한 뒤 수정합니다. 저장 후 목록으로 돌아와 선택 표시가 같은 파일에 있는지 확인하세요. 다른 사본을 수정했다면 내용이 정확하더라도 현재 연결에는 적용되지 않습니다. Config에서 관리하는 트래픽 분기 설정과 Home의 서버 목록은 역할이 다르므로 같은 데이터로 취급하면 안 됩니다.

각 설정 섹션의 역할

Shadowrocket의 텍스트 설정은 대괄호로 표시된 섹션 이름을 기준으로 구성됩니다. 섹션 이름은 한 줄을 차지하며, 다음 섹션이 나오기 전까지 이어지는 내용이 해당 섹션에 속합니다. General에는 기본 동작 설정, Rule에는 순서대로 확인할 조건, Host에는 호스트 이름과 주소의 매핑, URL Rewrite에는 요청 주소를 변경하거나 리디렉션하는 규칙을 둡니다. 어떤 줄이 도메인처럼 보여도 무조건 Host에 넣지 마세요. 먼저 이 줄이 경로를 결정하는지, DNS 결과를 지정하는지, 요청 주소를 바꾸는지 판단해야 합니다.

아래는 구조를 확인하기 위한 최소한의 예시입니다. 기본 설정과 Rule만 보여 주며 서버 정의는 포함하지 않으므로 전체 설정을 대체하지 않습니다. PROXY에 사용할 수 있는 대상이 있는지는 Home에서 확인하세요. 예시 도메인은 설명용입니다. 실제로 검증할 때는 테스트 권한이 있고 접속 결과를 알고 있는 주소를 사용하세요. 서버 상태를 확인하려고 예시 주소를 반복해서 열지 마세요.

[General]
dns-server = system

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

원본을 보존하고 실험용 사본을 만드세요

편집 전에 현재 정상 작동하는 설정을 내보내거나 복사하고, 용도를 알아볼 수 있는 이름으로 사본을 저장하세요. 백업에는 기존 General, Rule, 사용자 지정 Host 내용이 복원 가능하도록 포함해야 합니다. 서버 목록도 저장했는지 별도로 확인하세요. 내보낸 파일에는 구독 주소나 인증 정보가 들어 있을 수 있으니 공개 게시판에 파일 전체를 올리지 마세요. 도움을 요청할 때는 관련 규칙, 가린 대상 정보, 실제 오류 현상만 공유하세요.

항목이 정상적으로 적용되는지는 저장 결과, 앱 내 편집기 설명, 요청 기록을 함께 확인해야 합니다. 영문 반각 쉼표와 등호, 섹션 이름을 그대로 유지하세요. 한글 문장 부호, 보이지 않는 공백, 문서 편집기에서 복사한 특수 따옴표 때문에 설정이 예상대로 해석되지 않을 수 있습니다. 저장 직후 오류가 발생하면 마지막 변경 사항부터 되돌린 뒤 한 줄씩 복구하세요. 여러 섹션을 한꺼번에 수정하지 마세요.

구독 업데이트와 설정 업데이트 구분하기

기존 구독은 주로 서버 항목을 업데이트하는 데 사용되며, 원격 설정은 트래픽 분기 규칙이나 기본 설정을 갱신할 수 있습니다. 두 작업은 서로 다릅니다. 서버를 업데이트해도 Rule은 바뀌지 않을 수 있고, 원격 설정을 다시 가져오면 로컬에서 수정한 내용도 다시 확인해야 할 수 있습니다. 업데이트 위치와 원격 콘텐츠의 종류, 저장 대상을 확인한 뒤 진행하세요. 구독 주소는 이용 중인 서비스 제공업체에서 확인하세요. 이 페이지에서는 주소를 제공하거나 서비스 제공업체의 품질을 평가하지 않습니다.

앱 내 편집 화면과 이 페이지의 예시가 완전히 일치하지 않는 경우 현재 표시되는 항목 설명을 따르고, 기존에 정상 작동하는 설정은 유지하세요. 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요. 앱 업데이트는 App Store에서 진행하며, 앱을 업데이트하기 위해 설정 파일 전체를 교체할 필요는 없습니다. 설정은 네트워크 동작을 관리하고 App Store는 앱의 구입 및 업데이트를 담당하므로 각각 따로 확인해야 합니다.

02 · Global Routing 및 규칙 적용 순서

규칙을 확인하기 전에 Home에서 Global Routing을 열어 현재 모드를 확인하세요. Config는 설정에 따른 분기, Proxy는 프록시, Direct는 직접 연결을 뜻합니다. Rule에 따라 트래픽을 분기하려면 Config를 선택한 뒤 새 요청을 발생시키고 기록을 확인하세요. Config에서 규칙을 편집했더라도 Proxy 모드를 유지한 채 모든 요청이 프록시를 거치는 것을 확인하는 것만으로는 Rule 문법에 문제가 있다고 판단할 수 없습니다. 현재 모드에 따라 해당 규칙이 판단에 사용되는지가 달라집니다.

첫 번째로 매칭되는 규칙이 우선이며, 긴 규칙이 우선하는 것은 아닙니다

Rule은 위에서 아래로 확인하며, 조건에 처음으로 일치하는 규칙이 해당 요청의 정책을 결정합니다. 아래에 더 구체적인 규칙이 있어도 앞에서 매칭된 결과를 자동으로 바꾸지 않습니다. 정확한 도메인 규칙을 포괄적인 접미사 규칙보다 위에 배치하는 것은 사용자가 정하는 우선순위이지, 앱이 자동으로 정렬해 주는 것이 아닙니다. 순서를 바꿀 때는 규칙이 있는 전체 섹션을 확인하세요. 원하는 규칙이 파일에 들어 있는지만 확인해서는 안 됩니다.

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

이 예시에서 api.example.com은 첫 번째 줄에 먼저 매칭되고, 나머지 example.com 하위 도메인은 두 번째 줄까지 내려갑니다. 두 줄의 순서를 바꾸면 api.example.com이 접미사 조건에 먼저 매칭되어 정확한 도메인 규칙은 판단에 사용되지 않습니다. 이런 문제를 확인할 때는 대상 호스트 이름, 처음 매칭된 조건, 최종 정책을 기록한 다음 더 넓은 범위를 다루는 규칙이 위에 있는지 확인하세요.

FINAL은 나머지 요청을 처리합니다

FINAL에는 도메인이나 주소 조건을 추가하지 않습니다. 앞에서 매칭되지 않은 요청을 처리하므로 Rule의 마지막에 두어야 합니다. 연결에 실패했을 때 다른 경로로 자동 전환하는 명령도 아니며, 프록시 연결 상태를 확인하지도 않습니다. FINAL,PROXY는 남은 요청을 PROXY로 보낸다는 의미입니다. PROXY에 해당하는 서버를 사용할 수 없다면 요청이 실패할 수 있으며, FINAL이 연결 문제를 자동으로 해결해 주지는 않습니다.

FINAL을 중간에 두고 그 아래에 예외 규칙을 추가하지 마세요. 중간의 기본 처리 규칙이 나머지 요청을 먼저 받기 때문에, 그 아래 항목은 저장되더라도 의도한 예외 처리를 할 수 없습니다. 여러 FINAL 규칙을 서로 다른 대체 경로로 사용하는 것도 권장하지 않습니다. 나머지 요청이 어느 경로를 이용해야 하는지 먼저 정하고, 마지막에 명확한 규칙 하나로 표현하세요.

요청 기록의 주소가 처음 접속한 도메인과 다를 수 있습니다

페이지를 열면 메인 페이지, 이미지, API, 리소스 파일 등 여러 연결이 발생할 수 있습니다. IP 요청 하나가 PROXY를 사용했다고 해서 메인 도메인 규칙이 작동하지 않는다고 단정할 수 없습니다. Data의 요청 또는 연결 기록에서 테스트 시각과 대상 호스트 이름에 해당하는 항목을 찾아 매칭 정보를 확인하세요. 기록에 대상 IP만 표시된다면 요청에 도메인 정보가 포함되어 있는지, 기존 연결에서 발생한 요청인지도 확인해야 합니다.

규칙을 저장한 뒤에도 이미 연결된 세션은 이전 경로를 계속 사용할 수 있습니다. 설정을 저장하고 선택된 파일을 확인한 다음 새 연결을 만든 뒤 대상 요청을 발생시키세요. 필요하다면 관련 앱을 완전히 종료한 후 다시 여세요. 같은 페이지를 연속으로 새로고침하는 것만으로 확인하지 마세요. 캐시 때문에 페이지가 갱신된 것처럼 보여도 확인하려는 새 연결은 발생하지 않았을 수 있습니다. 검증 결과는 식별 가능한 새 요청과 연결되어야 합니다.

03 · DOMAIN 계열 규칙 작성법

요청 기록에서 실제 호스트 이름을 복사한 뒤 매칭 방법을 선택하세요. 도메인 규칙의 조건에는 전체 URL을 쓰지 않습니다. https://, 경로, 쿼리 매개변수, 포트도 포함하지 마세요. 예를 들어 대상 주소가 https://api.example.com/status라면 DOMAIN 조건에는 전체 주소가 아니라 api.example.com을 입력해야 합니다. 경로별 분기는 별도의 요구 사항이며, 경로를 DOMAIN 뒤에 붙여 구현할 수 없습니다.

DOMAIN: 지정한 호스트 이름만 매칭

DOMAIN은 특정 호스트 이름 하나만 처리할 때 적합합니다. DOMAIN,example.com,DIRECT는 이름이 같아 보여도 api.example.com을 포함하지 않으며, 이름에 example이 들어간 다른 도메인도 포함하지 않습니다. 로그인 API나 업데이트 주소, 내부 서비스에 예외를 적용하려면 실제 호스트 이름을 확인한 뒤 정확히 매칭하세요. 서비스에서 여러 호스트 이름을 사용한다면 한 번의 접속이 하나의 주소에만 대응한다고 가정하지 말고 각각 기록해야 합니다.

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

이 예시는 호스트 이름 두 개를 명시한 뒤 나머지 하위 도메인에 기본 처리 방식을 설정합니다. login.example.com의 정확한 규칙과 접미사 규칙이 모두 PROXY를 가리켜 중복처럼 보이지만, 별도로 관리해야 하는 주소임을 표시할 수 있습니다. 관리 목적이 없다면 같은 정책의 중복 항목을 삭제해 설정을 읽기 쉽게 만드는 편이 좋습니다. 정리하기 전에 순서에 따라 작동하는 다른 예외가 없는지 확인하세요.

DOMAIN-SUFFIX: 도메인 계층별 매칭

DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인을 매칭합니다. 도메인 경계를 기준으로 판단하므로 임의의 문자열 포함과 다릅니다. api.example.com은 포함되지만 notexample.com은 포함되지 않습니다. 조건에는 보통 example.com을 그대로 입력합니다. 별표를 추가하거나 정규식처럼 사용하지 마세요. 더 좁은 범위가 필요하면 api.example.com을 접미사로 지정하고, 그 하위 호스트 이름까지 포함할지 명확히 정하세요.

접미사 규칙으로 서비스 도메인의 여러 주소를 처리할 수 있지만, 한 페이지의 리소스가 모두 같은 도메인에 있는 것은 아닙니다. 로그인이 되는데 이미지가 표시되지 않는다면 메인 도메인 규칙의 범위를 계속 넓히기보다 이미지 요청의 실제 도메인을 확인하세요. 확인된 도메인을 모두 하나의 너무 넓은 키워드로 묶으면 관계없는 요청에 영향을 줄 수 있습니다. 실패한 요청을 먼저 수집한 뒤 정확한 규칙을 추가할지 다른 접미사 규칙을 만들지 결정하세요.

DOMAIN-KEYWORD: 예상보다 넓은 범위에 매칭될 수 있습니다

DOMAIN-KEYWORD는 도메인 문자열을 대상으로 키워드를 매칭하며, 키워드가 완전한 도메인 레이블 하나와 일치할 필요는 없습니다. DOMAIN-KEYWORD,example,PROXY는 해당 문자열이 들어간 서로 무관한 여러 도메인에 매칭될 수 있습니다. 이런 광범위한 매칭이 필요한 경우에 사용하고, 모든 DOMAIN-SUFFIX 규칙을 대신하는 용도로는 적합하지 않습니다. 문제를 해결할 때는 넓은 키워드를 실제로 확인된 호스트 이름으로 좁히면 오매칭을 줄일 수 있습니다.

규칙 조건에 한글 주석, 불필요한 끝 쉼표, 브라우저에서 복사한 문장 부호를 넣지 마세요. 정책은 정해진 위치에 입력하고 설명은 별도 줄에 작성해 주석이 필드로 해석되지 않도록 합니다. 설정 편집기에서 유형, 조건, 정책을 각각 입력할 수 있다면 긴 줄을 한꺼번에 붙여 넣는 것보다 필드별 입력이 오류를 찾기 쉽습니다. 저장 후 텍스트 화면으로 돌아와 결과를 확인하세요.

매칭 범위와 정책 변경을 나누어 검증하세요

도메인 규칙을 테스트할 때는 먼저 정책을 그대로 두고 대상이 해당 규칙에 매칭되는지 확인하세요. 조건이 정확한지 확인한 뒤 PROXY 또는 DIRECT를 변경합니다. 이 방법으로 ‘매칭되지 않음’과 ‘매칭은 됐지만 경로가 실패함’을 구분할 수 있습니다. 조건, 서버, DNS를 한꺼번에 바꾸면 성공하거나 실패해도 어떤 변경이 영향을 주었는지 알 수 없고, 이후 되돌릴 때도 기준이 불분명해집니다.

04 · IP, GEOIP 및 USER-AGENT

도메인 조건으로 모든 요청을 처리할 수는 없습니다. 일부 앱은 IP 주소에 직접 연결하며, 일부 연결 기록에는 규칙에 사용할 호스트 이름이 없습니다. 이 경우에만 IP-CIDR, IP-CIDR6 또는 GEOIP를 고려하세요. 먼저 실제 대상 주소와 주소 체계를 확인한 뒤 조건을 선택합니다. 브라우저 주소 표시줄의 문자만 보고 실제 연결에도 도메인이 포함된다고 추정하지 마세요. IP 규칙 하나가 웹사이트의 영구적인 식별 기준이 되는 것도 아닙니다.

IP-CIDR: 주소 및 프리픽스 길이

IP-CIDR 조건은 네트워크 주소와 슬래시 뒤의 프리픽스 길이로 구성됩니다. 192.168.0.0/16은 주소 범위를 나타내고, 192.168.1.20/32는 IPv4 주소 하나만 포함합니다. 프리픽스 숫자가 클수록 일반적으로 범위가 좁습니다. 규칙은 연결 대상 주소에 적용되며 현재 iPhone의 로컬 주소에 적용되는 것이 아닙니다. 내부 기기를 직접 연결하려면 그 기기가 있는 대상 네트워크 범위를 입력해야 합니다. 기기 자체 주소를 임의로 복사하지 마세요.

[Rule]
IP-CIDR,192.168.1.20/32,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fd00::/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시는 내부 주소 하나를 먼저 지정한 다음 더 넓은 사설 주소 범위를 추가해 나중에 예외를 넣기 쉽게 구성했습니다. 실제 환경에는 다른 내부 네트워크 대역이 사용될 수 있으므로 네트워크 설정과 관리자가 제공한 정보를 따르세요. 사설 IP를 DIRECT로 설정해도 라우팅 경로만 직접 연결로 선택할 뿐, 접근 권한이 자동으로 생기는 것은 아닙니다. 해당 네트워크에 연결되어 있어야 하며 대상 서비스가 적절한 포트에서 요청을 받고 접근을 허용해야 합니다.

IP-CIDR6 및 IPv6 문제 해결

IP-CIDR6은 IPv6 주소 범위에 사용합니다. 예시의 fd00::/8은 로컬 주소 범위 작성 방법을 보여 줄 뿐, 모든 IPv6 주소를 직접 연결해야 한다는 의미는 아닙니다. 같은 호스트 이름이 두 종류의 주소를 모두 반환하는 경우 IPv4 규칙만으로는 실제 IPv6 연결을 처리하지 못할 수 있습니다. 기록에서 연결에 사용된 주소 유형을 확인한 다음 규칙 추가 여부를 결정하세요. 일반적인 해결책으로 주소 체계 전체를 비활성화하지 마세요.

일부 IP 계열 규칙은 no-resolve 매개변수를 지원해 해당 규칙을 확인하는 과정에서 도메인을 추가로 조회하지 않도록 할 수 있습니다. 이는 매칭 과정에서 발생하는 조회를 제한하는 것으로, 요청에 필요한 모든 DNS 처리를 취소하는 것은 아닙니다. 요청에 도메인만 있고 사용할 수 있는 대상 IP가 없다면 규칙이 예상대로 매칭되지 않을 수 있습니다. 사용하기 전에 현재 편집기가 해당 매개변수를 지원하는지 확인하고, 매개변수를 넣은 경우와 넣지 않은 경우를 각각 검증하세요.

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

GEOIP는 언어가 아니라 주소 데이터베이스를 기준으로 합니다

GEOIP,CN,DIRECT는 대상 IP의 지리적 분류에 따라 DIRECT를 선택한다는 뜻입니다. 페이지 언어, 도메인 접미사 또는 사용자의 위치를 기준으로 분류하는 것은 아닙니다. 도메인에서 분산된 IP 주소를 사용할 수 있고 데이터베이스의 분류가 실제와 다를 수 있으므로 서비스 운영 지역을 추정하거나 연결 속도를 보장하는 기준으로 삼지 마세요. 일부 서비스에만 예외를 적용하려면 검증된 DOMAIN 규칙을 앞에 두는 편이 전체 GEOIP 조건을 넓히는 것보다 관리하기 쉽습니다.

도메인 규칙과 GEOIP가 함께 있으면 적용 순서가 여전히 중요합니다. 앞에 있는 도메인 조건이 먼저 매칭되면 뒤의 IP 지역 분류가 정책을 자동으로 바꾸지 않습니다. 기록에서 요청이 GEOIP에 매칭되었다면 앞의 도메인 조건이 실제 호스트 이름을 포함하는지 먼저 확인한 뒤 현재 연결에 도메인 정보가 남아 있는지 확인하세요. 요청 대상을 확인하지 않고 주소 데이터베이스만 업데이트해도 문제가 해결되지 않을 수 있습니다.

USER-AGENT는 앱 식별을 대신하지 않습니다

USER-AGENT는 가져올 수 있는 요청 헤더 필드를 기준으로 매칭합니다. 예를 들어 USER-AGENT,ExampleClient*,PROXY는 와일드카드 패턴 조건을 보여 줍니다. 앱 이름에 따라 트래픽을 분기하는 기능이 아니며, 모든 연결에서 필드를 확인할 수 있는 것도 아닙니다. 암호화된 요청의 헤더는 확인할 수 없는 경우가 많으므로 이런 규칙을 위해 무작정 복호화를 활성화하지 마세요. 매칭할 필드가 기록에 없다면 명확한 도메인 조건을 찾고, 나머지 요청은 FINAL로 처리하세요.

05 · PROXY, DIRECT, REJECT 및 프로토콜 매개변수

규칙의 앞부분은 ‘어떤 요청인지’를, 마지막 정책은 ‘어떻게 처리할지’를 지정합니다. PROXY, DIRECT, REJECT는 자주 사용하는 정책 키워드이며 대소문자와 철자를 정확히 유지해야 합니다. 정책 이름과 서버 프로토콜을 혼동하지 마세요. Shadowsocks, VMess, Hysteria2는 서버 연결에 사용하는 프로토콜을 나타내며, Rule에서 PROXY를 대신하는 일반적인 동작이 아닙니다. 조건이 매칭되는지 확인한 뒤 정책이 가리키는 실제 연결 대상을 점검하세요.

PROXY와 DIRECT의 차이

PROXY는 일반적으로 현재 선택된 프록시로 요청을 전달합니다. 실제 대상은 Home에서 선택한 서버와 설정의 정책 그룹 여부에 따라 달라집니다. DIRECT는 직접 연결 경로를 사용하지만 네트워크 환경, 시스템 권한, DNS 조회를 우회한다는 뜻은 아닙니다. 어떤 대상이 직접 연결된다고 해서 프록시 설정이 올바르다고 볼 수 없고, 프록시가 연결된다고 해서 모든 내부 주소를 프록시로 보내야 하는 것도 아닙니다. 서비스 위치와 사용 목적에 맞게 선택하세요.

현재 설정에 이름이 지정된 정책 그룹이 있다면 규칙 끝에 그룹 이름을 사용할 수도 있습니다. 이 경우 그룹이 실제로 존재하는지, 이름이 정확히 일치하는지, 사용할 수 있는 구성원이 있는지 확인하세요. 다른 파일의 그룹 이름을 붙여 넣는다고 그룹이 자동으로 생성되지는 않습니다. 이 페이지의 예시는 독립적으로 읽을 수 있도록 기본 정책을 사용합니다. 전체 설정에서 그룹을 사용 중이라면 기존 구조를 유지하면서 예외 규칙을 배치하세요.

REJECT는 요청을 명시적으로 거부합니다

REJECT는 매칭된 요청을 명시적으로 거부하는 데 사용하며, 실패하면 다른 서버로 전환하는 기능이 아닙니다. 차단해야 하는 대상이 확실할 때만 사용하세요. 로그인에 필요한 도메인에 REJECT를 잘못 설정하면 앱이 계속 대기하거나 버튼이 반응하지 않고 일부 리소스만 표시되지 않을 수 있습니다. 거부된 요청을 찾아 조건의 범위가 지나치게 넓은지 확인한 뒤 규칙을 삭제하거나 범위를 좁히세요.

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,internal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

이 규칙은 서로 다른 세 호스트 범위에 적용되는 동작을 보여 주는 예시이며 실제 로그인 도메인을 차단 목록에 추가하라는 뜻이 아닙니다. blocked.example.com은 거부하고 internal.example.com은 직접 연결하며, 나머지 example.com 하위 도메인은 프록시로 보냅니다. 순서를 바꾸면 결과도 달라질 수 있습니다. 규칙을 장기간 관리하려면 각 예외가 필요한 이유를 간단히 기록해 두세요. 이유를 설명할 수 없는 거부 규칙을 쌓아 두는 것보다 관리하기 쉽습니다.

이미 보유한 서버의 프로토콜 매개변수만 확인하세요

서버를 가져온 뒤 프로토콜 유형을 확인하고 주소, 포트, 인증 정보를 차례로 점검하세요. Shadowsocks의 암호화 방식과 비밀번호, VMess 및 VLESS의 식별 정보, Trojan의 비밀번호와 TLS 설정은 각각 의미가 다릅니다. 필드 위치가 비슷하다고 서로 바꾸어 사용할 수 없습니다. 온라인에 흩어진 예시보다 이용 중인 서비스 제공업체가 전달한 전체 정보를 우선하세요. 누락된 값은 제공업체에 확인하고 임의로 추측하지 마세요.

TLS 연결 실패 시 서버 이름, 인증서 조건, 시스템 시간을 확인하세요. 인증서 검증을 건너뛰는 설정을 기본 문제 해결 방법으로 사용하지 마세요. Hysteria2를 사용할 때는 UDP에 실제로 연결할 수 있는지도 확인해야 합니다. 한 번 응답이 있었다고 모든 전송 방식이 정상이라고 볼 수는 없습니다. 프로토콜마다 성공 조건을 따로 검증하고, 한 서버의 결과로 다른 서버 설정까지 올바르다고 판단하지 마세요.

PROXY 요청은 실패하지만 DIRECT는 성공한다면 선택된 서버, 프로토콜 유형, 실패 단계를 기록한 뒤 Home에서 해당 서버 항목을 확인하세요. 같은 서버를 통해 모든 대상에 연결할 수 없다면 사이트별 규칙을 추가하기보다 서버와 네트워크를 먼저 점검해야 합니다. 특정 대상 하나만 실패한다면 추가 도메인, 특수 포트, 서버 측 접근 제한이 있는지 확인하세요.

06 · General, DNS 및 Host 매핑

DNS는 호스트 이름을 연결 가능한 주소로 변환하고, Rule은 요청 처리 정책을 결정합니다. 서로 연관되어 있지만 같은 기능은 아닙니다. 페이지가 열리지 않을 때는 먼저 주소를 가져왔는지, 어느 주소에 연결했는지, 어떤 정책을 사용했는지 구분하세요. DNS만 바꿔도 비밀번호 오류가 해결되지는 않으며, PROXY만 바꿔도 존재하지 않는 도메인이 조회되는 것은 아닙니다. 문제를 단계별로 기록하면 관련 없는 항목을 반복해서 수정하는 일을 줄일 수 있습니다.

dns-server와 시스템 DNS 환경

General의 dns-server = system은 시스템에서 제공하는 DNS 설정을 사용하는 항목입니다. 필드 역할을 이해하기 위한 기본 예시이지 모든 네트워크에 권장하는 설정은 아닙니다. 시스템 DNS 환경은 Wi-Fi, 셀룰러 네트워크, 네트워크 관리 설정에 따라 달라집니다. 설정에서 DNS 옵션을 바꾸기 전에 현재 네트워크와 기존 DNS 설정을 기록하세요. 네트워크를 전환한 뒤 차이가 생겼을 때 비교할 수 있습니다.

[General]
dns-server = system

[Host]
lab.example.com = 192.168.1.20

[Rule]
DOMAIN,lab.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

이 예시는 lab.example.com을 내부 기기의 주소로 지정하고 해당 도메인을 직접 연결하도록 설정합니다. 도메인과 기기를 실제로 관리하는 테스트 환경에서만 사용하세요. Host는 주소 매핑을 담당하고 DOMAIN은 정책 선택을 담당합니다. 후자가 없으면 요청이 다른 Rule에 따라 프록시로 전달될 수 있습니다. 반대로 DIRECT만 설정하고 주소를 올바르게 조회하지 못하면 호스트 이름이 해당 기기를 가리키지 않을 수 있습니다.

Host는 인증서와 서비스의 식별 정보를 바꾸지 않습니다

호스트 이름을 특정 IP로 매핑해도 접속에 사용되는 이름은 대체로 그대로 유지됩니다. HTTPS 서비스는 해당 이름과 일치하는 인증서를 제공해야 하며, 서버는 호스트 이름을 기준으로 사이트를 선택할 수 있습니다. IP 주소로 페이지가 열린다고 해서 임의의 Host 매핑도 정상 작동한다고 볼 수는 없습니다. 주소 연결 가능 여부, 인증서 일치 여부, 사이트 설정은 서로 다른 조건이므로 각각 충족해야 합니다.

Host는 동적으로 주소가 바뀌는 공개 서비스의 장기적인 고정 설정에 적합하지 않습니다. 서비스 주소가 바뀐 뒤에도 이전 매핑이 남아 있으면 요청이 이미 사용할 수 없는 대상으로 전달되어 다른 기기에서는 정상인데 현재 기기에서만 실패할 수 있습니다. 문제를 해결할 때는 남아 있는 매핑을 확인하고 일시적으로 제거한 뒤 새 연결을 만들어 결과를 비교하세요. 내부 기기에 매핑을 사용한다면 네트워크에서 주소를 다시 할당해 기기 주소가 바뀌었는지도 확인해야 합니다.

DNS 캐시와 연결 재사용 구분하기

매핑을 수정한 뒤에도 이전 DNS 기록이나 기존 연결이 결과에 영향을 줄 수 있습니다. 파일을 저장하고 설정이 선택되어 있는지 확인한 다음 다시 연결해 새 요청을 발생시키세요. 필요하다면 앱에서 제공하는 기능으로 관련 캐시를 지우세요. 페이지에 이전 내용이 표시된다고 해서 Host가 적용되지 않았다고 바로 판단하지 마세요. 페이지 캐시, 서버 캐시, 연결 재사용이 이전 결과를 유지할 수 있습니다. 새 기록의 대상 주소를 우선적으로 확인하세요.

기록에서 도메인에 대응하는 주소가 보이지 않는다면 현재 네트워크에서 해당 이름을 조회할 수 있는지 확인한 뒤 철자 오류, 내부 DNS 의존 여부, 앱 자체의 조회 방식을 점검하세요. 일부 앱은 일반적인 도메인 확인 방식으로 요청 정보가 완전히 드러나지 않을 수 있습니다. 이를 근거로 모든 DNS가 설정을 우회한다고 결론 내리지 마세요. 여러 페이지를 한꺼번에 테스트하기보다 반복 가능한 대상 하나로 범위를 좁히는 편이 원인을 찾기 쉽습니다.

General 항목별 확인

General에는 시스템 트래픽 처리, 예외 범위, 주소 체계와 관련된 매개변수도 있을 수 있습니다. 이를 ‘최적화 스위치’처럼 묶어서 붙여 넣지 마세요. 현재 설정을 기준으로 항목의 의미와 Rule과의 관계를 먼저 확인해야 합니다. 트래픽 처리 범위에 영향을 주는 매개변수라면 Rule을 추가하는 것만으로 그 효과를 무시할 수 없을 수 있습니다. 한 번에 하나씩 수정하고 변경 전 값을 기록한 뒤 해당 현상이 해결되었는지 확인하세요.

암호화 DNS 같은 조회 방식을 사용할 때는 조회 요청이 대상에 도달하는 경로와 연결 의존성도 고려해야 합니다. 프록시 서버 주소를 조회해야 하는데 DNS 서버에 접속하려면 해당 프록시가 필요한 경우 시작 단계에서 서로를 기다리는 상황이 생길 수 있습니다. 이런 문제가 발생하면 정상 작동이 확인된 기본 설정으로 되돌린 뒤 DNS와 연결을 순서대로 구성하세요. 근본적인 의존성을 해결하지 않고 조회 주소만 계속 추가하지 마세요.

07 · URL Rewrite의 용도와 제한

바꾸려는 대상이 접속 경로인지 요청 주소인지 먼저 확인하세요. example.com을 PROXY로 보내는 것은 Rule에 해당하고, 기존 주소를 다른 URL로 바꾸는 경우에는 URL Rewrite가 필요할 수 있습니다. 두 설정 섹션은 서로 대체할 수 없으며 URL Rewrite를 Rule보다 앞에 둔다고 트래픽 분기 우선순위가 높아지는 것도 아닙니다. 서로 다른 문제를 처리하므로 검증할 때 라우팅 결과와 주소 변경을 따로 확인하세요.

제어 가능한 HTTP 주소 하나로 시작하세요

URL Rewrite는 일반적으로 매칭 표현식, 대상 주소, 처리 동작으로 구성됩니다. 아래 예시는 HTTP에서 HTTPS로 리디렉션하는 구조를 설명합니다. 테스트 전에 해당 대상을 직접 관리하는지 확인하고, 현재 편집기에서 지원하는 동작과 문법을 따르세요. 표현식의 역슬래시는 마침표를 일반 문자로 처리하고, 괄호는 경로 부분을 캡처하며, 대상에 있는 $1은 첫 번째 캡처 그룹을 참조합니다.

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

이 줄은 URL 시작 부분에서 http://example.com/을 매칭하고 이후 내용을 대상 주소에 포함합니다. 302는 임시 리디렉션을 뜻합니다. 이 규칙으로 대상 서버가 HTTPS를 자동 지원하게 되거나 인증서 오류가 해결되는 것은 아닙니다. 대상 주소에 접속할 수 없다면 요청을 다른 실패 지점으로 보내는 결과만 생깁니다. 먼저 대상 URL에 직접 접속할 수 있는지 확인한 뒤 원래 URL이 해당 주소로 이동하는지 테스트하세요.

정규식의 매칭 범위를 제한하세요

정규식에서 마침표는 기본적으로 다른 문자와도 매칭될 수 있으므로 이스케이프하지 않으면 범위가 넓어질 수 있습니다. 시작 앵커를 사용하면 문자열의 임의 위치에서 잘못 매칭되는 일을 줄일 수 있습니다. 짧은 키워드 하나만 조건으로 쓰면 어떤 URL을 처리하려는지 명확하지 않은 경우가 많습니다. 전체 프로토콜, 정확한 호스트 이름, 필요한 경로를 기준으로 시작하고 결과를 확인한 뒤 범위를 넓히세요. 처음부터 넓은 조건을 작성한 뒤 오매칭을 하나씩 제외하지 마세요.

URL에는 쿼리 매개변수, 인코딩된 문자, 다양한 경로 형식이 포함될 수 있습니다. 예시의 캡처 그룹은 슬래시 뒤의 내용을 유지하지만, 복잡한 주소를 모두 단순히 이어 붙일 수 있다는 뜻은 아닙니다. 로그인 콜백, 서명된 요청, 매개변수 순서에 민감한 API는 일부만 바꿔도 검증에 실패할 수 있습니다. 이런 대상은 먼저 프로토콜 요구 사항을 확인하고, 일반 페이지를 여는 정규식을 인증 흐름에 그대로 사용하지 마세요.

리디렉션 반복과 요청 의미 변경 방지

새 규칙을 추가한 뒤 대상 주소가 같은 규칙에 다시 매칭되거나 다른 규칙에 의해 원래 주소로 되돌아가는지 확인하세요. 페이지가 반복해서 이동하거나 주소가 계속 바뀌고 요청 수가 늘어난다면 새 규칙을 비활성화하고 기록을 보존하세요. 여러 주소를 양방향으로 바꾸면 반복이 쉽게 발생할 수 있습니다. 관리할 때는 원래 조건, 대상 주소, 최종 도착 지점을 명확히 기록하세요. 한 줄만 보고 규칙이 올바른지 판단하지 마세요.

리디렉션은 요청 방식, 본문, 인증 헤더 처리에도 영향을 줄 수 있으며 실제 동작은 설정된 액션과 요청을 보내는 앱에 따라 달라집니다. 브라우저에서 GET 요청이 한 번 성공했다고 API의 POST 요청도 같은 방식으로 작동한다고 볼 수는 없습니다. 양식 제출, 결제, 인증 요청은 서비스 프로토콜을 정확히 이해하지 못했다면 그대로 유지하고 일반 규칙으로 일괄 변경하지 마세요.

HTTPS에서 확인할 수 있는 정보와 인증서의 범위

일반적인 암호화 연결에서는 전체 URL 경로가 보통 라우팅 규칙에 그대로 노출되지 않습니다. HTTPS 내용을 확인하는 기능에는 별도의 복호화 및 신뢰 조건이 필요합니다. URL Rewrite를 작성했다고 이런 조건이 자동으로 충족되는 것은 아닙니다. 이 페이지의 예시는 암호화되지 않은 HTTP 주소에서 시작하며 규칙 검증을 위해 신뢰 인증서를 추가할 필요가 없습니다. 도메인 기준으로 트래픽을 분기하려는 경우 Rule을 사용하면 됩니다.

인증서 신뢰 설정을 모든 Rewrite 실패의 해결책으로 사용하지 마세요. 테스트 요청을 실제로 확인할 수 있는지, 표현식이 매칭되는지, 동작을 지원하는지, 대상에 접속할 수 있는지 먼저 점검한 뒤 현재 요구에 적합한 기능인지 판단하세요. 앱에 따라 인증서를 직접 검증하거나 접속 경로를 고정할 수도 있습니다. 실패한다면 검증 조건을 계속 낮추기보다 Rewrite 범위를 넓히는 작업을 중단하세요.

검증을 마치면 필요한 규칙만 남기고 각 규칙의 사용 목적과 테스트 주소를 기록하세요. 웹사이트가 자체적으로 리디렉션을 처리한다면 로컬 Rewrite를 중복 추가해도 관리 단계만 늘어납니다. 규칙을 삭제한 뒤에도 접속 결과가 같다면 서버나 브라우저 캐시에서 이동을 처리했는지 확인하세요. 기능을 어느 쪽에서 담당하는지 파악한 뒤 규칙을 유지할지 결정하면 이후 설정을 옮길 때 숨은 의존성을 줄일 수 있습니다.

08 · 설정 검증, On Demand 및 관리 절차

검증 전에 확인 가능한 목표를 한 문장으로 작성하세요. 예를 들어 ‘api.example.com의 새 요청은 DOMAIN에 매칭되어 DIRECT로 연결되어야 한다’와 같이 정합니다. 그런 다음 현재 네트워크, Global Routing 모드, 선택된 설정, 서버를 기록하고 한 번 접속해 보세요. 스위치 색상이 바뀌는 것이 아니라 요청이 예상대로 매칭되고 대상 서비스가 정상적인 결과를 반환하는지가 성공 기준입니다. 라우팅은 올바르게 선택되었지만 서버 연결이 실패한 경우와 규칙이 매칭되지 않은 경우는 서로 다른 방식으로 확인해야 합니다.

실패 단계에 따라 확인하고 변경 사항을 연달아 쌓지 마세요

첫째, 시스템 네트워크가 정상인지 확인합니다. 둘째, 연결 스위치와 VPN 구성 권한을 확인합니다. 셋째, 서버를 점검합니다. 넷째, 규칙을 확인합니다. VPN 구성 추가 권한을 거부했거나 관련 구성을 삭제했다면 Rule을 먼저 수정할 필요 없이 최초 연결 절차로 돌아가 다시 설정하세요. 시스템 안내에 대한 자세한 내용은 VPN 구성 추가 및 시스템 권한 안내에서 확인할 수 있습니다.

Connectivity Test는 서버 응답을 확인하는 데 도움을 줄 수 있지만 실제 서비스 요청을 대신하지는 않습니다. 테스트에 실패하면 주소, 포트, 프로토콜, 현재 네트워크를 확인하세요. 응답은 있지만 웹페이지가 열리지 않는다면 DNS, TLS, 규칙, 대상 주소를 살펴보세요. 테스트 방식마다 확인하는 단계가 다를 수 있으므로 한 번 표시된 결과를 전체 연결 경로가 정상이라는 보장으로 해석하지 마세요. 연결 시간 초과 문제 해결 순서를 참고해 이어서 확인할 수 있습니다.

On Demand는 연결 트리거를 제어하며 규칙의 의미를 바꾸지 않습니다

Settings에서 On Demand의 실제 조건을 확인하고 ‘언제 연결할지’와 ‘연결 후 트래픽을 어떻게 분기할지’를 구분하세요. On Demand는 설정된 조건에 따라 연결을 시작하는 기능이며 잘못된 비밀번호를 고치거나 Rule 순서를 바꾸지 않습니다. 규칙을 디버깅할 때는 먼저 수동 연결로 안정적인 기준을 만든 뒤 분기가 정상 작동하는지 확인하세요. 그다음 필요한 On Demand 조건을 활성화하면 자동 재연결이 테스트 결과에 미치는 영향을 줄일 수 있습니다.

수동으로 연결을 끊은 뒤 다시 연결된다면 설정 파일이 저장되지 않았다고 바로 판단하지 말고 On Demand와 시스템 트리거 조건부터 확인하세요. 백그라운드 배터리 사용량을 살펴볼 때는 비슷한 네트워크, 사용 시간, 서버 조건에서 비교해야 합니다. 한 번 배터리가 줄어든 것만으로 특정 설정에 문제가 있다고 결론 내릴 수 없습니다. 상시 연결과 On Demand 사용의 장단점은 On Demand 및 백그라운드 배터리 사용 안내에서 확인할 수 있습니다.

되돌릴 수 있는 검증 기록을 남기세요

변경할 때마다 원래 규칙, 수정한 규칙, 테스트 대상, 실제 매칭 결과를 기록하세요. 결과가 예상과 다르면 이번 변경을 즉시 되돌린 뒤 다음 단계를 정합니다. 실패한 상태에서 예외를 계속 추가하면 나중에 연결이 복구되더라도 어느 줄이 영향을 줬는지 파악하기 어렵습니다. 서로 겹치는 조건을 많이 남기기보다 목적이 분명한 규칙 몇 개로 요구 사항을 하나씩 확인하세요.

문제 해결 기록을 공유할 때는 구독 링크, 비밀번호, 식별 정보, 키, 공개하면 안 되는 내부 주소를 가리세요. 보통 관련 Rule 내용, 가공한 대상 이름, 매칭된 정책, 오류가 발생한 단계만 있으면 충분합니다. 설정 파일 전체를 공유할 필요는 없습니다. 스크린샷에 인증 정보가 노출되지 않았는지도 확인하세요. 파일을 업로드하거나 전체 구독 정보를 제공할 필요 없이 문제 설명에 필요한 최소한의 정보만 공유하면 됩니다.

업데이트 후 정기 확인

App Store에서 앱을 업데이트한 뒤 현재 설정이 선택되어 있는지 확인하고 자주 사용하는 핵심 규칙을 점검하세요. 구독을 업데이트했다면 서버 선택이 여전히 유효한지 확인하고, 원격 설정을 업데이트했다면 로컬 예외가 예상한 위치에 있는지 확인하세요. 기기를 바꾸거나 앱을 다시 설치할 때는 앱 복원과 설정 복원을 각각 진행해야 합니다. 구입 기록만으로 모든 사용자 지정 데이터가 자동 복원되는 것은 아닙니다. 자세한 절차는 구입 항목 복원 안내에서 확인하세요.

계속 확인하려면 이 페이지의 목차에서 해당 설정 섹션으로 이동하세요. 서버 추가부터 전체 절차를 다시 진행하려면 Shadowrocket 사용 가이드를 참고하세요. 구입, 가져오기 실패, 시스템 권한 관련 문제는 FAQ에서 항목별로 확인할 수 있습니다. 각 규칙의 범위를 명확히 하고, 모든 변경을 되돌릴 수 있게 하며, 각 판단을 재현 가능한 새 요청으로 검증하는 것이 중요합니다. 설정 파일을 계속 길게 만드는 것이 목표는 아닙니다.