Shadowrocket 규칙 설정 가이드

01 설정 파일 구조와 수정 범위

Shadowrocket에서 서버 정보, 구독 항목, 설정 파일은 서로 다른 역할을 합니다. 서버 정보에는 연결할 엔드포인트와 프로토콜 매개변수가 들어갑니다. 구독은 사용자가 이미 보유한 연결 정보를 가져오고 갱신하는 데 쓰이며, 설정 파일은 일반 설정, 매칭 조건과 처리 정책을 구성합니다. Home에 서버가 표시된다고 해서 현재 Config에 해당 요청에 맞는 규칙이 포함되어 있다는 뜻은 아닙니다. 반대로 규칙이 완전한 설정 파일도 누락된 서버 주소, 비밀번호나 프로토콜 매개변수를 채워 주지는 않습니다. 문제를 점검할 때는 이 세 가지를 각각 확인해 모든 원인을 규칙 탓으로 돌리지 않도록 하세요.

먼저 섹션 이름을 확인한 다음 각 행을 읽으세요

일반적인 설정은 대괄호로 표시된 섹션 이름에 따라 나뉩니다. [General]에는 일반 동작 설정, [Rule]에는 순서대로 처리되는 규칙, [Host]에는 정적 도메인 매핑, [URL Rewrite]에는 URL 매칭 및 재작성 항목이 들어갑니다. 섹션 이름에 따라 다음 행을 해석하는 방식이 달라집니다. 같은 행도 잘못된 섹션에 있으면 예상대로 처리되지 않을 수 있습니다. 읽을 때는 가장 가까운 섹션 이름을 먼저 찾고 키·값이나 규칙 필드를 확인하세요. 한 행에 도메인이 있다는 이유만으로 트래픽 분기 규칙이라고 판단하지 마세요.

[General]
bypass-system = true
dns-server = system
ipv6 = false

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

[Host]
localhost = 127.0.0.1

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

이 조각은 섹션 간 관계를 보여 주는 예시일 뿐입니다. 일반 설정에서 시스템 DNS를 사용하고, 규칙에 따라 예시 도메인에는 PROXY를 선택하며, 일부 주소는 GEOIP로 판단하고, 나머지 요청은 FINAL로 처리한다는 뜻입니다. Host와 URL Rewrite는 각각 다른 유형의 작업을 처리합니다. 이 예시를 모든 사용자에게 권장되는 조합으로 받아들여서는 안 됩니다. 특히 DNS, IPv6, 최종 정책은 사용 중인 네트워크와 기존 연결 서비스를 고려해 확인해야 합니다. 수정할 때는 기존 필수 항목을 유지하고, 예시에 맞추려고 이해하지 못한 설정을 삭제하지 마세요.

Config에서 실제로 사용하는 파일 확인하기

Config를 열면 먼저 파일이 목록에 있는 것과 현재 사용 중인 것을 구분하세요. 가져오기에 성공해도 파일 목록에 추가되었을 뿐, 현재 연결에 그 파일이 선택되었다는 뜻은 아닙니다. 현재 선택된 상태를 확인한 뒤 해당 파일의 내용을 살펴보세요. 시험 삼아 수정할 때는 앱에서 제공하는 복사 또는 내보내기 기능으로 먼저 사본을 저장하고, 용도를 구분할 수 있는 이름을 붙이세요. 사본을 저장한 뒤에는 현재 사용 중인 항목을 다시 확인하세요. 시험 파일을 편집했는데 실제 연결은 이전 설정을 사용하고 있어 저장이 적용되지 않았다고 오해할 수 있습니다.

파일의 출처에 따라 수정 내용을 유지할 수 있는지도 달라집니다. 원격 주소에서 설정을 갱신하는 경우 다음 업데이트 때 로컬 수정 사항이 덮어써지는지 먼저 확인하세요. 사용자 구독의 서버 업데이트와 설정 파일 업데이트는 서로 다릅니다. 서버 목록을 갱신해도 Rule이 바뀌지 않을 수 있고, 원격 설정을 다시 가져와도 구독이 갱신되는 것은 아닙니다. 오래 유지할 사용자 지정 규칙은 추가한 항목, 삽입 위치와 수정 목적을 기록하세요. 원격 내용이 바뀌면 파일명이 같다는 이유만으로 내용도 그대로라고 여기지 말고, 변경 사항을 비교해 다시 병합하세요.

수정은 한 번에 한 계층으로 제한하세요

먼저 ‘연결 정보가 올바른지, 설정 파일이 선택되었는지, 규칙 순서가 올바른지’를 차례로 확인해 기준 상태를 만드세요. 첫 조정에서는 도메인 규칙 하나만 바꾸고 General, Host, 재작성 섹션은 그대로 둔 다음 새로운 요청을 만들어 테스트하세요. 서버 교체, DNS 변경, 최종 정책 수정과 재작성 기능을 한꺼번에 적용하면 접속이 복구되어도 어떤 변경이 효과가 있었는지 알 수 없습니다. 실패해도 되돌릴 기준이 불분명해집니다. 수정 목적을 ‘예시 도메인과 그 하위 도메인에 PROXY 적용’처럼 구체적으로 적으면 ‘모든 규칙 최적화’보다 검증하기 쉽습니다.

파일을 복원할 때도 계층별로 처리하세요. 원래 설정으로 되돌린 뒤 현재 라우팅 모드와 선택된 서버를 다시 확인하세요. 필요한 경우 연결을 끊었다가 다시 연결한 다음 새 요청을 보내세요. 기존 연결, 캐시된 페이지와 백그라운드 재시도는 수정 전 동작을 계속 보일 수 있으므로 설정이 복원되었는지 판단하는 유일한 근거로 삼지 마세요. 처음 가져오기를 끝내지 않았다면 기본 사용 흐름으로 돌아가 연결을 먼저 확인한 뒤 이 페이지의 다음 섹션을 읽으세요. 연결 엔드포인트를 사용할 수 없는데 규칙을 반복해서 수정하는 일을 피할 수 있습니다.

02 General, DNS 및 주소 확인

[General]은 여러 일반 동작을 설정하지만 ‘속도 설정 모음’은 아닙니다. DNS, IPv6, 시스템 우회 등의 설정은 요청이 규칙 판정에 들어가기 전후에 어떤 정보를 사용할 수 있는지에 영향을 주며 네트워크 호환성도 바꿀 수 있습니다. 기존 설정을 살펴볼 때는 각 키를 앱 내 관련 설명과 함께 확인하세요. 다른 사용자의 설정값을 고정된 기준으로 여기지 마세요. 특히 Wi-Fi와 Cellular를 전환하면 네트워크가 제공하는 DNS 확인자, 주소 계열과 접근 가능한 경로가 달라질 수 있습니다. 같은 설정에서 동작이 달라져도 반드시 규칙 문법이 잘못된 것은 아닙니다.

DNS는 주소를 확인하며 최종 정책과는 다릅니다

도메인에 접속하려면 보통 해당 도메인의 주소를 확인해야 합니다. DNS는 도메인에 어떤 주소가 연결되는지 알려 주고, Rule은 매칭된 요청에 어떤 정책을 적용할지 결정합니다. 서로 관련은 있지만 대체할 수는 없습니다. 도메인 확인에 성공해도 PROXY 연결이 실패할 수 있고, IP 규칙이 예상과 다르게 동작하는 원인이 실제 확인된 주소와 예상 주소의 차이일 수도 있습니다. 문제를 점검할 때는 먼저 접속한 도메인을 기록하고, 주소 확인 성공 여부와 반환된 주소, 요청이 최종적으로 매칭된 규칙을 살펴보세요. ‘열리지 않는다’는 이유만으로 곧바로 DNS 문제라고 단정하지 마세요.

[General]
dns-server = system
ipv6 = false

dns-server = system은 이 설정에서 시스템 DNS를 사용한다는 뜻이지, 특정 공용 DNS 주소를 직접 지정한다는 뜻은 아닙니다. 기존 네트워크 동작을 이해하기 위한 출발점으로 쓸 수 있지만 모든 네트워크에 적합하다고 보장하지는 않습니다. 네트워크에 내부 도메인이 있다면 DNS 확인자를 임의로 바꿨을 때 내부 이름의 올바른 응답을 받지 못할 수 있습니다. 시스템 DNS 자체에 문제가 있다면 현재 네트워크부터 확인해야 합니다. DNS를 변경하기 전에 기존 값을 보관하고, 변경 후에는 새 주소 확인과 연결 결과를 검증하세요. 브라우저에 캐시된 페이지 하나만 새로고침해서는 충분하지 않습니다.

IPv6 설정은 연결 가능성을 고려해 판단하세요

ipv6 = false는 이 예시에서 관련 IPv6 동작을 끕니다. 일반적으로 권장되는 성능 설정은 아닙니다. IPv6를 지원하는 네트워크와 서비스는 IPv4와 연결 조건이 다를 수 있습니다. 끈 뒤 동작이 달라졌더라도 주소 계열이나 경로를 더 살펴봐야 한다는 뜻일 뿐, 특정 주소 계열이 항상 더 빠르다는 근거는 아닙니다. IPv6를 사용해야 한다면 대상에 IPv6 주소가 있는지, 사용 중인 서버와 프로토콜이 이를 예상대로 처리하는지, Rule에 해당하는 IP-CIDR6 항목이 있는지 함께 확인하세요.

주소 규칙을 이용해 문제를 점검할 때는 이번 요청에서 실제로 사용된 주소를 확인해야 합니다. IPv4 대역만 살펴봤는데 요청이 IPv6를 선택했다면 기존 결론에는 근거가 부족합니다. 한 번의 테스트에서 얻은 주소를 장기간 사용할 Host 매핑으로 고정하지도 마세요. 같은 도메인도 네트워크, 지역 또는 서비스의 트래픽 분배에 따라 서로 다른 주소를 반환할 수 있습니다. 정적으로 고정하면 정상적인 가용성 조정이 방해될 수 있습니다. 먼저 도메인 규칙으로 경로를 선택하고, 정적 매핑이 꼭 필요한 경우에만 Host의 유지 관리 비용과 적용 범위를 따져보세요.

시스템 우회와 규칙 로그의 범위를 이해하세요

bypass-system = true는 시스템 트래픽 우회와 관련되므로 구체적인 적용 범위는 앱의 현재 설명을 확인해야 합니다. 모든 서비스 요청이 동일한 Rule을 하나씩 거친다는 뜻도 아니고, 이 설정을 켜면 모든 앱이 같은 방식으로 동작한다는 보장도 없습니다. 예상한 로그가 표시되지 않으면 규칙뿐 아니라 기존 연결 재사용 여부, 시스템 구성 요소가 요청을 시작했는지, 다른 우회 설정이 적용되었는지도 살펴보세요. Rule의 매칭 순서를 논하기 전에 테스트 요청이 현재 연결 처리 경로에 실제로 들어왔는지 확인하세요.

재현 가능한 테스트는 다음과 같이 진행할 수 있습니다. 먼저 시스템 DNS를 기준으로 유지하고, 도메인 하나를 선택해 주소 확인과 접속 결과를 기록하세요. DNS 관련 설정 하나만 변경한 뒤 다시 연결하고 새 요청을 만드세요. 마지막으로 주소, 매칭된 규칙과 오류가 발생한 단계를 비교하세요. DNS를 바꾼 뒤 특정 네트워크에서만 복구된다면 새 설정을 모든 기기에 바로 적용하지 말고 해당 네트워크에서 제공하는 DNS 서비스를 더 살펴보세요. 설정의 목표는 동작을 설명할 수 있게 하는 것입니다. 한 번 페이지가 열렸다는 사실만으로 모든 요청이 예상대로 처리된다고 입증할 수는 없습니다.

집의 Wi-Fi에서는 같은 설정이 정상인데 Cellular로 바꾸면 문제가 생긴다면 테스트 조건을 나누어 기록하세요. On Demand 조건에 따라 연결 상태가 달라졌는지 확인한 뒤 Global Routing, 현재 서버와 주소 확인 결과를 점검하세요. 관련 트리거 조건은 On Demand 자동 연결 안내에서 확인할 수 있습니다. 네트워크 변경과 주소 확인 변화를 따로 살펴보면 여러 DNS 값을 연달아 바꾸는 것보다 안정적이고 재검증하기 쉬운 원인을 찾을 수 있습니다.

03 DOMAIN 계열 규칙과 도메인 범위

도메인 규칙은 ‘특정 이름 또는 이름 그룹에 어떤 정책을 적용할지’를 지정할 때 적합합니다. 한 번 확인한 주소를 고정 IP로 적는 것보다 서비스 이름을 직접 기준으로 삼으므로 일반적으로 관리하기 쉽습니다. 자주 쓰이는 유형은 DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD입니다. 이 세 유형은 우선순위가 아니라 매칭 범위가 다릅니다. Shadowrocket은 목록 순서대로 확인하므로 범위가 구체적인 규칙도 넓은 규칙 뒤에 놓이면 실행되지 않을 수 있습니다. 유형을 고를 때는 먼저 대상 범위를 설명한 다음 키워드를 정하세요. 규칙을 복사한 뒤 어떤 요청까지 포함하는지 추측하지 마세요.

DOMAIN: 정확한 도메인 이름만 매칭

DOMAIN,api.example.com,PROXY는 지정한 도메인 이름 전체를 매칭합니다. API 하위 도메인을 같은 사이트의 다른 하위 도메인과 구분할 때 적합합니다. 여기에는 URL을 넣는 것이 아닙니다. https://, 경로, 쿼리 매개변수와 포트는 포함하지 않습니다. 특정 페이지 경로를 처리하려는 경우 DOMAIN만으로는 표현할 수 없습니다. 같은 도메인 아래의 서로 다른 경로도 동일한 도메인 조건에 속하기 때문입니다. 브라우저 주소창의 전체 주소를 도메인 필드에 붙여 넣는 것은 매칭이 실패하는 흔한 원인입니다.

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

이 예시는 두 개의 정확한 도메인을 각각 처리하고, 다른 하위 도메인은 뒤에 오는 규칙에 맡깁니다. 확인할 때는 요청에 실제로 사용된 이름이 입력한 이름과 일치하는지 살펴보세요. 페이지는 기본 도메인에 먼저 접속한 뒤 로그인 도메인으로 이동하고, 다른 정적 리소스 도메인에서 콘텐츠를 불러올 수 있습니다. 기본 페이지가 열렸다고 모든 리소스가 같은 정책을 사용했다고 볼 수는 없습니다. 요청 기록에서 문제가 발생한 도메인을 확인한 뒤 정확한 규칙을 추가할지 매칭 범위를 넓힐지 결정하세요. 리소스 로딩에 실패할 때마다 사이트의 모든 도메인에 같은 정책을 적용하지 마세요.

DOMAIN-SUFFIX: 도메인과 하위 도메인 매칭

DOMAIN-SUFFIX,example.com,PROXY는 예시 도메인과 그 하위 도메인을 포함하며, 같은 도메인 트리를 한꺼번에 처리할 때 적합합니다. 도메인 경계를 기준으로 매칭하므로 임의의 문자열 포함으로 이해해서는 안 됩니다. notexample.com처럼 뒤쪽 문자가 비슷한 다른 도메인은 해당 도메인 트리에 속하지 않습니다. 보통 루트 도메인을 그대로 사용하며 앞에 별표를 붙일 필요가 없습니다. 값에 경로를 넣지 마세요. 인터페이스 하나만 직접 연결하려면 정확한 도메인 예외를 먼저 쓰고 그다음 접미사 규칙을 추가할 수 있습니다.

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

위와 같은 순서는 ‘인터페이스 예외를 먼저 적용하고 나머지 예시 도메인에는 PROXY를 사용’한다는 의미를 분명히 합니다. 두 행의 순서를 바꾸면 인터페이스 요청이 먼저 접미사 조건에 매칭되어 뒤에 있는 정확한 예외가 적용되지 않습니다. DOMAIN이 DOMAIN-SUFFIX보다 자동으로 우선하는 특별한 규칙은 없습니다. 결과를 결정하는 것은 위치입니다. 많은 도메인을 관리한다면 같은 서비스의 정확한 예외를 먼저 모은 뒤 범위가 넓은 규칙을 배치하고, 변경 기록에 예외가 필요한 이유를 적어 나중에 정리하면서 실수로 삭제하지 않도록 하세요.

DOMAIN-KEYWORD: 문자열 범위는 신중하게 사용

DOMAIN-KEYWORD,example,PROXY는 도메인에 포함된 키워드로 매칭하며, 일반적으로 접미사 규칙보다 범위가 넓습니다. 대상이 실제로 안정적인 키워드로 정의되는 경우에 적합하지만, 원래 처리할 의도가 없었던 다른 이름까지 매칭할 수 있습니다. 흔히 쓰이는 짧은 문자열일수록 오매칭 위험이 큽니다. 한 번 테스트에 성공했다고 특정 서비스의 모든 도메인과 같은 범위라고 보아서는 안 됩니다. 예측 가능한 범위가 필요하다면 정확한 DOMAIN 또는 DOMAIN-SUFFIX 항목을 우선 사용하세요.

도메인 판단은 클라이언트가 해당 이름을 확인할 수 있는지에도 영향을 받습니다. IP 주소로만 표시되는 연결이 반드시 DOMAIN에 매칭된다고 가정할 수 없습니다. 이미 설정된 장시간 연결에는 규칙 변경이 바로 반영되지 않을 수도 있습니다. 검증할 때는 새 연결을 만들고 기록에 나타난 실제 대상과 매칭 항목을 확인하세요. 필요하다면 테스트를 마친 뒤 관련 앱을 종료하고 새 요청을 시작하세요. ‘특정 도메인이 예외 규칙을 따르지 않는다’면 먼저 앞쪽에 더 넓은 규칙이 있는지, 다음으로 이름 정보가 제공되는지 확인한 뒤 주소 확인과 캐시를 점검하세요.

04 GEOIP, IP-CIDR 및 추가 규칙

도메인 규칙과 달리 IP 규칙은 대상 주소를 기준으로 판단합니다. 알려진 네트워크 대역, 내부 서비스와 주소의 지역 분류가 필요한 경우 적합하지만 특정 웹사이트의 모든 서비스를 자동으로 표현하지는 않습니다. 웹사이트는 여러 주소를 사용할 수 있고, 한 주소를 여러 서비스가 함께 사용할 수도 있습니다. 한 번 확인한 주소를 더 큰 네트워크 대역으로 확대하면 다른 대상까지 규칙에 포함될 수 있습니다. 주소 조건을 작성하기 전에 고정 주소 하나, 관리하는 네트워크 대역 또는 주소 귀속 데이터베이스에 따라 판단되는 집합 중 무엇을 매칭하려는지 확인하세요. 세 가지 요구사항은 각각 다르게 처리해야 합니다.

IP-CIDR과 IP-CIDR6의 범위

IP-CIDR은 IPv4 주소 대역에, IP-CIDR6은 IPv6 주소 대역에 사용합니다. 슬래시 뒤 숫자는 네트워크 프리픽스 길이이며 포트 번호가 아닙니다. IPv4의 /32는 단일 주소, IPv6의 /128은 단일 주소를 의미합니다. 프리픽스 길이가 짧을수록 일반적으로 더 넓은 범위를 포함합니다. 내부 네트워크에서는 실제 대역을 확인해 입력하세요. 주소 앞부분이 비슷하다는 이유만으로 범위를 임의로 넓히면 안 됩니다. 예시의 문서용 예약 주소는 형식을 설명하기 위한 것이며 실제 연결 대상이 아닙니다.

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

no-resolve는 해당 IP 조건을 시도하기 위해 추가로 도메인을 확인하지 않도록 합니다. 모든 DNS를 무시하는 설정은 아니며, 요청 처리 중 주소 확인이 전혀 필요 없다는 뜻도 아닙니다. 요청에 도메인 정보만 있고 판단에 사용할 대상 주소가 아직 없다면 이 옵션이 있는 IP 조건이 반드시 매칭된다고 볼 수 없습니다. 이후에는 적용 가능한 다른 규칙을 계속 확인합니다. 이 옵션의 사용 여부는 규칙의 목적에 따라 결정하세요. 추가 주소 확인을 피하는 것과 주소 확인 결과로 분류하는 것은 서로 다른 선택입니다.

GEOIP는 IP 주소의 지역 귀속을 판단합니다

GEOIP,CN,DIRECT는 사용할 수 있는 주소 귀속 데이터를 기준으로 대상이 지정된 지역 코드에 속하는지 판단합니다. 이는 IP의 지역 귀속을 확인하는 것이지 도메인 접미사, 페이지에 표시되는 언어 또는 사용자의 위치를 확인하는 것이 아닙니다. 서비스의 실제 배포 상황 전체를 반영한다고 보장하지도 않습니다. 같은 도메인도 네트워크에 따라 다른 주소를 반환하면 매칭 결과가 달라질 수 있고, 데이터베이스 분류와 운영 환경 사이에 차이가 있을 수도 있습니다. 특정 도메인에 고정 정책을 적용해야 한다면 GEOIP에 기대어 예외를 처리하지 말고 명시적인 도메인 규칙을 GEOIP 앞에 작성하세요.

[Rule]
DOMAIN,api.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

이 순서는 먼저 인터페이스 정책을 고정하고, 나머지 판단 가능한 대상에 GEOIP를 적용한 뒤 최종 규칙으로 처리합니다. 이번 주소 확인에서 인터페이스 주소가 CN에 해당하더라도 앞에 있는 DOMAIN이 먼저 매칭되므로 PROXY를 사용합니다. 반대로 GEOIP를 앞에 두면 인터페이스가 지역 조건에서 매칭을 끝낼 수 있습니다. 이런 문제를 확인할 때는 실제 주소와 규칙 위치를 모두 살펴보세요. 도메인 하나와 지역 라벨 하나만 보고 클라이언트가 잘못 판단했다고 결론 내릴 수 없습니다.

USER-AGENT의 적용 조건과 한계

USER-AGENT는 확인 가능한 요청 헤더에 의존하며, 모든 앱을 안정적으로 식별하는 수단은 아닙니다. 앱이 요청 헤더를 변경할 수 있고, 같은 앱에서도 요청마다 값이 달라질 수 있습니다. 암호화된 연결의 요청 헤더는 직접 확인할 수 없는 경우도 있습니다. 요청이 특정 앱에서 시작되었다고 해서 매칭 가능한 USER-AGENT가 반드시 포함된다고 가정하지 마세요. 서비스 경로를 안정적으로 선택해야 한다면 앱에 표시된 이름만으로 규칙 조건을 추측하기보다 명확한 도메인이나 IP로 표현할 수 있는지 먼저 확인하세요.

[Rule]
USER-AGENT,ExampleClient*,PROXY
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

예시의 ExampleClient*는 매칭 값의 형식을 설명하기 위한 것입니다. 실제로 확인할 수 있는 정보와 앱에서 지원하는 매칭 방식에 따라 설정하세요. 이 규칙을 매칭하려고 이해하지 못한 트래픽 복호화 설정을 바로 켜지 마세요. 이 페이지에서는 USER-AGENT를 일반적인 트래픽 분기의 전제 조건으로 삼지 않습니다. 기록에서 요청 헤더를 확인할 수 없다면 관찰 가능한 도메인이나 IP 조건으로 바꾸는 편이 검증과 네트워크 간 유지 관리에 더 유리합니다. 설정의 가독성은 조건이 명확한 데서 비롯되며 규칙 유형이 많다고 좋아지는 것은 아닙니다.

주소 규칙을 회귀 테스트할 때는 매칭되어야 하는 대상과 매칭되면 안 되는 대상을 각각 하나 이상 선택하고, 둘 다 새 연결을 만드는지 확인하세요. 내부 네트워크 대역은 서로 다른 Wi-Fi에서도 따로 검증해야 합니다. 같은 주소 대역이 다른 네트워크에서는 전혀 다른 기기를 가리킬 수 있기 때문입니다. 특정 규칙이 아니라 전체 연결이 느린 문제라면 속도 저하 단계별 문제 해결을 참고해 서버 연결 가능성, 로컬 네트워크와 규칙 매칭을 나누어 확인하세요.

05 PROXY, DIRECT, REJECT 및 Global Routing

규칙의 마지막 부분에는 보통 처리 정책이 들어갑니다. PROXY, DIRECT, REJECT는 각각 프록시 연결, 직접 연결, 요청 거부를 의미하지만 Global Routing의 세 가지 모드와 같지는 않습니다. 정책은 규칙이 매칭된 뒤 요청을 어떻게 처리할지 결정하고, 라우팅 모드는 현재 연결의 전체 라우팅 방식을 정합니다. 둘을 혼동하면 ‘DIRECT를 썼는데도 프록시를 사용한다’거나 ‘규칙을 바꿨는데 아무 변화가 없다’고 잘못 판단할 수 있습니다. 테스트 전에는 Global Routing, 현재 Config, 실제로 매칭된 항목 순서로 확인하세요.

Config: 현재 설정에 따른 라우팅

설정 라우팅 모드에 해당하는 인터페이스 용어는 Config이며, Rule을 검증할 때 주로 사용하는 상태입니다. 이 모드에서는 해당 처리 경로에 들어온 요청이 설정 조건에 따라 정책을 선택합니다. 모든 서비스가 사용자의 기대대로 작동한다는 보장은 없으며, 현재 설정과 관련 항목에 따라 처리됩니다. 잘못된 파일을 선택했거나 앞쪽에 범위가 넓은 규칙이 있거나 Host가 주소를 바꿨다면 결과가 달라질 수 있습니다. 규칙을 수정하거나 화면을 캡처해 다른 사람에게 도움을 요청할 때 ‘연결을 켰다’고만 설명하기보다 현재 모드가 Config라고 명시하세요.

Proxy 및 Direct 모드: 비교 테스트

Proxy 모드는 프록시 경로를 확인할 때 주로 사용하고, Direct 모드는 직접 연결의 동작을 살펴볼 때 사용합니다. 비교 조건으로 활용할 수 있지만 시스템 우회, 주소 확인이나 프로토콜 동작을 모두 덮어쓰는 절대적인 스위치는 아닙니다. 테스트할 때는 서버, 네트워크와 대상을 그대로 유지하고 모드만 바꾸세요. Proxy에서는 접속되지만 Config에서는 안 된다면 규칙, 최종 정책과 관련 설정부터 확인하세요. Proxy에서도 접속되지 않는다면 Rule을 바로 다시 작성하기보다 연결 정보와 서버 연결 가능성을 먼저 확인하세요.

PROXY는 연결 서비스를 만들지 않습니다

PROXY는 매칭된 요청을 해당 프록시 경로로 전달할 뿐, 서버 정보를 자동으로 생성하거나 만료된 구독을 복구하지 않습니다. 먼저 Home에서 선택된 서버가 사용자가 이미 보유한 연결 정보에 해당하는지, 주소·포트·인증·프로토콜 매개변수가 일치하는지 확인하세요. 일부 프로토콜에는 전송 방식, TLS 이름 또는 추가 필드가 필요합니다. 이름이 같다는 이유만으로 설정이 완전하다고 판단하지 마세요. 앱을 한 번 구매하는 것과 연결 서비스는 별개이며, 규칙이 올바르더라도 서버가 반드시 사용 가능한 것은 아닙니다.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,local.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

DIRECT는 현재 네트워크에서 대상에 직접 연결한다는 뜻이지, 대상에 반드시 접속할 수 있다는 뜻은 아닙니다. 내부 이름은 특정 Wi-Fi의 DNS에 의존할 수 있고, 일부 서버는 특정 출발지 주소에서만 접속을 허용할 수 있습니다. DIRECT가 실패하면 곧바로 PROXY로 바꾸지 말고 로컬 네트워크와 주소 확인 결과를 점검하세요. 규칙이 올바른지와 대상에 접속할 수 있는지는 별개의 문제입니다. 예상한 DIRECT가 매칭되었는데 대상이 연결을 거부한다면 규칙은 제대로 실행되었지만 연결 환경이 대상의 요구 조건을 충족하지 못했을 수 있습니다.

REJECT는 범위를 명확히 지정하세요

REJECT는 매칭된 요청을 거부하며, 접속할 필요가 없다고 확실히 알고 있는 대상에 적합합니다. 범위가 넓은 키워드나 큰 주소 대역을 처음부터 REJECT에 지정하면 페이지에 필요한 API, 로그인 리디렉션이나 리소스 요청도 함께 차단될 수 있습니다. 페이지 일부가 비거나 계속 로딩되거나 로그인에 실패하면 관련 요청이 거부 규칙에 매칭되었는지 확인하세요. 규칙을 삭제하기 전에 사본에서 범위를 일시적으로 좁히고 같은 동작을 다시 테스트하세요. 원인이 해당 조건임을 확인한 뒤 필요한 최소한의 수정만 유지하세요.

FINAL에도 정책을 지정해야 합니다. 예를 들어 FINAL,PROXY는 앞의 규칙에 매칭되지 않은 요청을 프록시 경로로 보내고, FINAL,DIRECT는 나머지 요청을 직접 연결합니다. 두 설정은 서로 다른 목표이며 모든 사용자에게 통하는 기본값은 없습니다. 최종 정책을 정하기 전에 예외가 필요한 요청, 사용 중인 서비스의 연결 가능성과 규칙을 관리할 방법을 정리하세요. 자주 발생하는 현상은 질문과 답변에서 확인할 수 있습니다. 다만 문제를 기록할 때는 현재 모드와 실제로 매칭된 정책도 남기세요. ‘연결 실패’라고만 적어서는 원인을 파악하기 어렵습니다.

06 매칭 순서, 예외 및 FINAL

규칙 목록의 핵심 원칙은 위에서 아래로 확인하고, 처음 매칭된 적용 가능 항목이 정책을 결정한다는 것입니다. 모든 조건을 모은 다음 ‘가장 정확한’ 규칙을 자동으로 고르는 방식이 아닙니다. 일반적인 순서 기반 규칙에서는 뒤에 있는 정확한 조건이 앞의 넓은 조건을 자동으로 덮어쓰지 않습니다. 따라서 설정 파일은 어떤 규칙이 있는지뿐 아니라 어디에 배치되어 있는지도 확인해야 합니다. 규칙이 적용되지 않을 때는 해당 행만 검색하기보다 목록의 처음부터 확인하세요. 요청을 막고 있는 것이 이미 위쪽에 있는 다른 항목일 수 있습니다.

명확한 예외를 범위 조건보다 먼저 배치하세요

관리하기 쉬운 구성 방법 중 하나는 구체적인 서비스 예외, 도메인 트리 또는 관리하는 주소 대역 규칙, 일반 분류, 마지막으로 FINAL 순서로 작성하는 것입니다. 유일하게 올바른 구조라는 뜻은 아니지만 ‘왜 이 대상은 대부분의 대상과 다르게 처리되는지’를 쉽게 파악할 수 있습니다. 예를 들어 API에는 PROXY를 적용하고 같은 도메인 트리의 나머지 요청에는 DIRECT를 적용하려면 DOMAIN을 DOMAIN-SUFFIX 앞에 두세요. 나중에 키워드 규칙을 추가할 때는 기존 예외 범위를 넘어서는지 다시 확인하세요.

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

api.example.com으로 새 요청을 보내면 첫 번째 행이 조건을 만족하므로 뒤의 접미사 조건으로 결과를 설명할 필요가 없습니다. static.example.com 요청은 첫 번째 행에 매칭되지 않으므로 두 번째 행에서 정책이 결정됩니다. 도메인 규칙에 매칭되지 않은 대상에 대해서는 그다음 주소 조건과 GEOIP를 확인할 수 있습니다. 이 순서는 수동 점검에도 사용할 수 있습니다. 대상별로 각 행의 매칭 여부를 기록하고 처음 매칭된 위치를 찾으면 설정이 수정 목적에 맞는지 판단할 수 있습니다.

FINAL은 기본 처리이며 규칙을 수정하는 수단이 아닙니다

FINAL은 보통 Rule의 마지막에 두어 앞의 조건에서 처리되지 않은 요청에 명확한 결과를 제공합니다. 앞쪽에 배치하면 뒤의 일반 규칙이 실행되지 않고, 뒤쪽에 예외가 남아 있어도 유효하지 않은 것처럼 보일 수 있습니다. FINAL이 반복해서 나타난다면 설정을 병합할 때 구조를 정리하지 않았을 가능성이 큽니다. 사본에서 목적에 맞는 최종 기본 처리 하나만 남기고 앞선 항목을 확인하세요. FINAL을 두 번째로 추가해 첫 번째 FINAL을 ‘덮어쓸’ 수는 없습니다. 통계나 테스트용 표시로 사용하지도 마세요.

두 설정 파일을 병합할 때 각각의 완전한 Rule 섹션을 그대로 이어 붙이는 것으로 끝낼 수는 없습니다. 각 파일의 정확한 예외를 추려내고 같은 조건에 서로 다른 정책이 지정되었는지 확인한 뒤 범위가 넓은 항목의 순서를 정하세요. 마지막에는 하나의 명확한 기본 처리로 합쳐야 합니다. 중복 조건은 문법상 올바르더라도 실제로 적용되는 행을 유지 관리자가 잘못 이해하게 만들 수 있습니다. 정리할 때는 텍스트가 같은지만 비교하지 말고 적용 범위도 이해해야 합니다. 접미사 규칙 하나가 서로 완전히 같지는 않은 여러 정확한 도메인 규칙을 포함할 수 있습니다.

충돌 사례로 동작을 검증하세요

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

이 예시에서는 API 요청이 첫 번째 행에 먼저 매칭되므로 두 번째 행이 결과를 결정할 기회가 없습니다. 수정 방법은 두 행의 순서를 바꾸는 것이지 프록시 서버를 교체하거나 동일한 DOMAIN을 마지막에 한 줄 더 복사하는 것이 아닙니다. 반대로 첫 번째 DIRECT가 모든 하위 도메인에 적용되도록 의도한 것이라면 실제로 효과가 없는 뒤쪽 예외를 삭제해 파일이 의도를 반영하게 하세요. 규칙은 적을수록 항상 좋은 것은 아니지만 남겨 두는 각 규칙에는 설명 가능한 범위와 테스트 근거가 있어야 합니다.

규칙을 바꾼 뒤에는 연결 재사용으로 관찰이 늦어질 수 있다는 점을 고려하세요. 이미 만들어진 연결은 이전 경로를 계속 사용할 수 있고, 웹페이지를 새로고침해도 예상한 새 연결이 만들어지지 않을 수 있습니다. 설정을 저장하고 선택된 상태를 확인한 뒤 연결을 다시 만들고 새 테스트를 진행하세요. 비교 테스트에서는 같은 네트워크, 같은 서버와 같은 대상을 사용해 네트워크 전환으로 인한 주소 변화가 규칙 순서의 변화로 오해되지 않게 하세요. 동적으로 주소가 할당되는 도메인은 매번 실제로 확인된 주소도 기록해야 합니다.

마지막으로 반대 방향도 확인하세요. 대상 예외가 적용되는지만 볼 것이 아니라 새 규칙이 인접한 서비스에 영향을 주지 않는지도 확인해야 합니다. 정확한 도메인을 키워드 규칙으로 바꿨다면 같은 문자열이 들어간 관련 없는 도메인도 하나 이상 점검하세요. GEOIP를 위로 옮겼다면 이전에 PROXY를 적용해야 했던 API가 여전히 예외에 먼저 매칭되는지 확인하세요. 규칙 관리는 끝에 항목을 계속 추가하는 일이 아니라 조건 간 경계를 관리하는 일입니다. 정리할 때마다 되돌릴 수 있는 사본을 보관하고 고정 테스트를 다시 실행하세요.

07 Host와 URL Rewrite의 역할과 범위

Host와 URL Rewrite는 설정에 함께 자주 등장하지만 Rule과는 서로 다른 문제를 해결합니다. Host는 정적 매핑으로 이름 확인 결과에 영향을 주고, URL Rewrite는 URL 조건에 따라 재작성하거나 리디렉션합니다. Rule은 처리 정책을 선택합니다. 도메인이 PROXY에 매칭되었다고 해서 주소 확인이나 재작성까지 올바르다는 뜻은 아닙니다. Host를 추가해도 요청이 자동으로 직접 연결되지는 않습니다. 문제를 점검할 때는 기능을 구분해 비활성화하거나 되돌려 보면서 ‘대상이 어떻게 바뀌었는지’와 ‘어떤 경로로 연결되었는지’를 따로 관찰하세요.

Host로 이름과 주소를 고정하는 방법

[Host]
localhost = 127.0.0.1
test.example.com = 192.0.2.10

첫 번째 행은 흔히 쓰이는 로컬 이름 매핑 예시이고, 두 번째 행은 문법을 설명하기 위한 문서용 예약 주소입니다. 실제 서비스 주소가 아닙니다. 실제로 매핑을 고정하려면 대상 주소를 명확히 알고 그에 맞는 테스트 목적이 있어야 합니다. 웹사이트의 정상 주소 확인에는 여러 주소와 장애 전환 로직이 포함될 수 있지만 Host는 로컬에서 확인되는 결과를 지정한 주소로 고정합니다. 서비스 주소가 바뀌면 이전에 작동하던 매핑이 문제의 원인이 될 수도 있습니다. 사용자 지정 매핑마다 용도를 기록하고 임시 테스트가 끝난 뒤 삭제할지 검토하세요.

정적 매핑은 일반적으로 요청에서 사용하는 도메인 자체를 바꾸지 않으며 TLS의 이름 검증을 대신하지도 않습니다. HTTPS 도메인을 다른 서버로 지정해도 해당 서버는 원래 도메인을 올바르게 처리하고 그 이름에 맞는 인증서를 제공해야 합니다. 주소에 연결할 수 있다는 이유만으로 접속이 성공한다고 생각하는 것은 흔한 오해입니다. 인증서 이름이 일치하지 않으면 정상적인 주소 확인으로 복원하거나 서버 설정을 확인하세요. 인증서 오류를 DOMAIN-SUFFIX 정책 탓으로 돌리거나 검증을 꺼서 잘못된 매핑을 감추지 마세요.

URL Rewrite는 URL 조건을 매칭합니다

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

이 예시는 매칭된 HTTP 주소를 예시 HTTPS 주소로 리디렉션합니다. 정규식의 ^는 시작 위치, \.는 도메인 안의 마침표 문자 그대로를 의미하며, 끝의 슬래시는 매칭 범위를 좁히는 역할을 합니다. 마침표를 이스케이프하지 않으면 정규식에서 임의의 문자 하나를 뜻할 수 있습니다. 도메인 뒤에 적절한 경계가 없으면 의도하지 않은 주소까지 매칭될 수 있습니다. 여기의 대상 주소는 고정값이므로 경로와 쿼리 매개변수가 모두 자동으로 유지된다고 가정하지 마세요.

302는 리디렉션 응답을 나타냅니다. 리디렉션은 클라이언트가 새 URL에 접속하도록 하는 응답이지 원래 요청 안에서 모든 연결 동작을 조용히 바꾸는 방식이 아닙니다. 새 요청에서도 주소 확인과 경로 선택, 연결이 필요합니다. 대상에 접속할 수 없다면 재작성 자체가 성공해도 페이지가 정상적으로 열리지 않습니다. 테스트할 때는 원래 주소가 표현식에 매칭되는지, 응답이 예상한 대상을 가리키는지, 후속 요청이 정상 처리되는지 각각 확인하세요. 브라우저 주소가 바뀌었다는 사실만으로 후속 리소스 요청도 모두 올바르다고 볼 수는 없습니다.

확인 가능한 범위를 먼저 살펴본 뒤 재작성을 사용하세요

HTTP와 HTTPS에서 볼 수 있는 정보는 서로 다릅니다. 설정에 규칙을 하나 적었다고 모든 암호화 요청의 전체 URL을 바로 읽을 수 있는 것은 아닙니다. 추가 조건이 있어야 관찰할 수 있는 내용을 처리하려면 먼저 앱의 관련 설명을 읽고 인증서와 신뢰 설정에 미치는 영향을 살펴보세요. 이 페이지에서 설명하는 일반적인 규칙 기반 트래픽 분기는 트래픽 복호화를 켤 필요가 없으며, 이를 접속 문제의 기본 해결 절차로 권장하지 않습니다. 특정 도메인에 PROXY를 적용하려는 목적이라면 Rule을 사용하세요. 경로 매칭을 위해 추가 처리 계층을 도입할 필요는 없습니다.

유지 관리하기 쉬운 재작성 규칙에는 원본 범위, 대상 주소와 예상 응답이 명시되어야 합니다. 캡처 그룹이 포함된 복잡한 정규식을 복사했다면 대체 문자열에서 캡처 내용을 어떻게 참조하는지 먼저 확인하세요. 가장 단순한 경로와 쿼리 매개변수가 있는 경로를 각각 테스트하세요. 문법이 비슷해 보인다고 표현식의 의미도 같다고 가정하면 안 됩니다. 임시 진단용 규칙은 장기적으로 사용할 규칙과 따로 기록하고 테스트가 끝나면 정리하세요. 나중에 다른 경로에 접속할 때 의도치 않은 동작이 발생하는 일을 막을 수 있습니다. 복잡할수록 정확한 것은 아니며 요구사항을 충족하는 가장 단순한 표현식이 검토하기 쉽습니다.

Host와 URL Rewrite를 함께 점검할 때는 정상적인 DNS와 최소한의 Rule을 유지한 상태에서 대상에 원래 접속할 수 있는지 확인한 뒤 Host 또는 URL Rewrite를 추가하세요. Host를 추가한 뒤에만 실패하면 주소와 인증서를 확인하세요. 재작성을 추가한 뒤에만 실패하면 매칭 경계, 대상과 반복 여부를 확인하세요. 둘 다 되돌린 뒤에도 실패한다면 서버와 네트워크 계층으로 돌아가세요. 이런 순서라면 잘못된 매핑이나 리디렉션을 더 많은 규칙으로 보완하는 일을 피하고, 최종적으로 남긴 각 설정이 해결하는 문제가 무엇인지 명확히 알 수 있습니다.

08 설정 검증, 문제 해결 및 복원

편집을 마친 뒤에는 ‘웹페이지가 열리는지’만으로 결론을 내리지 말고 명확한 목표를 중심으로 검증하세요. 어떤 도메인을 어떤 네트워크에서 어떤 서버로 연결할지, 어떤 규칙에 매칭되어 PROXY, DIRECT 또는 REJECT 중 무엇이 적용되어야 하는지 먼저 설명하세요. 그런 다음 현재 Config와 Global Routing을 확인하고 새 요청을 보내 결과를 살펴보세요. 요청이 실패하더라도 주소 확인, 연결, 인증, 대상 응답 중 어느 단계에서 문제가 발생했는지 구분할 수 있습니다. 항목을 무작정 추가하거나 삭제하지 않아도 됩니다.

반복 가능한 테스트 기록 만들기

매 테스트마다 대상, 네트워크 환경, 선택된 서버, 설정 파일과 매칭 결과를 기록하세요. 최소한 세 가지 유형의 대상을 준비하세요. PROXY가 적용되어야 하는 명확한 예외, DIRECT가 적용되어야 하는 명확한 예외, FINAL로 처리되어야 하는 일반 대상입니다. 거부 규칙이 있다면 REJECT가 적용되어야 하는 대상도 추가하세요. 테스트에는 사용자가 실제로 접근 권한을 가진 서비스를 사용하면 됩니다. 검증을 위해 새로운 연결 서비스를 찾을 필요는 없습니다. 두 차례의 결과를 비교할 때 수정한 항목을 제외한 나머지 조건은 가능한 한 동일하게 유지하세요.

Connectivity Test와 실제 서비스 요청은 따로 확인하세요

Connectivity Test는 해당 테스트 조건에서 연결 상태를 판단하는 데 도움이 될 수 있지만, 테스트 성공이 모든 웹사이트와 요청, 트래픽 분기 규칙의 정상 작동을 보장하지는 않습니다. 실제 서비스 요청은 다른 도메인, 주소 계열, 연결 방식이나 인증 절차를 사용할 수 있습니다. 반대로 테스트 실패만으로 모든 서비스에 접속할 수 없다고 단정해서도 안 됩니다. 테스트 대상과 오류 정보를 확인하세요. 올바른 방법은 테스트 도구로 범위를 좁힌 다음 실제 서비스에 새 요청을 보내 규칙과 경로를 확인하는 것입니다. 하나의 결과를 전체 네트워크 상태로 간주하지 마세요.

모든 PROXY 요청이 실패한다면 최소 설정을 유지하고 현재 서버와 사용 중인 서비스 상태를 확인하세요. 특정 도메인만 실패하면 매칭된 규칙, 주소 확인과 대상 응답을 살펴보세요. 페이지 본문은 표시되지만 리소스가 빠져 있다면 리소스 도메인과 REJECT 항목을 각각 확인하세요. 네트워크를 바꿀 때만 실패한다면 DNS, On Demand와 주소 계열의 변화를 기록하세요. 이런 식으로 원인을 나누어 점검하는 편이 General의 모든 매개변수를 한꺼번에 바꾸는 것보다 효과적입니다. 서비스 인터페이스 하나의 문제 때문에 정상 작동하던 다른 규칙까지 망가뜨리는 일도 피할 수 있습니다.

로그에는 필요한 정보만 남기세요

앱에서 제공하는 기록으로 대상, 매칭 규칙과 오류 단계를 확인하세요. 구독 링크, 비밀번호나 인증 정보를 공개된 토론에 그대로 붙여 넣지 마세요. 문제 해결 자료를 저장할 때는 화면 캡처와 텍스트에 민감한 정보가 포함되어 있는지 먼저 확인한 뒤, 문제를 재현하는 데 필요한 최소한의 규칙 조각만 공유하세요. 서버 이름에도 사용자가 지정한 정보가 들어 있을 수 있으므로 함께 확인해야 합니다. 설정 파일 전체를 공유한다고 문제 해결이 자동으로 빨라지는 것은 아닙니다. 정리되지 않은 로그를 많이 제공하기보다 요청 조건과 처음 매칭된 근거를 분명히 남기는 편이 유용합니다.

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

위의 최소 조각으로는 연결 인증 정보를 노출하지 않고도 규칙 순서를 설명할 수 있습니다. 실제 문제를 정리할 때는 실제 서비스 이름을 예시 도메인으로 바꾸면서 ‘정확한 예외를 접미사 규칙보다 앞에 둔다’와 같은 구조는 유지할 수 있습니다. 실제 주소의 지역 귀속 여부가 문제와 관련 있다면 예시 주소를 사용했음을 명시해 독자가 테스트 결과를 실제 값으로 오해하지 않게 하세요. 재현 자료는 규칙의 논리를 설명할 수 있어야 하지만 사용자의 구독 정보나 서버 인증 정보를 포함할 필요는 없습니다. 비공개 링크를 문제 제목이나 파일명에 넣지 마세요.

복원 후 원격 업데이트가 다시 덮어쓰지 않았는지 확인하세요

예상과 다른 동작이 발생하면 수정 전 사본을 복원하고 해당 파일이 선택되었는지 확인하세요. 원래 Global Routing과 서버 선택도 복원한 뒤 연결을 다시 만들고 동일한 테스트를 진행하세요. 복원 직후 정상 작동한다면 수정 사항을 하나씩 다시 적용해 최소한의 차이를 찾으세요. 복원 후에도 실패한다면 네트워크와 서비스 상태도 바뀌었는지 확인하세요. 원격 설정을 다시 업데이트하면 로컬 수정이 덮어써질 수 있습니다. 복원을 마친 뒤에는 목록에 표시된 이름이 이전과 같다는 이유만으로 판단하지 말고 파일 내용도 확인하세요.

일상적인 관리에는 안정적인 설정 하나, 테스트용 사본 하나와 간단한 변경 기록을 남겨 두면 좋습니다. 규칙을 추가한 뒤 고정 테스트를 실행하고, 구독 업데이트 후 선택된 서버가 여전히 예상에 맞는지 확인하세요. 기기를 바꾼 뒤에는 설정이 가져와졌는지 다시 살펴보세요. 앱 구매 상태만으로 모든 연결 정보가 동기화된다고 가정해서는 안 됩니다. iPad의 앱 구매와 사용 방법은 iPad에서 구매한 앱 및 사용 안내를 참고하세요. 구매 복원은 앱을 다시 받는 절차이며 설정 이전이나 서버 매개변수 확인을 대신하지 않습니다.

전체 연결 절차를 다시 확인하려면 Shadowrocket 사용 가이드로 돌아가세요. 자주 발생하는 현상을 빠르게 찾아보려면 질문과 답변 및 문제 해결을 확인하세요. 앱 출처를 확인하려면 정품 여부를 확인하는 세 가지 항목을 참고하세요. 앱 아이콘, 개발자 Shadow Launch Technology Limited, 앱 ID 932747118을 App Store 페이지에서 함께 대조하세요. 설정은 규칙 수나 파일 길이가 아니라 이해하기 쉽고, 검증할 수 있으며, 되돌릴 수 있는지를 기준으로 관리해야 합니다.