Shadowrocket 규칙 및 설정 참고서

01 / CONFIG STRUCTURE

설정 파일 구조: 서버 정보와 동작 규칙 구분하기

Shadowrocket에서 서버 정보는 '어떤 서버로 연결할지'를 정하고, 설정 파일은 '요청을 어떻게 처리할지'를 정합니다. 서로 관련은 있지만 같은 정보는 아닙니다. 보유한 구독은 일반적으로 서버 항목을 가져오고 업데이트하는 데 사용하며, 트래픽 분기 규칙이 포함된 설정 파일은 Config에서 확인하고 활성화해야 합니다. Home에 서버가 표시된다고 해서 사용자 지정 규칙까지 적용되었다고 볼 수는 없습니다. 설정을 확인하기 전에 현재 선택한 서버, 활성화된 설정 파일, Global Routing 상태를 기록해 두세요. 그래야 이후 문제를 같은 조건에서 살펴볼 수 있습니다.

네 가지 설정 섹션의 역할

일반 텍스트 설정에서는 대괄호로 섹션 이름을 표시합니다. [General]에는 DNS 및 시스템 트래픽 관련 설정과 같은 일반 매개변수를 둡니다. [Rule]에는 요청 매칭 조건과 해당 정책을 둡니다. [Host]에는 지정한 도메인의 주소 매핑을 작성합니다. [URL Rewrite]는 표현식에 맞는 URL을 처리합니다. 섹션 이름은 단순한 제목이 아닙니다. 각 행이 속한 섹션에 따라 해석 방식이 달라집니다. 도메인 규칙을 General에 붙여 넣으면 행의 문법이 올바르더라도 Rule 규칙으로 사용할 수 없습니다.

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

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

[Host]
localhost = 127.0.0.1

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

이 조각은 구조를 파악하기 위한 예시이며, 전체 설정에 그대로 적용하라는 의미는 아닙니다. General의 두 행은 각각 불리언 매개변수와 DNS 값을 보여 줍니다. Rule의 세 행은 도메인, 주소 범위, 최종 정책을 나타냅니다. Host의 localhost는 로컬 루프백 이름 예시이고, 마지막 행은 HTTP에서 HTTPS로 리디렉션하는 방식을 보여 줍니다. 예시 도메인은 실제 서비스와 관계가 없으므로 복사하기 전에 목적을 먼저 확인하세요. 특히 FINAL 값은 매칭되지 않은 모든 요청에 영향을 주므로, 예시에서 PROXY를 사용했다고 그대로 따라 해서는 안 됩니다.

구두점, 줄 구성 및 가독성

규칙 필드는 반각 쉼표로 구분하고, 매개변수 값은 반각 등호로 지정하며, 섹션 이름에는 반각 대괄호를 사용합니다. 입력기의 전각 쉼표, 따옴표, 공백은 내용이 예상대로 해석되지 않는 원인이 될 수 있습니다. 규칙은 한 줄에 하나씩 작성하고, 웹페이지 줄바꿈을 새 규칙으로 오해하지 마세요. 읽을 때는 '키워드, 매칭 값, 정책, 선택적 매개변수' 순으로 나눠 볼 수 있지만 모든 키워드의 필드 수가 같은 것은 아닙니다. FINAL에는 매칭 값이 없으므로 기계적으로 세 열을 채워서는 안 됩니다.

설정 섹션의 배열 순서를 고정된 처리 절차로 이해해서는 안 됩니다. 파일에서 General이 Rule보다 위에 있다고 해서 모든 요청에 일반 매개변수를 먼저 적용한 뒤 다른 섹션을 차례대로 처리한다는 뜻은 아닙니다. Host와 URL Rewrite도 Rule의 후속 규칙이 아닙니다. 위에서 아래로 순서를 확인해야 하는 곳은 Rule 내부입니다. 설정 구조와 규칙 우선순위를 구분하면 설정 섹션 전체를 옮겨 '규칙 우선순위를 높이려는' 무효한 수정을 피할 수 있습니다.

Config에서 활성화된 항목 확인하기

Config에 들어가면 먼저 현재 선택된 파일을 확인한 다음 살펴보거나 편집할 항목을 여세요. 복사본을 수정하기 전에는 용도를 알아보기 쉬운 이름을 붙이고 원본 파일을 보관합니다. 편집 내용을 저장하는 것과 파일을 활성화하는 것은 별개의 확인 단계입니다. 저장은 텍스트가 기록되었다는 의미일 뿐, 현재 연결에서 해당 파일을 사용한다는 뜻은 아닙니다. 파일 목록으로 돌아가 선택 상태를 확인하고 Global Routing도 점검하세요. 화면 구성은 앱 업데이트에 따라 달라질 수 있으므로 특정 화면 좌표가 아니라 파일 이름, 선택 상태, 실제 요청 결과를 기준으로 판단해야 합니다.

사용 중인 앱이 맞는지 아직 확인하지 못했다면 정식 앱 확인 안내에서 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. Shadowrocket은 Apple 플랫폼의 유료 클라이언트이며 App Store에서만 받을 수 있습니다. 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 기본 환경을 확인한 뒤 이 페이지의 필요한 설정 조각만 수정하면, 서버와 설정을 동시에 변경하는 것보다 문제 원인을 쉽게 파악할 수 있습니다.

03 / DOMAIN MATCHING

도메인 규칙: 정확한 이름, 접미사, 키워드

트래픽 분기 대상을 안정적인 도메인으로 표현할 수 있다면 먼저 도메인 규칙을 고려하세요. 주소를 직접 나열하는 것보다 '특정 사이트나 서비스'라는 의도를 잘 표현하고, 서버 주소가 바뀌어도 영향을 덜 받습니다. 다만 도메인은 전체 URL이 아닙니다. 프로토콜, 경로, 쿼리 매개변수, 포트를 DOMAIN의 매칭 값에 그대로 붙여 넣으면 안 됩니다. 브라우저 주소창의 전체 URL에서 먼저 호스트 이름을 추출한 다음, 그 이름만 매칭할지 하위 도메인까지 포함할지 판단하세요.

DOMAIN: 지정한 이름만 매칭

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

첫 번째 행은 api.example.com, 두 번째 행은 account.example.com을 대상으로 합니다. DOMAIN은 '이 단어가 포함됨'을 뜻하지 않으며 다른 하위 도메인까지 자동으로 포함하지 않습니다. 실제 요청이 images.api.example.com이라면 같은 서비스처럼 보여도 첫 번째 행이 매칭된다고 단정할 수 없습니다. 정확한 규칙은 일부 명확한 예외를 처리할 때 적합합니다. 예를 들어 대부분의 요청에는 최종 정책을 적용하고 특정 호스트 이름 하나에만 DIRECT를 적용할 수 있습니다. 사용하기 전에 실제 요청에서 전체 이름을 확인하고, 페이지에 표시되는 브랜드 이름을 네트워크 요청의 호스트 이름으로 착각하지 마세요.

DOMAIN-SUFFIX: 도메인 경계를 기준으로 접미사 범위 매칭

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

DOMAIN-SUFFIX,example.com은 example.com과 www.example.com 같은 하위 도메인을 포함합니다. 도메인 경계를 기준으로 접미사를 판단하므로 임의의 문자열 끝부분을 비교하는 방식이 아닙니다. 따라서 notexample.com은 정상적인 매칭 대상이 아닙니다. 위 예시처럼 넓은 접미사 규칙보다 private.example.com의 정확한 예외를 먼저 작성하세요. 두 행의 순서를 바꾸면 접미사 규칙이 예외 이름을 먼저 매칭해 정확한 규칙이 의도한 역할을 하지 못합니다. 규칙 수보다 적용 범위의 관계가 더 중요합니다.

접미사를 작성할 때는 보통 별표를 붙이지 않습니다. *.example.com을 DOMAIN-SUFFIX의 표준 값으로 사용하면 와일드카드 표현식과 접미사 매칭 방식이 혼동됩니다. 이미지 도메인까지 포함해야 한다는 이유로 범위를 짧은 공용 접미사까지 넓히지도 마세요. 범위가 넓을수록 관계없는 서비스가 함께 포함될 가능성이 커집니다. 실제 서비스에서 사용하는 등록 도메인을 출발점으로 삼고, 모든 요청이 같은 접미사를 공유한다고 추측하기보다 요청 기록을 보고 별도 도메인을 추가하세요.

DOMAIN-KEYWORD: 범위가 넓고 잘못 매칭될 가능성도 큽니다

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 매칭합니다. 여기서 example은 완전한 도메인이 아니며 DOMAIN-SUFFIX처럼 도메인 경계도 고려하지 않으므로 관계없는 이름까지 매칭될 수 있습니다. 이처럼 넓은 조건이 꼭 필요하고 적용 범위를 확인할 수 있을 때만 사용하세요. example.com과 하위 도메인만 대상으로 한다면 접미사 규칙이 일반적으로 의도에 더 잘 맞습니다. 규칙이 짧다고 더 정확한 것은 아니며, 키워드가 적다고 관리가 쉬운 것도 아닙니다.

페이지 도메인과 전체 요청 도메인은 다릅니다

한 페이지가 로그인, 이미지, API, 정적 리소스 도메인에 각각 요청을 보낼 수 있습니다. 홈페이지는 열리지만 로그인이 실패하더라도 같은 규칙이 간헐적으로 달리 동작한다는 뜻은 아닙니다. 다른 요청에 다른 정책이 적용되었을 수 있습니다. 문제가 발생한 시점에 요청 기록을 확인해 실제로 실패한 이름을 찾은 뒤 규칙을 추가할지 결정하세요. 타사 리소스 도메인은 여러 서비스에서 함께 사용할 수 있으므로, 한 페이지에 표시된다는 이유만으로 해당 도메인의 모든 요청이 그 페이지와 같은 정책을 사용해야 한다고 판단해서는 안 됩니다.

요청 기록에 IP만 있고 매칭에 사용할 도메인 정보가 없다면 도메인 규칙이 올바른 확인 지점이 아닐 수 있습니다. 이때는 비슷한 도메인 규칙을 더 추가하는 대신 주소 규칙, DNS, 요청 발생 방식을 살펴보세요. 국제화 도메인이나 형식이 특수한 이름도 실제 기록에 표시된 형식을 기준으로 해야 합니다. 수정 후에는 대상 이름뿐 아니라 매칭되면 안 되는 비슷한 이름도 테스트하세요. 그래야 필요한 범위를 포함하면서 경계 밖의 대상은 포함하지 않았는지 확인할 수 있습니다.

05 / POLICY

Global Routing과 PROXY, DIRECT, REJECT

Global Routing의 Config, Proxy, Direct는 모드를 선택하는 항목이고, Rule의 PROXY, DIRECT, REJECT는 규칙의 처리 정책입니다. 비슷해 보이지만 서로 다른 계층에 속합니다. 규칙 적용 여부를 확인할 때는 먼저 Global Routing을 살펴보세요. 현재 요청을 Config 방식으로 처리하지 않는다면 Rule을 수정했다고 연결 결과가 바뀐다고 단정할 수 없습니다. 특히 테스트를 위해 Proxy나 Direct로 잠시 전환했다면 사용자 지정 분기를 확인하기 전에 원래 모드로 되돌리세요.

PROXY: 프록시 경로를 사용하지만 원격 연결 성공을 보장하지 않습니다

규칙 정책 PROXY는 현재 프록시를 선택해 연결하려는 의도를 나타냅니다. 서버 주소를 지정하는 값도 아니며 필요한 인증이나 프로토콜 매개변수를 보완하지도 않습니다. 보유한 서버 정보의 주소, 포트, 인증 정보 또는 관련 설정이 잘못되었다면 규칙이 PROXY에 올바르게 매칭되어도 연결에 실패할 수 있습니다. 따라서 요청에 예상한 정책이 적용되었는지와 해당 정책의 연결 경로가 사용 가능한지를 각각 확인해야 합니다. 이 두 확인을 '규칙이 적용되지 않음'이라는 하나의 문제로 뭉뚱그리면 잘못된 방향으로 점검하게 됩니다.

Home에서 선택한 서버도 기록에 포함해야 합니다. 같은 설정 파일을 사용하더라도 서버를 바꾸면 결과가 달라질 수 있으며, 그렇다고 Rule 문법이 바뀐 것은 아닙니다. 사용자 지정 정책이나 그룹은 이름과 실제 연결 대상을 확인하고, 정의되지 않은 이름을 예시에 작성하지 마세요. 이 문서에서는 추가 그룹 정의에 의존하지 않도록 세 가지 기본 정책만 사용합니다. Trojan 매개변수를 더 확인하려면 Trojan 매개변수 안내를 참고하세요. 프로토콜 매개변수 문제를 도메인 규칙 수정으로 해결하려 하지 마세요.

DIRECT: 현재 네트워크에서 직접 연결

DIRECT는 Shadowrocket을 중지하거나 시스템의 VPN 설정을 끈다는 뜻이 아닙니다. 현재 처리 과정에서 대상에 직접 연결하는 방식을 선택합니다. 대상에 접속할 수 있는지는 현재 네트워크, 해석 결과, 서비스 상태에 따라 달라집니다. 로컬 네트워크 대상에 DIRECT를 사용하는 것은 접속 목적에 맞는 경우가 많지만 기기가 해당 네트워크에 연결되어 있어야 합니다. 기기가 같은 네트워크에 없거나 로컬 서비스가 해당 주소에서 요청을 받지 않으면 DIRECT 규칙만으로 존재하지 않는 네트워크 연결을 만들 수는 없습니다.

REJECT: 매칭된 요청을 명시적으로 거부

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

첫 번째 행은 지정한 이름의 요청을 거부하고, 두 번째 행은 접미사 조건에 맞는 나머지 요청에 PROXY를 적용하며, 마지막 행은 그 밖의 트래픽을 처리합니다. REJECT는 연결을 원하지 않는 대상을 명확히 지정할 때 사용하며, 아직 정하지 못한 최종 정책의 대용으로 쓰지 마세요. 거부한 이름이 로그인, 인증, 콘텐츠 로딩 기능도 담당한다면 페이지 일부에 문제가 생길 수 있습니다. 수정 전에 해당 이름의 용도를 파악하고, 수정 후에는 홈페이지 표시 여부만 보지 말고 주요 기능을 확인하세요.

거부 정책은 페이지의 불필요한 요소를 자동으로 정리해 주지 않습니다. 웹페이지에서 보이는 콘텐츠와 네트워크 요청이 일대일로 대응하는 것도 아니며, 하나의 도메인이 여러 기능을 맡을 수 있습니다. 특정 리소스를 차단하려고 접미사나 키워드 규칙 범위를 지나치게 넓히면 정상 요청까지 영향을 받을 수 있습니다. 정확한 대상부터 시작해 요청 기록으로 조건을 확인한 뒤 범위를 넓힐지 판단하세요. 문제가 생기면 예외 규칙을 계속 추가해 기존 오류를 가리기보다 방금 추가한 거부 규칙부터 되돌리세요.

FINAL: 매칭되지 않은 요청의 처리 방식 지정

FINAL은 매칭 값이 없는 최종 규칙이며, 일반적인 형식은 FINAL,PROXY 또는 FINAL,DIRECT입니다. 전역 모드와는 다른 개념입니다. FINAL은 Config의 규칙 설정에 속하며 앞선 규칙에 매칭되지 않은 요청만 처리합니다. 어느 정책을 선택할지는 원하는 기본 동작에 따라 달라지므로 특정 값이 모두에게 정답이라고 볼 수 없습니다. PROXY를 사용한다면 보유한 서버가 사용 가능한지 확인하세요. DIRECT를 사용한다면 목록에 없는 대상이 직접 연결된다는 점을 고려해야 합니다.

세 모드에서 증상이 다르게 나타나면 바로 결론을 내리지 말고 차이를 기록하세요. Direct에서는 연결되지만 Proxy에서 실패한다면 서버 경로를 확인해야 할 수 있습니다. Proxy에서는 연결되지만 Config에서 실패한다면 적용된 정책과 다른 설정을 점검해야 할 수 있습니다. 세 모드 모두 실패한다면 대상이나 현재 네트워크가 원인일 수도 있습니다. 구체적인 판단에는 연결 기록이 필요하며, 모드 전환 결과만으로 다른 모든 원인을 배제할 수는 없습니다.

07 / HOST AND URL REWRITE

Host 및 URL Rewrite: 주소 매핑과 URL 변경은 별도로 처리

Host는 이름과 주소의 연결을 처리하고, URL Rewrite는 표현식에 맞는 URL을 처리합니다. 둘 다 PROXY나 DIRECT를 선택하는 기능은 아닙니다. 접속이 실패하면 먼저 무엇을 바꾸려는지 명확히 하세요. 같은 도메인을 다른 주소로 해석하려는 것인지, 기존 URL을 새 URL로 리디렉션하려는 것인지, 아니면 연결 경로만 바꾸려는 것인지 구분해야 합니다. 앞의 두 경우는 이 장과 관련이 있을 수 있지만 세 번째는 Rule에서 처리해야 합니다. 트래픽을 분기하려고 Host를 수정하면 주소나 인증서 문제까지 추가될 수 있습니다.

Host의 기본 예시와 적용 범위

[Host]
localhost = 127.0.0.1

왼쪽은 이름, 오른쪽은 주소입니다. localhost와 127.0.0.1은 로컬 루프백의 예시입니다. 여기서 '로컬 기기'는 연결을 시작하는 기기 자신을 뜻하며 라우터나 선택한 프록시 서버가 아닙니다. 원격 서버에 접속해야 하는 서비스에 이 주소를 사용하지 마세요. 매핑을 작성해도 주소 정보만 제공할 뿐 해당 주소에서 필요한 서비스가 자동으로 실행되지는 않습니다. 대상 포트에서 서비스가 수신 대기하지 않거나 네트워크에 연결할 수 없거나 서비스 설정이 맞지 않으면 이름이 주소에 매핑되어도 연결에 실패할 수 있습니다.

실제 도메인의 주소를 고정하기 전에 해당 주소를 누가 관리하는지, 안정적인지, 해당 방식으로 접속해도 되는지 확인하세요. 많은 서비스는 지역과 부하에 따라 주소를 동적으로 반환하므로 그중 하나를 고정하면 기존 분산 처리가 제대로 작동하지 않을 수 있습니다. 매핑 때문에 정상적인 DNS 변경이 보이지 않으면 이후 문제를 확인할 때 해석 서비스가 계속 이전 주소를 반환한다고 오해할 수도 있습니다. Host는 명확하고 직접 관리할 수 있는 매핑에 적합하며 일시적인 해석 결과를 무기한 보관하는 용도로는 적절하지 않습니다.

Host는 TLS 인증을 대신하지 않습니다

HTTPS 연결에는 요청 도메인과 인증서 등의 조건도 관련됩니다. 도메인을 특정 주소로 매핑해도 그 주소가 해당 도메인에 맞는 서비스를 제공한다는 뜻은 아니며 인증서 이름 불일치를 자동으로 해결하지도 않습니다. TLS 오류가 발생하면 대상 이름, 주소, 서버 설정을 확인하고 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 테스트가 끝나 더 이상 매핑이 필요하지 않다면 삭제하고 연결을 다시 시작한 뒤 실제 주소를 확인하세요. 그래야 이전 설정이 다른 진단에 영향을 주지 않습니다.

URL Rewrite의 세 가지 구성 요소

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

이 행은 매칭 표현식, 대체 대상, 리디렉션 상태 코드 순으로 구성됩니다. 처음의 ^는 문자열 시작 위치부터 매칭한다는 의미입니다. example 뒤의 백슬래시는 마침표를 일반 문자로 처리합니다. 이를 생략하면 정규식에서 마침표는 보통 임의의 문자 하나를 뜻해 매칭 범위가 넓어집니다. 마지막 슬래시도 조건의 일부입니다. 여기서는 임시 리디렉션을 보여 주기 위해 302를 사용했으며, 이 설정이 모든 HTTP 접속을 해결하거나 기존 URL의 경로와 쿼리 매개변수를 자동으로 보존한다고 볼 수는 없습니다.

예시의 대체 대상은 고정 URL이며 매칭된 URL의 나머지 부분을 명시적으로 보존하지 않습니다. 실제 요구 사항에 경로나 쿼리 매개변수가 포함된다면 캡처 범위와 대체 방식을 먼저 설계한 뒤 통제 가능한 몇 가지 대상으로 테스트하세요. 시작 도메인이 같다는 이유만으로 로그인 콜백, API 요청, 일반 페이지를 모두 사이트 홈으로 리디렉션해서는 안 됩니다. 범위가 너무 넓은 재작성은 요청의 의미를 바꾸거나 리디렉션 루프를 일으킬 수 있습니다. 재작성된 대상이 다른 재작성 조건에도 해당한다면 상호 작용도 확인해야 합니다.

HTTPS에서 확인할 수 있는 정보의 한계

HTTPS 연결에서는 전체 경로와 요청 내용이 대개 암호화되므로 URL Rewrite만 추가해 모든 암호화된 요청에 적용할 수 있다고 가정해서는 안 됩니다. 이 장에서는 HTTPS 복호화 설정을 요구하지 않으며 규칙 분기의 전제 조건으로 인증서 설치를 요구하지도 않습니다. 도메인에 따라 연결 방향만 정하려는 경우 도메인 규칙을 사용하면 되며 전체 URL을 확인하기 위해 다른 설정을 추가할 필요는 없습니다. 기능이 적용되는지는 실제로 볼 수 있는 요청 정보와 앱이 지원하는 처리 조건을 기준으로 판단하세요.

두 설정 섹션을 테스트할 때는 되돌리는 단계도 포함하세요. 기존 값을 먼저 기록하고 매핑이나 재작성 규칙 하나를 추가해 대상 동작을 확인한 다음, 변경을 취소하고 다시 테스트해 증상이 변경에 따라 일관되게 달라지는지 살펴보세요. 취소한 뒤에도 문제가 남아 있다면 항목을 계속 추가하기보다 캐시, 기존 연결, 대상 서비스의 변경 여부를 확인하세요. 전체 파일에서 네 섹션의 관계를 다시 살펴보려면 설정 파일 구조 해설을 참고하세요. 이 장에서는 영향을 설명하고 검증할 수 있는 범위로 제한하는 것을 원칙으로 합니다.

08 / CHANGE AND VERIFY

설정 수정 및 문제 해결: 반복 가능한 검증 절차 만들기

규칙이 올바르다는 판단과 접속에 성공했다는 판단은 서로 관련이 있지만 동일하지 않습니다. 올바른 규칙이 일시적으로 사용할 수 없는 경로를 선택할 수도 있습니다. 접속에 한 번 성공했더라도 캐시나 기존 연결 덕분일 수 있어 새 규칙이 적용되었다는 증거가 아닐 수 있습니다. 신뢰할 수 있는 검증을 위해 테스트 조건을 고정하고 원본 설정을 보관하며 한 번에 하나의 요소만 변경하고 새 요청 결과를 기록하세요. 이 장에서는 앞서 살펴본 규칙을 되돌릴 수 있는 절차로 정리합니다. 특정 도메인 오류, 수정 후 변화 없음, 설정 업데이트 후 동작 변경 등에 활용할 수 있습니다.

1단계: 기준 상태를 기록하고 설정은 변경하지 않기

먼저 현재 네트워크 유형, Global Routing, 활성화된 파일, 선택된 서버를 기록한 뒤 어떤 작업에서 문제가 발생하는지 설명하세요. '작동하지 않음'이라고만 쓰지 말고 홈페이지가 열리지 않는지, 이미지가 표시되지 않는지, 로그인이 실패하는지, API 요청이 실패하는지, 로컬 네트워크 기기에 접속할 수 없는지 구분해야 합니다. 반복해서 재현할 수 있는 동작을 정하고 가능한 한 같은 대상을 사용하세요. 원래 문제가 간헐적으로 발생한다면 기준 상태를 여러 번 관찰해야 합니다. 그렇지 않으면 수정 후의 우연한 성공을 해결 효과로 오해하기 쉽습니다.

2단계: 복사본을 저장하고 수정 범위를 좁히기

Config에서 원본 파일을 보관한 뒤 복사본을 편집하세요. 관련 섹션에 비슷한 규칙이 이미 있는지, 조건이 중복되었는지, FINAL이 앞쪽에 있는지 확인합니다. 도메인 하나의 문제라면 광범위한 키워드를 바로 추가하지 말고 가장 범위가 좁은 DOMAIN 예외부터 추가하세요. DNS를 조정할 때는 Rule을 이동하지 말고, Host를 조정할 때는 서버를 바꾸지 마세요. 그래야 결과가 달라졌을 때 하나의 명확한 변경 사항과 연결해 원인을 파악할 수 있습니다.

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

이 부분 설정 예시는 정확한 예외를 검증하기 위한 것입니다. api.example.com에는 PROXY를 적용하고, 접미사에 해당하는 다른 이름에는 DIRECT를 적용하며, 나머지 요청은 최종 정책으로 처리합니다. 각 행의 의미를 확인한 다음 자신의 대상과 예상 정책을 대응시키세요. 예시 도메인으로 실제 연결 상태를 테스트하지 말고, 이미 존재하는 FINAL 뒤에 조각 전체를 추가하지도 마세요. 현재 파일 구조가 복잡하다면 복사본에서 최소 재현부터 진행하고 논리가 맞는지 확인한 뒤 장기간 유지할 설정에 반영하세요.

3단계: 저장하고 활성화한 다음 새 요청 보내기

편집을 마친 뒤 저장 상태를 확인하고 Config로 돌아가 활성화된 항목을 확인한 다음 Global Routing을 Config로 설정하세요. 대상 작업을 다시 실행하고, 기존 연결 재사용이 관찰에 미치는 영향을 줄여야 한다면 연결을 끊었다가 다시 연결합니다. 다시 연결해도 모든 앱 캐시가 사라지는 것은 아니므로 요청 기록에서 새 네트워크 요청이 발생했는지 확인해야 합니다. 테스트 중에는 '페이지에 변화가 없음'을 '규칙에 변화가 없음'과 동일하게 보지 마세요. 페이지가 관련 리소스를 다시 요청하지 않았을 수도 있습니다.

4단계: 연결보다 매칭부터 확인하기

요청에 예상한 정책이 적용되지 않았다면 Rule의 위쪽부터 범위 관계, 실제 호스트 이름, 주소 유형, Global Routing을 확인하세요. 정책은 예상대로인데도 연결에 실패한다면 선택된 서버, 프로토콜 정보, DNS, 대상 응답을 점검합니다. 특정 네트워크에서만 실패하면 네트워크 조건을 비교하고, 특정 서버에서만 실패하면 서버 연결 결과를 비교하세요. 정책이 이미 올바른데도 반복 규칙을 추가하지 마세요. 중복 항목은 인증 오류, 연결할 수 없는 주소, 대상 서비스의 문제를 해결하지 못합니다.

5단계: 인접한 대상도 다시 확인하고 복구 기록 남기기

대상이 정상적으로 복구된 뒤에도 같은 접미사에 속하는 다른 요청, 해당 범위에 속하지 않는 대상, 영향을 받을 수 있는 로컬 네트워크 접속을 확인하세요. 최종 정책을 수정했다면 매칭되지 않은 모든 요청의 경로가 바뀔 수 있으므로 더 넓게 회귀 테스트를 해야 합니다. 기록에는 어느 행을 왜 수정했는지, 어떻게 검증했는지, 어떻게 되돌릴 수 있는지를 포함하세요. 민감한 요청 내용을 전부 저장할 필요는 없습니다. 장기적으로 유지하는 설정의 가치는 수정한 당일에 동작하는 것뿐 아니라 나중에도 이유를 이해할 수 있다는 데 있습니다.

원인을 찾지 못했다면 켜져 있는데 연결되지 않을 때의 점검 순서를 따라가거나 문제 해결에서 관련 항목을 찾아보세요. 가져오기와 연결 절차를 다시 확인하려면 빠른 시작 가이드를 참고하세요. 구매 및 기기 호환성은 App Store 정품 안내에서 확인할 수 있습니다. 시스템 요구 사항과 유니버설 구매 여부는 App Store 페이지의 표기를 기준으로 합니다. 규칙 문제를 해결하기 위한 단계로 클라이언트를 다시 구매하지 마세요.