Shadowrocket 구성 파일 구조와 작성법: [General], [Rule], [Host], [URL Rewrite] 섹션별 안내

이 글의 핵심

Shadowrocket 구성 파일은 설정값과 규칙, 주소 처리 방식을 정리하는 파일이며 서버 구독과는 다릅니다. 이미 서비스 정보를 보유하고 있고 .conf 파일을 읽거나 수정하려는 사용자를 위해 네 섹션을 구분하는 방법부터 Config에서 파일을 가져오고 편집한 뒤 선택하는 절차, Global Routing과 연결 기록으로 결과를 확인하는 방법까지 설명합니다.

1. 구성 파일, 서비스 정보, 라우팅 모드 구분하기

.conf는 대괄호로 감싼 섹션 이름 아래에 관련 내용을 작성하는 텍스트 구성 파일입니다. [General]에 규칙을 넣거나 [Rule]에 DNS 설정을 넣으면 원하는 설정을 제대로 표현할 수 없습니다. 파일을 읽을 때는 먼저 섹션 이름을 확인하고 각 행의 문법을 살펴보세요. 도메인 하나만 검색해 바로 붙여 넣고 수정하지 마세요.

4개 섹션

General, Rule, Host, URL Rewrite를 설명합니다

3개 메뉴

Home은 연결, Config는 구성 파일, Settings는 앱 설정을 관리합니다

마지막 1개 규칙

FINAL은 규칙 목록의 맨 마지막에 두어 기본 처리 규칙으로 사용합니다

이 글은 사용자가 이미 서비스 제공업체와 구독 정보를 보유하고 있다고 가정합니다. Home의 서버 정보는 연결 대상과 포트, 인증 방식을 설명하고, Config 파일은 요청을 어떻게 라우팅할지 정합니다. 구성 파일을 가져와도 누락된 서버 정보가 자동으로 채워지지 않으며, 서버 구독을 업데이트해도 현재 선택한 구성 파일이 업데이트되는 것은 아닙니다.

Home: 기존 서버 정보를 확인하고 연결 대상을 선택한 뒤 Global Routing을 살펴봅니다.
Config: 구성 파일을 가져오고 선택하거나 편집합니다. 파일이 목록에 있다고 해서 선택된 상태인 것은 아닙니다.
Settings: 앱 설정을 조정합니다. 예를 들어 Settings → On Demand에서 조건에 따른 연결을 관리할 수 있습니다. On Demand는 규칙 라우팅을 대신하지 않습니다.

2. [General]: 전역 설정은 키와 값으로 작성

[General]에는 키 = 값 형식으로 작성합니다. DNS와 같은 전역 설정을 넣는 섹션이며 DOMAIN-SUFFIX 규칙을 작성하는 곳은 아닙니다. 문제를 해결할 때는 먼저 기존 값을 기록하고 한 번에 하나만 변경하세요. DNS와 규칙, 연결 대상을 동시에 바꾸면 어떤 변경이 결과에 영향을 줬는지 파악하기 어렵습니다.

[General]
dns-server = system

이 예시는 DNS에서 시스템이 제공하는 DNS 서버를 사용하도록 설정합니다. 모든 네트워크 환경에 적용할 수 있는 고정된 해결책은 아닙니다. 현재 네트워크에서 DNS 문제가 발생하고 있다면 system을 유지해도 문제가 자동으로 해결되지는 않습니다. 다른 DNS 서버를 지정하려면 직접 사용 가능 여부를 확인한 주소를 선택하고 앱에서 지원하는 형식에 맞춰 입력하세요.

설정 행 확인

섹션 이름: [General]
설정 키: dns-server
대입 기호: 영문 등호 =
이 글의 예시 값: system

먼저 설정이 들어갈 섹션을 확인한 다음, 값의 형식과 실제 네트워크 환경이 맞는지 점검하세요.

규칙 행 확인

섹션 이름: [Rule]
규칙 유형: DOMAIN-SUFFIX
매칭 대상: example.com
적용할 정책: PROXY

규칙 필드는 영문 쉼표로 구분하며, 설정 행처럼 등호를 사용하지 않습니다.

‘구성을 완성’한다는 이유로 인터넷에서 본 설정을 전부 추가하지 마세요. 의미를 설명할 수 있는 설정만 유지하세요. IPv6나 시간 제한 동작을 바꾸려면 출처가 불분명한 값을 그대로 쓰지 말고 앱 내 안내와 해당 설정의 허용 값을 먼저 확인하세요.

3. [Rule]: 위에서부터 매칭하고 FINAL은 마지막에 배치

[Rule]은 요청에 적용할 정책을 정합니다. 규칙은 위에서부터 순서대로 확인하며, 매칭되면 해당 정책이 적용됩니다. 따라서 범위가 좁은 예외 규칙은 일반적으로 범위가 넓은 규칙보다 앞에 둡니다. 아래 예시는 문법만 보여 줍니다. example.com은 예시 도메인이므로 실제 대상으로 바꿔야 합니다.

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

키워드	이 예시의 매칭 대상	확인할 점
`DOMAIN`	login.example.com과 정확히 일치	이 예외 규칙을 뒤에 나오는 도메인 접미사 규칙보다 먼저 처리합니다.
`DOMAIN-SUFFIX`	example.com 및 하위 도메인	URL 경로, 프로토콜 접두사, 포트는 입력하지 않습니다.
`IP-CIDR`	192.168.0.0/16 주소 범위	`no-resolve`를 사용하면 이 IP 규칙만을 위해 도메인 조회를 강제로 시작하지 않습니다.
`GEOIP`	IP 지리 데이터베이스에서 CN으로 분류된 주소	도메인 접미사가 아니라 IP 데이터베이스를 기준으로 판단합니다.
`FINAL`	앞선 규칙에 매칭되지 않은 요청	맨 마지막에 배치하세요. 뒤에 오는 규칙은 일반적인 매칭 과정에서 적용되지 않습니다.

이 예시에서 login.example.com에 접속하면 첫 번째 행이 먼저 매칭되어 DIRECT가 적용됩니다. www.example.com은 두 번째 행에 매칭되어 PROXY가 적용됩니다. 앞의 두 행 순서를 바꾸면 로그인 도메인도 접미사 규칙에 먼저 매칭되어 첫 번째 행의 예외가 적용되지 않습니다.

4. [Host]: 도메인 매핑은 프록시 규칙과 다릅니다

[Host]는 도메인에 로컬 주소를 지정할 때 사용합니다. “이 이름이 어떤 주소를 가리키는가”를 정하며, [Rule]은 “이 요청에 어떤 정책을 적용하는가”를 정합니다. 두 섹션은 서로 다른 역할을 하므로 매핑을 추가한 뒤에도 해당 요청이 어떤 규칙에 매칭됐는지 확인해야 합니다.

[Host]
device.example.com = 192.0.2.10

192.0.2.10은 문서에서 사용하는 예시 주소이며 실제 연결할 수 있는 기기의 주소가 아닙니다. 여기서는 “도메인=주소” 형식만 보여 주므로 그대로 복사해도 웹페이지가 열리지 않습니다. 실제로 사용할 때는 직접 확인한 대상 주소를 입력하고 현재 네트워크에서 해당 주소에 접속할 수 있는지 확인하세요.

왼쪽에는 도메인을 입력합니다. https://나 /path는 붙이지 마세요.
매핑은 브라우저 주소창의 도메인을 바꾸지 않으며 HTTPS 인증서 요구사항도 자동으로 변경하지 않습니다.
잘못된 주소를 지정하면 연결에 실패하거나 인증서가 일치하지 않을 수 있습니다. 매핑 오류를 숨기려고 인증서 검증을 끄지 마세요.
앱이 별도의 DNS 조회 방식을 사용하거나 기존 연결을 재사용하면 결과가 바로 바뀌지 않을 수 있습니다. 새 연결을 만들고 연결 기록도 함께 확인하세요.

명확한 매핑이 필요하지 않다면 이 섹션은 비워 두어도 됩니다. 문제를 찾기 위해 임시로 행을 추가했다면 확인이 끝난 뒤 삭제하거나 원래 값으로 되돌리세요. 원격 서비스 주소가 바뀐 뒤에도 이전 매핑이 남아 있으면 계속 잘못된 주소를 가리킬 수 있습니다.

5. [URL Rewrite]: 주소 패턴에 따라 요청 변경

[URL Rewrite]는 URL을 매칭하고 변경하는 규칙을 지정하며 프록시 정책은 선택하지 않습니다. 일반적인 형식에는 매칭 표현식, 대상 주소, 처리 방식이 포함됩니다. 아래에서는 HTTP 주소를 리디렉션하는 예시로 문자열 시작 부분 매칭, 도메인의 마침표 이스케이프, 302 임시 리디렉션 문법을 설명합니다.

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

목적에 맞는 섹션을 선택하고 두 종류의 규칙을 혼용하지 마세요

연결 정책을 바꾸려는 경우

[Rule]을 사용합니다.
예를 들어 example.com에 PROXY를 적용합니다.
연결 기록에서 매칭된 규칙과 정책을 확인합니다.

요청 주소를 바꾸려는 경우

[URL Rewrite]를 사용합니다.
예를 들어 매칭된 HTTP 주소를 HTTPS로 리디렉션합니다.
매칭 표현식과 대상 주소, 리디렉션 반복 여부를 확인합니다.

“어떤 연결 경로를 사용할지”와 “어떤 주소를 요청할지”는 별개의 문제이므로 각각 확인해야 합니다.

예시의 ^는 문자열의 시작을 지정하고 \.은 마침표 문자 자체와 매칭됩니다. 표현식의 범위가 너무 넓으면 관련 없는 주소에도 영향을 줄 수 있습니다. 대상 주소가 원래 규칙에 다시 매칭되면 리디렉션이 반복될 수도 있습니다. HTTPS 요청은 암호화되어 있으므로 규칙 한 줄을 추가한다고 해서 내부 경로를 읽고 변경할 수 있는 것은 아닙니다. 별도 설정이 필요한지는 구체적인 처리 방식에 따라 달라집니다. 이 글에서는 HTTPS 복호화 설정을 다루지 않습니다.

6. Config에서 가져오고 편집한 뒤 적용하기

현재 사용할 수 있는 파일을 보관한 다음 새 파일을 가져오거나 복사본을 편집하세요. 원격 구성 URL은 사용자가 출처를 확인한 주소여야 하며, 응답 내용도 로그인 페이지나 웹페이지 안내가 아닌 구성 텍스트여야 합니다. 토큰이 포함된 URL은 민감한 정보이므로 공개 스크린샷이나 문의 기록에 노출하지 마세요.

원본 보관

Config에서 현재 선택된 파일 이름을 기록하고 원본 텍스트 복사본을 보관하세요. 이후 테스트가 실패하면 원본 파일로 복구하고, 상태를 확인하지 않은 채 수정을 계속 덧붙이지 마세요.
파일 가져오기

Config에서 오른쪽 위의 “+”를 누르고 이미 보유한 구성 URL을 입력한 다음 Download를 눌러 가져옵니다. 가져온 뒤 목록의 파일과 실제 내용을 확인하고 서버 구독 URL을 .conf 파일 URL로 착각하지 마세요.
텍스트 편집

Config에서 대상 파일 오른쪽의 정보 버튼을 열고 Edit Plain Text로 이동합니다. 먼저 섹션 이름을 확인한 다음 행별로 수정하세요. 화면에 현지화된 레이블이 표시된다면 현재 화면에서 해당하는 편집 메뉴를 선택하세요.
구성 파일 선택

저장한 뒤 Config로 돌아가 대상 파일을 누르고 선택 표시가 있는지 확인합니다. Home → Global Routing으로 돌아가 Config를 선택하세요. 텍스트를 저장하는 것만으로 다른 모드가 자동으로 Config로 바뀌지는 않습니다.
다시 확인

Home에서 기존 연결 대상을 사용할 수 있는지 확인한 뒤 새 연결을 만들고 대상 도메인 하나와 대상이 아닌 도메인 하나를 테스트합니다. 연결 기록에서 요청 대상, 정책, 매칭된 규칙을 확인하고 필요하면 원본 파일로 복구해 비교하세요.

원격 구성 파일을 업데이트하면 로컬 수정 내용이 덮어써질 수 있습니다. 계속 유지해야 할 규칙은 복사본에 저장하고 업데이트 후 섹션 내용을 비교하세요. 구성 파일에 서버 정보나 인증 정보, 전용 주소가 포함되어 있다면 공유 전에 각 항목을 정리해야 합니다. 파일 이름만 가리는 것으로는 충분하지 않습니다.

7. Global Routing과 연결 기록으로 적용 여부 확인하기

“가져온 상태”와 “파일의 규칙에 따라 라우팅하는 상태”는 다릅니다. 이 글의 [Rule] 예시를 확인하려면 먼저 Global Routing이 Config로 설정되어 있는지 확인하세요. 다른 모드는 용도가 다르므로 모드를 임시로 바꾼 뒤의 결과만으로 규칙 파일이 적용됐다고 판단하지 마세요.

Config

권장

현재 구성 파일의 규칙에 따라 정책을 결정합니다. 이 글의 도메인 예외, 접미사 매칭, FINAL 기본 처리 규칙은 이 모드에서 확인해야 합니다.

사용 예: 이 글의 라우팅 규칙을 읽고 수정하거나 적용 여부를 확인할 때.

Proxy

프록시를 사용할 수 있는 트래픽을 프록시 경로로 보내 기존 연결 대상이 작동하는지 확인합니다. 이 글의 개별 라우팅 규칙을 검증하는 용도는 아닙니다.

사용 예: 규칙의 영향을 잠시 제외하고 프록시 연결을 점검할 때.

Direct

직접 연결 경로를 사용해 네트워크를 비교할 수 있습니다. 이 모드로 전환한 뒤 접속 결과가 달라져도 기존 구성의 도메인 규칙이 잘못됐다는 뜻은 아닙니다.

사용 예: 현재 네트워크에서 직접 연결이 가능한지 확인할 때.

Scene

설정된 Scene 조건에 따라 라우팅 방식을 결정합니다. 문제를 해결할 때는 구성 파일뿐 아니라 Scene 조건과 실제로 적용된 모드도 함께 확인하세요.

사용 예: Scene 전환 조건을 명확히 설정하고 이해한 상태에서 사용할 때.

테스트는 연결 스위치가 켜져 있는지만 보지 말고 관찰할 수 있는 결과를 기준으로 진행하세요. 브라우저 캐시와 기존 연결, 앱 자체의 요청 방식이 판단에 영향을 줄 수 있습니다. 수정 후에는 새 요청을 보내고 연결 기록을 함께 확인하세요. 아래 표는 문제 해결 방향을 안내하며 모든 앱의 접속 결과를 보장하지는 않습니다.

관찰된 현상	우선 확인할 항목	다음 단계
규칙을 저장했지만 정책이 바뀌지 않음	현재 파일이 선택되어 있는지, Global Routing이 Config인지 확인	선택 상태를 확인하고 다시 연결한 뒤 새 요청의 기록을 확인하세요.
특정 도메인만 접속되지 않음	앞에 배치된 DOMAIN, DOMAIN-SUFFIX 또는 REJECT 규칙	파일 순서에 따라 첫 번째로 매칭되는 규칙을 찾으세요.
도메인이 이전 주소로 확인됨	Host 매핑, DNS 캐시, 기존 연결	매핑을 복원하고 새 연결로 비교하세요.
주소가 계속 리디렉션됨	URL Rewrite의 매칭 범위와 대상 주소	먼저 해당 규칙을 제거한 다음 한 행씩 복원하며 확인하세요.
업데이트 후 사용자 지정 규칙이 사라짐	같은 이름의 원격 구성 파일을 업데이트했는지 확인	로컬 복사본을 복원하고 업데이트 전후의 텍스트를 비교하세요.

확인이 끝나면 현재 어떤 파일을 사용하는지, 요청이 어떤 규칙에 매칭됐는지, 해당 정책이 적용된 이유를 설명할 수 있어야 합니다. 이 세 가지를 확인한 뒤 복잡한 규칙을 추가하세요. 매핑이나 주소 변경이 필요하지 않다면 해당 섹션을 비워 두거나 추가하지 않아도 됩니다.