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

이 글의 핵심

.conf를 읽을 때는 기본 설정, 라우팅 규칙, 도메인 매핑, 요청 재작성을 구분한 뒤 현재 활성화된 파일과 Global Routing을 확인하세요. 기존에 사용할 서비스와 구독이 있고 로컬 설정을 수정하려는 사용자를 위한 글입니다. 예시는 구문 설명용이며 실제 연결 정보는 포함하지 않습니다. 수정 후에는 앱의 연결 기록에서 규칙이 어떻게 적용됐는지 확인하세요.

1. .conf 섹션 구조: 섹션 이름이 역할을 결정합니다

Shadowrocket의 .conf는 텍스트 형식의 설정 파일입니다. 대괄호로 묶인 이름이 섹션을 나타내며, 다음 섹션 이름이 나올 때까지의 내용은 해당 섹션에 속합니다. [General]에는 주로 키와 값 설정이, [Rule]에는 한 줄에 하나씩 매칭 규칙이 들어갑니다. 올바른 내용을 잘못된 섹션에 넣으면 기대한 대로 작동하지 않습니다.

Home에서는 연결과 서버 선택을, Config에서는 설정 파일 관리를, Settings에서는 앱 설정을 처리합니다. 구독으로 제공되는 서버 정보와 .conf에서 트래픽 경로를 정하는 규칙은 서로 다른 항목입니다. 서버 목록을 가져오거나 업데이트해도 현재 설정 파일이 자동으로 바뀌지는 않습니다.

4개 섹션

General, Rule, Host, URL Rewrite 살펴보기

3개 메뉴

Home, Config, Settings의 역할

최종 규칙 1개

예시에서는 FINAL을 Rule 섹션의 마지막에 배치합니다

아래 코드는 구조를 확인하기 위한 예시이며, 서버 정보가 포함된 완전한 연결 설정이 아닙니다. example.com은 예시 도메인이고 192.0.2.10은 문서용 예시 주소입니다. 실제 설정에 사용할 값으로 오해하지 않도록 주의하세요.

[General]
dns-server = system

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

[Host]
example.com = 192.0.2.10

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

한 파일에 여러 섹션이 있다고 해서 모든 요청이 파일의 섹션 순서대로 처리되는 것은 아닙니다. 섹션은 설정을 정리하는 방식이며, 파싱·라우팅·재작성에는 각각 다른 처리 조건이 적용됩니다. 특히 위에 적힌 순서를 ‘Rule 다음에 Host, 마지막으로 URL Rewrite가 처리되는 고정 요청 흐름’으로 해석하면 안 됩니다.

2. General: 기본 동작과 DNS 설정

[General]에는 기본 설정이 들어갑니다. 이 섹션을 살펴볼 때는 키 이름, 등호 오른쪽의 값, 값 목록의 구분 기호를 하나씩 확인하세요. 다른 설정 형식에서 비슷해 보이는 항목을 그대로 붙여 넣지 말고, Shadowrocket 편집 화면에서 인식·저장되어 실제로 사용할 수 있는 설정 항목인지 확인해야 합니다.

[General]
dns-server = system

여기서 dns-server = system은 시스템 DNS를 사용한다는 뜻입니다. 모든 요청이 반드시 DIRECT로 처리된다는 의미도 아니고, 특정 사이트를 PROXY로 보내는 설정도 아닙니다. DNS는 도메인 이름을 해석하고 라우팅 규칙은 처리 정책을 선택합니다. 두 항목은 문제 해결 결과에 서로 영향을 줄 수 있지만 역할은 다릅니다.

도메인은 열리지 않지만 IP 주소로는 응답이 있는 경우: 먼저 DNS 설정과 해석 결과를 확인하세요. 곧바로 Rule 전체를 교체하지 마세요.
도메인은 해석되지만 출구 정책이 예상과 다른 경우: DNS만 바꾸지 말고 Global Routing과 적용된 Rule을 확인하세요.
네트워크를 바꾼 뒤 결과가 달라지는 경우: 시스템 DNS는 현재 네트워크에 따라 달라질 수 있습니다. 테스트에 Wi-Fi와 셀룰러 네트워크 중 무엇을 사용했는지 기록하세요.
기존 파일을 편집하는 경우: 같은 이름의 기존 설정을 우선 수정하세요. 동일한 키를 여러 번 작성해 적용 결과가 불분명해지는 일을 피할 수 있습니다.

DNS 변경과 라우팅 변경은 따로 테스트하세요. General 설정 여러 개와 Host 매핑, Rule을 한 번에 바꾸면 페이지가 다시 열리더라도 어떤 항목이 효과를 냈는지 알기 어렵고, 나중에 원래 상태로 되돌리기도 까다로워집니다.

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

[Rule]은 요청에 적용할 정책을 결정합니다. 규칙은 위에서부터 순서대로 매칭되며, 먼저 조건에 맞는 규칙이 처리 방식을 결정합니다. 따라서 구체적인 규칙을 포괄적인 규칙보다 앞에 두어야 합니다. FINAL에는 도메인이나 주소 조건이 없으며 앞선 규칙에 매칭되지 않은 트래픽을 처리하므로 이 섹션의 마지막에 배치하세요.

키워드	구문 예시	확인 사항
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	해당 도메인과 하위 도메인에 매칭됩니다. 문자열이 포함되기만 하면 매칭되는 방식은 아닙니다.
`IP-CIDR`	`IP-CIDR,192.0.2.0/24,DIRECT,no-resolve`	IPv4 대역을 기준으로 매칭합니다. no-resolve를 사용하면 이 규칙의 매칭을 위해 도메인 조회를 별도로 시작하지 않습니다.
`GEOIP`	`GEOIP,CN,DIRECT`	IP 지리 데이터베이스의 분류를 기준으로 판단하며, 웹페이지 언어를 기준으로 하지는 않습니다.
`FINAL`	`FINAL,PROXY`	추가 매칭 조건 없이 마지막에 기본 처리 규칙으로 사용합니다.

PROXY와 DIRECT는 정책이지 프로토콜 이름이 아닙니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 연결 유형과 매개변수는 해당 서버 설정에서 확인해야 합니다. 정책 대신 FINAL,Trojan이라고 작성해서는 안 됩니다. 사용자 지정 정책 이름을 사용한다면 해당 이름이 실제로 존재하고 사용할 수 있는지도 확인하세요.

[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

이 순서에서는 api.example.com이 먼저 DOMAIN에 매칭되어 DIRECT를 사용하고, www.example.com은 뒤에 있는 DOMAIN-SUFFIX에 매칭되어 PROXY를 사용할 수 있습니다. DOMAIN-SUFFIX를 앞에 배치하면 먼저 설정한 정확한 예외 규칙이 적용될 기회를 잃습니다. 테스트할 때는 전체 대상 호스트명을 사용하세요. 같은 사이트의 다른 하위 도메인으로 대신 테스트하면 안 됩니다.

요점: 먼저 매칭된 규칙을 확인하고 마지막 기본 규칙을 수정하세요

대상 트래픽이 앞에 있는 DOMAIN 또는 DOMAIN-SUFFIX 규칙에 이미 매칭됐다면 FINAL을 바꿔도 정책은 달라지지 않습니다. 먼저 연결 기록에서 매칭 결과를 확인한 뒤 해당 규칙의 위치나 내용을 수정하세요.

4. Host와 URL Rewrite: 주소 매핑과 요청 재작성은 다릅니다

[Host]는 지정한 도메인에 주소를 매핑하고, [URL Rewrite]는 요청 URL의 매칭 표현식에 따라 URL을 재작성하거나 리디렉션합니다. 전자는 ‘이 이름이 어떤 주소를 가리키는가’를, 후자는 ‘조건에 맞는 URL을 어떻게 바꿀 것인가’를 처리합니다. 둘 다 Rule의 라우팅 정책을 대신하지는 않습니다.

Host 매핑

섹션 이름: [Host]
왼쪽: example.com
오른쪽: 192.0.2.10
작성 방법: example.com = 192.0.2.10

예시 주소는 구문을 설명하기 위한 것입니다. 실제 매핑 값은 사용자가 직접 확인해야 합니다.

URL Rewrite 리디렉션

섹션 이름: [URL Rewrite]
매칭 표현식: ^http://example\.com/
대상 주소: https://example.com/
동작: 302, 임시 리디렉션

표현식, 대상 주소, 동작은 공백으로 구분합니다.

Host는 브라우저 주소창의 도메인을 IP 주소로 바꾸지 않으며, 대상 서버가 해당 도메인을 자동으로 처리하게 만들지도 않습니다. HTTPS에서는 인증서 이름이 접속한 호스트명과 일치해야 합니다. 도메인을 일치하지 않는 서버에 매핑하면 인증서 오류가 발생하거나 사이트 응답이 예상과 다를 수 있습니다. 인증서 검증을 끄는 대신 매핑을 바로잡으세요.

URL Rewrite 예시에서 ^는 문자열의 시작부터 매칭하고, \.은 도메인의 마침표 문자와 매칭하며, 302는 클라이언트를 대상 URL로 리디렉션합니다. 이 예시는 HTTP URL을 HTTPS 주소로 리디렉션하는 방법만 보여 주며, 모든 경로와 쿼리 매개변수가 유지된다는 보장은 없습니다. 이를 유지하려면 캡처 그룹과 치환 표현식을 명확히 설계해야 합니다.

먼저 테스트 URL 하나로 표현식이 맞는지 확인하세요. 모든 도메인에 매칭될 수 있는 지나치게 넓은 표현식은 바로 사용하지 마세요.
HTTP 예시에서는 HTTPS 콘텐츠를 복호화할 필요가 없습니다. 규칙이 HTTPS의 경로나 콘텐츠를 읽어야 한다면 별도의 HTTPS 복호화 조건과 신뢰 설정이 필요한 경우가 많습니다.
Host를 추가한 뒤 접속에 문제가 생기면 해당 매핑을 먼저 되돌리세요. URL Rewrite를 추가한 뒤 리디렉션이 반복되면 대상 URL이 같은 규칙에 다시 매칭되는지 확인하세요.

5. Config 편집 절차: 백업, 저장, 활성화, 확인

Config에서 파일을 편집하기 전에 실제로 활성화된 설정 파일이 무엇인지 확인하세요. 파일이 목록에 있는 상태, 텍스트가 저장된 상태, 설정이 선택되어 활성화된 상태는 서로 다릅니다. 활성화되지 않은 파일만 수정하면 현재 연결에는 새 규칙이 적용되지 않습니다.

원본 보관복사본 편집저장 및 활성화모드 확인새 요청 테스트기록 확인

원본 보관: Config에서 원본 파일 이름을 확인하고 파일 작업 기능으로 복사본을 만들거나 원본을 내보내세요. 원격 설정 주소에서 가져온 파일이라면 이후 업데이트가 수동 변경 사항을 덮어쓰지 않도록 복원 가능한 로컬 사본을 먼저 보관하세요.
편집 화면 열기: 대상 설정의 파일 작업에서 텍스트 편집 기능으로 이동하세요. 섹션 이름은 유지하고 필요한 항목만 수정합니다. 앱 화면 구성에 따라 편집 기능이 파일 작업 메뉴에 있을 수 있으므로 현재 화면을 기준으로 확인하세요.
구문을 확인하고 저장: Rule 필드는 영문 쉼표로, General과 Host의 키·값은 등호로, URL Rewrite 필드는 공백으로 구분합니다. 한글 쉼표나 전각 대괄호, 설명 문구가 매개변수에 들어가지 않도록 주의하세요.
설정을 선택: Config 목록으로 돌아가 편집한 파일이 활성화되어 있는지 확인하세요. 그런 다음 Home에서 현재 서버와 연결 상태를 살펴보세요.
Global Routing 확인: Rule을 테스트할 때는 Config를 사용하세요. Proxy와 Direct는 전체 라우팅 모드이므로 접속 결과만으로 특정 Rule 한 줄이 적용됐는지 판단할 수 없습니다. Scene을 사용한다면 해당 Scene에 실제로 설정된 구성과 정책도 확인하세요.
새 연결 만들기: 저장한 뒤 테스트 요청을 새로 보내고, 필요하면 연결을 끊었다가 다시 연결하세요. 기존 연결이나 캐시에 이전 상태가 남아 있을 수 있으므로 새 연결 기록에서 대상 도메인, 매칭 규칙, 최종 정책을 비교하세요.

Settings → On Demand는 자동 연결 조건을 다루며 Rule의 순서를 정하지 않습니다. ‘수정한 뒤 자동으로 다시 연결되는’ 문제는 이 메뉴에서 확인하세요. 특정 도메인에 잘못된 정책이 적용되는 문제라면 Global Routing과 현재 설정 파일을 확인해야 합니다. 자동 연결 문제와 트래픽 분기 문제를 구분해야 수정할 범위를 정확히 파악할 수 있습니다.

6. 자주 묻는 질문: 설정 미적용, 업데이트 덮어쓰기, 되돌리기

아래 문제는 현재 파일, 현재 모드, 새 요청 기록을 함께 확인해야 합니다. 브라우저에서 페이지가 열린다는 사실은 한 번 접속에 성공했다는 뜻일 뿐, 특정 규칙이 실행됐거나 예상한 서버가 사용됐다는 증거는 아닙니다.

Rule을 저장했는데 왜 기존 정책이 계속 적용되나요?

먼저 Config에서 방금 편집한 파일이 선택되어 있는지 확인한 다음, Home → Global Routing이 Config로 설정되어 있는지 확인하세요. 새 요청을 보내 연결 기록을 살펴보세요. 앞쪽 규칙에 이미 매칭됐다면 해당 규칙을 수정하거나 순서를 바꾸세요. FINAL 뒤에 규칙을 계속 추가하는 방법은 적절하지 않습니다.

구독을 업데이트하면 직접 작성한 .conf도 함께 업데이트되나요?

서버 구독 업데이트와 원격 설정 업데이트는 서로 다른 작업입니다. Home의 서버 목록을 업데이트했는지, Config의 원격 파일을 업데이트했는지 먼저 확인하세요. 원격 설정을 다시 가져오면 로컬 내용이 대체될 수 있으므로 중요한 수정 사항은 복사본으로 보관하고 업데이트 후 항목별로 비교하세요.

Host를 추가한 뒤 인증서 오류가 발생하면 어디를 수정해야 하나요?

새로 추가한 매핑을 먼저 되돌리고 새 연결로 다시 테스트하세요. 매핑한 주소가 원래 호스트명을 제공하는지 확인하고 서버 인증서도 점검하세요. 잘못된 매핑을 유지하려고 인증서 검증을 끄지 마세요. Host는 주소 대응 관계만 바꿀 수 있으며 인증서가 적용되는 이름은 바꾸지 못합니다.

설정을 잘못 수정했을 때 기존 구독에 영향을 주지 않고 복구하려면 어떻게 하나요?

Config에서 백업 파일을 다시 선택하고 테스트 전 Global Routing 상태로 되돌린 다음, 연결을 새로 만들어 확인하세요. 먼저 Home에 있는 기존 서버나 구독을 삭제하지 마세요. 이전 설정이 정상적으로 복구됐는지 확인한 뒤 복사본에서 한 번에 한 항목씩 변경해 문제가 생긴 줄을 찾으세요.

최종 확인 순서는 파일 활성화 여부, 라우팅 모드, 매칭 결과, DNS·Host·재작성 조건입니다. 설정 파일의 장점은 동작을 확인하고 변경을 되돌릴 수 있다는 데 있습니다. 한 파일에 가능한 한 많은 항목을 넣는 것이 목적은 아닙니다.