Shadowrocket .conf 설정 파일 구조와 사용법: General·Rule·Host·URL Rewrite

이 글의 핵심

Shadowrocket의 .conf는 섹션별로 구성된 텍스트 설정 파일이며, 서버 구독 파일이 아닙니다. 파일을 읽을 때는 대괄호로 표시된 섹션 이름을 확인한 다음 매개변수, 매칭 조건, 정책을 살펴보세요. 적용할 때는 Home → Global Routing에서 Config를 선택했는지도 확인해야 합니다. 이미 사용할 연결 정보를 보유하고 설정을 점검하거나 수정하려는 사용자를 위해, 이 글에서는 자주 쓰이는 네 섹션의 역할과 읽기 쉬운 예시, 항목별 테스트 방법을 설명합니다.

1. 섹션 이름부터 확인: .conf는 서버 목록이 아닙니다

설정 파일은 [General], [Rule] 같은 섹션 이름으로 내용을 구분합니다. 각 항목은 다음 섹션 이름이 나올 때까지 현재 섹션에 속합니다. 섹션 이름의 대괄호, 키 이름의 하이픈, 규칙에 쓰인 영문 쉼표는 모두 문법 요소이므로 한국어 문장부호로 바꾸면 안 됩니다. [URL Rewrite]의 공백도 그대로 유지해야 합니다.

서버 정보는 “어디에 연결하고 어떤 프로토콜과 인증 매개변수를 사용할지”를 나타내고, 설정 파일은 주로 “어떻게 해석하고 트래픽을 분기하며 요청을 변경할지”를 지정합니다. 파일에 PROXY가 있어도 사용 가능한 서버가 포함되어 있다는 뜻은 아닙니다. 아래 내용은 사용자가 이미 서비스와 구독 정보를 보유하고 있으며 Home에서 서버를 선택한 상태를 전제로 합니다.

네 섹션의 역할과 자주 하는 오해
섹션 이름	처리 대상	대신할 수 없는 내용
`[General]`	DNS, IPv6 등 전역 매개변수	특정 도메인의 트래픽 분기 규칙
`[Rule]`	도메인, 대상 IP 등의 매칭 조건과 정책	서버 주소와 인증 정보
`[Host]`	지정 도메인의 로컬 해석 매핑	HTTP 리디렉션 또는 연결 정책
`[URL Rewrite]`	처리 가능한 URL과 변경 동작	모든 암호화 트래픽의 자동 복호화

이 글의 예시는 문법을 이해하기 위한 것으로, 기존 파일을 통째로 덮어쓸 수 있는 완성된 설정이 아닙니다. example.com은 예시 도메인이며, 192.0.2.10은 문서용으로 예약된 예시 주소이므로 실제 서비스 테스트에 사용하면 안 됩니다. 편집하기 전에 원본 파일을 보관하고, 개인 주소나 인증 정보 또는 구독 자격 증명이 포함된 전체 설정을 공개적으로 공유하지 마세요.

2. General: 전역 매개변수를 확인한 뒤 트래픽 분기 규칙 수정

[General]은 “키 이름 = 값” 형식으로 작성합니다. 아래에는 자주 쓰이는 매개변수 세 가지를 읽는 방법만 소개합니다. 모든 네트워크에 적용할 수 있는 권장 조합은 아닙니다. 특히 DNS와 IPv6 설정은 주소 해석 결과나 주소 선택에 영향을 줄 수 있으므로, “일시적으로 접속된다”는 이유만으로 설정이 일반적으로 올바르다고 판단해서는 안 됩니다.

[General]
dns-server = system
ipv6 = false
bypass-system = true

General 매개변수

dns-server: system은 시스템 DNS를 사용한다는 뜻입니다.
ipv6: false는 이 설정에서 IPv6 지원을 끈다는 뜻입니다.
bypass-system: true는 일부 시스템 트래픽을 우회한다는 뜻입니다.

이 매개변수는 전역 동작에 영향을 주며 도메인별 규칙은 아닙니다.

Rule 정책

PROXY: 프록시 정책으로 처리합니다. 사용할 수 있는 서버가 이미 있어야 합니다.
DIRECT: 직접 연결 정책을 사용하며 프록시 서버를 거치지 않습니다.
REJECT: 매칭된 요청을 거부합니다.

전역 매개변수와 규칙 정책은 역할이 다릅니다. 문제를 확인할 때 한 번에 하나씩만 변경하세요.

예를 들어 특정 도메인 하나의 연결 경로만 잘못되었다면 DNS를 바로 바꾸기보다 먼저 [Rule]을 확인하세요. 여러 도메인의 해석이 동시에 실패하는 경우에만 dns-server와 현재 네트워크를 점검하면 됩니다. ipv6 = false도 기기의 다른 네트워크 설정까지 일괄 변경하지는 않으므로, 기기의 모든 앱이 더 이상 IPv6를 사용하지 않는다고 단정할 수 없습니다.

3. Rule: 위에서 아래로 매칭하고 FINAL은 마지막에 배치

[Rule]은 일반적으로 “규칙 유형, 매칭 대상, 정책” 형식입니다. FINAL에는 매칭 대상이 필요 없으며 정책을 바로 지정합니다. 보통 위에서 아래로 확인해 처음 매칭된 규칙을 적용하므로, 구체적인 예외 규칙은 위쪽에 두고 기본 처리 규칙은 마지막에 둡니다.

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

DOMAIN,api.example.com,DIRECT: 이 정확한 도메인만 매칭하며, 다음 접미사 규칙에 대한 예외로 사용합니다.
DOMAIN-SUFFIX,example.com,PROXY: example.com과 그 하위 도메인을 매칭합니다. 접미사 매칭에는 도메인 경계가 적용되므로 임의의 문자열 포함과는 다릅니다.
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve: 지정한 IPv4 대역을 매칭합니다. no-resolve는 이 규칙을 확인하기 위해 도메인을 별도로 해석하지 않도록 합니다.
GEOIP,CN,DIRECT: 대상 IP의 지리적 위치 데이터에 따라 판단하며, 웹페이지 언어나 도메인 접미사를 기준으로 하지 않습니다.
FINAL,PROXY: 앞의 규칙에 매칭되지 않을 때 프록시 정책을 사용합니다. 요청이 반드시 성공한다는 뜻은 아닙니다.

이 순서에서는 api.example.com이 먼저 정확한 도메인 규칙에 매칭되고, www.example.com은 접미사 규칙에 매칭됩니다. 앞의 두 규칙 순서를 바꾸면 더 넓은 접미사 규칙이 위에 놓여 정확한 도메인 예외가 적용되지 않습니다. 규칙을 작성했는데도 작동하지 않는 것처럼 보이는 흔한 원인입니다.

4. Host: 해석 결과를 바꾸지만 URL은 바꾸지 않습니다

[Host]에서는 지정한 도메인을 특정 주소에 매핑할 수 있습니다. 아래 한 줄은 “이 도메인을 이 주소로 해석한다”는 뜻이지, 브라우저를 IP 주소로 이동시키거나 DIRECT 또는 PROXY를 직접 지정하는 것이 아닙니다.

[Host]
lab.example.com = 192.0.2.10

해석 주소를 바꿔도 브라우저 주소창에는 lab.example.com이 그대로 표시될 수 있습니다. HTTPS에서는 요청에 사용되는 도메인과 서버 인증서의 도메인이 일치해야 합니다. 도메인을 다른 사이트만 응답하는 주소에 매핑하면 인증서 오류, 엉뚱한 사이트 표시 또는 연결 실패가 발생할 수 있으며, 원하는 콘텐츠로 자동 연결되는 것은 아닙니다.

“어떤 주소에 연결할지”와 “어떤 경로를 사용할지” 구분하기

Host 해석 매핑

도메인 전체가 정확히 입력되었는지 확인합니다.
매핑한 IP에서 해당 서비스가 여전히 제공되는지 확인합니다.
HTTPS에서는 도메인과 인증서 조건도 충족해야 합니다.

Rule 트래픽 분기 정책

도메인 규칙과 배치 순서를 확인합니다.
IP 규칙과 해석된 주소를 확인합니다.
연결 정책은 DIRECT 또는 PROXY로 지정합니다.

Host와 Rule은 함께 사용할 수 있지만, 주소 매핑은 정책을 대신하지 않으며 정책으로 잘못된 주소 매핑을 바로잡을 수도 없습니다.

로컬 매핑은 명시적으로 주소를 덮어쓰는 설정이므로 서비스 주소가 바뀌면 다시 확인해야 합니다. Host를 추가한 뒤에만 문제가 발생했다면 해당 매핑을 삭제하고 저장한 다음 연결을 새로 설정해 같은 도메인을 다시 테스트하세요. DNS, 규칙 순서, 서버를 동시에 변경하면 어떤 조치로 문제가 해결되었는지 알 수 없습니다.

5. URL Rewrite: 매칭 표현식, 대상, 동작을 함께 확인

[URL Rewrite]에서는 URL 변경 규칙을 선언합니다. 아래 예시는 특정 HTTP 도메인의 루트 경로를 HTTPS로 리디렉션하며, 끝의 302는 임시 리디렉션을 뜻합니다. 문법과 매칭 범위를 설명하기 위한 예시이며 모든 웹사이트에 같은 규칙을 적용하라는 의미는 아닙니다.

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

매칭 표현식: ^는 시작 위치, $는 끝 위치를 지정합니다. \.는 점 문자 자체를 뜻하므로 도메인에 포함된 점이 정규식 와일드카드로 처리되지 않습니다.
대상 주소: https://example.com/은 리디렉션할 주소입니다. 이 예시는 경로와 쿼리 매개변수를 유지하지 않고 고정된 대상으로 이동합니다.
동작: 302는 리디렉션 상태 코드이며, 서버 포트나 프록시 프로토콜이 아닙니다.

표현식에 끝 위치 제한이 포함되어 있어 이 규칙은 http://example.com/docs나 쿼리 문자열이 붙은 주소와 매칭되지 않습니다. 매칭 범위를 바꾸기 전에 경로와 매개변수를 유지할지 먼저 결정하세요. 모든 요청을 같은 루트 경로로 보내면 로그인 콜백, 검색 결과 또는 API 호출이 제대로 작동하지 않을 수 있습니다.

6. 활성화와 테스트: Config 상태를 확인한 뒤 항목별로 점검

파일을 저장한 상태, 파일을 선택한 상태, 규칙이 트래픽 분기에 적용되는 상태는 서로 다릅니다. 편집을 마친 뒤 Config에서 현재 선택된 파일을 확인하고 Home으로 돌아가 Global Routing을 점검하세요. 아래 설명은 Shadowrocket 자체의 라우팅 상태를 기준으로 하며, 앱이 처리하는 연결에 적용됩니다. 기기의 모든 네트워크 활동을 절대적으로 보장하는 것은 아닙니다.

Config

권장

현재 설정 파일의 규칙에 따라 정책을 선택합니다. 매칭되지 않은 요청의 경로는 FINAL에 지정된 내용으로 결정되며, 나머지가 항상 직접 연결되는 것은 아닙니다.

적합한 용도: 이 글의 Rule 예시를 확인하거나 평소 규칙에 따라 트래픽을 분기할 때.

Proxy

전역 라우팅 상태로 프록시를 사용하며 Config의 개별 규칙에 따른 경로를 선택하지 않습니다. 전환하면 문제가 규칙 선택과 관련 있는지 확인하는 데 도움이 됩니다.

적합한 용도: 프록시 경로를 임시로 비교할 때. DOMAIN-SUFFIX 규칙의 매칭 순서를 확인하는 용도로는 적합하지 않습니다.

Direct

전역 라우팅 상태로 직접 연결을 사용합니다. 이 상태에서 웹사이트에 접속할 수 있어도 설정의 PROXY 규칙이 적용되었다는 뜻은 아닙니다.

적합한 용도: 현재 네트워크의 직접 연결 상태를 비교해 프록시 경로 문제와 대상 서비스 문제를 구분할 때.

Global Routing의 Scene은 상황별 라우팅 동작을 설정하는 기능이며 Config와 같다고 볼 수 없습니다. 설정 파일을 처음 확인할 때는 Config를 선택하세요. Settings → On Demand도 활성화되어 있다면 자동 연결 조건을 확인해 자동 재연결을 방금 파일을 수정한 결과로 오해하지 않도록 주의하세요.

원본 보관

Config에서 현재 사용할 수 있는 설정의 사본을 보관한 뒤 테스트할 파일을 편집하세요. 예시 조각으로 파일 전체를 덮어쓰지 마세요.
파일 선택

Config에서 수정 내용을 저장하고 현재 선택 표시가 가리키는 파일 이름을 확인하세요. 원격 파일은 이후 업데이트가 로컬 변경 사항을 덮어쓸 수 있으므로 주의해야 합니다.
라우팅 상태 확인

Home → Global Routing으로 이동해 Config를 선택한 다음, Home에서 선택한 서버가 사용 가능한 기존 서버인지 확인하세요.
연결 다시 설정

기존 연결의 영향을 배제하려면 Home에서 연결 스위치를 껐다가 다시 켠 뒤 대상 요청을 새로 실행하세요. 연결을 재사용할 수 있는 페이지를 새로 고치는 것만으로는 충분하지 않습니다.
항목별 재테스트

먼저 Home → Connectivity Test로 기본 연결 상태를 확인한 다음 특정 도메인을 테스트하세요. 매번 규칙 한 개 또는 매개변수 한 개만 변경하고 결과를 기록합니다.

Connectivity Test 결과만으로 앱 수준의 전체 동작을 검증할 수는 없습니다. 테스트에 성공해도 특정 URL Rewrite가 실행되었다거나 특정 웹사이트의 모든 리소스가 동일한 정책을 사용한다고 단정할 수 없습니다. 웹사이트는 여러 도메인에 요청을 보내는 경우가 많습니다. 메인 페이지는 정상인데 이미지가 표시되지 않으면 관련 도메인을 각각 확인하고, 광범위한 규칙 하나만 추가하지 마세요.

7. 자주 묻는 질문: 파일은 올바른데 예상대로 작동하지 않을 때

DIRECT를 설정했는데 왜 여전히 프록시를 거치나요?

먼저 Home → Global Routing이 Config로 설정되어 있는지, 현재 올바른 설정 파일이 선택되었는지 확인하세요. 그런 다음 해당 규칙 위에 더 광범위한 DOMAIN-SUFFIX 규칙이나 다른 매칭 규칙이 있는지 살펴봅니다. 구체적인 예외를 넓은 범위의 규칙보다 위에 배치하고 저장한 뒤 연결을 새로 설정해 다시 테스트하세요.

구독을 가져오면 Rule도 새 규칙으로 자동 변경되나요?

서버 구독 업데이트와 설정 파일 업데이트는 서로 별개입니다. Home의 서버 목록이 바뀌어도 Config의 규칙 파일이 업데이트된 것은 아닙니다. 서버 목록과 현재 설정을 각각 확인하세요. 설정을 원격 주소에서 가져왔다면 업데이트 전에 로컬 변경 사항을 저장해 이후 업데이트가 덮어쓰지 않도록 하세요.

Host에 IP를 입력했는데 HTTPS 오류가 나는 이유는 무엇인가요?

먼저 해당 IP가 지정된 도메인의 서비스를 제공하는지, 서버 인증서에 그 도메인이 포함되어 있는지 확인하세요. Host 항목을 잠시 삭제하고 연결을 다시 설정한 뒤 같은 주소에 접속해 비교합니다. 인증서 검증을 끄는 방법으로 도메인 매핑 문제를 해결하려고 하지 마세요.

FINAL,PROXY만 추가하면 연결할 수 있나요?

아니요. FINAL은 기본 정책만 지정하며 서버 주소, 포트, 인증 정보를 제공하지 않습니다. 먼저 Home에 사용자가 보유한 서버가 있고 선택되어 있는지 확인한 뒤 Connectivity Test를 실행하세요. 연결 자체가 실패한다면 도메인 규칙을 더 추가해도 대개 해결되지 않습니다.

마지막으로 현재 파일, Global Routing 상태, 규칙 순서, DNS와 Host, 요청별 동작 순서로 확인하세요. 키워드 작성 방법은 규칙 참고 자료에서, 라우팅 상태 선택은 라우팅 모드 안내에서 확인할 수 있습니다. 여러 매개변수 묶음을 한꺼번에 바꾸기보다 변경 전후 파일을 보관하면 되돌리거나 원인을 찾기 쉽습니다.