Shadowrocket
규칙 및 설정 참고

01 / 파일과 적용 범위

설정 구조와 적용 조건

서버 정보와 설정 파일 구분하기

서버 정보는 기존 서비스 중 어느 것을 통해 요청을 연결할지 결정하고, 설정 파일은 어떤 조건에서 어떤 처리 방식을 선택할지 결정합니다. 서로 관련은 있지만 같은 것은 아닙니다. 구독을 가져온 뒤 Home의 SERVER 목록에 항목이 표시되더라도 Config에서 적절한 트래픽 분기 설정을 선택했다는 뜻은 아닙니다. 반대로 PROXY가 적힌 규칙 파일이 서버 주소, 포트 또는 인증 정보를 자동으로 채워 주지도 않습니다. 연결을 점검하기 전에 현재 사용 중인 서버와 선택된 설정을 각각 확인하세요. 목록이 갱신된 것을 규칙이 갱신된 것으로 착각하지 않도록 주의해야 합니다.

.conf는 설정 텍스트를 구성하는 파일 형식입니다. 먼저 대괄호로 둘러싸인 구간 제목을 찾고, 각 구간의 내용을 확인하세요. General에는 보통 전역 매개변수가, Rule에는 순서가 있는 매칭 규칙이, Host에는 도메인 매핑이, URL Rewrite에는 주소 재작성 항목이 들어갑니다. 구간 제목은 일반 설명문이 아닙니다. 대괄호를 빠뜨리거나 규칙을 다른 구간에 붙여 넣거나 편집 중 줄바꿈을 지우면 파싱 결과가 달라질 수 있습니다. 규칙 철자만 확인하지 말고 어느 구간에 들어 있는지도 살펴보세요.

간단한 예시로 구간별 문법 구분하기

[General]
bypass-system = true

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

[Host]
lab.example.com = 192.168.1.20

이 예시에는 서로 다른 세 가지 작성 형식이 포함되어 있습니다. General과 Host는 매개변수나 매핑 관계를 등호로 나타내고, Rule은 규칙 필드를 영문 쉼표로 구분합니다. 도메인 접미사 규칙에서는 두 번째 필드가 매칭 값이고 세 번째 필드가 정책입니다. FINAL에는 별도의 매칭 값이 없으므로 정책이 바로 뒤따릅니다. 예시의 사설 주소는 Host 형식을 설명할 뿐이며, 실제 네트워크에 해당 호스트가 있을 때만 의미가 있습니다. 권장 설정도 아니고 연결에 필요한 모든 정보가 포함된 것도 아닙니다.

서로 다른 구간의 문법을 혼용하는 것은 흔한 실수입니다. 예를 들어 DOMAIN-SUFFIX 뒤의 쉼표를 등호로 바꾸거나 Host 매핑을 Rule 한 줄로 작성하는 경우입니다. 코드를 복사할 때 구두점이 전각 문자로 바뀌지 않았는지, 도메인 앞뒤에 웹페이지에서 복사한 따옴표가 붙지 않았는지, 파일에 서식 있는 텍스트가 섞이지 않았는지도 확인하세요. 저장한 뒤 앱에서 파싱 오류를 알리는지 먼저 살펴보세요. 오류가 특정 줄을 가리키면 해당 줄뿐 아니라 바로 앞 줄도 함께 확인해야 합니다. 줄바꿈이나 구간 경계가 빠진 경우 다음 줄에서 오류가 드러날 수 있습니다.

저장, 선택, 적용 여부 확인하기

설정을 편집한 뒤 먼저 저장하고, Config으로 돌아가 실제로 방금 수정한 파일이 선택되어 있는지 확인한 다음 Home에서 Global Routing이 Config인지 점검하세요. 선택되지 않은 파일만 수정하면 현재 연결에는 새 규칙이 적용되지 않습니다. Proxy 또는 Direct 상태에서는 요청 결과를 Rule 순서 검증에 사용할 수도 없습니다. 앱 내 메뉴 위치는 변경될 수 있으므로 현재 화면을 기준으로 확인하되, ‘파일 내용, 선택된 항목, 실행 모드’는 항상 각각 따로 기록하세요.

원격 설정과 로컬 편집도 구분해 관리해야 합니다. 나중에 원격 주소에서 파일을 갱신하면 로컬에서 추가한 규칙이 교체될 수 있습니다. 변경 사항을 계속 유지하려면 앱에서 허용하는 파일 관리 방식으로 별도 사본을 만든 뒤 편집하고, 되돌릴 수 있도록 원본을 보관하세요. 유일하게 사용할 수 있는 설정 파일의 여러 구간을 한 번에 수정하지 마세요. 먼저 도메인 규칙 하나를 검증한 뒤 다른 규칙을 추가하면, 문제가 생겼을 때 내용 오류인지 파일 선택 오류인지 업데이트로 덮어쓴 것인지 판단하기 쉽습니다.

파일 구간을 읽는 방법부터 익히려면 .conf 구조 자세히 알아보기를 함께 참고하며 구간별로 비교해 보세요. 이후 장을 읽을 때도 현재 파일의 전체 맥락을 유지하세요. 한 줄의 문법이 올바르다는 것은 그 줄이 특정 문법에 맞는다는 뜻일 뿐, 전체 설정이 현재 네트워크와 사용 환경에 적합하다는 뜻은 아닙니다.

02 / 전역 매개변수와 도메인 매핑

General 및 Host

General은 Rule을 대신하지 않습니다

General의 매개변수는 설정의 전반적인 처리 환경에 적용되며, 웹사이트별 트래픽 분기 목록으로 사용할 수 없습니다. 예를 들어 bypass-system = true는 시스템 트래픽 우회와 관련된 설정이지, “모든 웹사이트를 DIRECT로 연결”한다는 뜻이 아닙니다. 이러한 설정으로 인해 일부 트래픽은 일반 규칙 판단에 들어오지 않을 수 있습니다. 요청을 분석할 때는 먼저 해당 요청이 관찰 및 처리 가능한 범위에 있는지 확인하세요. 설정에 FINAL이 있다는 이유만으로 기기의 모든 연결이 반드시 그 규칙을 거친다고 추정하지 마세요.

전역 매개변수를 바꾸기 전에 해결하려는 문제를 구체적으로 정리하세요. 도메인 확인 실패인지, 로컬 네트워크 접근 문제인지, 특정 요청이 기록에 나타나지 않는 문제인지 구분해야 합니다. 문제가 명확해야 관련 매개변수를 바꾸는 것이 적절한지 판단할 수 있습니다. 온라인에서 본 General 설정 전체를 기존 설정에 덮어쓰면 DNS, 우회 및 연결 동작이 동시에 바뀔 수 있습니다. 이후 웹사이트에 다시 접속되더라도 어떤 변경이 영향을 준 것인지 알기 어렵습니다. 기존 값을 보관하고 한 번에 매개변수 하나만 조정한 뒤 같은 요청으로 비교하세요.

[General]
bypass-system = true

이 예시는 불리언 매개변수의 작성 방식만 보여 줍니다. 매개변수 이름, 등호, 값은 영문 그대로 유지하세요. 이름만 보고 다른 매개변수를 임의로 추측하거나 다른 설정 형식의 키를 .conf로 옮기지 마세요. 앱에서 인식하는 매개변수와 실제 동작은 현재 앱의 지원 여부를 기준으로 확인해야 합니다. 모르는 키가 있으면 비슷한 철자를 반복해서 시도하기보다 기존 설정 설명과 앱 안내를 먼저 확인하세요. 파일을 저장할 수 있다는 사실만으로 모든 매개변수가 예상대로 적용된다고 볼 수는 없습니다.

Host는 매핑을 바꾸며 정책을 직접 지정하지 않습니다

Host는 지정한 도메인을 지정한 주소에 매핑합니다. 즉 “이 이름은 어느 주소에 해당하는가”에 답합니다. Rule은 “이 요청에 어떤 정책을 적용해야 하는가”를 결정합니다. Host에 도메인을 넣었다고 해서 DIRECT로 설정되는 것은 아닙니다. 도메인 규칙에서 먼저 PROXY가 매칭되면 해당 결과에 따라 요청을 처리합니다. Host 매핑이 적용된 뒤에는 대상 주소와 관련된 판단에 다른 주소가 사용될 수도 있습니다. 이 설정을 분석할 때는 이름, 확인된 주소, 정책을 각각 구분해 기록하세요.

[Host]
lab.example.com = 192.168.1.20

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

이 예시에는 매핑과 도메인 규칙을 함께 적어 두어 두 기능의 차이를 보여 줍니다. lab.example.com은 예시 도메인이고 192.168.1.20은 사설 주소입니다. 실제로 사용할 때는 본인 네트워크에 존재하는 호스트로 바꿔야 합니다. 규칙에서 DIRECT를 선택하더라도 기기에서 해당 사설 주소에 접근할 수 있는 네트워크 환경이 필요합니다. 같은 로컬 네트워크에 연결되어 있지 않거나 대상 기기에서 필요한 서비스가 열려 있지 않으면 규칙이 올바르게 매칭되어도 연결은 되지 않습니다. 트래픽 분기 판단과 대상에 대한 연결 가능성을 같은 결과로 취급하지 마세요.

DNS, 캐시 및 연결 재사용의 영향 확인하기

Host는 애플리케이션 계층의 신원을 자동으로 바꾸지 않습니다. HTTPS 도메인에 접속할 때 서버 인증서는 접속한 이름과 일치해야 합니다. 해당 도메인의 서비스를 제공하지 않는 주소로 매핑하면 인증서 또는 핸드셰이크 오류가 발생할 수 있습니다. 이 경우 DIRECT 규칙을 계속 추가해도 대개 해결되지 않습니다. 대상 주소가 정확한지, 서비스가 해당 포트에서 대기 중인지, 서버가 실제로 그 도메인의 서비스를 제공하는지 먼저 확인하세요. 이름과 서비스가 일치하지 않는 문제를 관계없는 설정을 완화해 덮으려 하지 마세요.

도메인 매핑을 변경한 뒤에도 이전 DNS 캐시나 기존 연결이 관찰 결과에 일시적으로 영향을 줄 수 있습니다. 대상 앱의 관련 세션을 종료한 뒤 새 요청을 보내세요. 필요하다면 앱에서 사용할 수 있는 도구로 DNS 결과를 확인하고 새 요청과 기존 연결을 구분하세요. 기록에는 테스트 도메인, 예상 주소, 실제 주소, 매칭된 정책이 포함되어야 합니다. “웹페이지가 열리지 않음”만 기록하면 매핑 미적용인지, 서비스 연결 불가인지, 요청이 새로 생성되지 않은 것인지 판단하기 어렵습니다. 여러 설정을 계속 전환하기보다 동일한 테스트 조건을 유지하는 편이 문제 해결에 효과적입니다.

마지막으로 설정에 같은 이름의 Host 항목이나 더 넓은 도메인 규칙, 주소 규칙이 함께 있는지 확인하세요. 중복 매핑의 순서에 기대어 의도를 표현하지 말고, 하나의 명확한 매핑으로 정리할 수 있으면 먼저 통합하세요. 공용 웹사이트의 주소는 서비스 배포에 따라 바뀔 수 있으므로, 주소를 장기간 고정하려면 사용자가 직접 관리해야 합니다. 자체 로컬 네트워크 서비스라면 기기 주소가 안정적인지 확인하세요. 규칙 관리는 텍스트를 파싱할 수 있게 만드는 데 그치지 않고, 설정의 이름과 실제 네트워크가 계속 일치하도록 유지하는 과정입니다.

03 / 이름 매칭

DOMAIN 및 도메인 규칙

정확한 이름, 접미사, 키워드로 범위 선택하기

도메인 규칙은 “요청 이름을 알고 있는 경우”의 트래픽 분기를 처리합니다. DOMAIN은 완전한 도메인 하나를 대상으로 하고, DOMAIN-SUFFIX는 해당 도메인과 하위 도메인을 대상으로 하며, DOMAIN-KEYWORD는 이름에 지정한 문자열이 포함되어 있는지 확인합니다. 세 규칙 모두 URL 경로를 매칭하지 않습니다. 도메인 뒤의 슬래시, 쿼리 매개변수, 페이지 조각은 이 규칙의 매칭 값이 아닙니다. api.example.com만 처리하려면 https://가 포함된 전체 주소를 넣지 마세요. 도메인 규칙으로 같은 호스트의 서로 다른 페이지를 구분할 수도 없습니다.

규칙을 선택할 때는 먼저 필요한 범위를 정확히 표현하는 가장 좁은 유형을 사용하세요. 특정 호스트에는 DOMAIN, 공통 정책을 적용할 하위 도메인 전체에는 DOMAIN-SUFFIX를 사용하고, 도메인 접미사와 관계없이 문자열로 구분해야 할 때만 DOMAIN-KEYWORD를 고려하세요. 키워드가 특정 조직이나 서비스를 자동으로 나타내는 것은 아닙니다. 같은 문자열이 포함된 다른 이름도 범위에 들어갈 수 있습니다. 짧고 흔한 단어를 키워드로 쓰면 의도하지 않은 요청에 적용되기 쉽고, 이런 오매칭은 문법 오류로 나타나지 않는 경우가 많습니다.

구체적인 예외 규칙을 넓은 규칙보다 앞에 배치하기

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

이 학습용 규칙 조합에서는 api.example.com이 먼저 정확한 규칙과 매칭되어 DIRECT를 선택합니다. www.example.com은 첫 번째 규칙과 매칭되지 않지만 접미사 규칙에 매칭되어 PROXY를 선택합니다. example.com에는 속하지 않지만 example이라는 문자열이 포함된 다른 이름만 키워드 규칙까지 도달해 REJECT될 수 있습니다. 앱이 세 가지 규칙 중 더 구체적인 것을 자동으로 비교하는 것이 아니라, 앞선 규칙이 먼저 매칭되면 판단이 끝납니다. 키워드 규칙을 맨 앞에 놓으면 같은 문자열이 포함된 요청에 대해 뒤의 두 규칙으로 예외를 적용할 수 없습니다.

DOMAIN-SUFFIX 값은 보통 example.com으로 작성합니다. 앞에 별표를 붙일 필요가 없으며 와일드카드 표기와 이 유형을 혼용하지 마세요. 이 규칙은 도메인 레이블 경계를 기준으로 접미사를 매칭하므로 notexample.com은 끝부분의 글자가 비슷하다는 이유만으로 example.com의 하위 도메인이 되지 않습니다. 특수 문자, 국제화 도메인 또는 앱 내부 변환이 포함된 이름은 요청 기록에 실제로 표시된 형식을 확인한 뒤 규칙을 작성하세요. 브라우저 주소창에 보이는 문자만 보고 판단하지 마세요.

요청 이름과 주소창의 이름은 다를 수 있습니다

한 페이지는 보통 여러 요청으로 구성됩니다. 기본 문서는 한 도메인에서 제공되더라도 이미지, 스크립트, 로그인 및 API는 각각 다른 도메인을 사용할 수 있습니다. 주소창의 도메인에 규칙을 추가했는데 페이지 일부가 여전히 제대로 작동하지 않는다고 해서 규칙이 무효인 것은 아닙니다. 실패한 요청이 어떤 이름을 사용했는지 확인하세요. 앱도 마찬가지입니다. 앱 이름이 해당 앱의 모든 서비스 도메인을 뜻하지 않으므로 아이콘이나 제품명만 보고 전체 도메인 목록을 추측할 수 없습니다. 이 문서에서는 서비스 도메인 목록을 제공하지 않으며, 사용자의 실제 요청 기록을 기준으로 확인해야 합니다.

연결 기록에 대상 IP만 있고 규칙에 사용할 도메인 정보가 없다면 도메인 규칙이 이름을 알아서 추론할 수 없습니다. 일부 요청은 캐시, 앱 내부 DNS 확인 또는 다른 연결 방식을 거쳐 기록의 호스트 필드가 예상과 다르게 표시될 수도 있습니다. 문제를 확인할 때는 먼저 기록에 도메인이 포함되어 있는지 확인한 뒤 도메인 규칙이 적용될 수 있는지 판단하세요. “DOMAIN에 매칭되지 않음”을 곧바로 클라이언트가 규칙을 무시한 것으로 단정하지 마세요. 요청이 입력한 이름으로 매칭 절차에 들어오지 않았을 수도 있습니다.

도메인 규칙을 테스트할 때는 최소 세 가지를 비교하세요. 예상대로 매칭되어야 하는 완전한 이름, 같은 그룹의 다른 하위 도메인, 영향을 받지 않아야 하는 유사한 이름입니다. 한 번에 규칙 유형 하나만 변경하고 매칭 항목과 정책이 어떻게 달라지는지 확인하세요. 키워드별 범위를 더 알아보려면 규칙 작성 기초 및 매칭 범위 비교를 읽어 보세요. 한 페이지가 열린다는 사실만 확인하는 것보다 이러한 경계 사례를 기록하는 편이 이후 오매칭을 예방하는 데 효과적입니다.

04 / 주소, 지역 및 기타 조건

IP-CIDR, GEOIP 및 기타 규칙

IP-CIDR은 주소 범위를 기준으로 판단하며 웹사이트 이름은 기준으로 삼지 않습니다

IP-CIDR의 매칭 값은 IPv4 주소와 접두사 길이입니다. 192.168.0.0/16은 사설 주소 범위를 나타내며 192.168.0.0이라는 호스트 하나만 매칭하지 않습니다. 접두사가 길수록 일반적으로 포함되는 주소 범위가 좁아집니다. 규칙을 작성하기 전에 실제 대상이 어느 네트워크 대역에 속하는지 확인하고, 편의를 위해 범위를 계속 넓히지 마세요. 웹사이트가 때때로 특정 주소로 확인된다고 해서 전체 주소 대역에 같은 정책을 적용해야 하는 것은 아닙니다. 특히 공유 인프라에서는 같은 대역에 서로 관련 없는 여러 서비스가 있을 수 있습니다.

[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
FINAL,PROXY

IPv6 주소 범위에는 IP-CIDR6을 사용하세요. 예시의 fc00::/7은 IPv6 로컬 주소 범위입니다. IPv6 주소를 IP-CIDR에 그대로 넣고 같은 결과를 기대할 수 없습니다. 사설 또는 로컬 주소에 대한 DIRECT 규칙은 연결 방식을 정할 뿐, 대상 네트워크로 가는 경로를 만들거나 대상 기기의 접근 권한을 바꾸지 않습니다. 기기가 해당 네트워크에 연결되어 있지 않거나 주소 충돌이 있거나 서비스가 대기 중이 아니라면 DIRECT에 매칭되어도 실패할 수 있으므로 네트워크와 서비스 자체를 계속 확인해야 합니다.

no-resolve의 핵심은 이 주소 규칙 때문에 추가 도메인 확인을 유발하지 않는 것입니다. 이미 IP를 대상으로 하는 요청은 기존 주소를 기준으로 확인할 수 있습니다. 도메인만 있고 사용할 수 있는 주소 정보가 없는 요청은 no-resolve가 붙은 주소 규칙에 반드시 매칭될 것이라고 기대하지 마세요. 전체 클라이언트의 DNS 확인을 중단하는 스위치도 아니며, 특정 도메인이 DNS를 영구적으로 우회한다고 선언하는 것도 아닙니다. 분석할 때는 요청에 이미 주소가 있는지와 앞선 도메인 규칙이 처리했는지를 함께 확인하세요.

GEOIP는 주소 데이터를 기준으로 하며 서비스 소유자를 뜻하지 않습니다

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

GEOIP는 대상 주소와 해당 지역 데이터를 바탕으로 판단합니다. GEOIP,CN,DIRECT는 지역 코드 CN에 해당하는 대상 주소를 매칭해 DIRECT를 선택한다는 뜻이지, 등록 주체 또는 사용자의 위치를 기준으로 분류한다는 뜻은 아닙니다. 하나의 도메인이 여러 지역의 주소로 확인될 수 있고 주소 데이터베이스가 실제 배포 환경과 다를 수도 있습니다. 따라서 특정 도메인에 고정 정책이 필요한 경우에는 GEOIP보다 앞에 규칙을 작성하세요. 지역 판단을 정확한 서비스 분류표로 취급하면 안 됩니다.

같은 도메인이 시간에 따라 다른 정책에 매칭되면 먼저 확인된 주소가 바뀌었는지 확인한 다음 지역 규칙의 위치를 살펴보세요. 기록 없이 GEOIP가 순서를 임의로 바꿨다고 단정하지 마세요. 대상 주소가 속한 지역과 프록시 출구의 지역도 구분해야 합니다. 둘은 서로 다른 정보이며, 규칙 매칭 대상과 사용자가 나중에 확인하는 출구 동작을 서로 대신해서는 안 됩니다. 주소 관련 문제를 해결할 때는 테스트한 도메인, 주소, 매칭 항목을 남겨야 합니다. 다음 요청에서는 다른 대상 주소를 사용할 수도 있습니다.

USER-AGENT 및 FINAL의 사용 범위

[Rule]
USER-AGENT,ExampleApp*,PROXY
FINAL,DIRECT

USER-AGENT는 읽을 수 있는 User-Agent 정보를 기준으로 매칭합니다. ExampleApp*은 교육용 패턴일 뿐 실제 앱 목록이 아니며, 기기에 설치된 앱 이름으로 프로세스를 식별하는 방식도 아닙니다. 암호화된 요청의 관련 필드는 항상 볼 수 있는 것이 아니므로 이 규칙이 특정 앱의 모든 트래픽을 신뢰성 있게 분류한다고 해석하면 안 됩니다. 예시를 매칭시키기 위해 이해하지 못하는 인증서나 복호화 설정을 추가하지 마세요. 기존 요청 정보로 검증할 수 있는 도메인 또는 주소 조건을 우선 사용하세요.

FINAL은 나머지 요청에 적용하는 기본 규칙이며 도메인이나 주소를 추가로 지정할 필요가 없습니다. Rule의 마지막에 두어 앞선 규칙에 매칭되지 않은 요청의 처리 방식을 명확히 하세요. FINAL을 중간에 두면 뒤에 있는 일반 규칙으로 나머지 요청을 처리할 수 없습니다. 긴 파일을 확인할 때는 먼저 FINAL을 검색해 하나만 있고 위치가 명확한지 확인한 뒤 앞선 구체 규칙을 살펴보세요. USER-AGENT, 지역 및 주소 규칙은 각각 사용할 수 있는 정보가 다릅니다. 조건을 계속 추가하기보다 먼저 요청에서 어떤 정보를 얻을 수 있는지 확인하는 것이 효과적입니다.

05 / 처리 결과와 전역 모드

정책 및 Global Routing

PROXY, DIRECT, REJECT는 서로 다른 질문에 답합니다

규칙의 앞부분은 매칭 여부를 판단하고 정책 필드는 매칭 뒤의 처리 방식을 정합니다. PROXY는 현재 선택된 프록시를 사용하고, DIRECT는 대상에 직접 연결하며, REJECT는 해당 요청을 거부합니다. 정책 이름은 도메인이나 서버 주소가 아닙니다. PROXY를 임시 설명 문구로 바꿔도 앱이 이를 자동으로 이해하지 않습니다. 기존 설정에서 이름이 있는 정책 그룹을 사용한다면 해당 항목이 실제로 존재하고 선택 관계가 올바른지 확인한 뒤 이름을 참조하세요. 이 문서에서는 복사해 사용할 수 있는 예시에 정의되지 않은 그룹 이름이 들어가지 않도록 기본 정책을 사용합니다.

PROXY에 매칭되었다고 요청이 성공하는 것은 아닙니다. 서버 정보가 유효하지 않거나 인증이 맞지 않거나 네트워크 제한 또는 대상 서비스 문제가 있으면 규칙 판단 이후에 실패할 수 있습니다. DIRECT도 “무조건 성공”을 보장하는 지시가 아니라 연결 경로만 바꿉니다. 문제를 해결할 때는 두 단계로 나눠 확인하세요. 먼저 어떤 정책이 선택되었는지 확인한 다음, 해당 정책을 사용한 연결이 왜 실패했는지 살펴보세요. 페이지가 열리는지만 보고 규칙 매칭 여부를 추측하면 전송 문제를 문법 문제로 오인하기 쉽습니다.

Global Routing은 설정에 따라 트래픽을 분기할지 결정합니다

Global Routing에는 Config, Proxy, Direct 세 가지 모드가 있습니다. 화면에 표시되는 모드 이름과 Rule의 대문자 정책 이름은 관련이 있지만 같은 계층은 아닙니다. Config는 선택된 설정에 따라 요청을 처리합니다. Proxy와 Direct는 해당 전역 모드에서 나타나는 동작을 확인하는 데 사용할 수 있습니다. DOMAIN 또는 IP-CIDR 규칙을 검증할 때는 먼저 Config으로 돌아가세요. 파일이 완벽하게 작성되어도 다른 모드에서는 해당 Rule 구간에 따라 트래픽을 판단하지 않을 수 있습니다.

모드를 바꾸는 것은 비교를 위한 테스트일 뿐 장기적인 해결책이 되어서는 안 됩니다. Proxy에서는 성공하고 Config에서는 실패한다면 Config에서 DIRECT를 선택했거나 REJECT에 매칭되었을 수 있고, 예상한 파일이 선택되지 않았을 수도 있습니다. 기록으로 실제 결과를 확인한 뒤 해당 규칙을 수정하세요. 테스트가 끝나면 원래 모드로 되돌리세요. 사용 환경이 바뀐 상태에서 이전 조건을 기준으로 결과를 해석하지 않도록 주의해야 합니다.

거부 정책을 사용할 때 예외와 복구 방법 마련하기

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

이 예시는 같은 접미사에 서로 다른 처리 방식을 적용하는 방법을 보여 줄 뿐, 예시 이름이 실제 어떤 서비스를 가리키는지는 나타내지 않습니다. api.example.com은 먼저 PROXY로 지정하고 metrics.example.com은 별도로 거부하며, 나머지 example.com 하위 도메인에는 DIRECT를 적용합니다. 접미사 규칙을 맨 앞으로 옮기면 두 구체적인 예외가 원래 의도대로 적용되지 않습니다. 정책과 규칙 순서는 함께 확인해야 합니다. 마지막 정책 필드의 철자만 확인해서는 안 됩니다.

REJECT를 사용할 때는 서비스 간 의존성을 고려하세요. 보조 기능으로 보이는 요청이 로그인, 리소스 확인 또는 세션 갱신에 사용될 수 있습니다. 일부 기능만 제대로 작동하지 않으면 규칙 구간 전체를 삭제하지 말고 해당 거부 규칙 하나를 잠시 제거한 뒤 새 요청을 보내세요. 원인을 확인한 다음 매칭 범위를 좁히거나 앞에 예외를 추가하세요. Global Routing과 Home의 관계를 확인하려면 처음 실행 및 Home 화면 구성 안내를 참고하세요. 서버 자체의 사용 가능 여부는 별도로 확인해야 합니다.

06 / 순서와 충돌

매칭 순서와 우선순위

먼저 매칭된 규칙이 먼저 결과를 결정합니다

Rule 구간에서는 일반 매칭 규칙을 순서대로 확인합니다. 규칙에 매칭되면 해당 정책을 적용하고 “더 정확해 보이는” 다음 조건을 계속 찾지 않습니다. 따라서 우선순위는 규칙 이름이 아니라 배열 위치에서 결정됩니다. DOMAIN이 DOMAIN-SUFFIX보다 자동으로 우선하는 것도 아니고 IP-CIDR이 GEOIP보다 본질적으로 낮은 것도 아닙니다. 설정을 작성할 때는 “구체적인 예외를 먼저, 일반 범위는 다음, 마지막에 FINAL” 순서로 구성하면 읽는 순서와 실제 판단 순서를 맞출 수 있습니다.

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

api.example.com을 예로 들면 첫 번째 규칙에서 DIRECT가 결정되며, example.com의 하위 도메인이라는 이유로 PROXY로 바뀌지 않습니다. www.example.com은 첫 번째 규칙에 매칭되지 않고 두 번째 규칙에 매칭되면 판단이 끝납니다. 사설 주소에 직접 접속할 때 앞의 도메인 조건이 적용되지 않거나 매칭되지 않으면 IP-CIDR 규칙으로 넘어갈 수 있습니다. 앞선 규칙에 매칭되지 않은 요청만 GEOIP 또는 FINAL로 이어집니다. 규칙을 하나씩 따라갈 때는 모든 요청에 완전한 도메인과 주소가 있다고 가정하지 말고 각 단계에서 실제로 사용할 수 있는 요청 정보를 확인하세요.

규칙 중첩 자체는 오류가 아니지만, 가려지는 규칙은 설명이 필요합니다

정확한 도메인 규칙과 접미사 규칙이 같은 요청을 모두 포함하는 것은 의도된 예외일 수 있습니다. 하지만 조건이 완전히 같은 두 규칙이 서로 다른 정책을 가리킨다면 대개 통합하거나 이유를 설명해야 합니다. 완전히 동일한 조건이 뒤에 다시 나타나도 같은 요청에 두 번째 선택지를 제공하지 않습니다. 큰 설정 파일을 확인할 때는 완전히 중복된 규칙을 먼저 찾고, 포함 관계를 살펴본 다음, 키워드와 접미사 사이의 범위 중첩을 확인하세요. 줄 수만으로 규칙의 충실도를 판단하지 마세요. 중복 항목은 유지 관리 부담만 늘리고 실제 동작을 추가하지 않을 수 있습니다.

규칙을 아래쪽에서 위쪽으로 옮긴 뒤 문제가 해결되었다면, 원래 어떤 규칙에 가려져 있었는지 더 확인해야 합니다. 새 규칙을 모두 맨 위에 두는 습관이 생기면 상단에 서로 충돌하는 예외가 쌓입니다. 올바른 방법은 가장 먼저 매칭된 넓은 조건을 찾아 필요한 예외를 그 앞에 두고, 업무별 그룹을 알아보기 쉽게 유지하는 것입니다. 같은 도메인에 서로 반대되는 정책을 계속 추가하면 나중에 관리하는 사람이 어떤 규칙이 실제 의도인지 판단하기 어려워집니다.

요청 목록으로 규칙 이동의 영향 검증하기

편집 전에 작은 예상 결과표를 만들고 최소한 ‘대상, 예상 정책, 예상 매칭 조건’을 적어 두세요. 구체적인 예외 하나, 일반 하위 도메인 하나, 사설 주소 하나, 기본 처리 대상 하나를 선택합니다. 규칙을 옮긴 뒤 문제가 있던 대상뿐 아니라 나머지 비교 대상도 다시 테스트하세요. 예외 하나를 해결하면서 전체 접미사 범위를 망가뜨리는 상황을 발견할 수 있습니다. 테스트 대상은 실제 사용 환경에서 선택해야 합니다. 이 문서의 예시 도메인에 접속할 수 있는지로 설정이 올바른지 판단하면 안 됩니다.

주소 규칙 사이의 순서에도 같은 원칙이 적용됩니다. 더 넓은 주소 범위가 DIRECT이고 그 안의 더 좁은 범위에 PROXY를 적용해야 한다면 좁은 범위를 앞에 배치하세요. GEOIP가 주소를 먼저 처리하면 뒤에 있는 주소 예외가 적용되지 않을 수 있습니다. 여기서 말하는 “구체적인 규칙 우선”은 작성자가 정렬을 통해 표현하는 원칙이며, 실행 중 접두사 길이에 따라 전체 규칙을 자동 정렬한다는 뜻이 아닙니다. 다른 네트워크 라우팅 표의 매칭 방식을 Rule 목록에 그대로 적용하지 마세요.

원격 규칙 참조나 기타 확장 내용이 설정에 포함되어 있다면 전체 판단 순서에서 어디에 위치하는지도 확인하세요. 직접 작성한 몇 줄만 읽고 파일에 더 앞선 광범위 규칙이 없다고 추정할 수는 없습니다. 매칭 결과를 설명하기 어렵다면 전체 파일로 돌아가 Rule의 시작부터 실제 순서대로 확인하고, 필요하면 최소 테스트 설정에 항목을 하나씩 추가하세요. 단순화는 영향을 주는 조건을 찾기 위한 방법입니다. 확인 후에는 원래 설정에 필요한 구간을 복구해야 하며, 지나치게 축약한 파일을 완전한 설정 대신 계속 사용해서는 안 됩니다.

07 / 주소 재작성 및 조합 예시

URL Rewrite와 자주 쓰는 작성 방식

주소 재작성은 프록시 정책 지정과 다릅니다

URL Rewrite는 패턴에 따라 요청 주소를 처리하는 기능이며, Rule에서 PROXY, DIRECT 또는 REJECT를 선택하는 것과는 다른 작업입니다. 도메인 트래픽 분기는 연결 경로를 결정하고 재작성 항목은 요청 대상 주소를 바꾸거나 리디렉션할 수 있습니다. 특정 도메인을 프록시로 연결하려고 재작성 규칙을 추가하지 말고 일반 도메인 규칙을 URL Rewrite에 붙여 넣지도 마세요. 접속 경로만 선택하면 되는 경우에는 Rule에서 표현하세요. 주소 동작을 실제로 바꿔야 할 때만 재작성 구간을 고려하세요.

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

이 예시는 매칭 패턴, 대체 주소, 리디렉션 상태 코드로 구성되며 제한된 HTTP에서 HTTPS로의 주소 리디렉션을 설명합니다. 패턴의 마침표는 역슬래시로 이스케이프하고, 맨 앞의 ^는 주소 시작 위치부터 매칭하도록 제한합니다. 도메인 뒤의 슬래시는 호스트 경계를 명확히 하는 데 도움이 됩니다. 이 짧은 예시만 보고 원래 경로와 쿼리 매개변수가 모두 예상대로 보존된다고 추정하지 마세요. 사용 환경에서 이를 보존해야 한다면 캡처와 대체 방식을 명확하게 설계하고 실제 결과를 하나씩 검증해야 합니다.

HTTPS 요청의 경우 주소 경로와 같은 정보가 항상 동일한 방식으로 읽히는 것은 아닙니다. 일반 도메인 분기에는 전체 URL을 볼 필요가 없지만 경로 단위 재작성에는 해당 요청 정보를 확인할 수 있어야 합니다. 따라서 “도메인 규칙에 매칭됨”이 재작성 패턴도 반드시 실행된다는 뜻은 아닙니다. 예시를 테스트하려고 인증서나 복호화 설정을 함부로 추가하지 마세요. 현재 요청 유형과 앱에서 확인 가능한 정보를 먼저 살펴본 뒤 URL Rewrite를 사용할지 결정하세요. 확인이 어렵다면 원래 요청 동작을 유지하는 편이 문제 해결에 유리합니다.

규칙 의도를 따로 검증할 수 있는 조합으로 나누기

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

[Host]
lab.example.com = 192.168.1.20

이 조합 예시는 로컬 네트워크 이름 매핑, 단일 도메인 거부, 전체 접미사에 대한 프록시 적용, 사설 주소 직접 연결을 함께 보여 줍니다. 먼저 두 개의 구체적인 도메인 예외를 확인하고, 다음으로 접미사 범위, 마지막으로 주소 및 기본 규칙을 살펴보세요. lab.example.com은 매핑을 통해 예시 사설 주소를 가리키고, 앞에 있는 DOMAIN 규칙은 DIRECT를 명확히 선택합니다. blocked.example.com은 먼저 거부되므로 뒤에 있는 접미사 PROXY 규칙이 적용되지 않습니다. 각 항목을 적은 변수로 독립적으로 확인할 수 있도록 예시에 재작성 규칙은 넣지 않았습니다.

실제 환경에 적용할 때는 사용 중인 설정의 사본을 먼저 만든 뒤 필요한 규칙 하나만 추가하세요. 특정 API만 다른 정책이 필요하다면 먼저 정확한 DOMAIN 규칙을 추가하면 됩니다. Host, GEOIP, 재작성을 한꺼번에 도입할 필요는 없습니다. 정확한 규칙을 검증한 다음에야 DOMAIN-SUFFIX로 범위를 넓힐지 고려하세요. 설정의 복잡성은 실제 요구 사항에서 비롯되어야 하며 예시에 키워드가 몇 개 들어 있는지에 좌우되어서는 안 됩니다. 구간이 하나 늘어날 때마다 별도로 설명하고 테스트해야 할 처리 단계도 하나씩 늘어납니다.

순환, 과도하게 넓은 패턴, 구독 개념 혼용 피하기

리디렉션을 테스트할 때는 최종 주소와 이동 횟수를 확인하세요. 새 주소가 다시 원래 패턴에 매칭되거나 대상 사이트가 요청을 원래 주소로 되돌리면 순환이 발생할 수 있습니다. 먼저 제어 가능한 경로 하나를 선택해 응답을 살펴본 뒤 매칭 범위를 넓히세요. 정규식에서 마침표, 물음표, 괄호는 특수한 의미가 있으므로 일반 URL을 확인 없이 패턴으로 사용해서는 안 됩니다. 문법이 올바르더라도 패턴 범위가 지나치게 넓으면 수정할 필요가 없는 요청까지 처리해 로그인 상태나 리소스 경로에 문제가 생길 수 있습니다.

서버 구독 주소와 설정 파일 주소도 혼동하지 마세요. 사용자가 보유한 구독은 서버 항목을 가져오는 데 쓰이지만 반드시 .conf 텍스트를 반환하는 것은 아닙니다. 설정 파일 주소는 앱이 인식할 수 있는 설정 내용을 반환해야 합니다. 예시 https://example.com/sub?token=xxxx는 명백한 가짜 값이며 사용할 수 있는 서비스 주소가 아닙니다. 확실하지 않은 주소를 Config에 가져온 뒤 파싱 오류가 발생하면 Rule 키워드를 추가해 해결하려 하지 말고 반환된 내용의 형식, 계정 상태, 주소의 용도를 먼저 확인하세요.

다른 사람에게 설정을 공유해 검토를 요청할 때는 문제를 재현하는 데 필요한 규칙과 구간만 남기고 개인 구독 주소, 인증 정보 및 기타 민감한 내용을 제거하세요. 파일 전체를 보내 추측하게 하기보다 “어떤 요청에 어떤 정책을 적용하려는지” 설명하세요. 자주 쓰는 화면 용어와 정책 이름은 용어 빠른 참조에서 확인할 수 있습니다. 조합 설정의 목적은 가능한 모든 네트워크 변경을 한 파일에 담는 것이 아니라 각 처리 단계를 설명할 수 있게 만드는 것입니다.

08 / 검증 절차

검증, 관리 및 문제 해결

정해진 순서로 테스트를 진행하세요

유효한 테스트를 하려면 입력과 환경을 고정해야 합니다. 현재 네트워크, Global Routing 모드, 선택된 설정, 프록시 선택을 먼저 기록한 다음 테스트할 완전한 호스트 이름과 예상 정책을 적으세요. 변경 사항을 저장한 뒤 Config으로 돌아가 파일을 확인하고, 모드를 Config으로 전환한 다음 대상 요청을 새로 보냅니다. 테스트 중 구독 갱신, 서버 변경, 네트워크 전환을 동시에 하지 마세요. 요청이 성공하거나 실패해도 단일 변수와 결과를 연결할 수 없습니다. 설정 문제 해결의 핵심은 버튼을 계속 누르는 것이 아니라 테스트를 재현할 수 있게 하는 것입니다.

앱에서 사용할 수 있는 요청 기록이나 진단 화면에서 대상 도메인, 대상 주소, 매칭 규칙 및 정책을 확인하세요. 표시되는 구체적인 필드는 현재 화면을 기준으로 합니다. 일부 요청에는 모든 정보가 없을 수 있으므로 누락된 항목은 그대로 기록하세요. Connectivity Test는 테스트 조건에서의 연결 상태를 파악하는 데 도움을 줄 수 있지만 실제 서비스 요청의 규칙 검증을 대신하지 않습니다. 테스트 성공은 해당 대상과 조건에서 특정 결과가 나왔다는 뜻일 뿐 모든 웹사이트나 앱 요청이 같은 경로를 사용한다는 보장은 아닙니다.

1. 파일이 저장되었고 Config에서 해당 파일을 선택했는지 확인하세요.
2. Global Routing이 Config인지 확인하고 현재 프록시 선택도 점검하세요.
3. 기존 세션을 종료한 뒤 명확한 새 요청을 보내세요.
4. 페이지가 열리는지만 보지 말고 매칭 조건과 실제 정책을 확인하세요.
5. 예외, 일반 범위 및 기본 처리 대상을 다시 테스트해 영향 범위를 확인하세요.

증상에 따라 DNS, 매칭, 전송 문제 구분하기

설정을 정상적으로 읽지 못하면 먼저 텍스트 구조를 점검하세요. 구간 제목, 영문 구두점, 필드 개수 및 정책 이름을 확인해야 합니다. DOMAIN 규칙은 보통 유형, 값, 정책의 세 부분으로 구성됩니다. FINAL은 정책이 바로 뒤따르므로 필드 수를 맞추려고 도메인을 추가해서는 안 됩니다. 코드를 복사하는 과정에서 설명문, 특히 웹페이지 제목, 줄 번호, 자동 줄바꿈 문자가 섞이지 않았는지 확인하세요. 앱에서 파일을 인식하는지 확인한 다음 요청 처리 방식을 살펴보세요. 파싱이 완료되지 않은 상태에서 네트워크 동작을 분석하지 마세요.

파일은 읽히지만 잘못된 규칙에 매칭되면 현재 파일이 선택되어 있는지, 모드가 Config인지, 요청의 실제 이름이 규칙과 일치하는지, 앞에 더 넓은 규칙이 있는지, FINAL이 너무 앞에 있는지를 순서대로 확인하세요. 도메인 규칙에서 이름을 사용할 수 없다면 요청에 대상 주소만 포함되어 있는지 확인하세요. 주소 규칙에 no-resolve가 있으면 사용할 수 있는 주소 정보가 이미 있는지도 확인해야 합니다. 각 가능성에는 확인할 수 있는 근거가 필요합니다. 매칭을 관찰하지 못했다고 해서 모두 “규칙이 작동하지 않음”으로 뭉뚱그리지 마세요.

올바른 규칙에 매칭되었는데 연결이 실패한다면 전송 단계의 문제를 확인하세요. PROXY에서는 사용자가 보유한 서버 정보와 인증을, DIRECT에서는 로컬 네트워크와 대상 서비스를 점검합니다. REJECT라면 실제로 거부하려는 요청이 맞는지 확인하세요. DNS 확인 실패, 연결 시간 초과, 인증서 오류는 서로 다른 단계의 문제이므로 같은 규칙 수정으로 해결하려 해서는 안 됩니다. 같은 대상을 Proxy와 Direct 모드로 잠시 비교할 수 있지만 테스트가 끝나면 원래 모드로 돌아가 Rule에서 실제 원인을 수정하세요.

되돌릴 수 있도록 유지 관리 기록 남기기

설정을 관리할 때는 변경 전후의 차이, 변경 이유, 검증할 대상을 기록하세요. “예외로 직접 연결하기 위해 특정 도메인 규칙을 접미사 규칙보다 앞으로 옮김”처럼 구체적으로 적고 “규칙 최적화”라고만 쓰지 마세요. 중복 항목, 장기간 사용하지 않은 예외, 더 이상 유효하지 않은 Host 매핑을 정기적으로 정리하되 한 번의 작업으로 모든 계층을 크게 바꾸지 마세요. 원격 설정이 갱신된 뒤에는 로컬 예외가 유지되었는지, 기존 순서가 바뀌지 않았는지 다시 확인해야 합니다.

설명하기 어려운 문제가 생기면 가장 최근에 정상 작동을 확인한 파일로 먼저 되돌려 기본 연결이 복구되는지 확인하세요. 그런 다음 사본에서 변경 사항 하나만 다시 적용해 문제를 재현합니다. 되돌린 뒤에도 실패한다면 방금 수정한 규칙만 문제라고 한정하지 말고 네트워크, 서비스 또는 구독 상태가 바뀌었는지도 고려하세요. 첫 연결 절차를 다시 확인하려면 빠른 시작 가이드를, 앱 출처와 구매 복원을 확인하려면 구매 항목 복원 안내를 참고하세요. 문제 해결 정보를 제출하기 전에 개인 인증 정보는 제거하고 최소한의 규칙, 요청 조건 및 실제 결과만 남기세요.