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

이 글의 핵심

사용 가능한 서비스가 있고 .conf 파일을 읽거나 수정하려는 사용자를 위한 안내입니다. 먼저 Config 파일과 Home의 서버를 구분한 뒤 네 가지 설정 섹션의 문법을 확인하고, 설정을 전환한 다음 항목별 테스트로 변경 사항이 적용됐는지 확인합니다. 예시는 필드와 매칭 방식만 설명하며, 사용 가능한 서비스 정보는 포함하지 않습니다.

1. .conf 파일과 Home, Config, Settings의 관계

Shadowrocket의 .conf 파일은 대괄호로 섹션을 나누는 텍스트 설정 파일입니다. [General]에는 보통 전역 매개변수, [Rule]에는 트래픽 분기 규칙, [Host]에는 도메인 매핑, [URL Rewrite]에는 요청 URL 변경 규칙이 들어갑니다. 이 글에서는 네 섹션을 다루지만, 전체 설정이 이 네 섹션으로만 구성된다는 뜻은 아닙니다.

Home에서는 사용자가 보유한 서버를 선택하고 연결을 제어합니다. Config에서는 설정 파일을 관리하고 선택하며, Settings에서는 앱 설정을 관리합니다. 서비스 구독 업데이트와 원격 설정 업데이트는 서로 다른 작업입니다. 전자는 보통 서버 정보를 갱신하고, 후자는 설정 내용을 갱신합니다. 로컬 수정 사항이 덮어써지는지 판단하려면 먼저 어떤 종류의 리소스를 업데이트하는지 확인하세요.

4개 섹션

General, Rule, Host, URL Rewrite 설명

3곳

확인 위치: Home / Config / Settings

1개 항목

한 번에 매개변수 하나 또는 규칙 하나만 수정

판단 기준: 활성 설정을 확인한 다음 파일 내용을 살펴보세요

Config를 열어 현재 선택된 파일과 편집 중인 파일이 같은지 확인합니다. 그런 다음 Home으로 돌아가 Global Routing을 Config로 설정하고 트래픽 분기를 테스트합니다. 선택되지 않은 파일을 저장해도 그 안의 규칙이 연결에 자동 적용되지는 않습니다.

2. [General]: 전역 매개변수와 DNS 기준 설정

[General]에서는 키 = 값 형식을 사용합니다. DNS 관련 매개변수는 도메인 조회에 적용할 설정을 지정합니다. 서버 지연 시간 테스트에 성공했다고 해서 이름 해석도 정상이라고 단정할 수는 없습니다. 지연 시간 테스트는 해당 테스트 경로만 보여 줍니다. 실제 웹페이지 접속에는 대상 도메인, 조회 결과, 이후 연결 과정도 영향을 줍니다.

[General]
dns-server = system
ipv6 = false

dns-server = system은 시스템 DNS 설정을 사용한다는 뜻입니다. 비교를 위한 기준으로 활용할 수 있지만, 현재 네트워크의 DNS가 정상 작동한다는 의미는 아닙니다. 특정 리졸버를 사용하려면 연결 가능 여부와 신뢰성을 확인한 주소를 입력하고 네트워크 환경에 맞게 설정하세요. 출처가 불분명한 매개변수를 여러 개 한꺼번에 추가하지 마세요.

ipv6 = false는 IPv6 지원을 끄는 설정입니다. 이 예시는 비교하기 쉬운 테스트 환경을 마련하기 위한 것이며, 모든 네트워크에서 IPv6를 꺼야 한다는 뜻은 아닙니다. 기기 전체의 네트워크 스택을 변경하는 설정도 아닙니다. 기존 환경에서 IPv6를 사용한다면 원래 값을 유지하고 DNS 조회 기록과 실제 연결 결과를 함께 확인하세요.

수정하기 전에 기존 dns-server 값을 기록하고 복구할 수 있도록 설정 파일을 따로 보관하세요.
같은 도메인으로 테스트하면서 이름 해석 성공 여부와 연결 수립 여부를 각각 기록하세요. 두 가지 실패를 같은 문제로 취급하지 마세요.
일반적인 DNS는 포트 53을 사용합니다. DNS 요청에 도달할 수 있는지와 웹페이지의 443 포트에 연결할 수 있는지는 별도로 확인해야 합니다.
테스트 중에는 DNS, 서버, 규칙을 동시에 바꾸지 마세요. 어떤 변경이 영향을 줬는지 판단하기 어려워집니다.

3. [Rule]: 순서대로 매칭하고 FINAL로 마무리하기

[Rule]은 보통 위에서 아래 순서로 확인하며, 일치하는 규칙을 찾으면 해당 규칙의 정책을 적용합니다. 구체적인 규칙을 포괄적인 규칙보다 앞에 두세요. FINAL은 앞선 규칙과 일치하지 않은 요청을 처리하므로 마지막에 배치합니다. 아래 예시에는 문서용으로 예약된 도메인과 주소를 사용했으며, 접속을 권장하는 대상이 아닙니다.

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

DOMAIN-SUFFIX,example.com,PROXY는 해당 도메인과 하위 도메인에 매칭되므로 *.example.com 형식으로 쓸 필요가 없습니다. IP-CIDR은 대상 IP가 속한 네트워크 대역을 기준으로 매칭합니다. 예시의 no-resolve는 이 IP 규칙을 위해 별도로 도메인 조회를 하지 않는다는 뜻입니다. 모든 도메인을 먼저 조회한 뒤 대역을 확인할 것으로 기대해서는 안 됩니다.

GEOIP,CN,DIRECT는 대상 IP의 지리 정보 데이터에 따라 매칭합니다. 웹사이트의 언어, 도메인 접미사, 운영 주체를 판별하는 규칙은 아닙니다. 결과는 사용하는 데이터베이스에 따라 달라지므로 특정 도메인이 반드시 DIRECT로 연결된다고 보장할 수 없습니다. 도메인별 정책을 확실히 지정하려면 앞부분에 명시적인 도메인 규칙을 작성하세요.

매칭 필드

DOMAIN-SUFFIX: example.com: 도메인 접미사
IP-CIDR: 192.0.2.0/24: IPv4 네트워크 대역
GEOIP: CN: 대상 IP의 국가·지역 코드

명확한 도메인 규칙을 앞에 두고 IP 규칙은 실제 필요에 따라 배치하세요.

정책 필드

PROXY: 프록시 정책으로 연결 처리
DIRECT: 대상에 직접 연결
REJECT: 요청 거부

FINAL은 규칙 키워드입니다. 뒤에 FINAL,PROXY처럼 정책을 지정해야 합니다.

여기서 PROXY는 서버 주소, 포트, 인증 정보를 포함하지 않으며 사용 가능한 서비스를 생성하지도 않습니다. 실제로 연결할 서버는 사용자가 보유한 서버와 현재 선택에 따라 달라집니다. 알 수 없는 정책 이름이 나오면 설정 파일에 해당 정책이 별도로 정의되어 있는지 먼저 확인하세요. 이름을 프로토콜 이름으로 바로 바꾸지 마세요.

4. [Host]: 로컬 매핑과 트래픽 분기 규칙은 다릅니다

[Host]는 특정 도메인에 로컬 매핑을 적용합니다. 가장 간단한 형식은 도메인과 IP 주소를 등호로 연결하는 것으로, 주소가 고정된 테스트 환경에 적합합니다. 아래의 192.0.2.10은 문서용 예시 주소이며 실제 사이트에 접속할 수 있는지 확인하는 데 사용할 수 없습니다.

[Host]
lab.example.com = 192.0.2.10

이 항목은 “lab.example.com에 지정된 주소를 사용한다”는 뜻이지 “DIRECT로 연결한다”는 뜻은 아닙니다. 이름 해석이나 매핑으로 대상 주소가 정해진 뒤에도 연결은 해당 라우팅 설정에 따라 처리됩니다. 이 도메인의 아웃바운드 정책을 지정하려면 [Rule]에 별도 규칙을 작성하세요.

도메인 이전: 서버 주소가 바뀐 뒤에도 고정 매핑이 이전 IP를 가리킬 수 있으므로 함께 확인해야 합니다.
HTTPS: 매핑을 적용해도 인증서 검증 요건은 바뀌지 않습니다. 서버 인증서의 도메인은 요청한 도메인과 일치해야 합니다.
앱 캐시: 매핑을 수정한 뒤 새 연결을 시작하세요. 이미 수립된 연결은 다시 이름을 조회하지 않을 수 있습니다.
입력 형식: 왼쪽에는 도메인을 입력합니다. https://, 경로, 포트는 넣지 마세요.

한 번 조회한 주소를 동적 라우팅을 사용하는 사이트에 장기간 고정하지 마세요. 웹사이트가 CDN을 사용하거나 네트워크에 따라 주소를 배정하는 경우, 오래된 매핑이 정상적인 이름 조회를 우회해 일부 리소스만 시간 초과될 수 있습니다. 모든 요청이 동시에 실패하는 것과는 양상이 다릅니다.

5. [URL Rewrite]: URL 매칭과 변경 작업 지정

[URL Rewrite]는 요청 URL을 대상으로 하며 프록시 아웃바운드를 선택하는 기능은 아닙니다. 규칙에는 보통 매칭 표현식, 대상 주소, 작업이 포함됩니다. 아래 예시는 테스트 도메인의 HTTP 요청을 HTTPS로 리디렉션합니다. 끝의 302는 리디렉션 상태 코드이며 포트 번호가 아닙니다.

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

표현식 앞의 ^와 끝의 $는 매칭 범위를 제한합니다. \.는 도메인의 일반적인 마침표를 나타내며, (.*)는 경로와 그 뒤의 내용을 캡처합니다. 대상의 $1은 첫 번째 캡처 그룹을 참조합니다. 마침표를 .로 그대로 쓰면 정규식에서 임의의 한 문자와 매칭되어 예상보다 범위가 넓어질 수 있습니다.

먼저 직접 제어할 수 있는 HTTP 테스트 주소 하나로 규칙을 확인하세요. 복잡한 로그인 페이지부터 시작하지 마세요.
리디렉션이 발생하는지, 경로와 쿼리 매개변수가 예상대로 유지되는지 확인하세요.
대상이 원래 주소로 다시 리디렉션되지 않는지 확인해 순환을 방지하세요.
검증을 마친 뒤 매칭 범위를 조금씩 넓히고, 되돌릴 수 있도록 수정 전 규칙을 보관하세요.

6. Config에서 .conf 편집, 선택, 검증하기

편집을 시작하기 전에 현재 사용할 수 있는 파일을 복사해 두세요. 파일이 원격 설정에서 제공된 경우에는 로컬 사본으로 저장한 뒤 테스트해야 다음 원격 업데이트에서 수정 내용이 덮어써지는 일을 막을 수 있습니다. 사본 이름은 local-test.conf처럼 구분하기 쉽게 정하면 됩니다. 파일명만으로 설정 적용 여부가 결정되지는 않습니다.

기존 설정 백업 항목 하나 편집 저장 후 선택 연결 다시 수립 요청 확인

Config 열기: 대상 파일을 찾고 파일 작업 메뉴에서 텍스트 편집을 선택합니다. 편집 아이콘이나 표시 방식은 인터페이스 변경에 따라 달라질 수 있으니 실제로 표시되는 항목을 확인하세요.
섹션 경계 확인: 키와 값이 올바른 섹션에 있는지 확인하세요. dns-server = system을 [Rule]에 붙여 넣거나 FINAL,PROXY를 General 매개변수로 작성하지 마세요.
저장 후 선택: Config 파일 목록으로 돌아가 방금 저장한 파일에 활성 표시가 있는지 확인하세요. 편집기에서 파일을 열어 보는 것만으로 설정이 전환되지는 않습니다.
모드 확인: Home → Global Routing으로 돌아가 Config를 선택합니다. Proxy와 Direct는 전체 연결을 프록시 또는 직접 연결로 처리하는 방식과 비교할 때 사용하세요. 파일에 작성한 트래픽 분기 규칙이 적용됐음을 증명하는 방법으로는 적합하지 않습니다. Scene은 설정된 장면 조건과 함께 확인해야 합니다.
테스트 연결 다시 수립: 잠시 연결이 끊겨도 괜찮다면 다시 연결한 뒤 테스트 페이지를 새로 여세요. 기존 연결을 재사용하지 않도록 합니다. 요청 기록에서 대상, 정책, 오류 정보를 확인하세요.

Settings → On Demand에서는 설정한 조건에 따라 자동 연결되도록 할 수 있습니다. 이는 .conf 파일 선택과는 별개의 설정입니다. 연결 상태가 저절로 바뀌는 문제를 조사할 때는 On Demand 조건도 확인하세요. 자동 재연결을 방금 저장한 설정이 연결을 시작한 것으로 오해하지 마세요.

검증할 때는 비교할 수 있도록 현상을 기록하세요. 예를 들어 동일한 테스트 도메인이 수정 전에는 이름 조회에 성공하지만 연결 시간 초과가 발생했고, 수정 후에도 조회에는 성공하면서 규칙 매칭 결과가 DIRECT로 바뀌었다면 매칭과 아웃바운드 동작이 바뀌었다는 뜻입니다. 실제 접속이 복구됐는지는 페이지 요청이 완료되는지 추가로 확인해야 합니다. 연결 스위치만 확인해서는 충분하지 않습니다.

7. 설정 편집 시 자주 묻는 질문

규칙을 저장했는데도 왜 이전 정책으로 연결되나요?

먼저 Config에서 현재 선택된 파일을 확인한 다음 Home → Global Routing이 Config로 설정되어 있는지 확인하세요. 두 항목을 확인한 뒤 대상 규칙보다 위에 있는 포괄적인 규칙이 먼저 매칭되는지 살펴보고, 새 요청을 보내 기존 연결이 이전 정책을 계속 사용하고 있는 가능성을 제외하세요.

FINAL을 첫 줄에 두면 어떻게 되나요?

FINAL은 해당 위치까지 도달한 요청을 처리하므로 앞에 배치하면 뒤에 있는 일반 규칙이 매칭되지 않습니다. FINAL을 [Rule] 맨 아래로 옮기고 구체적인 도메인, 네트워크 대역, 기타 조건을 앞에 배치한 다음 순서를 하나씩 확인하세요.

업데이트 후 수동으로 수정한 내용이 사라지는 이유는 무엇인가요?

먼저 원격 설정을 업데이트했는지, Home에서 서비스 구독을 업데이트했는지 확인하세요. 원격 설정을 다시 가져오면 로컬 내용이 덮어써질 수 있습니다. 테스트 변경 사항을 오래 보관하려면 별도의 로컬 사본에 작성하고 이후에도 해당 사본이 선택되어 있는지 확인하세요.

Host 매핑을 삭제했는데도 도메인 접속에 문제가 있으면 어떻게 하나요?

저장한 뒤 다시 연결하고 대상 페이지를 닫았다가 새로 여세요. 다른 매핑이나 규칙, 앱 연결 캐시가 남아 있는지도 확인하세요. 이어서 DNS 응답과 실제 대상 주소를 확인해 이름 조회 실패, 연결 시간 초과, 인증서 오류를 구분하세요. 일반적인 해결책처럼 고정 IP를 반복해서 추가하지 마세요.

설정을 마친 뒤 검증된 로컬 사본을 보관하고 수정한 필드와 테스트 결과를 기록하세요. 나중에 문제가 생기면 이 기준 설정으로 되돌린 다음 수정 사항을 하나씩 복원하세요. 설정 전체와 서버를 동시에 바꾸는 것보다 원인을 찾기 쉽습니다.