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

이 글의 핵심 내용

자체 서버와 구독을 이미 보유하고 있으며 .conf 파일을 읽거나 수정하려는 사용자를 위한 안내입니다. 먼저 Config에서 현재 활성화된 파일을 확인한 다음 기본 매개변수, 분기 규칙, 도메인 매핑, URL 재작성을 차례로 살펴봅니다. 각 설정을 어느 섹션에 넣어야 하는지와 최소한의 수정으로 문제를 찾는 방법을 알아볼 수 있습니다. 도메인과 주소 예시는 문법 설명용이며, 실제로 사용할 수 있는 서버 설정이 아닙니다.

1. .conf 파일이란? 현재 사용 중인 파일 확인하기

.conf는 설정 텍스트 파일이며 Home의 서버 목록과는 다릅니다.Shadowrocket은 설정 파일로 규칙과 관련 매개변수를 관리할 수 있지만, 기존 구독이 정상적으로 업데이트되었다고 해서 현재 활성화된 규칙 파일까지 바뀌는 것은 아닙니다. 먼저 Config에서 선택된 설정 파일을 확인하고, Home → Global Routing에서 모드를 확인해야 해당 파일의 규칙이 트래픽 분기에 적용되는지 알 수 있습니다.

Config로 이동해 현재 선택된 파일을 찾아 파일명을 기록합니다. 편집할 예정이라면 먼저 원본 파일을 복사해 보관하세요.
해당 파일의 편집 화면을 열고 대괄호로 표시된 섹션 이름을 기준으로 내용을 확인합니다. 도메인만 검색한 뒤 곧바로 수정하지 마세요.
Home → Global Routing으로 돌아갑니다. 파일 규칙을 테스트하려면 Config를 선택하세요. Proxy와 Direct는 파일의 개별 규칙에 따라 경로를 선택하지 않습니다.
저장한 뒤 수정한 파일이 활성화되어 있는지 다시 확인하고 같은 대상으로 테스트합니다. 연결이 이전 상태를 유지한다면 연결을 끊었다가 다시 연결한 후 확인하세요.

섹션 이름에 따라 뒤따르는 내용을 해석하는 방식이 달라집니다.[General] 뒤에는 보통 key = value 형식의 매개변수가 오고, [Rule] 뒤에는 쉼표로 구분된 규칙이 옵니다. 다음 섹션 이름이 나올 때까지 같은 형식이 적용됩니다. [Host]에 DOMAIN-SUFFIX 규칙을 넣지 말고, 섹션 이름에 전각 대괄호를 사용하지 마세요.

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

2. [General]과 [Host]는 각각 무엇을 설정하나요?

[General]은 기본 동작을 설정하고, [Host]는 도메인과 주소 간의 고정 매핑을 지정합니다.이름 해석에 문제가 생기면 먼저 Config의 현재 파일에서 이 두 섹션을 확인하세요. 둘 다 트래픽 분기 규칙은 아닙니다. 도메인을 [Host]에 입력해도 요청이 반드시 DIRECT로 연결되는 것은 아니며, DNS 매개변수를 바꿔도 Global Routing이 자동으로 Config로 전환되지는 않습니다.

[General] 확인 항목

내용 형식: key = value
매개변수 예시: dns-server = system
주요 역할: DNS 등 기본 설정 지정
확인 위치: Config → 현재 파일 → 편집 화면

기존 매개변수의 의미를 먼저 확인한 뒤 하나씩 조정하세요. 섹션 전체를 한 번에 교체하지 마세요.

[Host] 확인 항목

내용 형식: 도메인 = IP 주소
문법 예시: lab.example.com = 192.0.2.10
주요 역할: 지정한 도메인에 고정 주소 매핑
포함하지 않는 항목: URL 경로 및 서버 포트

매핑 대상이 바뀌면 함께 업데이트해야 합니다. 이전 주소가 남아 있으면 연결이 계속 실패할 수 있습니다.

dns-server = system은 시스템 DNS를 사용한다는 뜻이지, 모든 요청의 아웃바운드 정책을 지정한다는 뜻은 아닙니다.현재 파일에서 다른 DNS 설정을 사용한다면 먼저 기존 값을 기록하고 변경 전후의 이름 해석 결과를 비교하세요. 도메인이 주소로 해석된 뒤에도 규칙, 선택한 서버, 원격 이름 해석 방식 등의 영향을 받을 수 있습니다. DNS 응답이 있다는 이유만으로 웹페이지에 접속할 수 있다고 판단하지 마세요.

[Host]는 HTTPS 인증서의 신원 확인을 바꾸지 않습니다.예를 들어 직접 관리하는 테스트 주소를 lab.example.com에 매핑해도 브라우저는 기존 도메인으로 접속하며, 서버 인증서는 해당 도메인에 유효해야 합니다. 주소 매핑이 정확해도 인증서 오류, 대상 포트의 미수신 상태, 해당 사이트에 대한 서버 설정 누락으로 접속이 실패할 수 있습니다. 매핑 문제를 감추기 위해 인증서 오류를 무시하지 마세요.

특정 도메인 하나만 문제가 있다면 [Host]에 오래된 매핑이 남아 있는지 확인한 뒤 해당 도메인에 적용되는 규칙도 살펴보세요.
여러 도메인의 이름 해석이 동시에 실패한다면 [General]의 DNS 매개변수를 확인하고 수정 전 파일과 비교하세요.
도메인은 해석되지만 연결 시간이 초과된다면 경로와 서버 포트를 추가로 확인하세요. HTTPS의 일반적인 포트는 443이며, 이름 해석에 성공해도 해당 포트에 연결할 수 있다는 뜻은 아닙니다.

3. [Rule]은 위에서부터 어떻게 적용되나요?

[Rule]은 작성된 순서대로 확인하며, 처음 일치하는 유효 규칙이 정책을 결정합니다.Home → Global Routing → Config로 이동한 뒤 현재 파일에서 규칙 순서를 확인하세요. 아래 흐름은 규칙에 따른 트래픽 분기 과정을 설명하며, DNS, Host, URL Rewrite가 내부적으로 항상 같은 고정 순서로 처리된다는 뜻은 아닙니다.

요청 확인 규칙을 차례로 확인 첫 번째 일치 항목 정책 적용 기본 처리

[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이라는 정확한 도메인만 일치합니다.	정확한 예외 규칙은 더 넓은 범위의 규칙보다 앞에 배치해야 합니다.
`DOMAIN-SUFFIX`	example.com과 그 하위 도메인에 일치합니다.	https://, 경로, 포트는 입력하지 마세요.
`IP-CIDR`	192.0.2.0/24 주소 대역에 일치합니다.	`no-resolve`는 이 규칙을 위해 도메인 이름 해석을 추가로 수행하지 않도록 합니다.
`GEOIP`	IP 지리 정보 데이터베이스를 기준으로 CN에 일치합니다.	IP 데이터를 기준으로 판정합니다. 도메인 접미사만으로는 지역을 판단할 수 없습니다.
`FINAL`	앞선 규칙에 일치하지 않은 요청을 처리합니다.	뒤에 오는 규칙을 먼저 차단하지 않도록 마지막에 배치하세요.

정확한 예외 규칙은 폭넓은 일치 규칙보다 앞에 와야 합니다.이 예시에서는 api.example.com이 먼저 DOMAIN에 일치해 DIRECT를 사용하고, 그 외에 example.com 접미사와 일치하는 요청은 PROXY를 사용합니다. 앞의 두 규칙 순서를 바꾸면 정확한 도메인도 접미사 규칙에 먼저 일치합니다. 여기서 PROXY는 프록시 정책을 뜻할 뿐 서버 설정을 자동으로 만들지는 않습니다. Home에서 사용할 수 있는 서버가 선택되어 있는지 확인하세요.

no-resolve는 모든 DNS 조회를 끄는 옵션이 아닙니다. 이 옵션은 해당 IP 규칙에서의 이름 해석 동작을 제한합니다. 대상 IP를 아직 확인하지 못한 도메인 요청이 no-resolve가 붙은 규칙에 반드시 일치한다고 볼 수는 없습니다. IP 주소로 직접 접속하는 요청은 이미 확보된 주소를 기준으로 판단할 수 있습니다. 문제를 확인할 때는 도메인 접속과 IP 직접 접속을 구분해 테스트하세요.

요약: 구체적인 예외 규칙을 먼저 배치한 다음 기본 정책을 조정하세요

특정 도메인의 연결 경로가 잘못되었다면 먼저 위쪽에 더 넓은 범위의 규칙이 있는지 확인하고 필요한 정확한 규칙을 앞에 배치하세요. FINAL의 정책부터 전역 변경하면 일치하지 않던 다른 요청의 경로까지 함께 바뀔 수 있습니다.

4. [URL Rewrite]와 도메인 트래픽 분기는 어떻게 다른가요?

[URL Rewrite]는 URL 일치 여부를 확인하고 주소를 다시 작성하며, 프록시 경로를 선택하지는 않습니다.요청 주소를 다른 주소로 리디렉션해야 할 때 이 섹션을 확인하세요. 특정 도메인을 PROXY로 보내려는 경우에는 [Rule]을 수정해야 합니다. 다음은 문서용 예시 도메인에만 적용되는 HTTP 리디렉션 문법이며, 일반적인 웹 이용에 사용할 규칙이 아닙니다.

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

^와 $는 일치 범위를 제한합니다. example\.com의 백슬래시는 마침표를 일반 문자로 일치시키기 위한 것입니다.
(.*)은 뒤에 오는 내용을 캡처하고, 대상 주소의 $1은 해당 캡처 결과를 참조합니다.
302는 다음 요청을 임시 리디렉션으로 보내는 응답 코드이며 프록시 서버 포트가 아닙니다.
대상 조건은 http://에만 일치하므로 이미 https://를 사용하는 대상은 같은 규칙에 다시 일치하지 않습니다.

VPN을 통해 연결된다는 이유만으로 HTTPS의 전체 경로가 자동으로 표시되는 것은 아닙니다.암호화된 URL 경로나 내용을 읽어 재작성하려면 일반적으로 MITM 관련 설정, 호스트 범위, 인증서 신뢰 설정이 필요합니다. URL Rewrite 규칙만 추가해서는 충분하지 않습니다. 이 예시는 문법 설명을 위해 HTTP 주소를 사용하므로 설정을 읽기 위해 인증서 신뢰 범위를 넓힐 필요는 없습니다.

재작성 결과를 확인할 때는 최종 페이지가 열리는지만 보지 말고 리디렉션 과정도 확인하세요.브라우저가 이전 리디렉션을 캐시했거나 앱이 HTTPS를 바로 사용하면 규칙이 적용되지 않은 것처럼 보일 수 있습니다. 먼저 원래 요청이 정규식에 실제로 일치하는지 확인한 다음 예상한 302 응답이 발생하는지 살펴보세요. 페이지가 마지막에 열렸다는 사실만으로 이 규칙이 적용되었다고 판단하지 마세요.

5. 파일을 수정한 뒤 단계별로 확인하는 방법

한 번에 변수 하나만 바꿔야 현상과 설정의 관계를 파악할 수 있습니다.테스트 전에 현재 파일, Global Routing 모드, 선택한 서버를 기록하세요. 이미 사용 중인 구독의 서버 목록을 방금 업데이트했다면 서버 선택도 고정해 두어 서버 변화와 규칙 변화를 혼동하지 않도록 하세요.

기준 상태 기록:정상 작동하는 원본 파일을 보관하고, 수정 전 같은 대상이 정상적으로 열렸는지, 시간 초과가 발생했는지, 이름 해석이나 인증서 오류가 있었는지 기록하세요.
모드 확인:Home → Global Routing에서 Config를 선택합니다. Scene을 사용하는 경우 장면 조건에 따라 실제로 선택된 모드를 확인하세요. 해당 파일의 규칙이 적용 중이라고 섣불리 가정하지 마세요.
한 곳만 수정:예를 들어 정확한 DOMAIN 규칙 하나만 추가합니다. 저장 후 해당 파일이 계속 활성화되어 있는지 확인하고 요청을 다시 보냅니다.
기존 연결 제외:이미 연결된 장시간 세션은 이전 경로를 계속 사용할 수 있습니다. 기존 요청을 종료하고 필요하면 다시 연결한 뒤 같은 대상에 접속하세요.
원본과 비교:수정 후 문제가 발생했다면 원본 파일을 복원해 다시 테스트하세요. 복원 후에도 문제가 계속되면 규칙을 계속 추가하지 말고 서버, 네트워크, 대상 서비스도 확인하세요.

Connectivity Test는 연결 상태를 파악하는 단서일 뿐, 실제 서비스 요청 테스트를 대신하지 않습니다.Home에서 테스트한 뒤에도 문제가 발생하는 도메인을 직접 열어 보세요. 테스트 성공은 해당 조건에서 테스트 대상에 연결할 수 있다는 뜻이지, 모든 도메인의 DNS, Host 매핑, 규칙, URL Rewrite가 올바르다는 뜻은 아닙니다.

On Demand는 연결을 시작하는 조건을 설정하며, 개별 요청의 규칙 선택을 해결하지는 않습니다.네트워크 상태에 따라 연결이 자동으로 바뀐다면 Settings → On Demand에서 트리거 설정을 확인하세요. 이 기능이 켜져 있는데도 도메인의 연결 경로가 잘못되었다면 Global Routing과 Config를 확인해야 합니다. 두 종류의 문제를 같은 스위치로 반복해서 해결하려 하지 마세요.

원본 파일에서는 정상이고 새 파일에서 문제가 생겼다면 방금 수정한 섹션과 규칙 순서를 먼저 비교하세요.
DIRECT는 정상이고 PROXY에서 문제가 생긴다면 선택한 서버와 대상까지의 연결 가능성을 확인하세요. DNS 설정 오류라고 바로 단정하지 마세요.
특정 도메인만 문제가 있다면 정확한 규칙, 고정 매핑, 해당 도메인의 재작성 조건을 확인하세요.
설정 파일이 원격에서 업데이트된다면 로컬 사본을 보관하고, 업데이트 후 직접 수정한 내용이 대체되었는지 확인하세요.

6. 설정 파일 관련 자주 묻는 질문

규칙을 파일에 입력했는데 왜 모든 요청이 같은 경로로 연결되나요?

먼저 Home → Global Routing에서 Proxy나 Direct가 선택되어 있지 않은지 확인한 다음 Config에서 활성화된 파일을 확인하세요. 대상 규칙보다 위에 더 넓은 DOMAIN-SUFFIX 규칙이 있는지, FINAL이 앞쪽에 배치되어 있는지도 살펴보세요. 수정 후에는 이전 세션을 재사용하지 않도록 연결을 새로 시작하세요.

구독이 있으면 .conf도 따로 확인해야 하나요?

네. 사용 중인 서버 구독은 일반적으로 서버 정보를 관리하고, 규칙 파일은 별도의 설정을 담당합니다. 구독을 업데이트한 후 Home에서 서버가 바뀌었는지 확인하고 Config에서 현재 파일도 점검하세요. 서버 목록 업데이트에 성공했다는 이유만으로 규칙 파일까지 업데이트되었다고 판단하지 마세요.

[Host]에 lab.example.com:443처럼 입력해도 되나요?

이 섹션에는 도메인과 IP 주소의 매핑을 입력하며 도메인 뒤에 포트를 붙이지 않습니다. 서버 포트는 요청 URL이나 연결 설정으로 결정됩니다. 대상이 HTTPS의 443 포트를 사용한다면 주소 매핑, 443 포트의 연결 가능 여부, 인증서 도메인을 각각 확인하세요. 세 항목을 Host 한 줄에 합치면 안 됩니다.

FINAL,DIRECT와 FINAL,PROXY 중 무엇을 선택해야 하나요?

규칙에 일치하지 않는 요청을 어떻게 처리할지에 따라 선택하세요. 첫 번째는 기본 요청을 직접 연결하고, 두 번째는 기본 요청에 프록시 정책을 적용합니다. Config에서 FINAL 위에 어떤 도메인과 주소가 포함되는지 먼저 확인한 뒤 나머지 트래픽의 처리 방식을 정하세요. 어느 쪽도 완전한 규칙 설계를 대신하지는 않습니다.

[URL Rewrite]를 삭제하면 모든 웹페이지 문제가 해결되나요?

아니요. 원본 파일을 보관한 뒤 문제가 발생한 대상과 관련된 재작성 규칙만 잠시 제거하고 테스트하세요. 문제가 그대로라면 원래 내용을 복원하고 [Host], DNS, [Rule]을 계속 확인합니다. 문제가 사라지면 정규식의 일치 범위를 좁히고 리디렉션 대상을 점검하세요.