Shadowrocket 규칙 및 설정 가이드

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

Subscribe와 Config 구분하기

Subscribe는 일반적으로 서버 목록을 업데이트하고, Config는 연결 동작과 요청 분할을 관리합니다. 두 항목은 서로 다른 기존 출처에서 가져올 수 있습니다. 서버 목록에서 노드를 선택할 수 있다는 것은 연결 매개변수가 클라이언트에 들어왔다는 뜻일 뿐, 특정 규칙 파일이 활성화되었다는 의미는 아닙니다. 반대로 내용이 완전한 설정을 가져왔더라도 그 안에서 참조하는 프록시 출구가 반드시 작동하는 것은 아닙니다. 편집을 시작하기 전에 Home에서 선택한 서버, Config에서 사용 중인 파일, Global Routing의 현재 모드를 각각 확인하세요. 서로 다른 세 가지 상태를 하나의 스위치처럼 혼동하지 않도록 주의해야 합니다.

설정 파일은 대괄호 안의 섹션 이름으로 역할을 구분합니다. General에는 전체 연결 및 이름 확인 설정을, Rule에는 순서대로 적용되는 분할 규칙을, Host에는 지정된 호스트 이름의 주소 매핑을, URL Rewrite에는 조건에 맞는 요청 주소의 재작성을 입력합니다. 섹션 이름은 일반 설명 문구가 아니므로 대괄호 안에 한국어 제목을 넣어 대신할 수 없습니다. 각 설정 항목은 해당 섹션 아래에 작성해야 합니다. 예를 들어 FINAL은 Rule에 속하는 규칙입니다. 섹션 표시를 생략하고 General 설정 뒤에 이어 쓰면 파싱 결과가 예상과 달라질 수 있습니다.

# 구조 예시: 섹션별 역할만 표시
[General]
dns-server = system

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

[Host]
intranet.example.com = 192.0.2.10

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

복사본으로 되돌릴 수 있는 수정 절차 만들기

위 예시는 모든 네트워크에서 사용할 수 있는 완성 설정이 아닙니다. 특히 Host 매핑에는 문서 전용 주소가 있으므로 실제로 사용하기 전에 해당 예시 항목을 삭제하거나 사용자가 직접 관리하는 내부 주소로 바꿔야 합니다. 기존 파일을 편집할 때는 먼저 정상 작동하는 복사본을 저장하고, 선택한 파일 이름과 모드를 기록한 다음 테스트 파일을 별도로 만드세요. 매번 한 종류의 동작만 조정하는 것이 좋습니다. 예를 들어 DOMAIN 규칙 하나를 추가해 적용 여부를 확인한 후 DNS를 조정하세요. 섹션 네 곳을 한꺼번에 수정하면 화면이 정상으로 돌아와도 어떤 변경이 영향을 주었는지 알기 어렵습니다.

일반 텍스트 설정에는 영문 문장 부호를 사용합니다. 등호, 쉼표, 대괄호를 전각 문자로 바꾸면 안 됩니다. 문서 편집기에서 복사할 때 자동으로 바뀐 따옴표나 눈에 보이지 않는 공백도 확인하세요. 한 줄 주석은 샵 기호로 시작할 수 있으며, 설명은 별도 줄에 적는 편이 좋습니다. 긴 한국어 설명을 규칙 정책 뒤에 바로 붙이지 마세요. 파일 확장자만으로 내용의 유효성을 판단할 수 없습니다. 임의의 텍스트 파일 이름을 .conf로 바꿔도 문법이 완성되지는 않습니다. 저장한 뒤 Config로 돌아가 파일이 정상적으로 불러와지는지, 방금 수정한 복사본이 선택되어 있는지 확인하세요.

로컬 편집과 원격 업데이트의 관계

원격 설정은 다음 업데이트 때 로컬 내용을 덮어쓸 수 있습니다. 개인 규칙을 장기간 유지하려면 현재 파일이 원격 업데이트로 관리되는지 먼저 확인한 뒤 로컬 복사본이나 앱에서 제공하는 편집 방법을 선택하세요. 방금 저장했다는 사실만으로 변경 사항이 계속 유지된다고 판단하지 마세요. 파일을 다시 열어 규칙이 예상한 위치에 남아 있는지 확인하고, 업데이트 후에도 다시 검증하는 편이 확실합니다. 구독 링크에는 접근 자격 증명이 포함될 수 있으므로 공개 메모나 문제 화면 캡처에 기록하지 마세요. 다른 사람에게 문제를 설명할 때는 규칙 유형과 오류 현상만 남기면 됩니다.

이 페이지에 없는 섹션이나 항목이 파일에 있더라도 예시와 맞추려고 섹션 전체를 삭제하지 마세요. 기존 설정은 로컬 네트워크, 이름 확인 또는 특정 요청 처리를 담당할 수 있습니다. 해당 항목을 먼저 이해한 뒤 유지 여부를 판단하고, 확실하지 않다면 원본 복사본에서 테스트하세요. 이 페이지는 섹션의 역할을 확인하고, 구체적인 규칙을 살펴본 다음, 정책과 매칭 순서를 확인하는 순서로 참고하면 됩니다. 이 순서대로 점검하면 문법상 불러올 수 있는지와 실제 동작이 올바른지를 따로 확인할 수 있어, 파일이 완전해 보인다는 이유만으로 설정이 유효하다고 단정하지 않게 됩니다.

02 · General, DNS 및 연결 전제 조건

전역 설정은 분할 규칙을 대신하지 않습니다

General의 항목은 연결 및 이름 확인의 기본 동작에 영향을 주고, Rule은 조건에 맞는 요청에 어떤 정책을 적용할지 결정합니다. 두 항목은 서로 관련이 있지만 대체할 수는 없습니다. 예를 들어 DNS 서버를 변경하면 대상 도메인이 확인되는 주소가 달라질 수는 있지만, 명시적으로 지정된 DOMAIN 규칙의 정책이 PROXY에서 DIRECT로 바뀌지는 않습니다. 반대로 Rule을 수정해도 철자가 틀린 서버 주소를 고칠 수는 없습니다. 문제를 확인할 때는 대상 도메인 확인, 대상 요청의 분할 처리, 프록시 서버 연결을 각각 별도로 검증하세요. 접속할 수 없는 모든 상황을 “규칙이 작동하지 않는다”는 하나의 원인으로 묶지 마세요.

[General]
# 시스템에서 제공하는 DNS 사용
dns-server = system

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

이 설정은 example.com 전체 도메인에 해당하는 요청을 PROXY로 보내고, 나머지 미일치 요청은 DIRECT로 처리합니다. dns-server의 system 값은 시스템에서 제공하는 DNS 설정을 사용한다는 의미이지, 현재 네트워크에서 모든 도메인이 제대로 확인된다는 보장은 아닙니다. 네트워크를 바꾼 뒤 동작이 달라지면 먼저 시스템 네트워크와 이름 확인 조건을 점검한 다음 앱 설정을 살펴보세요. 출처를 모르는 설정의 DNS 주소를 여러 개 그대로 복사하지 마세요. 이름 확인 서비스에 접속할 수 있는지, 응답이 올바른지, 현재 네트워크에 적합한지 확인해야 합니다. 항목이 많다고 조회가 더 안정적인 것은 아닙니다.

도메인 규칙과 IP 규칙이 확인하는 정보는 다릅니다

DOMAIN과 DOMAIN-SUFFIX는 호스트 이름을, IP-CIDR과 GEOIP는 주소를 기준으로 판단합니다. 요청에 도메인 정보가 유지되는 경우 앞쪽의 도메인 규칙이 먼저 출구를 결정할 수 있습니다. 규칙이 주소를 필요로 하는데 현재 도메인만 있다면 주소 확인이 발생할 수 있습니다. 확인된 주소는 네트워크, 캐시 및 서버 측 트래픽 분산에 따라 달라질 수 있으므로 같은 도메인이 매번 같은 주소 범위 규칙에 걸린다고 볼 수 없습니다. 진단 기록에는 요청 도메인과 실제 대상 주소를 함께 확인하세요. 브라우저 주소 표시줄만으로 연결 정보를 전부 알 수는 없습니다.

IP-CIDR에서 no-resolve를 사용하는 것은 해당 주소 규칙을 위해 도메인 조회를 능동적으로 수행하지 않도록 하는 것입니다. “클라이언트 전체에서 DNS를 사용하지 않는다”는 뜻도 아니고 모든 도메인을 무시한다는 의미도 아닙니다. 요청에 판단에 쓸 수 있는 주소가 이미 있다면 해당 네트워크 대역 규칙에 매칭될 수 있습니다. 도메인만 있고 적절한 주소가 없다면 뒤쪽 규칙을 계속 확인해야 합니다. 이 매개변수의 사용 여부는 규칙이 판단에 참여할 단계를 고려해 정해야 합니다. 모든 IP 규칙에 붙여야 하는 성능 옵션으로 취급하지 마세요.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
FINAL,PROXY

IPv6, 로컬 네트워크 및 캐시의 범위

IPv4 네트워크 대역 규칙은 IPv6 주소에 자동으로 적용되지 않습니다. 네트워크와 대상 서비스가 IPv6를 사용한다면 필요한 IP-CIDR6 규칙이 있는지 확인하고, 현재 연결 설정에서 어떤 주소 경로를 허용하는지도 확인하세요. 특정 주소 계열을 단순히 끄면 증상이 일시적으로 달라질 수 있지만, 문제의 원인이 해결되었다는 뜻은 아닙니다. 로컬 네트워크 장치도 모두 호스트 이름으로 접속할 수 있는 것은 아닙니다. 일부는 로컬 장치 검색, 일부는 고정 주소, 일부는 다른 포트에서 대기하는 서비스에 의존합니다. 먼저 대상 장치가 같은 네트워크에 있는지 확인한 다음 분할 규칙이 관련 있는지 판단하세요.

DNS 또는 Host를 수정해도 이름 확인 캐시와 이미 연결된 세션 때문에 테스트 결과가 늦게 반영될 수 있습니다. 이때는 새 요청을 보내고, 필요하면 다시 연결한 뒤 새로운 진단 기록을 확인하세요. 이전 페이지가 즉시 바뀌지 않는다고 설정을 계속 추가하지 마세요. 기존 설정의 ipv6, bypass-system 같은 항목은 앱 내 설명을 참고해 적용 범위를 파악하세요. 필드 이름만 보고 기능을 추측하지 않는 것이 좋습니다. 특히 시스템 서비스나 로컬 네트워크 처리는 운영체제의 네트워크 경로에도 영향을 받을 수 있습니다.

“도메인으로 접속할 수 없지만 주소를 직접 입력하면 연결된다”고 해서 곧바로 Host 규칙을 써야 하는 것은 아닙니다. 많은 서비스는 올바른 Host 요청 헤더, TLS 인증서 이름 및 서버 측 라우팅에 의존하므로 주소로 직접 접속하면 원래 실패할 수 있습니다. 이름 확인 여부, 연결 성립 여부, 인증서 검증 여부를 각각 기록한 뒤 다음 조치를 결정하세요. 다른 사례는 FAQ의 규칙 및 문제 해결을 참고할 수 있습니다. 사용 중인 설정은 유지하고 테스트 복사본에서만 이름 확인 항목을 바꾸는 것이 네트워크가 복구된 뒤 숨은 오류가 남지 않도록 하는 기본 방법입니다.

03 · Rule 유형과 매개변수 의미

규칙은 조건 다음에 정책을 씁니다

일반적인 규칙은 “유형, 매칭 값, 정책” 순서로 작성하며 각 필드는 영문 쉼표로 구분합니다. 유형에 따라 뒤에 오는 값의 해석이 달라집니다. 같은 example.com이라도 DOMAIN 뒤에 쓰면 완전한 도메인이고, DOMAIN-SUFFIX 뒤에 쓰면 도메인 접미사입니다. 정책은 조건에 일치한 뒤의 처리 방법이며 매칭 조건에 포함되지 않습니다. FINAL은 예외적인 기본 처리 규칙이므로 도메인이나 주소 매개변수가 필요하지 않습니다. 따라서 FINAL,PROXY로 작성합니다. 세 번째 필드를 기계적으로 추가하면 오히려 의미가 불분명해집니다.

세 가지 도메인 규칙의 선택 방법

DOMAIN,api.example.com,PROXY는 api.example.com에만 적용됩니다. www.example.com이나 example.com은 자동으로 포함되지 않습니다. 동일 사이트의 루트 도메인과 하위 도메인에 같은 정책을 적용하려면 DOMAIN-SUFFIX,example.com,PROXY가 더 적합합니다. 접미사 매칭은 도메인 계층의 경계를 기준으로 하므로 임의의 문자열 끝부분을 검색하는 것으로 이해하면 안 됩니다. 매칭 값에는 https://, 포트, 경로 또는 쿼리 매개변수를 포함하지 마세요. 이는 도메인의 일부가 아니므로 넣어도 기대한 대로 매칭되지 않는 경우가 많습니다.

DOMAIN-KEYWORD,example,PROXY는 도메인에 example이라는 문자열이 있는지 확인합니다. example.com에 속하지 않는 다른 호스트 이름까지 포함할 수 있으므로 브랜드 일부만 보고 전체 사이트를 분할 처리하는 방법으로는 적합하지 않습니다. 경계가 명확한 DOMAIN 또는 DOMAIN-SUFFIX를 우선 사용하고, 문자열 조건이 꼭 필요한 경우에만 DOMAIN-KEYWORD를 선택하세요. ads라는 키워드가 정확한 광고 목록을 뜻하는 것도 아닙니다. 정상적인 서비스 도메인과 매칭될 수 있으므로 REJECT에 사용하려면 실제 요청을 먼저 확인해 정상 콘텐츠까지 차단하지 않도록 하세요.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
DOMAIN-KEYWORD,tracking,REJECT
GEOIP,CN,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
USER-AGENT,ExampleClient*,PROXY
FINAL,PROXY

주소, 지역 및 요청 헤더 규칙의 한계

GEOIP,CN,DIRECT는 대상 IP의 지역 분류에 따라 정책을 정합니다. 웹페이지 언어, 사이트 운영 회사의 소재지 또는 도메인 접미사를 기준으로 판단하지 않습니다. 콘텐츠 전송 네트워크를 사용하는 사이트는 지역에 따라 다른 주소를 반환할 수 있으며, 주소 데이터베이스에도 업데이트 시점과 식별 범위의 한계가 있습니다. 특정 도메인의 출구를 안정적으로 지정해야 한다면 GEOIP보다 앞에 명시적인 도메인 규칙을 두세요. IP-CIDR에서 슬래시 뒤 숫자는 접두사 길이이며, 숫자가 클수록 일반적으로 포함 범위가 좁습니다. IPv4 주소 하나는 /32로 지정할 수 있습니다. 호스트 포트를 주소 뒤에 붙여 네트워크 대역처럼 쓰면 안 됩니다.

USER-AGENT는 확인 가능한 요청 헤더 내용을 대상으로 하며, “특정 앱 선택”을 위한 범용 기능은 아닙니다. 암호화된 트래픽의 요청 헤더는 일반적으로 직접 확인할 수 없으므로 USER-AGENT 규칙 하나가 모든 HTTPS 요청에 적용되리라 기대하면 안 됩니다. 이 규칙을 위해 임의로 복호화 범위를 넓혀서도 안 됩니다. 예시의 별표는 매칭 패턴의 일부이고 ExampleClient는 설명용 이름일 뿐 실제 앱을 가리키지 않습니다. 여러 앱이 같은 요청 헤더를 공유하거나 한 앱이 요청마다 다른 값을 사용할 수도 있으므로 실제 대상 도메인을 확인하는 일을 대신할 수 없습니다.

규칙 표는 실제 필요에 맞춰 간결하게 유지하세요. 전체 호스트 이름 하나만 프록시로 보내면 되는 경우 처음부터 범위가 넓은 키워드, 지역 전체 및 큰 네트워크 대역을 추가할 필요가 없습니다. 반대로 한 사이트의 모든 하위 도메인을 제어하려면 현재 확인된 호스트 이름을 일일이 나열할 필요도 없습니다. 최소한의 조건으로 예상 동작을 재현한 뒤 범위를 넓힐지 결정하세요. 익숙하지 않은 키워드는 용어 매뉴얼을 참고하되, 최종적으로는 규칙 이름만 보고 효과를 추측하지 말고 현재 요청이 실제로 매칭되는지 확인해야 합니다.

04 · PROXY, DIRECT, REJECT 및 모드

규칙 정책과 Global Routing은 서로 다른 선택 단계입니다

PROXY는 매칭된 요청을 현재 프록시 출구로 보내고, DIRECT는 대상에 직접 연결하며, REJECT는 요청을 거부합니다. 이 세 정책이 각각 별도의 서버 설정을 의미하는 것은 아니며, 설정이 PROXY라는 노드를 자동으로 만들지도 않습니다. PROXY를 사용하기 전에 사용자가 보유한 서버 정보를 올바르게 가져왔는지 확인하고 Home에서 적절한 출구를 선택하세요. 현재 파일에서 사용자 지정 정책 그룹 이름을 사용한다면 설정에 해당 이름이 정의되어 있고 철자가 일치하는지, 그룹에 사용할 수 있는 출구가 있는지도 확인해야 합니다.

Config 모드는 Rule의 분할 처리를 검증하는 기본 환경입니다. Proxy와 Direct 모드는 연결 경로를 비교하는 데 도움이 되지만 특정 Rule의 순서가 올바르다는 점을 증명하지는 않습니다. 운영체제 서비스, 로컬 네트워크 및 앱의 실제 설정에도 별도의 처리 범위가 있을 수 있으므로 모드 이름이 기기의 모든 트래픽을 제한 없이 포괄한다고 이해하면 안 됩니다. 테스트를 위해 모드를 바꿀 때는 원래 설정을 기록하세요. 테스트가 끝나면 Config로 복원하고 새 요청으로 규칙 동작을 확인해 이후 판단이 잘못되지 않도록 하세요.

DIRECT는 “클라이언트 사용 중지”가 아닙니다

DIRECT 규칙은 대상 요청에 직접 연결 정책을 적용한다는 뜻이지, Shadowrocket을 끄거나 설정 파일의 나머지 내용을 모두 무효화한다는 의미가 아닙니다. 클라이언트는 다른 요청을 처리하거나 이름을 확인하고 진단 정보를 기록할 수 있습니다. 로컬 네트워크 주소, 내부 서비스 또는 원래 직접 접속이 정상인 도메인에는 더 구체적인 DIRECT 조건을 지정할 수 있습니다. 직접 연결의 성공 여부는 현재 네트워크의 라우팅, 방화벽 및 대상 서비스에 달려 있습니다. DIRECT를 모든 연결 제한을 우회하는 해결책으로 취급하지 마세요.

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

이 예시는 intranet.example.com을 접미사 규칙 앞에 예외로 두므로 직접 연결하고, example.com의 다른 호스트 이름은 PROXY를 사용할 수 있습니다. blocked.example.org는 명시적으로 거부됩니다. 마지막 줄의 FINAL,DIRECT는 나머지 요청을 직접 연결한다는 의미이며, 앞선 규칙에 이미 매칭된 요청이 마지막 줄로 다시 돌아온다는 뜻은 아닙니다. 설정을 읽을 때 각 줄을 독립적인 판단으로 보고, 조건과 정책을 먼저 확인한 다음 파일 내 위치를 고려해 실제 적용 범위를 파악하세요.

REJECT 적용과 연결 실패 구분하기

REJECT는 요청을 능동적으로 거부하는 정책이지 “프록시 연결에 실패하면 자동으로 직접 연결한다”는 뜻이 아닙니다. 의도적으로 대상을 거부하면 페이지가 비거나 리소스가 일부 로드되지 않거나 앱에 네트워크 오류가 표시되는 것이 예상된 결과일 수 있습니다. 사용하기 전에 해당 대상을 차단해도 되는지, 로그인·이미지·API 등의 다른 기능을 담당하지 않는지 확인하세요. REJECT 규칙을 삭제한 뒤 페이지가 정상으로 돌아왔다면 매칭 조건을 더 좁혀 보세요. 사이트의 모든 요청이 반드시 프록시를 거쳐야 한다고 곧바로 판단하면 안 됩니다. 키워드 범위가 넓을수록 연쇄적인 영향을 줄 가능성이 큽니다.

PROXY 경로가 실패해도 FINAL을 곧바로 DIRECT로 바꾸지 마세요. 서버 주소 확인, 포트 연결, 프로토콜 인증 또는 대상 접속 중 어느 단계에서든 문제가 생길 수 있습니다. 기본 처리 정책을 바꾸면 미매칭 요청 전체에 영향을 주어 원래 문제를 오히려 가릴 수 있습니다. 먼저 Connectivity Test나 명확한 대상 요청으로 현재 출구를 사용할 수 있는지 확인한 뒤 사용자가 보유한 매개변수를 점검하세요. 연결 테스트 결과와 특정 사이트에 접속할 수 있는지는 서로 다른 문제입니다. 한 번 테스트를 통과했다고 모든 대상 요청이 성공한다고 단정할 수 없습니다.

On Demand는 연결을 언제 시작하거나 복원할지 결정하는 기능이지 어떤 도메인이 매칭되는지를 정하지 않습니다. Global Routing 및 Rule과는 역할이 다릅니다. 연결이 성립하지 않으면 연결 상태와 주문형 조건을 먼저 확인하고, 연결은 되었지만 예상한 출구를 사용하지 않으면 분할 규칙을 확인하세요. 사용자 지정 정책 그룹에는 추가 선택 단계가 있을 수 있으므로 “현재 모드—매칭 규칙—지정된 정책—실제 출구” 순서로 점검해야 합니다. 모드에 대한 자세한 내용은 프록시 모드에서 확인하세요. 연결을 반복해서 켜고 끄는 것으로 정책 흐름 점검을 대신하지 마세요.

05 · 매칭 순서, 우선순위 및 기본 처리

먼저 매칭된 규칙이 적용되며 규칙 이름으로 자동 정렬되지 않습니다

Rule의 일반 규칙은 파일에 적힌 순서대로 위에서 아래로 판단합니다. 앞에서 이미 매칭된 요청은 보통 뒤에 있는 더 구체적인 규칙을 기다리지 않습니다. “더 정확해 보인다”는 이유로 DOMAIN이 DOMAIN-SUFFIX보다 자동으로 높은 우선순위를 얻지 않으며, IP-CIDR도 GEOIP보다 본래 우선하지 않습니다. 우선순위는 무엇보다 규칙의 위치에서 결정됩니다. 규칙을 구성할 때는 명확한 예외를 먼저 두고, 일반적인 범위 규칙을 뒤에 배치한 다음 마지막에 기본 처리 규칙을 둡니다. 읽기 쉽고 나중에 규칙을 추가할 때 충돌도 줄일 수 있습니다.

[Rule]
# 특정 호스트를 먼저 예외로 처리
DOMAIN,api.example.com,DIRECT
# 같은 사이트의 나머지 요청은 프록시 사용
DOMAIN-SUFFIX,example.com,PROXY
# 미매칭 요청은 직접 연결
FINAL,DIRECT

이 순서에서는 api.example.com이 첫 번째 줄에서 DIRECT로 처리됩니다. www.example.com은 첫 번째 조건에 맞지 않지만 두 번째 줄에 매칭되어 PROXY를 사용합니다. 두 줄의 순서를 바꾸면 api.example.com이 먼저 접미사 범위에 포함되므로 직접 연결 예외가 적용되기 어렵습니다. 우선순위를 테스트하려면 두 조건에 모두 해당하는 대상을 선택해야 순서가 실제로 차이를 만든다는 점을 확인할 수 있습니다. 서로 겹치지 않는 도메인 두 개만 방문해서는 규칙 간 적용 관계를 검증할 수 없습니다.

FINAL은 뒤로 계속 넘겨 적용되는 일반 조건이 아닙니다

FINAL은 앞선 모든 규칙에 매칭되지 않은 요청을 처리하며 일반적으로 Rule의 마지막 항목이어야 합니다. 중간에 두면 뒤에 있는 일반 규칙이 나머지 요청을 처리할 기회를 잃습니다. 파일 마지막에 새 규칙을 추가할 때 FINAL 뒤에 작성하지 않았는지 특히 확인하세요. FINAL을 여러 개 작성해도 상황에 따라 자동으로 바뀌는 기본 처리 방식이 만들어지지 않습니다. 서로 다른 범위에 다른 정책이 필요하다면 기본 처리 규칙을 반복해 모호한 요구를 표현하지 말고 각 범위의 조건을 먼저 명확히 하세요.

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시에서는 도메인 예외를 주소 분류 규칙보다 앞에 둡니다. 따라서 example.com이 GEOIP에 매칭될 수 있는 주소로 확인되더라도 앞에서 이미 매칭된 요청에는 도메인 규칙이 적용됩니다. 도메인 매칭에 필요한 정보가 요청에 없다면 주소 조건을 이어서 확인해야 합니다. 이런 차이를 규칙이 무작위로 작동하지 않는 것으로 오해하지 마세요. 적용 가능한 정보는 요청이 처리 흐름에 들어올 때 무엇을 포함하고 있는지에 따라 달라집니다. 순서 문제와 조건 식별 문제를 구분하려면 호스트 이름, 대상 주소, 매칭된 규칙 행 및 최종 정책을 함께 기록하세요.

중복, 범위 중첩 및 원격 내용의 영향

중복 규칙이 반드시 문법 오류를 일으키는 것은 아니지만 관리 부담을 늘립니다. 같은 DOMAIN-SUFFIX를 앞에서는 PROXY, 뒤에서는 DIRECT로 지정하면 뒤의 규칙이 생각한 대로 덮어쓰지 못하는 경우가 많습니다. 관리하기 전에 같은 도메인을 검색해 더 넓은 접미사나 키워드 규칙이 이미 있는지, 앞선 주소 규칙이 먼저 매칭되는지 확인하세요. 중복 항목을 삭제하기 전에 원본 복사본을 보관하고 필요한 예외가 포함되어 있지 않은지 확인해야 합니다. 정리의 목적은 단순히 줄 수를 줄이는 것이 아니라 각 규칙의 역할을 설명할 수 있게 하는 것입니다.

기존 설정에서 외부 규칙 내용을 참조하는 경우 주 설정 파일에서 해당 항목이 놓인 위치도 확인해야 합니다. 외부 목록의 내용만 볼 것이 아니라 언제 매칭 판단에 참여하는지, 어떤 정책으로 처리되는지, 업데이트 후 범위가 바뀌는지도 확인하세요. 아직 이해하지 못한 참조를 이름만 보고 “우선순위가 더 높을 것”이라고 판단하지 마세요. 이 페이지의 독립된 예시를 로컬 테스트 복사본에서 먼저 검증한 뒤 복잡한 기존 설정과 항목별로 비교할 수 있습니다. 확인 없이 알 수 없는 계층에 예시를 그대로 끼워 넣는 것은 권장하지 않습니다.

매칭 순서 테스트에는 규칙이 많을 필요가 없습니다. 예외 규칙 하나, 범위 규칙 하나, FINAL 하나면 충분합니다. 세 가지 동작을 확인한 뒤 나머지 항목을 몇 개씩 복원하세요. 항목을 추가할 때마다 같은 테스트 대상을 방문하고 새 연결로 기록을 확인하면 어떤 항목이 범위 충돌을 일으켰는지 정확히 찾을 수 있습니다. Proxy로 전환해야만 접속되고 Config에서는 안 된다면 앱을 먼저 재설치하지 말고 매칭된 정책부터 확인하세요. 일부 사이트만 지정하는 전체 설정은 DOMAIN-SUFFIX 규칙 작성법에서 확인할 수 있습니다.

06 · Host 및 URL Rewrite의 적용 범위

Host는 이름 확인 결과를 바꾸며 연결 출구를 직접 선택하지 않습니다

Host 섹션은 호스트 이름에 대응하는 주소를 지정합니다. “이 이름이 어떤 주소로 확인되는가”를 다루며 “어떤 정책으로 연결하는가”를 정하지는 않습니다. 예를 들어 내부 서비스가 사용자가 관리하는 주소를 고정으로 사용해야 한다면 Host에 명시적으로 매핑하고, Rule에서는 필요에 따라 DIRECT를 선택할 수 있습니다. 두 섹션의 역할을 따로 이해해야 합니다. Host 매핑만으로 요청이 직접 연결되는 것은 아니며, DIRECT만으로 올바른 내부 이름 확인 설정이 자동으로 채워지는 것도 아닙니다. 매핑 주소가 실제 대상 서비스와 일치하지 않으면 규칙을 아무리 정확히 작성해도 잘못된 대상에 연결됩니다.

[Host]
intranet.example.com = 192.0.2.10

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

192.0.2.10은 문서 전용 주소입니다. 이 내용은 문법 설명을 위한 것이며 내부 서비스에 그대로 사용해서는 안 됩니다. 실제로 입력하기 전에 사용자의 네트워크 관리자나 서비스 설정 기록에서 주소와 포트를 확인하세요. 서비스 주소가 네트워크에 따라 바뀐다면 고정 Host 설정으로 한 네트워크에서는 접속되고 다른 네트워크에서는 실패할 수 있습니다. 서비스가 여러 주소를 사용해 트래픽을 분산하는 경우 단일 주소 고정이 장애 대응을 방해할 수도 있습니다. 정적 매핑을 이름 확인 문제 진단의 대체 수단으로 장기간 사용하지 말고, 출처를 모르는 메모에서 특정 사이트의 오래된 주소를 복사하지 마세요.

매핑은 TLS 이름이나 서버 설정을 바꾸지 않습니다

HTTPS에서 도메인으로 접속할 때 연결 주소와 인증서 검증에 사용하는 이름은 서로 다른 개념입니다. Host는 연결할 주소를 바꿀 수 있지만 서버는 해당 도메인에 적합한 인증서와 응답을 제공해야 합니다. 매핑한 뒤 인증서 오류가 발생하더라도 검증을 무시해 설정이 올바르다고 판단하면 안 됩니다. 대상 서비스가 해당 도메인을 실제로 지원하는지와 서버 측 사이트 연결 설정이 올바른지 먼저 확인하세요. 같은 주소에서 여러 사이트를 운영할 수 있으므로 주소에 연결된다는 사실만으로 원하는 도메인 콘텐츠가 반환된다고 볼 수 없습니다.

Host를 수정한 뒤 테스트할 때도 캐시와 기존 연결의 영향을 받을 수 있습니다. 파일을 저장하고 선택된 파일을 확인한 다음 새 요청을 보내세요. 필요하면 이전 페이지를 닫고 다시 열어 실제 대상 주소를 비교합니다. 특정 앱에서만 변화가 없다면 앱 자체 이름 확인 기능을 사용하거나 주소에 직접 접속하는지 확인해야 합니다. 다른 앱에서 매핑이 적용되었다고 해서 기기의 모든 요청이 같은 경로를 사용한다고 추정하지 마세요. 관리할 때는 각 정적 매핑의 용도와 출처를 기록하고 서비스 이전 후 확인하면 설정을 바꾸지 않았는데 갑자기 작동하지 않는 상황을 줄일 수 있습니다.

URL Rewrite는 주소 패턴에 따라 요청을 처리합니다

URL Rewrite는 인식 가능한 요청 주소를 다시 작성하는 기능이지 서버 목록 업데이트나 도메인 분할 처리의 다른 이름이 아닙니다. 일반적으로 매칭 표현식, 대체 주소 및 동작으로 구성됩니다. 아래 예시에서는 리디렉션 동작을 사용해 예시 사이트의 HTTP 주소를 HTTPS로 보내고 캡처 그룹으로 원래 경로를 유지합니다. 정규식의 마침표는 이스케이프해야 하며 시작 앵커는 주소의 앞부분만 대상으로 제한합니다. 그렇지 않으면 단순해 보이는 표현식이 관련 없는 주소와도 매칭될 수 있습니다. 실제로 사용하기 전에 매칭되어야 하는 예와 매칭되지 않아야 하는 예를 각각 작성해 확인하세요. 성공 사례 하나만으로 검증을 끝내지 마세요.

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

여기서 $1은 앞에 있는 괄호가 캡처한 내용을 가리키며, 302는 클라이언트가 대체 주소로 이동하도록 지시합니다. 대상 사이트는 실제로 HTTPS 서비스를 제공해야 합니다. 이 규칙이 서버에 인증서를 추가하거나 페이지를 만들 수는 없습니다. 리디렉션으로 이후 요청의 호스트 이름이 바뀌어 다른 Rule이 적용될 수 있으므로 최종 출구가 달라졌다면 대상이 변경되었는지 확인하세요. 대체 주소가 다시 원래 표현식에 매칭되거나 서버가 이전 주소로 되돌려 보내면 무한 반복이 발생할 수 있습니다. 해당 규칙을 즉시 비활성화하고 전체 리디렉션 경로를 확인하세요.

HTTPS 요청의 경로와 요청 헤더는 일반적으로 암호화된 내용에 포함되어 있어 모든 URL Rewrite에서 직접 처리할 수 있는 것은 아닙니다. 복호화가 필요한 경우 인증서 신뢰, 대상 호스트 제한 및 앱 호환성에도 한계가 있습니다. 이 페이지의 분할 규칙을 설정하기 위해 복호화를 켤 필요는 없으며, 간단한 조건 하나를 테스트하려고 처리 범위를 넓히는 것도 권장하지 않습니다. 도메인 규칙으로 해결할 수 있는 출구 설정은 Rule에서 처리하세요. Host, Rule 및 URL Rewrite는 각각 다른 문제를 해결합니다. 함께 사용할 때는 이름 확인, 정책, 재작성된 새 요청을 따로 검증해 리디렉션 한 번이 성공했다는 이유로 전체 설정이 정상이라고 단정하지 마세요.

07 · 자주 쓰는 규칙 작성 및 조정 방법

지정한 사이트만 PROXY로 연결하기

지정된 소수의 사이트만 프록시를 사용하고 나머지는 직접 연결해야 한다면 “명확한 도메인 조건과 FINAL,DIRECT” 구조를 사용할 수 있습니다. 먼저 동작을 확인할 수 있는 대상 하나부터 시작하고 검증하지 않은 키워드 규칙을 대량으로 가져오지 마세요. 아래 예시는 example.com과 하위 도메인을 프록시 범위에 넣고 내부 호스트는 별도로 직접 연결합니다. 실행하기 전에 실제로 관리하려는 도메인으로 바꾸고 현재 프록시 서버를 사용할 수 있는지 확인하세요. 예시 도메인은 매칭 관계를 설명하기 위한 것으로 실제 서비스 연결 테스트에 사용할 수 없습니다.

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

실제 웹사이트는 주소 표시줄에 보이는 도메인 외에도 별도 로그인 API, 정적 리소스 또는 파일 서비스를 요청하는 경우가 많습니다. 페이지의 글자는 표시되는데 이미지가 로드되지 않으면 모든 트래픽을 곧바로 PROXY로 보내지 말고 누락된 리소스의 실제 요청을 확인하세요. 해당 리소스가 조정할 범위에 속하는지 확인한 뒤 필요한 DOMAIN 또는 DOMAIN-SUFFIX를 추가해야 합니다. 리소스 도메인을 여러 서비스가 공유한다면 접미사 범위를 넓혀 다른 사이트에 영향을 줄 수 있습니다. 이런 경우 전체 호스트 이름 규칙으로 범위를 더 정확히 제어할 수 있습니다.

명확한 예외를 두고 나머지 요청은 PROXY로 처리

내부 서비스, 로컬 네트워크 주소 또는 특정 지역 주소에는 DIRECT를 적용하고 나머지 요청은 프록시로 보내는 경우도 흔합니다. 이때 FINAL,PROXY는 기본 처리 규칙일 뿐 모든 요청이 첫 번째 줄부터 프록시를 사용한다는 뜻은 아닙니다. 이미 알고 있는 예외를 그 앞에 두고 도메인 조건과 주소 조건을 목적에 맞게 배치하세요. 특정 도메인을 반드시 프록시로 보내야 한다면 지역 규칙보다 앞에 두어 주소 분류에 따라 DIRECT로 처리되는 일을 방지할 수 있습니다. 지역 분류가 주요 업무 요구 사항을 명확히 설명해 주지는 않습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,intranet.example.org,DIRECT
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

이 예시는 일부 내부 주소 범위만 나열하며 모든 로컬 네트워크 상황을 망라하지 않습니다. 가정용 기기, 사무실 네트워크 또는 가상 네트워크는 다른 주소와 검색 방식을 사용할 수 있습니다. 실제 네트워크 구성에 맞춰 보완해야 하며, 예시를 그대로 복사했다고 모든 로컬 서비스를 포함한다고 볼 수 없습니다. no-resolve의 범위도 유의하세요. 해당 주소 조건을 위해 능동적으로 이름을 확인하지 않는 기능이지 내부 호스트 이름을 주소로 바꿔 주는 기능은 아닙니다. 내부 이름을 확인할 수 없다면 시스템 DNS, Host 또는 사용자의 내부 이름 확인 설정을 점검해야 합니다.

정확한 대상을 거부해 불필요한 차단 방지하기

확인된 요청 대상을 거부해야 한다면 이름에 흔히 쓰이는 단어를 기준으로 넓은 범위의 REJECT를 설정하기보다 DOMAIN부터 사용하세요. 전체 호스트 이름은 확인하기 쉽고 필요할 때 원래 상태로 되돌리기도 쉽습니다. 아래 예시는 telemetry.example.com만 거부하고 example.com의 다른 호스트는 프록시로 연결되도록 합니다. DOMAIN-KEYWORD,telemetry,REJECT로 바꾸면 같은 문자열이 들어간 다른 도메인에도 영향을 줄 수 있습니다. 범위를 넓힐지는 실제 요청 기록과 명확한 요구 사항을 근거로 결정해야 합니다. 규칙이 “더 완전해 보인다”는 이유만으로 넓히지 마세요.

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

REJECT를 검증할 때는 대상 요청이 실제로 거부되는지, 페이지의 핵심 기능은 정상인지, 로그인이나 제출 작업에서 문제가 생기지 않는지 함께 확인하세요. 특정 엔드포인트가 통계 기능과 업무 응답을 함께 담당할 수도 있으므로 이름만으로 차단 결과를 판단하기 어렵습니다. 문제가 생기면 방금 추가한 정확한 규칙을 비활성화하고 같은 작업을 다시 테스트하세요. 원인과 결과를 확인한 뒤 유지할지 삭제할지 결정하면 됩니다. 차단을 유지하려고 예외를 여러 개 더 쌓아 설정을 이해하기 어려운 임시방편 모음으로 만들지 마세요.

상황별 설정을 관리 기록으로 정리하기

세 가지 설정 예시는 서로 다른 요구 사항의 출발점이며 각각 FINAL이 있으므로 그대로 이어 붙이면 안 됩니다. 통합할 때는 먼저 전체 기본 처리 정책을 정한 뒤 필요한 도메인 예외, 내부 주소 및 거부 규칙을 추려 순서를 다시 확인하세요. 새 조건을 추가할 때마다 “내부 API는 직접 연결” 또는 “지정한 사이트는 프록시 사용”처럼 용도를 한 줄로 기록하는 편이 좋습니다. 구독 자격 증명은 기록하지 마세요. 요구 사항이 사라지면 용도에 따라 해당 규칙을 삭제할 수 있어 수백 줄 중에서 출처를 추측하는 것보다 확실합니다.

기존 구독을 교체한 뒤 PROXY 경로만 작동하지 않는다면 도메인 조건을 다시 쓰기보다 서버 선택과 연결 매개변수를 먼저 확인하세요. 규칙이 가리키는 정책은 그대로인데 정책 뒤의 출구가 바뀌었을 수 있습니다. 여러 구독을 그룹화하거나 중복 노드를 관리하는 방법은 여러 구독 관리 안내를 참고하세요. 관리 범위를 분명히 유지해야 합니다. 서버 정보는 서버 관리에서, 대상 매칭은 Rule에서, 이름 확인은 General 또는 Host에서 다룹니다. 각 역할을 구분하면 네트워크가 바뀐 뒤 조정할 부분을 빠르게 찾을 수 있습니다.

08 · 검증 절차, 문제 해결 및 관리

고정 테스트 대상과 관찰 기록 준비하기

설정을 검증할 때는 “페이지가 열리는가”뿐 아니라 예상한 경로로 열리는지도 확인해야 합니다. PROXY로 연결되어야 하는 도메인 하나, DIRECT로 연결되어야 하는 도메인 하나, FINAL 동작을 확인할 미등록 도메인 하나를 먼저 선택하세요. REJECT를 사용한다면 명확히 거부할 대상도 추가합니다. 각 테스트 대상에 기대하는 정책을 적고 실제 대상, 매칭된 규칙 및 최종 출구를 기록하세요. 테스트 대상이 고정되어야 전후 비교가 의미 있습니다. 매번 다른 사이트를 사용하면 서버 측 변화를 설정 변경으로 오해할 수 있습니다.

1. 사용자가 보유한 서버 정보를 가져왔는지 확인하고 Home에서 사용할 수 있는 출구를 선택합니다.
2. Config에서 테스트 복사본을 선택하고 Global Routing을 Config로 설정합니다.
3. 연결을 설정한 뒤 새 요청으로 고정 테스트 대상에 접속합니다.
4. 앱에서 제공하는 요청 기록 또는 진단 화면에서 매칭 조건과 정책을 확인합니다.
5. 한 번에 한 곳만 수정하고 같은 테스트를 반복합니다. 통과하면 되돌릴 수 있는 복사본을 저장합니다.

Connectivity Test는 일부 연결 조건을 판단하는 데 도움이 되지만 실제 서비스 테스트를 대신하지는 않습니다. 서버 연결에 성공해도 대상 사이트의 인증, 리소스 로드 및 요청 방식이 정상이라는 뜻은 아닙니다. 반대로 웹페이지 하나가 실패했다고 서버 전체를 사용할 수 없는 것도 아닙니다. 문제가 생기면 이름 확인, 연결, 규칙 매칭, 앱 계층 응답 중 어느 단계에서 실패했는지 먼저 확인한 뒤 해당 단계에 맞는 도구를 선택하세요. 기록이 부족하다면 설정을 여러 개 바꿔 보는 것보다 최소한으로 재현되는 설정 조각을 남기는 편이 원인 범위를 좁히는 데 효과적입니다.

증상에 따라 문제 해결 절차 선택하기

“규칙에 매칭되지 않음” 증상은 접미사 범위를 곧바로 넓히기보다 실제 호스트 이름부터 확인해야 합니다. 일부 페이지는 다른 도메인으로 리디렉션되며, 일부 앱은 API 호스트에 접속하고, 일부 요청은 주소를 직접 사용합니다. 조건 자체가 맞다면 파일이 선택되었는지, 저장되었는지, Global Routing이 Proxy 또는 Direct로 설정되어 있는지 확인하세요. 그런 다음 위쪽에 더 먼저 매칭되는 규칙이 있는지 살펴보세요. 특히 범위가 넓은 키워드, 주소 규칙 및 앞쪽에 배치된 FINAL을 주의해야 합니다. 이 순서를 지키면 상태 설정 오류를 규칙 추가로 해결하려는 일을 줄일 수 있습니다.

“규칙은 올바르게 매칭되지만 접속에 실패함” 증상은 연결 경로를 확인해야 합니다. 사용자가 보유한 주소, 포트, 인증 정보 및 프로토콜 관련 매개변수를 점검하세요. 인증 오류를 더 광범위한 Rule로 감추지 마세요. Trojan처럼 TLS를 사용하는 연결은 서비스 제공자가 안내한 이름과 매개변수도 확인해야 합니다. 매개변수는 사용자의 실제 서비스 정보를 기준으로 해야 하며 규칙 예시만으로 추측할 수 없습니다. 관련 항목은 Trojan 비밀번호, SNI 및 TLS 확인 사항을 참고하세요. 서버 목록이 비어 있다면 먼저 구독 업데이트 문제를 해결해야 합니다. 규칙은 서버 정보를 대신할 수 없습니다.

되돌리기, 업데이트 및 문제 자료 정리

변경이 정상적으로 적용될 때마다 용도가 분명한 안정 버전을 저장하고 수정한 조건과 이유를 기록하세요. 원격 설정이나 구독을 업데이트한 뒤에는 앱 전체에서 문제가 발생할 때까지 기다리지 말고 기존 테스트 대상을 먼저 확인해야 합니다. 새 버전에서 문제가 생기면 검증된 복사본으로 돌아가 기준 상태를 복구한 다음, 이전 파일과 새 파일을 섞어 계속 수정하기보다 섹션별로 비교하세요. 더 이상 사용하지 않는 Host 매핑, 오래된 예외 및 중복 규칙은 의존하는 항목이 없는지 확인한 후 정리합니다.

문제 자료를 정리할 때는 현재 모드, 관련 Rule의 앞뒤 몇 줄, 테스트 도메인, 예상 정책 및 실제 결과만 보관하면 됩니다. 전체 구독 링크, 서버 비밀번호, 접근 토큰 또는 개인 정보가 포함된 요청 주소를 공개하지 마세요. 화면을 캡처하기 전에 이런 정보가 보이는지 확인해야 합니다. 원인을 알기 어렵다면 최소 규칙 복사본으로 다시 테스트한 뒤 FAQ와 구독 업데이트 실패 자가 점검 절차를 비교해 보세요. 구독 파싱 문제와 규칙 분할 문제를 하나로 혼동하지 않도록 주의해야 합니다.