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

이 글 미리보기

이 글은 iPad 또는 iPhone에서 Shadowrocket을 사용하며 설정 파일을 편집하려는 분을 위한 안내입니다. 섹션별로 전역 매개변수, 트래픽 분기 규칙, 도메인 매핑, 요청 재작성을 구분하고 간단한 예제로 규칙 순서와 적용 조건을 확인합니다. 연결 테스트는 사용자가 이미 보유한 서비스 및 구독을 전제로 합니다. 예시 주소는 문법 설명용이며 실제로 사용할 수 있는 서비스가 아닙니다.

.conf 파일, 구독, 현재 연결의 차이

.conf는 설정 텍스트 파일이며, 대괄호로 표시된 제목이 섹션을 구분합니다. 제목 아래의 내용은 해당 섹션에 속합니다. [General]은 주로 키-값 형식을, [Rule]은 쉼표로 구분된 규칙 행을 사용합니다. 같은 작성 방식을 모든 섹션에 적용할 수는 없습니다. #으로 시작하는 단독 행은 주석으로 사용할 수 있습니다. 설명은 별도 행에 작성해 매개변수 값에 섞이지 않도록 하는 것이 좋습니다.

Home에서는 연결, 서버 선택, Global Routing 확인을 주로 합니다. Config에서는 설정 파일을 관리하고 선택하며, Settings에서는 앱 설정을 조정합니다. 기존 구독은 보통 서버 목록을 관리하는 데 사용되므로, 서버 항목이 업데이트됐다고 해서 현재 규칙 파일까지 교체된 것은 아닙니다. 설정 파일이 원격 리소스를 참조할 수도 있으니 업데이트 출처를 추가로 확인해야 합니다.

기존 설정 백업 섹션별 확인 저장 후 선택 라우팅 확인 새 요청 보내기

Config에서 편집하기 전에 원본 파일을 복사해 두고, Home에서 현재 선택된 서버와 Global Routing 상태를 기록하세요. 파일을 저장했다고 해서 사용 중인 설정으로 선택된 것은 아닙니다. 설정 파일을 선택했더라도 모든 트래픽이 반드시 해당 분기 규칙을 따르는 것은 아닙니다. 문제를 확인할 때는 ‘파일 내용’, ‘현재 설정’, ‘라우팅 모드’를 따로 살펴보세요.

4개 섹션

General, Rule, Host, URL Rewrite 확인

4가지 유형

규칙 예제에 DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL 사용

2회

수정할 때마다 대상 요청 테스트와 원상 복구 확인

판단 순서: 설정이 선택됐는지 먼저 확인한 뒤 문법 오류를 점검합니다

편집 전후 요청 결과가 완전히 같다면 규칙을 더 추가하기 전에 Config에서 선택한 파일과 Home → Global Routing을 확인하세요. 한 번에 한 섹션만 수정해야 결과를 구체적인 변경 사항과 연결할 수 있습니다.

[General]: 키-값 형식의 전역 매개변수

[General]에서는 설정 파일 전체 동작에 영향을 주는 매개변수를 지정합니다. 아래 예제는 시스템 DNS 사용, IPv6 비활성화, 시스템 트래픽 우회를 보여 주며 키 = 값 형식을 설명합니다. 문법 예시일 뿐, 모든 네트워크에 적합한 설정 조합은 아닙니다.

[General]
# 시스템에서 제공하는 DNS 사용
dns-server = system

# IPv6 사용 여부
ipv6 = false

# 시스템 관련 트래픽의 우회 허용
bypass-system = true

dns-server = system: 시스템에서 제공하는 DNS를 사용합니다. Wi-Fi를 바꾸면 시스템에서 사용할 수 있는 DNS 환경도 달라질 수 있으므로 두 네트워크에서 같은 결과가 나온다고 단정할 수 없습니다.
ipv6 = false: 이 설정의 IPv6 동작을 제어하며, 라우터나 기기 전체의 IPv6를 끄는 것은 아닙니다. 연결에 IPv6가 필요하다면 변경하기 전에 서버 주소와 현재 네트워크를 확인하세요.
bypass-system = true: 시스템 트래픽의 우회 처리와 관련된 설정입니다. 특정 웹사이트에 DIRECT를 지정하는 규칙은 아닙니다. 웹사이트별 분기는 [Rule]에서 확인하세요.

같은 키에 서로 충돌하는 값을 여러 개 입력하지 마세요. 설정 파일을 합칠 때는 기존 키를 먼저 확인하고, 전체 섹션을 그대로 덧붙이기보다 어떤 값을 남길지 결정하세요. DNS 문제도 ‘서버 도메인을 확인할 수 없음’과 ‘대상 웹사이트 도메인을 확인할 수 없음’을 구분해야 합니다. 두 경우는 연결 과정의 서로 다른 단계에 영향을 줍니다.

[Rule]: 한 줄씩 매칭하고 구체적인 조건을 앞에 배치

[Rule]에서는 요청에 적용할 정책을 결정합니다. 일반적인 형식은 규칙 유형,매칭 값,정책입니다. FINAL에는 매칭 값이 없으므로 적용할 정책만 작성합니다. 규칙은 순서대로 확인되며, 앞에서 이미 일치한 요청은 뒤에 있는 포괄적인 조건으로 다시 분류되지 않습니다.

[Rule]
# example.com 및 하위 도메인 매칭
DOMAIN-SUFFIX,example.com,PROXY

# 문서용 예시 IP 대역이며 실제 서비스 주소가 아닙니다
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve

# 대상 IP의 지역 데이터베이스 결과로 매칭
GEOIP,CN,DIRECT

# 앞선 규칙에 일치하지 않을 때 적용
FINAL,PROXY

PROXY는 프록시 정책을 뜻하며 실제로 사용할 수 있는 프록시 출구가 필요합니다. DIRECT는 직접 연결을 뜻합니다. 직접 만든 정책 그룹을 사용한다면 규칙 끝에 실제로 존재하는 이름을 입력해야 합니다. 철자, 공백, 대소문자를 확인하세요. 존재하지 않는 그룹 이름을 입력해도 해당 출구가 자동으로 만들어지지는 않습니다.

키워드	매칭 대상	확인할 사항
`DOMAIN-SUFFIX`	도메인 및 하위 도메인	프로토콜, 경로, 포트는 입력하지 않습니다. 예를 들어 example.com만 작성합니다.
`IP-CIDR`	IPv4 주소 대역	/24는 네트워크 프리픽스 길이입니다. no-resolve는 이 규칙만을 위해 도메인 조회가 발생하지 않도록 합니다.
`GEOIP`	대상 IP의 지역 정보	기기의 위치나 웹페이지 언어를 기준으로 매칭하는 것이 아닙니다.
`FINAL`	앞선 규칙과 일치하지 않은 나머지 요청	마지막에 배치하세요. 앞에 두면 이후 규칙이 매칭될 기회를 잃습니다.

이 섹션을 확인하려면 Home → Global Routing에서 Config를 선택하고, Config에서 방금 편집한 파일을 사용 중인지 확인하세요. Proxy는 전체 프록시 모드, Direct는 전체 직접 연결 모드입니다. Scene은 설정된 시나리오에 따라 처리되며 Config와 같은 의미가 아닙니다. 규칙별 동작을 확인하려면 전체 모드나 시나리오 전환으로 인한 영향을 먼저 배제하세요.

[Host]: 도메인 매핑을 바꿔도 연결 출구는 바뀌지 않습니다

[Host]에서는 도메인에 대응하는 주소를 지정합니다. 아래 예제는 완전한 호스트 이름을 문서용 예약 주소에 연결하며, 형식은 호스트명 = IP 주소입니다. 이 주소에는 웹사이트가 배포되어 있지 않으므로 복사 후 요청이 실패하는 것은 정상입니다. 실제 서버의 가용성을 판단하는 데 사용하지 마세요.

[Host]
# 형식 설명용
portal.example.com = 192.0.2.10
api.example.com = 198.51.100.20

Host 매핑은 HTTP 리디렉션도 아니고 DOMAIN-SUFFIX 규칙도 아닙니다. 브라우저 주소 표시줄에는 기존 도메인이 그대로 표시될 수 있으며, HTTPS 인증서도 요청한 도메인과 일치해야 합니다. 해당 도메인의 인증서가 없는 서버를 가리키면 네트워크 연결에 성공하더라도 인증서 오류가 발생할 수 있습니다. 매핑 문제를 숨기려고 인증서 오류를 무시하지 마세요.

도메인 매핑 확인

섹션: [Host]
호스트명: portal.example.com
대상 주소: 192.0.2.10
작성 형식: portal.example.com = 192.0.2.10

주소를 지정해도 대상 서버에 해당 웹사이트가 설정되어 있다는 뜻은 아닙니다.

트래픽 분기 대상 확인

섹션: [Rule]
규칙 유형: DOMAIN-SUFFIX
매칭 값: example.com
대상 정책: DIRECT 또는 이미 존재하는 프록시 정책

연결 출구 선택과 DNS 주소 지정은 서로 독립된 설정입니다.

확인할 때는 완전한 호스트 이름으로 새 요청을 보내세요. 기존 연결이 재사용될 수 있으므로 웹페이지가 계속 열리는지만 확인해서는 안 됩니다. 매핑을 제거한 뒤 정상화된다면 대상 주소, 서버의 서비스 수신 설정, 인증서를 확인하세요. 더 포괄적인 직접 연결 규칙을 계속 추가하지 마세요. 원격 프록시가 도메인을 다시 조회하는지는 연결 방식에 따라 다를 수 있으므로, 로컬 매핑이 모든 원격 DNS 조회를 강제로 제어한다고 생각하지 마세요.

[URL Rewrite]: URL 매칭 후 재작성 동작 실행

[URL Rewrite]에서는 URL 매칭과 동작을 처리하며 [Rule]의 쉼표 형식은 사용하지 않습니다. 아래 예제는 HTTP 주소를 HTTPS로 임시 리디렉션합니다. 동작의 302는 리디렉션 상태 코드이지 서버 포트가 아닙니다.

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

^는 URL의 시작 부분부터 매칭한다는 뜻으로, 주소 중간에서 의도치 않게 일치하는 것을 방지합니다.
example\.com에서 백슬래시는 마침표를 정규 표현식의 임의 문자로 취급하지 않고 일반 문자로 매칭하도록 합니다.
(.*)는 도메인 뒤의 내용을 캡처하고, 대상에 있는 $1은 해당 내용을 참조합니다.
url 302는 URL 리디렉션 동작을 지정합니다. 재작성 후 생성된 새 요청도 정상적인 DNS 조회, 트래픽 분기, 연결 설정이 필요합니다.

재작성 기능이 서버의 기능을 보완해 주지는 않습니다. 대상 사이트가 실제로 HTTPS를 지원하고 인증서도 유효해야 합니다. 대상 주소가 다시 원래 주소로 되돌아가면 리디렉션 루프가 발생할 수 있습니다. 먼저 정확한 도메인에 적용되는 규칙 하나로 테스트하고, 처음부터 모든 HTTP 주소에 포괄적인 정규식을 적용하지 마세요.

저장 후 확인 순서와 자주 묻는 문제

네 섹션은 하나의 파일에 함께 들어갈 수 있지만, 기계적으로 실행되는 네 단계의 파이프라인으로 이해해서는 안 됩니다. General은 전역 동작에 영향을 주고, Rule은 정책을 매칭하며, Host는 도메인 매핑에 영향을 주고, URL Rewrite는 표시되는 요청 URL을 처리합니다. 문제를 찾을 때는 실제 증상을 기준으로 나누어 확인하세요. 마지막 섹션이 앞의 모든 설정을 덮어쓴다고 생각하면 안 됩니다.

Config에서 사본을 저장하고 해당 파일을 선택했는지 확인하세요. 이름이 같은 다른 설정 파일을 잘못 선택하지 않았는지도 확인합니다.
Home으로 돌아가 서버가 사용 가능한지 확인한 뒤, 규칙 기반 트래픽 분기를 테스트하도록 Global Routing을 Config로 설정하세요.
대상에 새 요청을 보내고 대상 도메인, 예상 정책, 실제 연결 결과, 오류 메시지를 기록하세요. 필요한 경우 관련 요청 기록도 확인합니다.
방금 변경한 항목 하나를 되돌린 뒤 다시 테스트하세요. 변경과 되돌리기에 따라 결과가 안정적으로 달라지는 것을 확인한 후 다음 설정을 합치세요.

Rule을 수정했는데 왜 모두 직접 연결되나요?

먼저 Home → Global Routing이 Direct로 설정되어 있는지 확인한 다음 Config에서 선택된 파일을 확인하세요. Config를 사용 중이라면 대상 도메인보다 앞에 일치하는 DIRECT 규칙이 있는지, FINAL이 잘못 앞쪽에 배치됐는지 살펴보세요.

구독을 업데이트했는데 규칙은 왜 그대로인가요?

먼저 업데이트한 항목이 Home의 서버 구독인지 Config의 원격 설정인지 확인하세요. 서버 목록이 업데이트돼도 로컬 .conf 파일이 교체되는 것은 아닙니다. 원격 설정을 사용한다면 이후 업데이트가 로컬 변경 사항을 덮어쓰지 않도록 미리 백업하세요.

Host를 추가한 뒤 인증서 오류가 발생했어요. DIRECT로 바꾸면 해결되나요?

추가한 매핑을 먼저 되돌리고 새 요청을 보내세요. 오류가 사라지면 매핑 대상 서버가 원래 도메인에 유효한 인증서를 제공하는지 확인해야 합니다. DIRECT는 연결 출구 정책만 바꾸며 서버의 인증서 도메인을 수정하지는 않습니다.

URL Rewrite가 적용되지 않는데 설정이 저장되지 않은 걸까요?

먼저 현재 설정 파일을 확인한 다음 테스트 주소가 실제로 http://로 시작하는지, 도메인이 정규식과 일치하는지 확인하세요. 브라우저가 바로 HTTPS를 사용한다면 원래 HTTP 요청을 명확히 보낼 수 있는 테스트 방법을 이용하세요. 예제 적용 범위를 모든 도메인으로 넓히지 마세요.

설정을 수정한 뒤 연결이 계속 자동으로 다시 켜집니다. 어디를 확인해야 하나요?

Settings → On Demand에서 자동 연결 조건을 확인한 다음 시스템의 VPN 상태를 확인하세요. 자동 연결이 트리거되지 않도록 먼저 점검한 후 수동으로 다시 연결해 테스트하세요. 연결이 자동 복구된 것을 특정 Rule의 결과로 오해하지 마세요.

설정 파일에는 용도를 설명할 수 있고 결과를 검증할 수 있는 설정만 남기는 것이 좋습니다. 원격 규칙을 합치기 전에 매칭 범위, 대상 정책, 업데이트가 로컬 내용을 덮어쓰는지 확인하세요. 문법을 더 확인하려면 규칙 참고 자료를, 처음 연결하는 방법은 사용 안내를 확인하세요.

App Store 정품 확인 및 설정 준비

Shadowrocket은 Apple 플랫폼용 상용 비공개 소스 앱이며, App Store에서 한 번 구매해 사용할 수 있습니다. 개발자는 Shadow Launch Technology Limited입니다. iPhone, iPad 등 기기의 시스템 요구 사항과 호환성은 App Store 페이지의 표기를 기준으로 확인하세요. 앱 구매는 연결 서비스 이용권과 별개입니다. 가져오기와 연결에는 사용자가 이미 보유한 구독 또는 설정이 필요합니다.

정품 확인 안내 사용 안내 보기