Shadowrocket
규칙 및 설정 가이드

먼저 현재 파일을 확인하고 각 섹션의 역할을 구분하세요.

Config에서 실제 사용 중인 파일 확인

설정 파일은 서버 목록을 다른 형식으로 적어 둔 것이 아닙니다. 서버 정보에는 원격 연결에 필요한 주소, 포트, 프로토콜, 인증 매개변수가 담깁니다. 설정 파일은 요청을 분류하고 정책을 선택하는 방식과 일부 해석 및 처리 동작을 지정합니다. Config를 열면 파일이 가져와져 있다는 사실만으로 적용 중이라고 판단하지 말고, 현재 선택된 파일부터 확인하세요. 파일 존재 여부, 내용 저장 여부, 파일 선택 여부, Global Routing에서 Config 사용 여부는 각각 따로 확인해야 합니다. 방금 수정한 규칙이 연결에 영향을 주지 않는다면, 비슷한 규칙을 더 추가하기보다 이 네 가지를 먼저 점검하는 편이 효과적입니다.

편집을 시작하기 전에 현재 사용 가능한 파일의 사본을 남기고, 사용 중인 서버와 Global Routing 상태를 기록하세요. 처음 확인하는 경우 파일의 섹션 제목을 먼저 읽은 뒤 각 섹션의 필드를 살펴보세요. 첫 줄부터 전체 설정을 추측하며 읽을 필요는 없습니다. 대괄호로 표시된 제목은 설정 섹션을 구분하며, 뒤따르는 내용은 해당 섹션의 기준에 따라 해석됩니다. 같은 문구라도 서로 다른 섹션에 있으면 의미가 다를 수 있습니다. 예시 도메인은 문법 설명용이며 실제로 연결할 수 있는 서비스를 뜻하지 않습니다.

자주 쓰이는 네 섹션의 역할

General의 설정은 기본 처리 환경에 적용되며, 일반적인 트래픽 분기 규칙을 여기에 작성하면 안 됩니다. Rule의 각 행은 매칭 조건과 그 결과를 설명합니다. 예를 들어 도메인이 매칭되면 DIRECT를 선택할 수 있습니다. Host는 특정 호스트 이름의 주소 매핑을 변경하며, 해당 호스트에 프록시 정책을 지정하는 기능은 아닙니다. URL Rewrite는 확인 가능한 요청 주소를 처리하므로 일반 연결의 라우팅 판단을 담당하는 Rule을 대체하지 않습니다. 이 네 가지를 혼동하면 “도메인 주소를 매핑했는데 왜 프록시로 연결되지?” 같은 오해가 생깁니다. 주소의 출처와 정책의 출처는 서로 다른 판단 기준입니다.

[General]
dns-server = system

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

이 최소 예시는 시스템 DNS를 사용하고 example.com 및 하위 도메인에는 PROXY, 로컬 네트워크의 한 주소 범위에는 DIRECT를 지정하며 그 밖의 연결은 FINAL로 처리합니다. 실제로 사용할 서버 정보나 완전한 네트워크 요구 사항은 포함하지 않았습니다. 섹션 경계와 규칙 구조를 명확히 보여 주기 위한 예시입니다. 목차를 채우려고 비어 있는 Host 또는 URL Rewrite 섹션을 추가하지 마세요. 관련 요구가 없다면 파일을 간결하게 유지하는 편이 각 수정의 영향을 파악하기 쉽습니다.

편집, 저장, 가져오기는 서로 다른 작업

파일에서 설정을 가져온 뒤 섹션이 빠짐없이 있는지, 줄바꿈이 유지되었는지, 쉼표가 영문 문자로 입력되었는지 확인하세요. 서식 있는 텍스트에서 복사한 내용에는 중국어 문장 부호, 보이지 않는 공백, 줄바꿈 축약이 포함될 수 있습니다. 겉보기에는 맞아도 해석 결과가 달라질 수 있습니다. 저장한 뒤 편집 내용을 다시 열어 실제 저장된 텍스트가 예상과 일치하는지 확인하고 Config로 돌아가 선택된 파일도 확인하세요. 원격 소스의 설정을 업데이트했다면 로컬에서 직접 변경한 내용이 보존되는지 별도로 검증해야 합니다. 한 번 저장에 성공했다고 이후 업데이트 때마다 자동으로 병합된다고 볼 수는 없습니다.

출처가 복잡한 파일이라면 먼저 설명할 수 있는 기준 설정을 만들고, 실제로 필요한 항목만 하나씩 옮기세요. 항목을 한 묶음씩 추가할 때마다 테스트하고 고급 필드를 한꺼번에 복사하지 않아도 됩니다. 파일 이름은 식별에 도움이 될 뿐, 내용이 현재 기기에 적합하다는 증거는 아닙니다. 주석에 “직접 연결”이라고 적혀 있어도 실제 정책 키워드가 우선합니다. 마지막으로 저장된 텍스트, 현재 모드, 연결 기록을 함께 확인해 결과를 판단하세요. 다음 장에서도 같은 방식으로 점검합니다.

Global Routing은 라우팅 방식을 정하고, 정책은 매칭 후 처리 방법을 정합니다.

Config, Proxy, Direct를 확인하는 방법

Global Routing의 Config, Proxy, Direct는 라우팅 수준의 선택이며 개별 규칙의 다른 이름이 아닙니다. Config 모드는 현재 설정에 따라 연결을 처리하므로 Rule 섹션을 확인할 때 가장 먼저 살펴봐야 합니다. Proxy 모드는 프록시 경로의 연결 상태를 비교할 때, Direct 모드는 로컬 네트워크 경로를 비교할 때 유용합니다. 하지만 이를 근거로 모든 시스템 연결이 같은 방식으로 처리된다고 단정할 수는 없습니다. 기본 우회 설정, 시스템 예약 연결, 실제 네트워크 환경에 따라 관찰 범위가 달라질 수 있으므로 현재 테스트 중인 요청에 한정해 판단하세요.

예를 들어 어떤 도메인이 Proxy에서는 연결되지만 Config로 전환한 뒤 실패한다면, 조사 범위를 설정 경로, 이름 해석 차이 또는 정책 선택으로 좁힐 수 있습니다. 이것만으로 모든 도메인 규칙에 문제가 있다고 단정할 수는 없습니다. Config에서 해당 연결이 어떤 행과 매칭되었는지, 정책이 최종적으로 어디를 가리키는지 확인하세요. 반대로 Direct에서는 접속되지만 Proxy에서는 실패한다면, 도메인을 더 많은 DIRECT 목록에 추가하기보다 사용자가 보유한 서버의 연결 매개변수, 원격 접속 가능 여부, 프로토콜 요구 사항을 확인해야 합니다.

PROXY, DIRECT, REJECT의 실행 의미

규칙 행의 PROXY는 프록시 경로를 사용한다는 뜻이지만, 서버 주소 자체를 포함하지는 않습니다. 실제로 사용할 연결 대상은 현재 서버 선택과 설정의 정책 참조를 함께 확인해야 합니다. DIRECT는 해당 규칙이 지정하는 프록시 경로를 거치지 않고 대상에 직접 연결한다는 뜻입니다. 그렇다고 DNS 조회가 발생하지 않는다는 뜻도, 대상에 반드시 연결할 수 있다는 뜻도 아닙니다. REJECT는 매칭된 연결을 거부하며 차단이 명확히 필요한 대상에 사용합니다. 규칙이 연결을 차단하는 것과 페이지가 정상적으로 작동하는 것은 별개의 결과입니다. 페이지에서 필요한 리소스를 거부하면 기능이 작동하지 않을 수 있습니다.

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

이 세 도메인은 정책별 동작을 보여 주기 위한 예시이며, 완전한 서비스 설정으로 그대로 적용할 수 없습니다. DIRECT를 PROXY로 바꾸면 연결 경로 선택만 바뀌며 대상 주소, 인증서, 인증 매개변수가 자동으로 수정되지는 않습니다. 연결 실패를 REJECT로 바꾸는 것도 문제를 해결하는 방법이 아니라 연결을 의도적으로 종료하는 것입니다. 설정을 관리할 때는 주석에 영문 정책 이름을 번역해 반복하기보다 “이 정책이 필요한 이유”를 적으세요. 그래야 네트워크 환경이 바뀌었을 때 어떤 규칙을 다시 검토해야 하는지 알 수 있습니다.

정책 이름, 선택 대상 및 실패 시 전환

파일에 사용자 지정 정책 이름이 있다면 현재 설정에 해당 이름의 정의가 있는지 확인하세요. 대소문자와 공백도 실제 내용과 일치해야 합니다. 참조 행만 복사하고 참조 대상 정책을 빠뜨리지 마세요. 선택 또는 탐색 로직이 포함된 정책에서는 규칙 매칭이 첫 번째 분류 단계일 뿐이며, 최종 연결은 선택된 대상의 상태에 따라 달라질 수 있습니다. 따라서 기록에서 예상한 정책 이름을 확인한 뒤에도 실제 연결 대상을 계속 확인해야 합니다. 규칙은 올바르지만 서버를 사용할 수 없는 상황도 동시에 발생할 수 있으므로 둘을 나누어 처리하세요.

‘앞선 규칙과 매칭되지 않음’과 ‘매칭 후 연결 실패’도 구분해야 합니다. 전자는 뒤에 있는 규칙이나 FINAL에서 계속 처리됩니다. 후자는 대개 연결이 실패했다고 해서 같은 요청이 Rule 섹션으로 돌아가 연결 가능한 다음 규칙을 찾는 방식으로 처리되지 않습니다. 재시도 또는 정책 내부 전환이 있는지는 해당 설정과 기능에 따라 다릅니다. Rule의 순서를 예비 서버 목록처럼 간주하지 마세요. 이 차이를 이해하면 “두 번째 규칙은 사용할 수 있는데 왜 계속 시도하지 않나요?”라는 의문을 설명할 수 있습니다.

모드나 정책을 조정한 뒤에는 테스트 연결을 새로 만들고, 변경 전후의 모드, 매칭 행, 연결 대상을 기록하세요. 연결 스위치의 모양만 보고 성공 여부를 판단하지 말고, 모드·서버·DNS를 한 번에 모두 변경하지도 마세요. 나머지 조건을 그대로 유지해야 변화의 원인을 설명할 수 있습니다. 규칙을 익히려는 경우 Config에서 명확한 규칙을 소수만 사용해 재현 가능한 결과를 만든 뒤 일상 설정으로 확장하세요.

정확한 도메인, 도메인 접미사, 문자열 포함은 각각 적용 범위가 다릅니다.

DOMAIN: 도메인 전체가 일치하는 경우

DOMAIN은 도메인 전체가 일치하는 경우에 사용하며, 단일 서비스 주소에 명확한 예외를 지정할 때 적합합니다. DOMAIN,api.example.com,PROXY 규칙은 api.example.com을 대상으로 하며 example.com의 모든 호스트를 의미하지 않습니다. 도메인 값에 프로토콜 접두사, 경로, 포트를 넣지 말고 브라우저 주소창의 전체 URL을 그대로 붙여 넣지도 마세요. 같은 호스트에서 서로 다른 경로를 구분해야 한다면 일반 DOMAIN 규칙으로는 그 수준까지 지정할 수 없습니다. 먼저 필요한 것이 도메인 라우팅인지 요청 주소 처리인지 확인하세요.

정확한 규칙은 적용 범위를 제어하기 쉽고 로그에서 해당 요청을 찾아내기도 편리합니다. 특정 API에 예외를 추가할 때는 페이지 주소만 보지 말고 실제 요청 호스트를 확인하세요. 페이지 하나가 로그인 도메인, 정적 리소스 도메인, API 도메인에 각각 요청할 수 있습니다. 기본 페이지 규칙만 수정하면 다른 요청은 여전히 기존 정책을 따를 수 있습니다. 페이지 일부만 정상이고 나머지가 실패한다면 실패한 연결의 대상을 각각 확인하세요. 페이지 전체가 도메인 하나에 대한 단일 요청이라고 간주하지 마세요.

DOMAIN-SUFFIX: 도메인 계층을 기준으로 적용

[Rule]
# 정확한 예외는 더 넓은 접미사 규칙보다 앞에 배치
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX,example.com,DIRECT는 example.com과 그 하위 도메인에 적용됩니다. 임의 위치의 문자열 포함이 아니라 도메인 접미사 경계를 기준으로 하므로, 이름 어딘가에 example.com이라는 문구가 들어간 관련 없는 도메인이 반드시 매칭되는 것은 아닙니다. 접미사에는 보통 별표나 프로토콜 접두사를 붙이지 않습니다. 이 범위가 넓은 규칙을 정확한 예외 뒤에 두면 api.example.com은 첫 번째 행에 먼저 매칭되고, 같은 접미사에 속한 나머지 대상은 DIRECT를 따릅니다.

위 두 행의 순서를 바꾸면 범위가 넓은 규칙이 api.example.com을 먼저 처리합니다. 뒤에 있는 정확한 규칙이 더 상세하더라도 자동으로 우선권을 얻지는 않습니다. 설정을 검토할 때는 규칙의 의미뿐 아니라 그보다 앞에 적용 범위가 더 넓은 행이 있는지도 살펴보세요. 접미사 규칙은 같은 도메인 체계의 공통 정책을 표현하기에 적합하지만, 해당 체계에 필요한 모든 리소스가 그 접미사 아래에 있다는 뜻은 아닙니다. 외부 리소스와 이동 대상은 별도로 확인해야 합니다.

DOMAIN-KEYWORD: 범위가 넓은 문자열 포함은 신중하게 사용

DOMAIN-KEYWORD는 도메인에 포함된 지정 문자열을 기준으로 매칭하므로, 여러 도메인 체계에서 공통 문자열을 찾아야 할 때 적합합니다. 브랜드 의미로 대상을 식별하거나 도메인 소유자를 확인하지는 않습니다. 예를 들어 example이라는 키워드는 해당 문자열을 포함하는 여러 호스트에 매칭될 수 있어 명확한 접미사 하나보다 범위가 넓은 경우가 많습니다. example.com과 그 하위 도메인만 대상으로 한다면 DOMAIN-SUFFIX를 우선 고려하세요. 범위가 넓은 키워드를 사용하기 전에 잘못 포함될 수 있는 대상을 나열하고 그 적용 범위를 받아들일지 판단하세요.

세 규칙 유형 사이에 ‘정확한 유형이 넓은 유형보다 우선한다’는 고정 순서는 없습니다. Rule 섹션에 적힌 순서가 그대로 적용됩니다. 범위가 가장 좁은 예외를 먼저 배치한 뒤 공통 접미사를 추가하고, 꼭 필요한 경우에만 키워드를 고려하세요. 이 구성은 해석을 쉽게 하기 위한 관리 방식이지, 설정 파서가 강제하는 형식은 아닙니다. 키워드 규칙 하나가 여러 접미사를 이미 포함한다면 같은 정책의 접미사 행을 더 추가하는 일은 유지 관리 부담만 늘릴 수 있습니다.

도메인 정보가 보이지 않으면 원인을 억지로 단정하지 마세요

앱이 IP 주소로 직접 연결하거나 자체 이름 해석 방식을 사용하거나 기록에 도메인 정보가 없는 경우, DOMAIN 계열 규칙이 완전한 호스트 이름을 받는다고 가정할 수 없습니다. 먼저 기록에서 확인할 수 있는 대상을 살펴보고 IP 규칙이 필요한지 판단하세요. 브라우저에서 도메인을 확인했다고 해서 모든 하위 연결에도 같은 정보가 있다고 추론하지 마세요. 도메인 규칙의 매칭 여부는 다른 화면에서 사용자가 무엇을 보았는지가 아니라 연결이 처리 흐름에 들어올 때 어떤 정보를 확보할 수 있었는지에 따라 달라집니다.

도메인 목록을 정리할 때는 규칙 묶음마다 용도와 예외를 적고, 앞선 동일 정책 규칙이 완전히 포함하는 중복 항목은 제거하는 것이 좋습니다. 테스트에는 대상 도메인, 하위 도메인 하나, 매칭되면 안 되는 비슷한 도메인을 최소한 포함하세요. 이를 통해 필요한 연결이 규칙에 포함되었는지, 범위가 지나치게 넓어지지 않았는지 확인할 수 있습니다. 성공한 대상 하나만 테스트해서는 규칙 범위가 올바른지 알 수 없습니다.

규칙마다 참고하는 정보가 다르므로 연결에서 실제로 제공되는 정보부터 확인하세요.

IP-CIDR 및 IP-CIDR6의 네트워크 범위 표현

IP-CIDR은 네트워크 주소와 접두사 길이로 IPv4 주소 범위를 표현하고, IP-CIDR6은 IPv6에 사용합니다. 접두사 길이가 길수록 범위는 작아집니다. IPv4 주소 하나는 /32, IPv6 주소 하나는 /128로 표현할 수 있습니다. 네트워크 범위를 추가하기 전에 해당 범위가 실제로 처리해야 할 대상인지 확인하세요. 주소 하나의 접속 실패만으로 큰 주소 블록 전체에 같은 정책을 적용하지 마세요. 대상이 공유 인프라를 사용하면 범위가 너무 넓어져 원래 요구와 관계없는 서비스에 영향을 줄 수 있습니다.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

앞의 두 행은 일반적인 사설 IPv4 범위를, 세 번째 행은 IPv6 고유 로컬 주소 범위를 보여 줍니다. 이것만으로 모든 로컬 네트워크를 처리할 수 있는 것은 아닙니다. 실제 로컬 네트워크는 다른 사설 대역이나 별도의 주소 체계를 사용할 수 있으므로 기기의 네트워크를 확인해야 합니다. IPv6은 IPv4 규칙을 자동으로 보완하지 않습니다. IPv4 대역을 입력해도 해당 서비스의 IPv6 연결에 같은 정책이 적용된다고 볼 수 없습니다. 같은 도메인의 연결 결과가 때때로 달라진다면 기록에서 주소 계열을 따로 확인하세요.

no-resolve는 추가 이름 해석을 제한하며 대상 주소를 만들어 내지 않습니다

IP 규칙 뒤의 no-resolve는 해당 규칙을 매칭하기 위해 도메인 이름 해석을 추가로 시작하지 않도록 합니다. 대상 주소를 이미 알고 있는 연결을 처리하거나 IP 규칙 묶음에서 불필요한 해석을 미리 시작하지 않도록 할 때 적합합니다. DNS를 완전히 끄거나 모든 도메인이 이후 주소 판단을 건너뛴다는 뜻은 아닙니다. 현재 연결에 도메인만 있고 사용할 수 있는 대상 주소가 없다면 no-resolve가 붙은 IP 규칙으로 매칭되지 않을 수 있으며, 최종 정책은 다른 규칙이 결정합니다.

따라서 로컬 도메인에 DIRECT를 지정할 때 사설 네트워크 범위와 no-resolve만 추가하는 것으로는 충분하지 않을 수 있습니다. 호스트 이름이 로컬 DNS에서만 유효하다면 해당 이름의 해석 방식, 결과를 확인할 수 있는지, 앞선 도메인 규칙이 이미 요청을 처리했는지 함께 점검하세요. no-resolve를 속도를 높이는 일반적인 옵션으로 여기지 마세요. 이 옵션은 매칭 과정에서 추가 해석을 수행할지 바꾸므로 모든 규칙 끝에 기계적으로 추가하기보다 조회 동작을 제어할 필요에 따라 사용해야 합니다.

GEOIP는 주소 분류이지 서비스 소유 관계 판별이 아닙니다

GEOIP,CN,DIRECT는 주소 데이터베이스가 대상 IP를 분류한 결과에 따라 DIRECT를 적용한다는 뜻입니다. 웹사이트에서 사용하는 언어를 식별하거나 도메인 접미사로 판단하지 않으며, 운영 주체나 콘텐츠 저장 위치를 증명하지도 않습니다. 데이터베이스, 실제 대상 주소, 이름 해석 결과에 따라 매칭 여부가 달라집니다. 하나의 도메인이 여러 인프라를 가리킬 수 있고 이후 해석 결과가 바뀌면 주소 분류도 달라질 수 있습니다. 안정적인 정책이 필요한 서비스라면 명확한 도메인 규칙으로 의도를 먼저 표현하고 GEOIP는 범위가 더 넓은 후순위 분류로 사용하는 편이 일반적입니다.

GEOIP를 진단할 때는 이번 연결에서 실제 사용된 주소를 기록하고, 앞선 도메인 규칙이 이미 매칭을 끝냈는지 확인하세요. 대상 주소가 예상한 범위에 있다고 해서 GEOIP 행이 반드시 실행되는 것은 아닙니다. 반대로 GEOIP가 매칭되지 않았다고 바로 데이터베이스 오류로 단정할 수도 없습니다. 연결이 해당 판단 경로에 들어오지 않았을 수 있습니다. 지역별 분류를 정밀한 보안 경계로 사용하지 말고, 특히 인증, 접근 제어, 서버 인증서 검증을 대체하는 용도로 사용하지 마세요.

USER-AGENT의 가시성 범위

[Rule]
# 요청 정보를 매칭에 사용할 수 있는 경우에만 이 조건을 검토
USER-AGENT,ExampleApp*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

USER-AGENT는 요청에서 가져올 수 있는 User-Agent 정보를 매칭합니다. 예시의 별표는 패턴에서 와일드카드로 사용됩니다. 기기에 설치된 앱 이름으로 프로세스를 식별하는 기능이 아니며 앱의 모든 연결을 식별한다고 보장하지 않습니다. 암호화된 요청이나 해당 필드를 포함하지 않는 연결에는 이 규칙에 사용할 정보가 없을 수 있습니다. 문제를 해결할 때는 “앱이 연결을 시작했다”는 사실과 “해당 연결에 매칭 가능한 User-Agent가 포함되어 있다”는 사실을 구분해야 합니다. 앱 이름만 보고 규칙이 매칭되어야 한다고 추론하지 마세요.

여러 조건 유형을 함께 사용하는 파일은 ‘명확한 도메인 예외, 꼭 필요한 요청 정보 조건, 특정 네트워크 범위, 범위가 넓은 주소 분류, FINAL’ 순서로 정리해 볼 수 있지만 최종 순서는 실제 요구에 따라 달라집니다. 조건을 하나 추가할 때마다 어떤 정보에 의존하는지, 정보가 없을 때 어떤 규칙이 처리하는지 설명하세요. 이런 기록은 규칙 수만 세는 것보다 관리에 도움이 되며, 서로 다른 규칙을 같은 단계의 중복 표현으로 오해하지 않게 해 줍니다.

위에서 아래로 확인하고 매칭되면 중단합니다. 더 구체적이라고 자동으로 우선되는 것은 아닙니다.

규칙 이름이 아니라 순서에 따라 판단

Rule 섹션을 읽을 때는 구체적인 요청 하나를 규칙에 대입해 첫 번째 행부터 차례로 확인합니다. 조건이 매칭되면 해당 행에 지정된 정책을 사용하고, 뒤에 있는 일반 규칙으로 다시 분류하지 않습니다. 따라서 앞에 적힌 범위가 넓은 조건이 뒤의 여러 정확한 조건을 가릴 수 있습니다. ‘예외 우선’은 숨겨진 기능이 아니라 공통 규칙 앞에 예외를 배치해 관리자가 만든 결과입니다. 파일을 해석할 때는 적용 범위를 먼저 정리한 뒤 순서를 변경할지 판단하세요.

[Rule]
# 호스트 하나에 대한 예외를 먼저 적용
DOMAIN,api.example.com,PROXY

# 다음으로 도메인 전체에 공통 규칙 적용
DOMAIN-SUFFIX,example.com,DIRECT

# 주소가 확인된 로컬 네트워크 대상
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

# 범위가 넓은 주소 분류
GEOIP,CN,DIRECT

# 나머지 연결에 적용할 최종 정책
FINAL,PROXY

api.example.com은 첫 번째 행에 매칭되므로 접미사 규칙이 정책을 바꾸지 않습니다. static.example.com은 첫 행에 매칭되지 않으므로 접미사 규칙에 따라 DIRECT로 연결됩니다. 주소가 확인된 로컬 IP는 앞의 두 도메인 조건에 해당하지 않을 수 있으며, 그다음 네트워크 범위 규칙에서 처리됩니다. 앞선 조건에 하나도 매칭되지 않은 연결에만 FINAL이 적용됩니다. 각 단계는 조건을 판단하는 과정이지, 여러 경로를 하나씩 시도해 연결 여부를 확인하는 과정이 아닙니다. 정책이 적용된 뒤 발생하는 네트워크 오류는 이후 실행 단계의 문제입니다.

FINAL은 나머지 연결을 처리합니다

FINAL은 ‘가장 중요한 도메인 규칙’이 아니라 앞선 조건에서 분류되지 않은 나머지 연결에 적용되는 최종 정책입니다. FINAL,PROXY는 기본적으로 프록시 경로를 사용하도록 설정하며, FINAL,DIRECT는 기본 직접 연결을 의미합니다. 어느 쪽이 더 나은지는 맥락에 따라 다르므로 앞선 예외 범위와 실제 요구를 함께 고려해야 합니다. FINAL을 변경하면 개별 대상 하나가 아니라 아직 처리되지 않은 전체 범위가 바뀔 수 있으므로, 정확한 도메인 규칙 하나를 추가하는 것보다 영향이 큰 경우가 많습니다.

FINAL은 규칙 목록 맨 아래에 두고 그 뒤에 적용되기를 기대하는 일반 규칙을 추가하지 마세요. 파일 맨 끝에 내용을 추가하기만 하고 앞에 FINAL이 있는지 확인하지 않으면 새 행이 실행되지 않을 수 있습니다. 파일을 병합할 때는 특히 FINAL이 중복되지 않는지 확인하세요. 각각 완성된 두 Rule 섹션을 그대로 이어 붙여도 두 번째 섹션이 원래대로 작동하지는 않습니다. 먼저 기본 정책을 하나로 정한 뒤 두 파일에서 유효한 예외를 정리해 해당 FINAL 앞에 배치하세요.

중복 규칙, 충돌 및 도달할 수 없는 규칙

같은 조건과 같은 정책이 반복되면 보통 읽기만 어려워집니다. 같은 조건에 서로 다른 정책이 지정되면 먼저 나온 행이 적용됩니다. 더 알아채기 어려운 충돌은 적용 범위가 겹치는 경우입니다. 예를 들어 앞선 DOMAIN-SUFFIX가 뒤의 DOMAIN을 포함하거나 넓은 네트워크 범위가 더 작은 범위를 포함할 수 있습니다. 검토할 때 완전히 같은 텍스트만 검색하지 말고 대상 집합이 겹치는지도 비교하세요. 좁은 범위의 예외가 필요하다면 앞쪽으로 옮기고 후순위 규칙과 어떤 관계인지 주석으로 설명하세요.

설정에서 외부 규칙 모음을 참조하는 경우 참조 행도 현재 순서에 포함되는 판단 지점으로 보세요. 별도의 우선순위 체계로 취급하면 안 됩니다. 외부 내용이 바뀌면 매칭 범위가 넓어지거나 좁아져 이후 로컬 행에 전달되는 요청이 달라질 수 있습니다. 업데이트 후 결과가 달라졌다면 로컬 참조 위치와 외부 내용의 변경 사항을 모두 확인하세요. 로컬 파일이 바뀌었는지만 비교하면 실제 매칭 결과를 바꾼 요인을 놓칠 수 있습니다.

반복 가능한 테스트 매트릭스 만들기

순서를 조정하기 전에 최소 네 가지 유형의 테스트 대상을 고르세요. 정확한 예외, 공통 접미사, 주소를 알고 있는 로컬 대상, FINAL에서 처리되어야 할 대상입니다. 각 대상에 예상 매칭 행과 정책을 적은 뒤 새 연결을 하나씩 만들어 검증하세요. 많은 수치를 기록할 필요는 없습니다. 동일한 모드에서 같은 대상의 결과를 설명할 수 있는지가 중요합니다. 새 규칙으로 한 대상은 해결됐지만 정상적으로 작동하던 다른 대상이 바뀌었다면, 파일 끝에 패치를 더 붙이지 말고 적용 범위를 다시 확인하세요.

규칙 순서의 이유는 해당 행 옆의 주석에 남기세요. 특히 범위가 넓은 규칙보다 앞에 있어야 하는 예외를 표시해야 합니다. 파일을 재정렬하거나 병합할 때 이런 설명이 있으면 ‘유형별로 보기 좋게 정리했지만’ 실제 동작은 깨뜨리는 일을 막을 수 있습니다. 규칙 목록의 목적은 보기 좋은 순서가 아니라 예상 요청이 올바른 위치에서 판단을 멈추고, 분류되지 않은 대상이 명확한 최종 경로를 따르게 하는 것입니다.

이름 해석, 라우팅, 요청 재작성은 서로 연관되지만 서로를 대체하지 않습니다.

도메인 이름 해석과 연결 경로를 먼저 구분

DNS는 호스트 이름을 주소로 해석하고 Rule은 연결에 적용할 정책을 결정합니다. 두 요소는 서로의 관찰 결과에 영향을 줄 수 있지만 같은 설정은 아닙니다. 도메인이 특정 경로로 해석된 뒤 규칙에 따라 직접 연결되거나 프록시를 사용할 수 있으며, 연결 방식에 따라 서로 다른 위치에서 이름 해석이 이루어질 수도 있습니다. 문제를 진단할 때는 ‘어떤 주소를 받았는지’와 ‘연결에 어떤 정책을 사용했는지’를 각각 기록하세요. PROXY라고 해서 이름 해석이 반드시 원격에서 이뤄진다고 단정하지 말고, DIRECT라고 해서 모든 이름 해석이 같은 로컬 경로를 따른다고 추론하지도 마세요.

[General]
dns-server = system

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

dns-server = system은 시스템에서 제공하는 DNS 설정을 사용한다는 뜻으로 기본 동작을 설명하는 간단한 출발점입니다. 모든 네트워크 환경에 고정적으로 적용할 답은 아닙니다. 시스템 DNS가 내부 호스트 이름을 해석하지 못한다면 해당 호스트에 DIRECT를 지정해도 올바른 주소가 저절로 생기지 않습니다. 먼저 해당 이름의 해석에 특정 네트워크가 필요한지 확인하고 기기가 그 환경에 연결되어 있는지 점검하세요. 반대로 도메인이 정상적으로 해석되더라도 대상 포트에 접속할 수 있다는 뜻은 아닙니다. 이름 해석 성공은 연결 전 과정의 일부일 뿐입니다.

Host 매핑의 용도와 유지 관리 비용

[Host]
# 문서용 예시 주소이며 실제 서비스 호스트에 연결할 수 없습니다
lab.example.com = 192.0.2.10

[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY

Host 섹션은 지정한 호스트 이름에 명시적인 주소 매핑을 설정할 수 있습니다. 예시의 192.0.2.10은 필드 구성을 보여 주기 위한 문서용 주소입니다. 위의 매핑에는 DIRECT라는 의미가 없으며 실제 정책은 여전히 Rule에서 지정해야 합니다. 실제 주소를 매핑하려면 대상이 예상한 주소인지 확인하고 인증서, 서버의 호스트 이름 인식, 서비스 변경 가능성을 고려하세요. 도메인을 오래된 주소에 고정하면 이름 해석은 안정적으로 보일 수 있지만 서비스가 이전된 뒤에도 요청이 더 이상 유효하지 않은 위치로 향할 수 있습니다.

일시적인 진단에서 이름 해석 요인을 분리하려고 매핑을 사용할 수 있지만, 검증이 끝나면 유지할지 결정하고 그 이유를 기록하세요. 대상이 동적 주소나 부하 분산을 사용하는 경우 정적인 매핑을 장기간 유지하면 기존 연결 조정이 깨질 수 있습니다. 한 번의 이름 해석 결과에서 주소를 복사해 영구적으로 올바른 서비스 주소라고 간주하지 마세요. 인증서 이름이 일치하지 않을 때도 검증을 임의로 끄는 방식으로 문제를 감추면 안 됩니다. 대상 주소, 호스트 이름, 서버 인증서가 원래 서로 일치하는지 확인하세요.

URL Rewrite는 확인 가능한 요청 주소를 처리합니다

[URL Rewrite]
^https://example\.com/old$ https://example.com/new 302

이 예시에서는 정규 표현식으로 전체 주소를 제한하고 302 리디렉션으로 다른 주소를 가리킵니다. 시작의 ^와 끝의 $는 매칭 경계를 제한하며 도메인의 점은 임의의 문자로 해석되지 않도록 백슬래시로 이스케이프합니다. 요청에 쿼리 매개변수나 끝 슬래시가 있으면 이 전체 표현식과 일치하지 않을 수 있습니다. 이는 재작성 실패가 아니라 해당 형식이 애초에 조건에 포함되지 않은 것입니다. 표현식을 작성할 때는 먼저 매칭해야 할 주소 형태를 나열한 다음 경계를 넓힐지 결정하세요.

리디렉션은 원래 연결에 PROXY 또는 DIRECT를 선택하는 것과 다릅니다. 브라우저가 리디렉션을 받으면 새 요청을 보낼 수 있으며, 새 요청은 자체 대상에 따라 다시 라우팅 판단을 거쳐야 합니다. 재작성 후 순환이 발생하면 새 주소가 같은 표현식 또는 다른 표현식에 다시 매칭되는지 확인하세요. 테스트는 범위가 좁고 결과를 쉽게 확인할 수 있는 규칙 하나로 시작하세요. 처음부터 도메인 전체에 범위가 넓은 표현식을 적용하면 어느 리디렉션 단계에서 요청이 바뀌었는지 파악하기 어렵습니다.

암호화된 요청의 가시성 범위를 고려하세요

HTTPS의 전체 경로는 일반적인 네트워크 라우팅 처리에서 직접 드러나지 않는 경우가 많습니다. 설정에 URL Rewrite를 작성했다고 모든 암호화된 요청에 매칭 가능한 전체 URL 정보가 자동으로 제공되는 것은 아닙니다. 처리할 수 있는지는 요청의 가시성과 관련 설정에 따라 달라집니다. 일반적인 도메인 분기를 위해 요청 경로를 읽도록 처리 범위를 넓힐 필요는 없습니다. 이 페이지의 재작성 예시는 섹션 문법을 설명할 뿐이며 규칙을 익히기 위해 추가 인증서 관련 기능을 활성화할 필요가 없습니다. 이런 설정을 모든 연결 문제의 첫 번째 해결책으로 삼아서는 안 됩니다.

이 섹션들을 관리할 때는 캐시와 기존 연결도 고려해야 합니다. 시스템, 앱, 브라우저가 이름 해석 결과, 리디렉션 결과, 연결 상태를 저장할 수 있습니다. 수정 후 새 요청으로 다시 테스트하고 캐시 영향과 설정 미적용을 구분하세요. 앱마다 결과가 다르다면 우선 실제 요청의 도메인, 주소, 프로토콜을 비교하세요. 특정 섹션의 우선순위 차이로 바로 단정하지 마세요. 최종적으로는 이번 연결에서 확인할 수 있는 기록을 기준으로 결과를 설명해야 합니다.

요구 사항을 범위가 좁은 조건으로 표현하고 복구 가능한 방식으로 단계별 병합하세요.

기본 동작을 한 문장으로 먼저 정의

설정을 작성하기 전에 두 가지를 정리하세요. 별도로 지정되지 않은 연결을 어떻게 처리할지, 기본 동작에서 벗어나야 하는 대상은 무엇인지입니다. 첫 번째는 FINAL에 해당하고 두 번째는 예외 집합을 만듭니다. 기본 동작을 한 문장으로 설명할 수 없다면 새 규칙이 필요한지 판단하기도 어렵습니다. 도메인을 잔뜩 모은 뒤 전체 파일의 용도를 거꾸로 추측하지 마세요. 규칙이 많을수록 적용 범위 관계는 복잡해집니다. 서로 다른 파일에서 가져온 내용이라고 유지 관리 비용이 저절로 줄어들지는 않습니다.

[Rule]
# 기본 프록시, 직접 연결은 명확히 지정한 대상에만 적용
DOMAIN,printer.example.com,DIRECT
DOMAIN-SUFFIX,home.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

이 예시는 기본 프록시를 사용하고 지정된 대상은 직접 연결하는 구조입니다. printer.example.com과 home.example.com은 예시 이름이므로 실제 환경에 맞는지 사용자가 확인해야 합니다. 로컬 서비스를 실제로 제공하는 주소는 아닙니다. 기본 직접 연결을 사용하고 일부 도메인에만 프록시를 적용하려면 PROXY 조건을 소수로 지정하고 FINAL을 DIRECT로 변경하세요. 기본 동작이 서로 다른 두 설정 파일을 그대로 합치지 마세요. 한 파일의 예외가 다른 파일에서는 중복되거나 충돌할 수 있습니다.

예외, 공통 규칙 및 차단 대상

[Rule]
# 호스트 하나에 대한 예외를 공통 접미사 규칙보다 먼저 배치
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

이 조합에는 프록시 예외, 거부 예외, 접미사 공통 정책이 함께 포함됩니다. 두 개의 정확한 호스트를 접미사 규칙보다 앞에 둬야 서로 다른 처리 방식을 유지할 수 있습니다. REJECT는 명확히 차단할 대상에 사용해야 하며, 연결이 한 번 느렸다는 이유만으로 추가해서는 안 됩니다. 거부 규칙을 추가한 뒤 페이지 기능이 줄었다면 DNS를 계속 수정하기보다 필요한 API가 차단되었는지 먼저 확인하세요. 규칙이 올바르게 매칭되더라도 규칙에 담긴 서비스 결정이 적절하다는 뜻은 아닙니다. 검증할 때 라우팅과 기능을 모두 확인해야 합니다.

로컬 기기에 직접 연결을 설정하더라도 한 번 본 주소를 모두 장기 규칙으로 추가하지 마세요. 기기가 고정 주소를 사용하는지, 호스트 이름이 안정적인지, 같은 로컬 네트워크에서 접속해야 하는지 먼저 확인하세요. 규칙은 경로만 결정하며 현재 네트워크에 연결되지 않은 기기에 자동으로 접속할 수 있게 만들지는 않습니다. 특정 로컬 네트워크 대역에 의존하는 요구 사항이라면 Wi-Fi를 바꿀 때 주소 구성을 다시 확인하세요. 다른 네트워크에서 같은 주소 범위가 전혀 다른 의미일 수 있습니다.

구독 데이터와 규칙 파일은 별도로 관리

Subscribe로 가져오는 연결 정보와 Config에 저장되는 규칙 설정은 서로 다른 역할을 합니다. 기존 구독을 업데이트하면 서버 이름, 수량, 매개변수가 달라질 수 있습니다. 설정에서 이름으로 연결 대상을 참조한다면 그 참조가 여전히 유효한지 확인하세요. 구독 업데이트가 로컬 정책 참조를 모두 자동으로 수정해 준다고 생각하지 마세요. 규칙 파일 백업만으로 모든 연결 자격 증명이 저장되는 것도 아닙니다. 이전할 때 연결 정보, 현재 설정, 모드 상태를 각각 확인해 세 요소가 다시 함께 작동하는지 검증하세요.

사용자가 보유한 구독 주소, 인증 매개변수, 개인 키는 민감한 정보입니다. 다른 사람에게 문제를 설명할 때는 해당 내용을 가리고 필요한 규칙 조건, 정책 이름, 오류 단계만 남기세요. 예시 파일에도 실제 자격 증명을 포함하지 않아야 합니다. WireGuard 필드와 라우팅 규칙의 역할을 확인하려면 WireGuard 설정 매개변수 안내를 참고하세요. 프로토콜 매개변수는 연결을 설정하는 방식을 정하고 Rule은 어떤 대상이 해당 경로를 사용할지 결정합니다. 두 설정은 서로 대체할 수 없습니다.

병합, 업데이트 및 복구 순서

설정을 병합할 때는 먼저 현재 사용할 수 있는 파일을 백업하고 추가하려는 실제 요구 사항을 나열하세요. Rule 행의 개수만 비교하지 말고 새 내용에 General 설정, Host 덮어쓰기, URL Rewrite, 정책 참조가 포함되는지 확인해야 합니다. 이어서 중복 FINAL을 제거하고 예외를 관련 범위가 넓은 규칙보다 앞에 배치한 다음 참조 대상 이름이 있는지 확인하세요. 관련 규칙을 한 묶음씩 병합하고 저장 및 활성화한 뒤 대표 대상을 테스트하세요. 이상이 생기면 어떤 변경 지점으로 돌아가야 하는지 명확하게 알 수 있습니다.

원격 소스 설정 업데이트는 업데이트 작업이 완료되었는지만 확인하지 말고 변경 사항을 검토해야 합니다. 규칙 순서, 기본 정책, 주소 덮어쓰기의 변화를 비교하고 기존에 로컬에서 유지하던 예외가 남아 있는지 특히 확인하세요. 장기간 직접 관리해야 한다면 용도가 불분명한 고급 필드를 줄이고 중요한 규칙에는 이유를 남기세요. 파일을 이해하기 쉬울수록 문제가 발생했을 때 복구하기 쉽습니다. 유지 관리의 핵심은 규칙 수가 아니라 경계와 검증 기록을 명확히 하는 것입니다.

마지막으로 간결한 기준 설정을 하나 보관해 네트워크 문제와 복잡한 설정 문제를 구분하세요. 이 기준 설정도 사용자가 보유한 서버와 함께 사용해야 하며 독립적인 연결 서비스는 아닙니다. 일상 설정에 문제가 생기면 기준 설정으로 전환해 같은 대상을 비교하세요. 기준 설정에서 정상이라면 복잡한 규칙을 한 묶음씩 되돌리면 됩니다. 이 방식은 파일 전체를 반복해서 가져오는 것보다 원인을 명확히 보여 주며 문제 해결 중 원래 유효했던 설정을 잃는 일도 막아 줍니다.

처리 흐름을 확인한 뒤 같은 대상으로 비교하세요. 한 번 성공한 결과만으로 결론 내리지 마세요.

1단계: 현재 상태와 새 연결 확인

“규칙이 적용되지 않는다”는 문제가 생기면 먼저 기기의 현재 네트워크, Global Routing, 선택된 설정, 연결 대상을 기록한 다음 대상이 명확한 요청을 새로 보내세요. 기존 연결은 연결을 시작할 당시의 상태를 계속 사용할 수 있습니다. 파일만 수정한 뒤 기존 연결을 재사용하는 페이지를 새로고침하고 결론을 내리면 안 됩니다. 연결 스위치가 켜져 있다는 사실은 클라이언트가 해당 작업 상태에 들어갔다는 의미일 뿐입니다. 대상이 예상한 규칙에 따라 처리되었다는 증거는 아닙니다. 버튼이 올바른 위치에 있는지보다 이번 요청의 실제 기록을 확인해야 합니다.

다음으로 테스트 대상을 하나로 제한하세요. 브라우저의 한 페이지가 여러 리소스 요청을 보낼 수 있습니다. 이미지 하나가 성공해도 API 연결까지 성공했다는 뜻은 아니며, API 하나가 실패했다고 도메인 체계 전체가 실패한 것도 아닙니다. 식별하기 쉬운 실패 호스트 하나를 선택해 도메인 또는 IP, 매칭 규칙, 정책, 오류 증상을 기록하세요. 현재 화면에서 특정 정보를 확인할 수 없다면 알 수 없는 항목으로 기록하고, 페이지의 겉모습만 보고 존재하지 않는 매칭 기록을 추측하지 마세요.

2단계: 미매칭, 잘못된 정책, 실행 실패 구분

FINAL에 매칭되었다면 같은 대상을 첫 행부터 다시 확인하세요. 전체 URL을 DOMAIN 값으로 입력하지 않았는지, 도메인 없이 IP만 있는지, no-resolve 때문에 예상한 주소 판단이 이루어지지 않았는지 살펴보세요. 잘못된 정책에 매칭되었다면 그보다 앞에 있는 범위가 넓은 규칙을 먼저 찾으세요. 올바른 정책에 매칭되었는데 연결이 실패했다면 분류와 실행을 나누어 분석해야 합니다. 이때는 정확한 규칙을 계속 앞으로 옮기기보다 선택된 연결 대상을 확인하세요.

3단계: 로컬 네트워크와 기존 서버 비교

Connectivity Test로 보유 중인 서버의 연결 상태를 확인할 수 있지만, 한 번 성공했다고 모든 대상, 프로토콜, 실제 서비스가 정상이라는 뜻은 아닙니다. 테스트에 실패해도 테스트 과정이 실제 서비스 요청과 대상 및 처리 경로가 다를 수 있으므로 Rule 문제라고 단정할 수 없습니다. 결과를 보조 증거로 활용하고 실제 요청의 실패 단계를 함께 판단하세요. 대상 이름 해석 실패인지, 원격 연결 수립 실패인지, 연결 수립 후 서비스 응답 이상인지에 따라 확인할 필드가 달라집니다.

Config와 Proxy의 결과가 다르면 같은 기존 연결 대상을 고정한 뒤 대상의 이름 해석과 매칭 기록을 비교하세요. Direct에서도 실패한다면 로컬 네트워크에서 해당 대상에 정상적으로 접속할 수 있는지 확인하고, 특히 로컬 네트워크 호스트와 내부 이름의 환경 제약을 살펴보세요. 완전히 접속할 수 없는 것이 아니라 속도만 느려졌다면 로컬 Wi-Fi 또는 셀룰러 네트워크, 전송 매개변수, 실제 경로를 나누어 확인하세요. 연결 속도 단계별 문제 해결을 참고하고, 원인을 찾는 대신 PROXY 적용 범위만 계속 넓히지 마세요.

4단계: 변수를 되돌리고 대표 대상을 다시 테스트

최근 변경한 항목을 한 묶음씩 되돌리고 같은 대상으로 연결을 새로 만드세요. 범위가 넓은 규칙을 제거한 뒤 정상으로 돌아왔다면 어떤 대상을 포함했는지 더 확인해야 합니다. 같은 유형의 규칙을 모두 영구적으로 삭제해서는 안 됩니다. URL Rewrite를 되돌린 뒤 리디렉션이 정상으로 돌아왔다면 서버를 계속 변경하지 말고 표현식과 리디렉션 순환을 확인하세요. 간결한 설정으로 전환해도 문제가 같다면 복잡한 규칙이 주원인이 아닐 수 있습니다. 네트워크, 이름 해석, 기존 연결 매개변수 쪽으로 조사 범위를 옮기세요.

[Rule]
# 대상 하나의 분류를 임시로 확인하기 위한 설정이며 일상 설정 전체를 대신하지 않습니다
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

이 간결한 설정은 이미 알고 있는 대상이 예상한 정책에 따라 처리되는지 확인할 때 적합합니다. 실제 테스트에 사용할 도메인으로 바꾸고 복구할 수 있는 기존 설정을 보관하세요. 검증을 마친 뒤 일상 파일로 돌아가는 것을 잊지 마세요. 그렇지 않으면 다른 연결에도 테스트 파일의 FINAL이 적용됩니다. 임시 설정의 이름과 용도도 명확히 정해 두어 며칠 뒤 현재 어떤 파일을 사용 중인지 잊지 않도록 하세요. 테스트가 성공하면 기존 규칙을 한 묶음씩 복원하며 다시 검증해 차이를 만든 최소 변경 사항을 찾아내세요.

구매, 재설치, 구매 항목 복원 중 문제가 발생했다면 먼저 구매 항목 복원 안내를 확인하세요. 이 과정은 Rule 매칭과 관련이 없습니다. Shadowrocket은 App Store에서만 받을 수 있으며 iPhone과 iPad를 주요 사용 기기로 합니다. 시스템 요구 사항과 호환성은 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 복원 후에도 사용자 본인의 연결 정보와 설정을 확인해야 합니다. 구매 내역만으로 모든 서비스 환경이 복원되지는 않습니다.

최종 결론은 검증 가능한 사실로 기록하세요. 예를 들어 “이 도메인이 앞선 접미사 규칙에 매칭되어 정확한 예외로 옮긴 뒤 PROXY로 변경됨”처럼 작성하고, “설정이 고쳐짐”이라고 뭉뚱그리지 마세요. 원인과 결과를 기록해 두면 다음에 비슷한 현상이 생겼을 때 같은 문제인지 빠르게 판단할 수 있습니다. 전체 사용 과정을 다시 확인하려면 빠른 시작 가이드로 돌아가세요. 특정 규칙을 확인하려면 이 페이지의 목차에서 관련 섹션을 찾아보세요. 항상 실제 입력, 실제 매칭, 실제 실행 결과를 기준으로 판단해야 합니다.