Shadowrocket
규칙 및 설정 참고 자료

Shadowrocket의 설정 파일은 서버 목록을 다른 말로 부르는 것이 아닙니다. 서버 정보는 “어떤 연결 엔드포인트를 사용할지”를 정하고, 설정 파일은 “특정 요청을 어떻게 처리할지”를 정합니다. Subscribe에서 기존 구독을 업데이트하는 작업은 보통 연결 정보를 갱신하는 것이고, Config에서 설정을 바꾸면 규칙, DNS, 주소 매핑 등의 동작이 달라질 수 있습니다. 두 항목은 연동될 수 있지만, 구독 업데이트 한 번으로 모든 설정이 동기화되었다고 볼 수는 없습니다. 문제를 점검할 때는 현재 선택된 서버와 적용 중인 설정을 각각 기록해 한쪽만 확인하는 일이 없도록 하세요.

섹션 이름은 적용 범위를 정하고, 규칙 행은 조건을 나타냅니다

일반적인 .conf 텍스트 파일은 대괄호로 섹션 이름을 표시합니다. [General]에는 전체 옵션, [Rule]에는 순서대로 판정하는 분기 규칙, [Host]에는 호스트 이름과 주소의 정적 매핑, [URL Rewrite]에는 표시되는 요청 URL에 적용할 재작성 표현식을 넣습니다. 파일에서 섹션이 배열된 순서가 모든 기능의 실행 순서를 뜻하지는 않습니다. 위에서 아래로 순서대로 해석해야 하는 것은 Rule 안의 규칙 목록입니다. “우선순위를 높이겠다”는 이유로 Host 섹션을 파일 맨 앞에 옮기지 마세요.

[General]
dns-server = system

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

[Host]
example.com = 192.0.2.10

이 텍스트는 세 가지 역할을 따로 보여 줍니다. General은 시스템 DNS를 선택하고, Rule은 예시 도메인과 로컬 네트워크 주소의 경로를 나누며, Host는 예시 호스트 이름을 문서용 예약 주소에 매핑합니다. 여기 나온 주소는 형식을 설명하기 위한 것이므로 실제 서비스 설정에 사용하면 안 됩니다. URL Rewrite는 기본 연결에 필수적이지 않아 이 시작 예시에는 포함하지 않았습니다. 분기만 조정하려는 경우 다른 섹션은 그대로 두고 시작하세요. 여러 항목을 동시에 바꾸면 결과를 잘못 판단할 수 있습니다.

수정 전에 적용 대상을 확인하세요

Config에 들어가면 이름이 비슷한 파일을 열어 바로 수정하기보다 현재 선택된 설정부터 확인하세요. 원격 설정, 로컬 복사본, 임시 테스트 파일은 이름이 비슷해도 내용은 다를 수 있습니다. 기존 설정을 복사해 실험하고, 구분하기 쉬운 로컬 이름을 사용하며, 출처와 수정 목적을 기록하는 것이 좋습니다. 원격 설정을 다시 업데이트할 때 로컬 수정 사항이 덮어써지는지는 저장 방식에 따라 다릅니다. 계속 유지해야 할 규칙은 관리 위치를 명확히 정하세요. 수동 수정 사항이 원격 설정과 항상 병합된다고 가정하면 안 됩니다.

텍스트를 저장한 뒤에는 Config로 돌아가 해당 파일이 선택되어 있는지 확인하세요. 이어서 Global Routing이 Config로 설정되어 있는지도 점검합니다. 편집이 성공했다는 것은 텍스트가 저장되었다는 뜻일 뿐, 새 요청이 모두 그 설정대로 처리된다는 뜻은 아닙니다. 이미 연결된 요청에는 이전 처리 결과가 남아 있을 수 있으므로 새 요청을 만들어 확인하세요. 클라이언트에서 구문 분석 오류가 표시되면 먼저 오류를 수정한 뒤 연결을 테스트하세요. 불러올 수 없는 파일의 결과를 이전에 정상 작동하던 설정의 결과와 혼동하지 마세요.

텍스트 형식과 최소한의 수정

규칙 필드는 보통 영문 쉼표로 구분하고, 옵션은 영문 등호로 키와 값을 연결합니다. 한국어 입력기에서 입력된 전각 쉼표, 보이지 않는 공백, 서식 있는 텍스트에서 복사한 따옴표 때문에 겉보기에는 같아도 텍스트가 해석되지 않을 수 있습니다. 일반 텍스트 편집 방식을 사용하고, 한 줄에는 규칙 하나만 작성하세요. 설명을 알 수 없는 필드로 규칙 뒤에 덧붙이지 마세요. 이 문서의 코드 블록 밖에 있는 한국어 설명은 설정 내용이 아닙니다. 복사할 때 장 번호나 줄 번호를 함께 붙여 넣지 마세요.

한 번에 한 가지 동작만 수정하세요. 예를 들어 DOMAIN 규칙 하나만 추가한 다음 해당 도메인을 테스트합니다. DNS를 바꾸고, 재작성 규칙을 추가하고, FINAL을 옮기고, 서버까지 바꾸면 결과가 달라져도 어떤 변경이 원인인지 알 수 없습니다. 신뢰할 수 있는 변경 기록에는 수정 전 증상, 수정한 구체적인 행, 확인 결과를 적어 두세요. “설정 최적화”처럼 두루뭉술하게만 기록하지 마세요. 나중에 이전 상태로 되돌릴 때 긴 규칙 목록보다 이런 정보가 더 유용합니다.

도메인 규칙은 요청 처리 중 확인할 수 있는 호스트 이름을 대상으로 하며, 브라우저 주소창에 표시되는 전체 URL을 대상으로 하지 않습니다. DOMAIN에 프로토콜, 포트, 경로까지 함께 적으면 대개 예상한 대로 동작하지 않습니다. 예를 들어 example.com의 특정 페이지가 대상이라도 도메인 필드에는 호스트 이름만 입력합니다. 경로에 따라 요청을 처리해야 한다면 URL Rewrite가 적절한지 별도로 검토하세요. 도메인 규칙에 경로 매칭까지 맡기면 안 됩니다.

DOMAIN: 호스트 이름 하나를 정확히 지정

DOMAIN,example.com,DIRECT은 example.com 호스트 이름에 DIRECT를 적용한다는 뜻입니다. api.example.com까지 자동으로 포함하지 않으며, “웹사이트의 모든 리소스를 직접 연결한다”는 의미도 아닙니다. 한 페이지에서 기본 도메인, 정적 리소스 도메인, API 도메인으로 동시에 요청할 수 있습니다. 메인 페이지가 열려도 모든 요청이 같은 규칙에 일치했다고 볼 수는 없습니다. 특정 API를 정확히 처리해야 한다면 DOMAIN의 적용 범위를 확인하기 쉽고, 나중에 예외를 제거하기도 간편합니다.

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

이 예시에서는 먼저 api.example.com에 DIRECT를 지정하고, 그다음 example.com과 하위 도메인에 PROXY를 적용합니다. 예외는 범위가 더 넓은 접미사 규칙보다 앞에 있어야 합니다. 그렇지 않으면 요청이 접미사 규칙에 먼저 일치해 정확한 규칙이 적용될 기회를 얻지 못합니다. 결과를 결정하는 것은 실제 행의 순서이지, DOMAIN 키워드가 DOMAIN-SUFFIX보다 본질적으로 “더 높은 우선순위”를 갖는다는 뜻이 아닙니다.

DOMAIN-SUFFIX: 도메인과 하위 도메인에 적용

DOMAIN-SUFFIX는 도메인 계열을 한꺼번에 처리할 때 적합합니다. DOMAIN-SUFFIX,example.com,PROXY로 작성하면 대상은 example.com과 그 하위 도메인입니다. 경로를 덧붙일 필요가 없고 앞에 별표를 붙이지 않아도 됩니다. 접미사 매칭은 도메인 경계를 기준으로 해석해야 합니다. 문자열 끝부분이 비슷하다는 이유만으로 일치한다고 판단하면 안 됩니다. 관리할 때는 실제로 포함해야 하는 도메인 경계를 선택하세요. 몇 줄을 줄이려고 관련 없는 호스트까지 범위를 넓히지 마세요.

DOMAIN-KEYWORD: 적용 범위가 넓고 관리 부담도 큽니다

DOMAIN-KEYWORD는 도메인에 지정한 텍스트가 포함되어 있는지 확인합니다. 페이지 제목, 검색어, 웹페이지 본문을 검색하는 기능이 아닙니다. DOMAIN-KEYWORD,example,PROXY는 해당 키워드가 포함된 범위에 적용되지만, 일치하는 호스트가 모두 같은 서비스에 속한다고 보장하지는 않습니다. 키워드가 짧을수록 의도하지 않은 요청까지 포함될 가능성이 커집니다. 명확한 도메인 목록이 있다면 DOMAIN 또는 DOMAIN-SUFFIX를 우선 사용하세요. 더 넓은 매칭 범위를 감수할 수 있는 경우에만 키워드 규칙을 사용하세요.

키워드 규칙은 뒤에 있는 예외를 무력화하기 쉽습니다. 테스트할 때는 일치해야 하는 호스트 하나뿐 아니라 일치하면 안 되는 호스트도 함께 확인해 적용 범위가 넓어지지 않았는지 점검하세요. 키워드가 원격 설정에서 가져온 것이라면 주변 규칙과 주석을 읽고 함께 적용되는 예외가 있는지 확인해야 합니다. 원래의 맥락을 이해하지 않은 채 한 줄만 복사하면 제한된 범위의 규칙이 전역에 가까운 넓은 처리로 바뀔 수 있습니다.

도메인이 존재해도 클라이언트가 도메인을 인식한다고 단정할 수 없습니다

일부 앱은 IP에 직접 연결하거나 앱 내부에서 주소를 선택합니다. 이때 분기 과정에서 판단에 사용할 호스트 이름을 얻지 못할 수 있습니다. 요청 기록에 주소만 표시된다고 해서 곧바로 DOMAIN-SUFFIX를 잘못 작성했다고 판단하지 마세요. 먼저 요청이 도메인으로 시작되었는지, 대상 IP만 전달되었는지 확인한 다음 주소 규칙을 추가할지 결정하세요. IP가 어느 도메인에 속하는지 추측해 결론을 내리면 공유 주소나 동적 DNS 환경에서 오류가 생기기 쉽습니다.

웹페이지 리디렉션으로 두 번째 요청이 다른 호스트를 방문할 수도 있습니다. 최초 도메인에 규칙이 제대로 적용되어도 이후 리소스에는 다른 정책이 적용될 수 있습니다. 사용자가 기억하는 웹사이트 이름이 아니라 요청 기록에 표시된 실제 호스트 이름을 기준으로 확인하세요. 넓은 규칙과 예외의 관계를 더 알아보려면 사용자 지정 규칙, 매칭 순서 및 FINAL을 읽고 이 장으로 돌아와 매칭 범위를 하나씩 좁혀 보세요.

주소 규칙은 대상 주소를 판단하며 웹페이지 언어, 사용자 위치, 서비스 제공업체 이름을 기준으로 하지 않습니다. 앞선 도메인 규칙에 일치하지 않은 요청은 주소 조건으로 계속 판정할 수 있습니다. 더 앞에 있는 규칙에 이미 일치했다면 같은 요청에 대해 이후 IP-CIDR 또는 GEOIP가 정책을 다시 선택하지는 않습니다. 이 점을 이해하면 “주소 분류 결과가 예상과 다름”과 “요청이 주소 규칙까지 도달하지 않음”을 구분할 수 있습니다.

IP-CIDR: 네트워크 접두사로 IPv4 범위 지정

CIDR은 주소와 슬래시 뒤의 접두사 길이로 구성됩니다. 접두사가 길수록 범위가 좁습니다. 192.168.0.0/16은 사설 주소 범위를 나타내고, 192.168.1.10/32는 IPv4 주소 하나만 나타냅니다. 주소 필드에 포트 번호를 쓰거나 하이픈으로 시작 주소와 끝 주소를 표현하지 마세요. 로컬 기기에 DIRECT를 설정하려면 실제 기기 주소와 서브넷부터 확인하세요. 예시에 사설 주소가 나왔다고 해서 본인 네트워크도 반드시 그 범위에 속한다고 가정하지 마세요.

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

이 규칙은 사설 주소 매칭을 설명하기 위한 것으로, 로컬 네트워크에 필요한 모든 허용 규칙을 담고 있지는 않습니다. 로컬 네트워크 접속은 시스템 네트워크 권한, 기기 방화벽, 리스닝 주소, 라우팅의 영향도 받습니다. DIRECT에 일치했다는 것은 선택한 프록시를 거치지 않는다는 뜻일 뿐, 프린터, 파일 공유 또는 로컬 서비스에 반드시 연결된다는 의미는 아닙니다. 확인할 때는 대상 서비스가 실행 중인지, 같은 네트워크의 다른 기기에서 접속할 수 있는지도 함께 점검하세요.

no-resolve: 이 규칙의 판정만을 위한 능동적 DNS 조회 방지

주소 규칙 끝의 no-resolve는 해당 규칙에 일치하는지 확인하려고 도메인 조회를 새로 시작하지 않도록 하는 옵션입니다. “클라이언트 전체 DNS 비활성화”나 “기존 주소 정보 무시”를 뜻하지는 않습니다. 요청이 원래 IP를 사용하거나 처리 과정에서 이미 사용할 수 있는 주소를 확보했다면 관련 주소 판정에 참여할 수 있습니다. 따라서 no-resolve를 추가해 모든 DNS 문제를 해결할 수는 없으며, 도메인 규칙을 우선 적용하는 스위치로 사용할 수도 없습니다.

로컬 주소 규칙에 이 옵션을 추가하는 목적은 보통 아직 해석되지 않은 각 도메인이 로컬 서브넷 판정만으로 추가 조회를 일으키지 않도록 하는 것입니다. 실제 동작은 요청이 규칙 단계에 들어왔을 때 확보된 정보에 따라 달라집니다. 대상이 도메인인데 로컬 주소 규칙에 계속 일치하지 않는다면 옵션부터 삭제하지 말고 조회 결과와 요청 기록을 확인하세요. 우연히 결과가 달라졌다고 해서 최종 해결책이라고 판단하지 마세요.

GEOIP: 주소 데이터베이스 분류이며 서비스의 소속을 뜻하지 않습니다

GEOIP,CN,DIRECT는 주소 데이터베이스의 지역 분류에 따라 DIRECT를 선택합니다. 여기서 CN은 규칙 매개변수이며, “중국어 웹페이지” 또는 “특정 지역을 대상으로 하는 모든 서비스”를 뜻하지 않습니다. 하나의 호스트가 여러 주소를 사용할 수 있고, 콘텐츠 전송 네트워크의 DNS 결과도 접속 네트워크에 따라 달라질 수 있습니다. 주소마다 분류가 다를 수 있으며 데이터베이스 기록과 실제 네트워크 배포 사이에 시차가 생기기도 합니다. 그러므로 GEOIP는 범위가 넓은 조건으로 사용하고, 서비스의 정확한 정체를 판단하는 기준으로 삼지 마세요.

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

이 예시에서는 example.com이 먼저 도메인 규칙으로 처리됩니다. DNS 조회 결과가 CN 분류에 해당하더라도 이후 GEOIP가 DIRECT로 바꾸지는 않습니다. 도메인 규칙에 일치하지 않은 다른 요청만 GEOIP 판정으로 넘어갈 수 있습니다. 정책을 고정해야 하는 서비스가 있다면 알려진 호스트에 명확한 도메인 규칙을 먼저 설정하고, 나머지 요청에 GEOIP를 적용하면 결과를 더 쉽게 설명할 수 있습니다.

IPv6은 별도로 확인해야 하며 IPv4의 결과를 그대로 적용할 수 없습니다

IPv4와 IPv6은 서로 다른 주소 체계입니다. IP-CIDR만 작성했다고 IPv6까지 적용되는 것은 아닙니다. IPv6 접두사를 지정하려면 IP-CIDR6을 사용하세요. 도메인이 두 주소 유형을 모두 반환할 때 앱이 실제로 어느 주소를 선택하는지는 시스템과 네트워크 환경에도 영향을 받습니다. 한 번 연결에 성공했다고 해서 다른 주소 체계도 사용할 수 있다고 증명되는 것은 아닙니다. 문제를 확인할 때 실제 대상 주소를 기록한 뒤 규칙과 네트워크 연결을 각각 점검하세요.

규칙 조건은 “일치하는지”를 정하고, 정책은 “일치한 뒤 무엇을 할지”를 정합니다. PROXY, DIRECT, REJECT는 서로 다른 처리 결과이며 서비스 품질 등급이나 프로토콜 이름이 아닙니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 방식을 나타냅니다. 이 중 어떤 프로토콜을 사용해도 규칙의 PROXY에 추가 우선순위가 생기지는 않습니다. 설정을 관리할 때 조건, 정책, 연결 엔드포인트를 나누어 확인하세요. 규칙 오류를 다른 프로토콜로 덮으려 하지 마세요.

PROXY, DIRECT 및 REJECT

PROXY는 요청을 현재 프록시 선택에 해당하는 처리 경로로 전달합니다. 연결이 완료되는지는 사용자가 보유한 서버 정보, 인증 매개변수, 서버 상태에 따라 달라집니다. DIRECT는 대상에 직접 연결한다는 뜻입니다. 시스템 네트워크 제한을 모두 피한다거나 클라이언트를 끈 상태와 DNS 동작이 반드시 같다는 뜻은 아닙니다. REJECT는 일치하는 요청을 거부하며, 명확히 차단해야 하는 대상에 사용합니다. 서비스에 필요한 호스트를 거부하면 앱이 로드되지 않거나 반복 재시도, 일부 콘텐츠 누락을 보일 수 있습니다.

Global Routing의 Config, Proxy, Direct는 전체 요청에 적용되는 모드입니다. 규칙 행의 PROXY, DIRECT, REJECT는 설정 내부의 정책이므로 대소문자와 의미를 구분해 읽어야 합니다. 특정 Rule이 적용되는지 확인하려면 먼저 Config를 선택하세요. Proxy로 바꾼 뒤 요청이 정상화되어도 문제 원인이 설정의 분기 또는 직접 연결 경로에 있을 가능성을 시사할 뿐, 특정 행의 구문이 잘못됐다는 증거는 아닙니다. 비교 테스트를 마치면 이후 테스트의 전제가 달라지지 않도록 원래 모드로 되돌리세요.

USER-AGENT는 확인 가능한 요청 헤더에 따라 매칭됩니다

USER-AGENT 규칙은 확인 가능한 User-Agent 내용에 따라 매칭되며 앱 아이콘, 앱 이름, 시스템 프로세스 이름을 기준으로 하지 않습니다. 앱마다 요청 헤더가 다를 수 있고 업데이트 후 내용이 바뀔 수도 있습니다. 같은 헤더를 여러 프로그램에서 함께 사용할 수도 있습니다. 따라서 특정 문자열을 앱의 영구적인 식별자로 취급하는 것은 신뢰하기 어렵습니다. 실제 요청 헤더를 확인했고 해당 요청 상황에서 클라이언트가 이를 읽을 수 있다는 점을 확인한 경우에만 이 유형의 규칙을 사용하세요.

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

여기서 ExampleClient는 설명용 문자열이며 실제 앱을 가리키지 않습니다. 별표는 와일드카드 범위를 나타냅니다. 요청 헤더를 확인할 수 없다면 이 규칙은 예상대로 판정에 참여하지 못합니다. 암호화된 연결의 HTTP 헤더는 일반적인 전달만으로 확인할 수 없는 경우가 많습니다. 브라우저 개발자 도구에서 User-Agent가 보인다고 해서 클라이언트의 규칙 판정 단계에서도 반드시 보이는 것은 아닙니다. USER-AGENT 규칙을 확인하려고 인증서 신뢰 범위를 확대하거나 불필요한 트래픽 복호화를 활성화하지 마세요.

정책이 맞아도 연결은 실패할 수 있습니다

요청 기록에 PROXY가 표시되면 라우팅 경로가 선택됐다는 뜻일 뿐, 원격 측 인증, 주소 조회, 대상 연결까지 완료됐다는 뜻은 아닙니다. 이어서 서버 주소, 포트, 인증 방식, 전송 매개변수가 사용자가 보유한 서비스 정보와 일치하는지 확인하세요. DIRECT가 표시되면 직접 연결 경로가 선택됐다는 뜻입니다. 로컬 네트워크에서 대상에 연결할 수 없다면 규칙 이름을 바꿔도 네트워크 문제는 해결되지 않습니다. REJECT가 표시되면 서버를 테스트하기 전에 어떤 규칙이 요청을 거부했는지 먼저 찾으세요.

페이지가 일부만 로드될 때는 실패한 리소스와 정상 리소스를 나누어 살펴보세요. 한 앱에서 여러 요청이 발생해 각각 DIRECT, PROXY, REJECT로 처리될 수 있습니다. “앱이 열린다”는 것만으로 완전히 확인된 것은 아니며, “앱이 열리지 않는다”는 것만으로 특정 규칙이 원인이라고 볼 수도 없습니다. 실제 호스트, 일치한 규칙, 정책을 하나씩 대응해야 조건 범위, 행 순서, 연결 매개변수 중 무엇을 조정할지 판단할 수 있습니다.

일상적인 설정 관리에서는 도메인 또는 주소 조건으로 안정적인 네트워크 경계를 표현하고, USER-AGENT는 적용 범위를 명확히 확인할 수 있는 제한적인 상황에만 사용하세요. 요청 내부 세부 정보에 더 의존하는 규칙일수록 앱이나 플랫폼을 바꾸면 다시 테스트해야 합니다. 기존 설정에서 알 수 없는 사용자 지정 정책 이름을 발견했다면 먼저 그 이름이 어디에서 정의되고 참조되는지 찾으세요. 이름을 PROXY로 바꾼 뒤 동등한 설정이라고 단정하거나 임의의 이름이 클라이언트 기본 정책이라고 가정하지 마세요.

Rule의 핵심은 위에서 아래로 확인해 먼저 일치한 규칙의 정책을 적용하는 것입니다. 클라이언트가 모든 매칭 결과를 모은 뒤 가장 구체적으로 보이는 규칙을 선택하지는 않습니다. 정확한 도메인, 도메인 접미사, 키워드, 주소 범위 사이에도 행 순서를 대신하는 고정 우선순위는 없습니다. “규칙을 작성했는데 적용되지 않는다”면 같은 조건을 다시 추가하기보다 먼저 위쪽에 이미 요청을 처리하는 규칙이 있는지 확인하세요.

명확한 예외를 넓은 조건보다 앞에 배치

example.com과 하위 도메인은 PROXY로 보내되 api.example.com은 DIRECT로 연결해야 한다면, 먼저 개별 예외를 작성하고 다음에 접미사 범위를 작성하세요. 순서를 바꾸면 api.example.com이 접미사 규칙에 먼저 일치해 뒤에 있는 DOMAIN이 결과를 바꾸지 못합니다. REJECT에도 같은 원칙이 적용됩니다. 넓은 거부 규칙 앞에 필요한 예외를 두고, 예외가 원래 의도보다 더 많은 호스트에 적용되지 않는지 확인하세요.

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

한 줄씩 따라가면 api.example.com은 첫 번째 행에서 판정이 끝납니다. blocked.example.com은 두 번째 행에서 거부되고, 나머지 example.com 하위 도메인은 세 번째 행에서 PROXY를 사용합니다. 대상이 사설 주소이고 앞선 도메인 규칙에 일치하지 않았다면 네 번째 행에서 DIRECT가 선택될 수 있습니다. 나머지 요청은 GEOIP를 계속 확인하고, 여전히 일치하지 않아야 FINAL로 넘어갑니다. 원하는 행만 보지 말고 실제 요청 조건을 사용해 판정을 따라가세요.

FINAL은 보완 규칙이 아니라 기본 처리 규칙입니다

FINAL,PROXY에는 별도의 매칭 조건이 없습니다. 앞선 규칙에 일치하지 않은 요청을 처리하므로 Rule의 맨 마지막에 두어야 합니다. FINAL을 앞당기면 그 지점에서 남은 모든 요청을 가져가 뒤에 있는 일반 규칙이 적용되지 않습니다. FINAL의 정책은 사용자가 직접 결정해야 합니다. PROXY와 DIRECT는 기본 경로가 서로 다르므로 다른 사람의 설정 마지막 행만 보고 본인 네트워크에 더 적합한 쪽을 추측하면 안 됩니다.

관리하기 쉬운 Rule에는 명확한 FINAL 하나만 두는 것이 좋습니다. 두 규칙 세트를 합칠 때 흔히 생기는 실수는 첫 번째 설정의 FINAL까지 복사해 두 번째 설정 앞에 붙이는 것입니다. 그러면 두 번째 설정의 규칙 대부분이 적용되지 않습니다. 병합 후에는 모든 FINAL을 찾아 마지막 기본 규칙 하나로 정리하고, 중복 규칙과 서로 충돌하는 범위를 확인하세요. 파일 길이나 규칙 수만 비교해 병합 성공 여부를 판단하지 마세요.

중복 규칙, 충돌 규칙, 그럴듯해 보이는 순서

조건이 완전히 같은 규칙이 여러 번 나오면 보통 앞에 있는 규칙이 이미 결과를 결정합니다. 뒤에 다른 정책을 지정해도 “대체 정책”이 되지 않습니다. 예를 들어 같은 DOMAIN을 먼저 DIRECT, 다음에 PROXY로 두 번 작성해도 DIRECT 연결 실패 후 자동으로 프록시를 사용하는 것이 아닙니다. 분기 매칭은 연결 실패 후 재시도하는 절차가 아닙니다. 정책을 바꾸려면 뒤에 원하는 결과를 덧붙이지 말고 실제로 먼저 일치하는 규칙을 수정하세요.

규칙을 알파벳순으로 정리하는 것도 의미를 바꿀 수 있습니다. 보기 좋게 정렬하는 과정에서 넓은 조건보다 앞에 있던 예외가 뒤로 밀릴 수 있습니다. 규칙 유형별로 묶는 것도 같은 위험이 있습니다. 관리하기 쉬운 순서는 보통 명확한 예외, 서비스 도메인 범위, 주소 범위와 지역 분류, 마지막으로 기본 처리 규칙입니다. 이는 검토하기 편한 구성 방식일 뿐, 모든 설정에 그대로 복사해야 하는 고정 템플릿은 아닙니다.

추측 대신 매칭 표로 확인

수정 전에 직결해야 하는 호스트, 프록시를 거쳐야 하는 호스트, 거부해야 하는 호스트, FINAL로 처리되어야 하는 대상 등 테스트 대상을 3~5개 정리해 두세요. 각각 예상되는 규칙 행을 적고 새 연결로 실제 결과를 확인합니다. 예상과 다르면 실제 호스트와 주소가 예상과 같은지 먼저 확인한 다음 규칙을 한 줄씩 점검하세요. 순서 오류뿐 아니라 웹페이지 리디렉션, 리소스 도메인 변경, 주소 체계 차이도 발견할 수 있습니다.

설정에 외부 규칙 참조가 있으면 참조가 적용되는 위치와 현재 내용을 확인해야 합니다. 참조 이름이 같아도 내용이 계속 동일하다는 보장은 없습니다. 업데이트된 범위가 이전에 FINAL에 맡겼던 요청을 처리할 수도 있습니다. 로컬 파일에서 바로 보이는 몇 줄만 검토해서는 충분하지 않습니다. 더 자세한 순서 예시는 규칙 우선순위와 FINAL 특집에서 확인하세요. 읽은 뒤에는 현재 적용 중인 설정으로 돌아와 실제 행 순서를 점검해야 합니다.

General은 설정의 전체 옵션을 관리하며 규칙을 다른 형식으로 한곳에 모아 쓰는 섹션이 아닙니다. DNS, 네트워크 동작, 플랫폼별 매개변수를 설정할 수 있지만 클라이언트 인터페이스와 플랫폼 구현에 차이가 있으므로 다른 설정 파일의 모든 필드를 그대로 옮기면 안 됩니다. 인식되지 않는 키와 값이 즉시 뚜렷한 오류를 일으키지 않았다고 해서 적용되었다는 뜻은 아닙니다. 현재 클라이언트에서 지원 여부를 확인할 수 있는 설정부터 사용하고, 실제로 필요한 옵션을 하나씩 추가하세요.

DNS는 먼저 “주소가 무엇인지” 확인합니다

도메인 조회는 호스트 이름을 주소로 변환하고, 규칙은 요청 처리 정책을 정하며, 연결 단계에서는 대상에 도달을 시도합니다. 이 세 단계는 서로 관련되지만 같은 작업은 아닙니다. DNS 조회 결과가 있다고 대상에 연결할 수 있는 것은 아니며, PROXY에 일치했다고 DNS 조회도 반드시 같은 경로를 이용하는 것은 아닙니다. 문제가 생기면 먼저 “주소를 얻었는가”, 다음으로 “어떤 정책을 선택했는가”, 마지막으로 “연결의 어느 단계에서 실패했는가”를 확인하세요. 설정 파일 전체를 바로 교체하는 것보다 원인을 찾기 쉽습니다.

[General]
dns-server = system

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

dns-server = system은 시스템 DNS를 사용하는 시작 예시이며 모든 네트워크 환경에 적합하다는 뜻은 아닙니다. 이해하기 쉬운 기준선을 먼저 만드는 데 의미가 있습니다. 시스템이 제공하는 조회 방식을 유지하고 규칙이 예상대로 처리되는지만 확인할 수 있습니다. 기존 설정에서 다른 지원 DNS 옵션을 사용 중이라면 매개변수와 기존 결과를 기록한 다음 기준 설정으로 잠시 되돌릴지 결정하세요. 기존 설정의 목적을 모른 채 General 내용을 바로 지우지 마세요.

조회 결과에 따라 주소 규칙의 입력이 달라집니다

같은 도메인도 여러 주소를 반환할 수 있으며 네트워크 위치와 캐시 상태에 따라 결과가 달라질 수 있습니다. 호스트 이름을 조건으로 하는 도메인 규칙은 주소가 바뀌어도 보통 매칭 조건 자체가 달라지지 않습니다. 하지만 GEOIP와 IP-CIDR은 주소 정보를 직접 사용하므로 조회 결과가 달라지면 매칭 결과도 달라질 수 있습니다. 테스트 전후에 주소가 바뀌었다면 정책 변화가 방금 옮긴 규칙 때문이라고만 볼 수 없습니다. 해당 시점의 대상 주소도 함께 기록하세요.

브라우저, 앱, 시스템, 클라이언트가 각각 캐시나 연결 상태를 유지할 수도 있습니다. DNS를 변경한 직후 페이지를 한 번 새로고침해도 완전히 새로운 조회와 연결이 만들어지지 않을 수 있습니다. 대상 앱의 현재 활동을 종료한 뒤 새 요청을 보내고 클라이언트 기록에 새로운 시각과 대상 연결이 표시되는지 확인하세요. 관찰을 대신해 모든 데이터를 반복해서 지우지 마세요. 캐시가 어디에 있는지 확인하기 어렵다면 먼저 현재 상태를 보존한 뒤 최소 범위에서 점검하세요.

로컬 DNS 조회와 서버 측 조회를 혼동하지 마세요

일부 연결 방식은 호스트 이름 처리를 원격 측에 맡길 수 있고, 다른 경로에서는 먼저 로컬에서 주소를 확인할 수도 있습니다. 실제 동작은 프로토콜, 설정, 요청 형태에 따라 달라집니다. PROXY가 표시된다고 모든 조회가 서버 측에서 이루어진다고 단정할 수 없으며, 로컬 DNS 기록이 있다고 업무 트래픽이 프록시를 거치지 않았다고 단정할 수도 없습니다. DNS 요청 자체와 이후 대상 연결을 따로 확인하세요. 특히 용도가 다른 두 요청을 같은 트래픽으로 취급하지 마세요.

사용자가 보유한 서버 정보의 서버 주소가 도메인일 수도 있습니다. 이 주소를 조회할 수 없으면 클라이언트가 프록시 엔드포인트에도 연결하지 못할 수 있으며, 이 경우 업무 도메인 규칙이 아무리 정확해도 해결되지 않습니다. 서버 주소 조회부터 시작해 포트와 인증을 확인하고 마지막으로 대상 사이트를 점검하세요. 서버 호스트 이름과 업무 호스트 이름을 별도의 기록으로 구분하면 한 문제 때문에 잘못된 도메인 규칙을 계속 수정하는 일을 줄일 수 있습니다.

우회 옵션과 DIRECT는 서로 다른 계층입니다

General의 일부 네트워크 제외 또는 우회 설정은 특정 트래픽이 일반적인 Rule 판정 경로로 들어오지 않게 할 수 있습니다. DIRECT는 트래픽이 분기 판정에 들어온 뒤 선택되는 정책 중 하나입니다. 요청이 예상한 기록에 아예 나타나지 않는다면 Rule에 DIRECT를 추가하기보다 시스템의 네트워크 처리 상태와 관련 우회 설정을 확인하세요. 구체적인 필드는 현재 클라이언트에서 지원하는 설정 안내를 기준으로 해야 합니다. 이 문서에서는 플랫폼별 옵션을 공통 필수 항목으로 취급하지 않습니다.

General을 관리할 때는 각 항목의 목적을 기록하세요. 예를 들면 “시스템 조회 기준 유지” 또는 “기존 로컬 네트워크 동작 유지”와 같이 적으면 됩니다. 용도를 설명할 수 없는 매개변수는 원래 값으로 보존하고 복사본에서 개별 테스트하세요. 더 긴 설정을 참고해 항목을 하나씩 채우지 마세요. 필드가 많다고 적용 범위가 더 완전한 것은 아닙니다. 설명하고 검증하고 되돌릴 수 있어야 설정을 계속 안정적으로 사용할 수 있습니다. 기본 연결을 아직 설정하지 않았다면 시작 가이드로 돌아가 서버와 연결을 확인한 다음 조회 동작을 조정하세요.

Host와 URL Rewrite는 설정 파일에 함께 자주 등장하지만 적용 대상이 다릅니다. Host는 지정된 호스트 이름에 해당하는 주소 매핑을 바꾸고, URL Rewrite는 조건에 맞는 확인 가능한 요청 URL에 재작성 동작을 적용합니다. 어느 쪽도 “도메인만 바꾸면 같은 서비스를 사용할 수 있다”는 뜻은 아닙니다. 대상 서버가 해당 호스트 이름을 허용하는지, 인증서가 일치하는지, 앱이 리디렉션을 따르는지는 실제 연결과 서비스 동작에 달려 있습니다.

Host: 고정 매핑에는 분명한 목적이 있어야 합니다

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20

이 예시에서는 두 호스트 이름을 문서용 예약 주소에 각각 매핑해 키와 값의 형식을 보여 줍니다. 실제 접속에 그대로 사용하면 안 됩니다. 고정 Host 설정은 보통 사용자가 직접 관리하는 테스트 환경에서 사용합니다. 대상 주소의 용도를 확인하지 않은 채 “속도를 높이겠다”며 인터넷에서 본 주소를 임의로 입력하지 마세요. 도메인에 여러 백엔드가 연결되어 있을 수 있습니다. 주소 하나로 고정하면 원래의 분산 처리를 우회하거나 주소가 변경된 뒤에도 사용할 수 없는 대상에 계속 연결될 수 있습니다.

Host 매핑은 일반적으로 요청에 포함된 호스트 이름을 주소 문자열로 바꾸지 않습니다. 요청에는 원래 호스트 정보가 계속 포함될 수 있고, TLS 인증서도 해당 도메인과 일치해야 합니다. 도메인을 임의로 선택한 서버에 매핑해도 그 서버가 자동으로 원래 서비스를 제공하지는 않습니다. 인증서가 일치하지 않는다면 주소와 서비스 배포 상태부터 확인하세요. 매핑 오류를 숨기려고 인증서 검증을 무시하지 마세요.

Host는 Rule의 경로 선택 판단을 대신하지 않습니다

도메인에 정적 매핑이 있다고 자동으로 DIRECT가 적용되는 것은 아닙니다. 요청 정책은 현재 모드, 사용할 수 있는 호스트 이름, 주소 규칙을 함께 고려해 결정됩니다. 직접 관리하는 테스트 호스트에 고정 주소를 지정하고 직접 연결하려면 두 목적을 나누어 설정하세요. Host는 주소를 제공하고 Rule은 DIRECT를 지정합니다. 매핑과 정책을 분리하면 테스트 후 각각 제거할 수 있어 알아채기 어려운 정적 주소 설정이 남는 일을 방지할 수 있습니다.

URL Rewrite: 정규식을 이해한 뒤 동작을 선택하세요

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

이 예시는 확인 가능한 평문 HTTP URL을 정확히 매칭하고 302 동작으로 이전 경로를 새 경로로 보냅니다. 정규식에서 마침표는 임의의 한 문자를 뜻하므로 이스케이프해야 합니다. 시작의 캐럿과 끝의 달러 기호는 전체 매칭 범위를 제한합니다. 이 표현식은 예시의 이전 경로에만 적용되며 쿼리 매개변수나 다른 후속 내용이 붙은 주소까지 자동으로 포함하지 않습니다. 매칭 조건이 넓을수록 재작성하면 안 되는 요청까지 처리할 가능성이 커집니다.

302는 리디렉션 동작을 뜻합니다. 대상 서버의 파일을 직접 수정하거나 데이터를 영구적으로 이전하는 것은 아닙니다. 클라이언트가 리디렉션 응답을 받으면 후속 요청이 발생하며, 새 요청은 분기 규칙에 다시 참여할 수 있습니다. 결과는 캐시, 앱의 리디렉션 처리 방식, 대상 서비스 상태에도 영향을 받습니다. 앱이 리디렉션을 무시하거나 특정 응답만 허용한다면 브라우저에서 성공했다고 해서 앱 내부 요청도 성공한다고 볼 수 없습니다.

HTTPS의 제약을 생략하면 안 됩니다

HTTPS 경로와 HTTP 헤더는 일반적으로 암호화된 내용에 포함되므로 일반적인 프록시 전달만으로 전체 URL을 직접 볼 수 없습니다. 따라서 위의 HTTP 예시를 HTTPS로 단순히 바꿔도 반드시 적용된다고 볼 수 없습니다. 암호화된 트래픽을 처리하는 기능에는 별도의 설정과 신뢰 경계가 있습니다. 이 페이지에서는 이를 기본 분기의 전제 조건으로 삼지 않으며 일반적인 규칙 문제를 해결하기 위해 먼저 인증서 신뢰 범위를 넓히는 방법도 권장하지 않습니다. 도메인별 분기만 필요하다면 도메인 규칙을 우선 사용하세요.

재작성 규칙이 서로 영향을 주면 반복이 발생할 수 있습니다. 새 주소가 다른 표현식에 의해 이전 주소로 돌아가거나, 범위가 지나치게 넓은 표현식이 자신이 바꾼 결과까지 다시 매칭할 수 있습니다. 테스트할 때 주소 변화와 연속 응답을 확인해 리디렉션이 한 번 발생한 뒤 끝나는지 살펴보세요. 같은 대상을 처리하는 재작성 설정 여러 개를 동시에 활성화하지 마세요. 각 규칙의 목적을 설명하기 어렵다면 복사본에 하나만 남겨 효과를 확인한 뒤 나머지를 하나씩 되돌리세요.

되돌릴 때는 상태 세 곳을 함께 확인하세요

Host를 삭제해도 기존 조회 캐시와 연결에 이전 주소가 잠시 남을 수 있습니다. URL Rewrite를 삭제한 뒤에도 앱에 리디렉션 결과가 남아 있을 수 있습니다. 완전히 되돌리려면 설정을 복구하고 새 요청을 만든 다음 실제 주소와 경로를 확인해야 합니다. 문제가 계속되더라도 규칙을 더 추가하지 말고 이전 연결이 보이는지 새로운 동작이 발생한 것인지 먼저 판단하세요. 운영 서비스에 적용하기 전에는 사용자가 직접 관리하는 테스트 호스트에서 검증한 뒤 일상 설정에 반영하세요.

앞의 각 장을 조합할 때 목표는 규칙이 가장 많은 파일이 아니라 중요한 요청을 어떻게 처리하는지 설명할 수 있는 설정을 만드는 것입니다. 먼저 필요한 예외를 정하고 기본 처리 정책을 선택하세요. DNS와 Host는 구체적인 필요가 있을 때만 조정하고 URL Rewrite는 별도로 검증하세요. 시작하기 전에 기존 구독에서 서버 하나 이상이 정상 작동하는지 확인해 서버 장애와 분기 문제를 혼동하지 않도록 하세요.

한 줄씩 확인하기 쉬운 조합 예시

[General]
dns-server = system

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시는 정확한 예외, 차단 대상, 접미사 범위, 로컬 주소, 지역 분류, 최종 기본 처리의 구성 관계를 보여 줍니다. 프록시 엔드포인트는 포함하지 않으며 구독을 대신하는 연결 정보도 아닙니다. 실제로 적용하기 전에 각 조건을 본인의 대상과 대응시키세요. 필요하지 않은 예시 규칙은 남겨 두지 않아도 됩니다. 특히 REJECT는 대상이 실제로 차단되어야 하는지 확인한 경우에만 운영 설정에 추가하세요.

파일을 먼저 확인한 뒤 모드를 점검하세요

1. Config에서 현재 선택된 파일을 확인하고 방금 수정한 규칙이 그 파일에 실제로 들어 있는지, 구문 오류는 없는지 점검하세요.
2. Global Routing을 Config로 설정하고 현재 선택된 서버를 기록하세요. 규칙 테스트 중에 서버까지 동시에 바꾸지 마세요.
3. 대상 앱의 기존 연결을 종료한 뒤 새 요청을 보내고 실제 호스트, 대상 주소, 일치 조건, 처리 정책을 기록하세요.
4. 실제 매칭 결과와 예상한 행 번호를 비교하세요. 다르면 먼저 위쪽에서 적용 범위를 덮는 조건을 찾고, 같다면 연결, 주소 조회, 대상 서비스를 점검하세요.

모든 대상이 같은 정책으로 처리된다면 전역 모드와 FINAL 위치부터 확인하세요. 특정 호스트 하나만 문제가 있다면 정확한 도메인, 리디렉션 이후의 호스트, 주소 변경을 먼저 점검하세요. 프록시 경로 전체가 실패하면 현재 서버 정보와 네트워크 상태부터 확인하세요. 문제 범위에 따라 점검 시작점이 달라지므로 모든 문제를 DOMAIN-SUFFIX 추가로 해결할 수는 없습니다.

증상에 따라 다음 단계 선택

Connectivity Test는 엔드포인트 응답 여부를 판단하는 데 도움이 되지만 특정 웹사이트의 전체 요청 경로를 확인하는 테스트를 대신하지는 않습니다. 테스트에 성공해도 도메인 조회, 규칙, 인증 세부 사항, 대상 제한으로 실제 요청은 실패할 수 있습니다. 반대로 특정 테스트 방식에서 예상한 결과가 나오지 않았다고 모든 실제 연결이 불가능하다고 단정해서도 안 됩니다. 테스트 대상과 방식, 실제 서비스에서 나타난 현상을 각각 기록하세요.

되돌리기, 업데이트, 여러 기기에서 재사용

수정할 때마다 예상대로 일치해야 하는 대상 하나와 영향을 받으면 안 되는 비교 대상 하나 이상을 확인하세요. 문제가 다시 발생하면 정상 작동하던 이전 설정으로 돌아가 변경 때문에 문제가 생겼는지 확인한 다음 한 항목씩 복구하세요. 원격 설정 업데이트 후에도 같은 방식으로 점검하세요. 특히 새로 추가된 넓은 규칙, FINAL 위치, DNS 매개변수를 주의 깊게 확인해야 합니다. 파일 이름이 그대로라고 동작도 변하지 않았다고 볼 수는 없습니다.

여러 기기에서 재사용할 때는 규칙의 의도를 먼저 옮긴 뒤 지원되는 필드와 네트워크 환경을 확인하세요. 모바일 네트워크, 가정용 로컬 네트워크, 데스크톱 네트워크의 주소 범위는 서로 다를 수 있고 시스템의 네트워크 처리 기능도 다릅니다. 같은 텍스트를 사용해도 기기마다 기록 결과가 달라질 수 있습니다. 규칙과 설정은 참고 자료로 활용하되 플랫폼별 매개변수는 다시 검증하세요. 플랫폼별 다운로드 방법은 다운로드 페이지에서, 기본 연결 절차는 시작 가이드에서 확인할 수 있습니다. 자주 발생하는 증상은 자주 묻는 질문을 참조하세요.

문제를 설명할 때 필요한 정보를 남기세요

재현 가능한 기록에는 현재 모드, 선택된 설정, 민감 정보를 지운 관련 규칙, 실제 호스트 또는 주소, 예상 정책과 실제 정책, 수정 전후 차이가 포함되어야 합니다. 전체 구독 링크, 인증 정보, 개인정보가 포함된 로그는 보내지 마세요. 설정을 보여 줘야 한다면 관련 섹션만 남기고 인증 정보를 삭제하세요. 요청이 어떤 순서로 처리되는지 한 줄씩 따라갈 수 있어야 순서, 매개변수, 연결 중 무엇이 문제인지 판단할 수 있습니다.

최종 점검은 세 가지 질문으로 정리할 수 있습니다. 요청은 어떤 설정을 사용했는가, 가장 먼저 어떤 조건에 일치했는가, 그 이후 연결의 어느 단계에서 실패했는가? 앞의 두 질문은 설정을 해석하는 문제이고 마지막 질문은 네트워크와 엔드포인트를 확인하는 문제입니다. 이 순서대로 근거를 남기면 모든 이상을 “규칙이 작동하지 않는다”고 돌리는 일을 줄일 수 있습니다. 다음 유지보수도 설정 파일 전체를 교체하지 않고 이미 확인한 내용부터 이어갈 수 있습니다.