이 글은 Shadowrocket에 사용할 서비스 제공자 설정을 준비했고, 규칙을 이해하거나 조정하려는 사용자를 위한 안내입니다. 먼저 도메인과 대상 IP를 구분하고, ‘먼저 일치하는 규칙 적용, FINAL은 마지막에 배치’하는 순서를 익혀 보세요. 마지막으로 Config, Global Routing, 연결 기록에서 결과를 확인합니다. 예시는 규칙 문법 설명만을 위한 것이며 연결 서비스를 제공하지 않습니다. 앱의 일회성 구매와 회선 요금제는 별개입니다.
1. 규칙은 매칭 조건과 정책으로 구성됩니다
규칙은 연결에 적용할 아웃바운드 정책을 결정하며, 사용 가능한 프록시 연결을 만들어 주지는 않습니다. 일반적인 형식은 ‘규칙 키워드,매칭 내용,정책’이며 각 필드는 영문 쉼표로 구분합니다. FINAL에는 매칭 내용이 없으므로 키워드와 정책, 두 필드만 사용합니다. 설정 파일에서는 보통 [Rule] 섹션에 규칙을 작성합니다.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT여기서 DIRECT는 직접 연결, PROXY는 프록시 정책을 통한 아웃바운드 연결, REJECT는 연결 거부를 뜻합니다. 이름이 지정된 정책 그룹을 사용하는 경우 규칙 끝에는 현재 설정에 실제로 존재하는 그룹 이름을 쓸 수도 있습니다. 다른 설정에 있는 그룹 이름을 그대로 복사하면 정책 참조가 유효하지 않을 수 있습니다. 예시의 example.com은 문법 설명을 위한 도메인이며 서비스 접속 주소가 아닙니다.
이 규칙을 일반 라우팅에 적용하려면 Home → Global Routing에서 Config를 선택하고, Config에서 현재 사용 중인 설정을 확인합니다. Proxy와 Direct는 전체 라우팅 방식이 서로 다르므로 도메인별 라우팅 규칙의 기대 결과를 확인하는 데 함께 사용할 수 없습니다. Scene은 해당 시나리오의 조건에 맞춰 별도로 확인해야 합니다. 파일을 편집했다고 해서 현재 연결에 해당 파일이 적용된 것은 아닙니다.
2. DOMAIN 계열은 도메인과 매칭되며 URL 경로와는 매칭되지 않습니다
URL을 나눠서 살펴보겠습니다. https://api.example.com:443/account에서 호스트명은 api.example.com, 포트는 443, 경로는 /account입니다. 아래 세 가지 규칙의 매칭 내용에는 도메인이나 도메인 일부를 입력해야 합니다. https://, 포트, 경로는 포함하지 마세요. 웹페이지 제목이나 본문을 기준으로 연결 방향을 판단하지 않습니다.
| 키워드 | 작성 예시 | 매칭 범위 |
|---|---|---|
DOMAIN | DOMAIN,api.example.com,PROXY | 정확히 일치하는 도메인 api.example.com만 |
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,PROXY | example.com과 그 하위 도메인 |
DOMAIN-KEYWORD | DOMAIN-KEYWORD,example,PROXY | 도메인에 example 문자열이 포함된 대상 |
DOMAIN: 단일 호스트에 예외 규칙 적용
DOMAIN,api.example.com,PROXY는 www.example.com이나 v2.api.example.com과 매칭되지 않습니다. 로그인 API, 특정 API 또는 단일 호스트에만 별도 정책이 필요하다면 전체 도메인을 지정하는 편이 범위를 제어하기 쉽습니다. 도메인은 실제 연결 기록을 기준으로 확인하세요. 브라우저 주소창만 보고 모든 리소스의 호스트를 추측하지 마세요.
DOMAIN-SUFFIX: 도메인과 하위 도메인 전체에 적용
DOMAIN-SUFFIX,example.com,PROXY는 example.com, www.example.com, a.b.example.com에 적용되지만 notexample.com이나 example.com.other.test에는 매칭되지 않아야 합니다. 임의의 문자열 끝을 찾는 것이 아니라 도메인 계층의 접미사를 기준으로 합니다. 보통 example.com을 입력하면 되며 *.example.com으로 작성할 필요는 없습니다.
DOMAIN-KEYWORD: 범위가 넓으므로 의도치 않은 매칭을 확인하세요
DOMAIN-KEYWORD,example,PROXY는 example.com과 myexample.test에 모두 매칭될 수 있습니다. 문자열을 기준으로 넓게 적용해야 하는 경우에 사용할 수 있습니다. 대상이 명확한 도메인 계열이라면 DOMAIN-SUFFIX를 우선 사용하세요. 키워드가 너무 짧으면 적용 범위가 넓어지고 이후 문제를 찾기도 어려워집니다.
3. GEOIP와 IP-CIDR은 대상 IP와 매칭됩니다
도메인 규칙은 이름을 기준으로, IP 규칙은 연결 대상 주소를 기준으로 판단합니다. 도메인이 어떤 IP로 해석되는지는 DNS 응답, 네트워크 환경, 콘텐츠 전송 구성에 따라 달라질 수 있습니다. 따라서 ‘도메인이 특정 조직에 속한다’는 조건과 ‘대상 IP가 데이터베이스에서 특정 지역으로 분류된다’는 조건은 서로 다르며 대체할 수 없습니다.
GEOIP,CN,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT
IP-CIDR,203.0.113.7/32,PROXY- GEOIP:
CN은 지역 코드이며 IP 지리 정보 데이터베이스의 분류를 기준으로 매칭합니다. 페이지 내용, 사용자의 위치, 도메인 등록 정보를 판별하는 규칙이 아닙니다. - IP-CIDR:
192.168.50.0/24는192.168.50.0부터192.168.50.255까지의 주소 범위를 포함합니다. 실제로 연결할 수 있는 기기는 로컬 네트워크 환경에 따라 달라집니다. - 단일 IPv4 주소:
/32는 주소 하나만 포함합니다.203.0.113.7은 문서 예시용 주소이므로 프록시 서비스의 작동 여부를 확인하는 데 사용하면 안 됩니다. - IPv6:
IP-CIDR6등 해당 IPv6 규칙을 확인해야 합니다. IPv4 대역이 모든 주소 체계에 적용되는 규칙이라고 생각하지 마세요.
요청이 처음 도메인 형태로 들어온 경우 IP 계열 규칙의 판별 과정에 도메인 해석이 포함될 수 있습니다. 일부 IP 계열 규칙에는 no-resolve를 추가해 해당 규칙 때문에 별도의 도메인 조회를 하지 않도록 할 수 있습니다. 그렇다고 DNS가 꺼지는 것은 아니며, 모든 도메인 요청이 해당 IP 규칙에 매칭되는 것도 아닙니다. 처음 설정할 때는 이 매개변수를 추가하지 말고 DNS와 매칭 과정이 명확해진 뒤 조정하는 편이 좋습니다.
4. 먼저 매칭되는 규칙이 적용되고 FINAL은 나머지를 처리합니다
규칙은 보통 위에서 아래로 확인하며, 조건을 처음 만족한 규칙이 정책을 결정합니다. 이후에 더 ‘정확한’ 항목이 있어도 계속 검사하지 않습니다. DOMAIN이 DOMAIN-SUFFIX보다 자동으로 우선하는 것은 아닙니다. 범위가 넓은 규칙이 앞에 있으면 뒤에 있는 정확한 예외 규칙은 적용되지 않습니다.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,DIRECT| 대상 조건 | 먼저 매칭된 규칙 | 결과 |
|---|---|---|
| login.example.com | DOMAIN | DIRECT |
| img.example.com | DOMAIN-SUFFIX | PROXY |
| 그 외 도메인, 대상 IP는 CN으로 분류 | GEOIP | DIRECT |
| 앞선 조건에 모두 매칭되지 않음 | FINAL | DIRECT |
FINAL,DIRECT는 나머지 연결을 직접 연결하고, FINAL,PROXY는 나머지 연결에 프록시 정책을 적용합니다. 어느 형식이 더 낫다는 뜻이 아니라 기본 동작이 다르다는 의미입니다. ‘목록에 있는 사이트만 프록시를 사용’하려면 전자가 더 적합합니다. FINAL을 첫 줄에 배치하면 뒤에 있는 규칙은 매칭 기회를 잃습니다.
5. Config에서 규칙을 수정하고 확인하기
아래 단계는 사용 가능한 서비스 제공자 설정이 이미 있는 경우를 전제로 합니다. 규칙은 정책 선택 방식을 결정하지만, 프록시 연결 성공 여부는 서비스 매개변수와 네트워크 상태에도 영향을 받습니다. 수정 전에 원본 설정을 복사해 보관하세요. 원격 업데이트로 덮어쓸 수 있는 설정이라면 로컬 수정 사항의 저장 위치와 이후 업데이트 동작을 먼저 확인해야 합니다.
-
현재 설정 확인
Config로 이동해 현재 선택된 설정 파일을 확인합니다. 해당 파일의 편집 메뉴에서
[Rule]섹션을 확인하고, 아직 활성화하지 않은 복사본은 수정하지 마세요. -
정확한 규칙 추가
먼저
DOMAIN,api.example.com,PROXY형식의 규칙을 추가한 다음 필요에 따라 DOMAIN-SUFFIX로 범위를 넓힙니다. 영문 쉼표를 사용하고 정책 이름이 실제로 유효한지 확인하세요. -
Config 선택
Home → Global Routing → Config로 돌아가 연결 스위치가 켜져 있는지 확인합니다. 테스트 중에는 Proxy나 Direct로 전환하지 마세요. 확인 조건이 달라집니다.
-
새 연결 시작
저장한 뒤 연결을 다시 시작하고 테스트 페이지를 다시 열거나 테스트 앱을 재시작해 새 요청을 발생시킵니다. 이미 연결된 장시간 연결은 규칙을 편집해도 즉시 경로가 바뀌지 않을 수 있습니다.
-
연결 기록 확인
연결 기록에서 대상 도메인, 대상 IP, 선택된 정책을 확인합니다. 현재 기록에 매칭된 규칙이 표시된다면 함께 확인하세요. 실제 결과를 첫 번째 매칭 규칙에 따른 예상 결과와 항목별로 비교합니다.
확인할 때는 한 번에 조건 하나만 변경하세요. 먼저 전체 도메인 규칙이 매칭되는지 확인한 다음 접미사 규칙을 바꾸거나 IP 범위를 추가합니다. 웹페이지가 열린다는 사실만으로 예상한 정책이 적용됐다고 단정할 수는 없습니다. 캐시, 로컬 연결, 페이지에서 사용하는 다른 도메인이 판단에 영향을 줄 수 있습니다.
6. 규칙 미매칭과 연결 실패 구분하기
문제 해결은 두 단계로 진행합니다. 먼저 연결에 어떤 정책이 선택됐는지 확인한 뒤, 해당 정책의 아웃바운드 연결이 성공했는지 살펴봅니다. 아래 문구는 DNS 또는 네트워크 진단에서 볼 수 있는 오류 예시이며, 모든 화면에 같은 표현으로 표시되는 것은 아닙니다. 실제 기록에 해당 정보가 있을 때만 관련 항목을 확인하세요.
오류: NXDOMAIN
원인 및 해결: DNS 조회에서 도메인이 존재하지 않는다는 응답을 반환했습니다. 요청 도메인의 철자와 현재 DNS 응답을 확인하세요. 이름 해석 문제를 먼저 해결한 뒤 GEOIP 또는 대상 IP가 필요한 규칙을 확인합니다. FINAL을 수정해도 존재하지 않는 도메인에 유효한 주소가 생기지는 않습니다.
오류: Connection refused
원인 및 해결: 대상이 연결을 거부했습니다. 해당 포트에서 서비스를 수신하지 않거나 서비스 정책이 연결을 차단했을 수 있습니다. 먼저 기록에 표시된 정책과 대상 주소를 확인한 뒤 서비스 제공자에게 서버 주소, 포트, 프로토콜 매개변수를 문의하세요. 이 오류만으로 DOMAIN-SUFFIX 작성이 잘못됐다고 판단할 수는 없습니다.
오류가 없는데 기록에 예상과 다른 정책이 표시된다면 다음 네 가지를 먼저 확인하세요. 실제 호스트명이 다른지, 앞에 넓은 범위의 규칙이 있는지, 올바른 설정 파일을 선택했는지, Global Routing이 Config인지 살펴봅니다. 시간 초과를 해결하려고 범위가 넓은 규칙을 한꺼번에 추가하지 마세요. 비교 기준을 잃을 수 있습니다.
7. 자주 묻는 규칙 질문
DOMAIN-SUFFIX를 작성했는데 로그인 페이지가 여전히 예상대로 동작하지 않는 이유는 무엇인가요?
로그인을 다시 시도하고 연결 기록을 확인하세요. 로그인 과정에서 다른 도메인으로 이동했거나 앞에 있는 규칙이 정확한 규칙보다 먼저 적용됐을 수 있습니다. 먼저 기록에 나온 실제 호스트에 DOMAIN 규칙을 추가해 테스트한 다음 접미사 범위를 넓힐지 결정하세요.
GEOIP,CN,DIRECT가 모든 도메인 규칙을 대신할 수 있나요?
아니요. 이 규칙은 대상 IP의 데이터베이스 분류를 판단하며 웹사이트의 콘텐츠나 용도를 구분하지 않습니다. 도메인에 따라 정책을 고정해야 하는 요청은 GEOIP 앞에 해당 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 배치하세요.
구독을 업데이트했는데 규칙이 바뀌지 않은 것처럼 보이는 이유는 무엇인가요?
연결 정보 구독과 Config의 규칙 파일은 서로 다른 항목입니다. 먼저 Config에서 현재 파일의 [Rule] 내용을 확인하세요. Home에서 연결 목록이 성공적으로 업데이트됐다고 해서 규칙도 업데이트됐다고 판단하지 마세요.
On Demand를 켜면 규칙이 자동으로 수정되나요?
아니요. Settings → On Demand는 조건에 따라 연결을 시작하도록 제어할 뿐, 규칙 순서를 바꾸거나 도메인 범위를 선택하지 않습니다. 규칙을 확인할 때는 Config 내용과 Home → Global Routing의 현재 설정을 확인해야 합니다.
FINAL을 PROXY로 바꾸면 프록시가 정상 작동하는지 확인할 수 있나요?
아니요. FINAL은 매칭되지 않은 요청에 적용할 정책만 지정합니다. 먼저 연결에 PROXY가 실제로 적용됐는지 확인한 뒤 자신의 서비스 제공자 설정과 실제 아웃바운드 결과를 점검하세요. 테스트가 끝나면 평소 용도에 맞는 기본 정책으로 되돌립니다.