Shadowrocket의 .conf 파일은 섹션별로 설정을 구성합니다. 구독 주소를 입력하는 것만으로 트래픽 분기가 완성되는 것은 아닙니다. 이미 서비스 제공업체와 구독을 이용 중이며 Config에서 설정을 점검하려는 사용자를 위한 안내입니다. 먼저 각 섹션의 역할을 파악한 다음 전체 규칙, 도메인 매핑, 리디렉션 예제를 확인하고, 한 항목씩 수정한 뒤 다시 연결해 요청 기록을 점검하는 순서로 검증하세요.
1. .conf의 섹션 이름, 키와 값, 적용 조건
설정 파일은 텍스트 형식입니다. 대괄호 안의 이름은 섹션을 나타냅니다. 예를 들어 [General]이 있습니다. 다음 섹션이 시작되기 전까지의 내용은 현재 섹션에 속합니다. 섹션 이름의 공백은 유지해야 하며, [URL Rewrite]를 임의로 다른 표기로 바꾸면 안 됩니다. 키와 값은 보통 키 = 값 형식으로 작성하고, 규칙은 쉼표로 필드를 구분합니다. 두 형식을 혼용하지 마세요.
Home에서는 연결과 서버를 선택하고, Config에서는 설정 파일을 관리합니다. 텍스트를 가져오거나 저장했다고 해서 설정이 활성화된 것은 아닙니다. Config에서 현재 선택된 파일을 확인한 다음 Home → Global Routing에서 Config를 선택하세요. Proxy는 모든 트래픽을 프록시로 보내는 모드이고, Direct는 모두 직접 연결하는 모드입니다. Scene은 설정된 장면에 따라 라우팅 방식을 선택합니다. 규칙 순서를 확인할 때는 Scene 전환의 영향을 피하도록 Config로 고정하세요.
아래는 독립적으로 확인할 수 있는 기본 구조입니다. 일치하지 않는 트래픽은 DIRECT로 보내므로 파일이 정상적으로 파싱되는지 확인하는 데 적합합니다. 모든 네트워크에 적용할 수 있는 완성된 설정은 아닙니다. example.com은 문서 예시용 도메인이며, 이 사이트에서 제공하는 서비스가 아닙니다.
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT- 일반 텍스트 편집기를 사용하고 문장 부호는 영문 반각 문자를 쓰세요. 설명을 규칙 뒤에 바로 덧붙이지 마세요.
- 규칙은 한 줄에 하나씩 작성합니다. 메모가 필요하면 새 줄에
#으로 시작해 적으세요. - 먼저 원본 파일을 복사해 두고 테스트용 사본을 편집하세요. DNS, 규칙, 재작성 설정을 한꺼번에 바꾸지 마세요.
- 실제 파일에는 더 많은 섹션이 있을 수 있습니다. 이 글에서 다루는 네 섹션이 전체 기능을 모두 포함하는 것은 아닙니다.
2. General: 기본 동작 설정, 규칙 순서와는 별개
[General]에는 전역 기본 설정을 둡니다. 예를 들어 dns-server = system은 시스템 DNS 설정을 사용한다는 뜻입니다. 시스템에서 선택한 리졸버가 모든 네트워크에서 연결 가능하다는 의미는 아닙니다. 다른 방식으로 바꾸기 전에 현재 Wi-Fi 또는 셀룰러 네트워크, 대상 도메인, 오류 증상을 기록하세요.
DNS는 도메인 이름을 주소로 변환하고, Rule은 트래픽에 적용할 정책을 선택합니다. 서로 관련은 있지만 같은 설정은 아닙니다. DNS 조회에 실패했을 때 DOMAIN-SUFFIX 규칙을 추가해도 리졸버가 자동으로 복구되지는 않습니다. 반대로 DNS에서 주소를 받았더라도 대상 포트나 프록시 경로가 반드시 작동하는 것은 아닙니다.
General 기본 점검
- 섹션 이름
[General]- 설정 항목
dns-server- 예시 값
system- 작성 형식
dns-server = system
먼저 기존 DNS 조회 방식을 확인한 다음 변경 여부를 결정하세요.
앱에서 적용 여부 확인
- 파일 위치
- Config
- 라우팅 메뉴
- Home → Global Routing
- 테스트 모드
- Config
- 자동 연결 메뉴
- Settings → On Demand
On Demand는 조건에 따라 연결을 제어하며 Rule의 매칭 로직을 대신하지 않습니다.
텍스트를 편집할 때 설정 이름만 보고 기능을 추측하지 마세요. 지원 여부가 확인되지 않은 키는 무시되거나 파싱 문제를 일으킬 수 있습니다. General 설정을 추가할 때는 앱 내 설정 편집 화면의 해당 항목과 설명을 기준으로 하고, 변경 전 값을 보관하세요. On Demand의 자동 연결 동작도 별도로 확인해 문제를 진단하는 도중 자동 재연결로 흐름이 끊기지 않도록 하세요.
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과 하위 도메인을 매칭합니다. | 도메인만 입력하고 프로토콜, 포트, 경로는 넣지 마세요. |
IP-CIDR | 192.0.2.0/24 주소 범위를 매칭합니다. | 문서 예시용으로 예약된 네트워크 대역이며, 실제 서버 주소가 아닙니다. |
GEOIP | IP 지리 데이터베이스를 기준으로 CN을 판별합니다. | 결과는 IP 지리 데이터베이스에 따라 달라지며, 도메인 접미사만으로는 판단할 수 없습니다. |
FINAL | 앞선 규칙과 일치하지 않은 요청에 PROXY를 선택합니다. | 매칭 값 필드는 쓰지 않고 FINAL,PROXY로 작성합니다. |
no-resolve는 해당 IP 규칙을 매칭하기 위해 도메인 조회를 임의로 수행하지 않도록 합니다. 모든 DNS를 끄는 설정은 아닙니다. 요청 자체나 다른 규칙에 DNS 조회가 필요할 수 있습니다. 요청에 도메인만 있고 판단에 사용할 IP가 없으면 no-resolve가 붙은 IP 규칙과 일치하지 않을 수 있으니 실제 기록을 함께 확인하세요.
PROXY는 프록시 정책, DIRECT는 직접 연결 정책을 의미하며 프로토콜 이름은 아닙니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 프로토콜을 가리키며, 연결 정보는 사용자가 이용 중인 서비스에서 가져와야 합니다. 정책을 PROXY로 지정해도 연결이 자동으로 만들어지지 않습니다. 테스트하기 전에 Home에 사용할 수 있는 서버가 등록되어 있는지 확인하세요.
규칙 문제 진단: 먼저 요청과 일치한 규칙 확인
대상 도메인의 연결 경로가 예상과 다르면 요청 기록에서 도메인, 매칭된 규칙, 적용된 정책을 먼저 확인한 다음 해당 규칙만 이동하세요. 우선 General 설정 전체를 바꾸면 어떤 변경이 영향을 줬는지 파악하기 어렵습니다.
4. Host: 도메인 주소를 고정 매핑하며 출구 정책은 선택하지 않음
[Host]는 도메인과 주소의 매핑을 지정합니다. 가장 간단한 형식은 도메인 = IP 주소입니다. 대상 도메인에 대응하는 주소를 바꾸는 기능으로, Rule의 DIRECT 또는 PROXY를 대신하지 않으며 연결할 수 없는 주소를 접속 가능한 주소로 바꾸지도 않습니다.
[Host]
lab.example.com = 192.0.2.10이 예시는 문법만 설명합니다. 192.0.2.10은 문서 예시용으로 예약된 주소이므로 네트워크 연결 테스트에 사용할 수 없습니다. 자체 테스트 환경에서는 관리 권한이 있는 도메인과 실제로 연결 가능한 주소를 입력하고 서비스가 수신 대기 중인 포트를 확인하세요. Host 항목은 이름 매핑만 지정하므로 192.0.2.10:443처럼 작성하면 안 됩니다. HTTP는 보통 TCP 80, HTTPS는 보통 TCP 443을 사용하며 포트는 URL 또는 앱의 연결 설정으로 결정됩니다.
- 도메인은
lab.example.com처럼 입력하고,https://lab.example.com/path처럼 입력하지 마세요. - HTTPS를 사용할 때 서버 인증서는 요청한 도메인과 일치해야 합니다. IP를 고정해도 인증서 검증을 우회할 수는 없습니다.
- 테스트 전에 기존 연결을 종료하고 새 요청을 보내세요. 연결 재사용이나 캐시가 변경 사항을 가리지 않도록 해야 합니다.
- 테스트 매핑을 제거한 뒤 다시 확인해 임시 주소가 운영 설정에 장기간 남지 않도록 하세요.
주소가 바뀌었는데 페이지가 여전히 열리지 않는다면 주소 연결 여부, 포트 서비스, 인증서, 라우팅 정책을 각각 확인하세요. Host는 DNS 문제를 진단하는 도구 중 하나입니다. 인터넷에서 임의로 찾은 주소를 장기 설정에 넣는 용도로 사용하지 마세요.
5. URL Rewrite: URL을 매칭한 뒤 리디렉션 동작 지정
[URL Rewrite]는 URL 매칭과 재작성을 처리합니다. 아래 예시는 정규식으로 HTTP 주소를 매칭한 다음 302를 사용해 리디렉션 대상을 반환합니다. DNS 매핑을 만들거나 특정 도메인을 PROXY로 지정하는 또 다른 방법은 아닙니다.
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302^는 URL의 시작을,$는 끝을 지정해 주소 중간의 일부만 매칭되는 것을 방지합니다.example\.com의 마침표는 이스케이프되어 정규식의 임의 문자가 아닌 실제 마침표를 나타냅니다.(.*)는 슬래시 뒤의 내용을 캡처하고, 대상에 있는$1은 첫 번째 캡처 그룹을 참조합니다.302는 리디렉션 동작을 의미합니다. 브라우저는 응답을 받은 뒤 대상 주소로 새 요청을 보내며, 양쪽 트래픽을 직접 교환하는 것은 아닙니다.
이 표현식은 http://example.com/으로 시작하는 주소만 매칭합니다. https://example.com/이나 포트가 명시된 http://example.com:80/은 매칭하지 않습니다. 테스트 전에 이러한 경계를 명확히 정하세요. 모든 주소를 매칭하려고 도메인 부분을 함부로 넓히면 관련 없는 요청까지 재작성될 수 있습니다.
리디렉션이 반복되면 새로 추가한 재작성 규칙을 먼저 제거하고 원래 사이트의 응답을 확인하세요. HTTP에서 HTTPS로만 보내는 단방향 규칙도 서버 자체의 리디렉션 로직과 충돌할 수 있습니다. 최종 페이지가 열리는지만 보지 말고 최초 URL, 응답 상태 코드, 리디렉션 대상을 각각 기록하세요.
6. 단계별 검증: DNS 조회, 라우팅, 재작성을 따로 확인
네 섹션은 각각 기본 동작, 트래픽 분기, 이름 매핑, URL 처리를 다룹니다. 정해진 네 단계의 처리 파이프라인은 아닙니다. 실제 처리 방식은 요청에 DNS 조회가 필요한지, URL을 확인할 수 있는지, 도메인 규칙이 매칭되는지에 따라 달라집니다. 아래 숫자는 이 글의 예시 구조만 나타내며 앱의 전체 지원 범위를 뜻하지 않습니다.
- Config에서 원본 파일을 보관하고 테스트 파일이 선택되어 있는지 확인하세요. Home → Global Routing에서 Config를 선택하세요.
- 먼저 General과 Rule만 테스트하세요. 접속 가능한 것으로 확인된 대상을 사용하고 시간, 네트워크 유형, 선택한 서버를 기록하세요.
- 연결을 중지한 뒤 다시 연결하고 새 요청을 보내세요. DNS 조회 오류, 연결 시간 초과, TLS 오류, HTTP 상태 코드를 구분하세요.
- Host가 필요하면 관리 중인 도메인 매핑을 하나만 추가하고 변경 전후의 대상 주소를 비교하세요.
- 마지막으로 URL Rewrite만 따로 테스트해 리디렉션 대상을 확인하세요. 실패하면 전체 설정을 덮어쓰지 말고 가장 최근에 변경한 항목을 되돌리세요.
서버 지연 시간 테스트가 성공했다는 것은 해당 테스트에서 응답을 받았다는 의미일 뿐입니다. 대상 웹사이트의 DNS, TCP 443, TLS, HTTP 요청이 모두 정상이라는 뜻은 아닙니다. HTTP 403 응답을 받았다면 서버에서 요청에 응답한 것이므로 서버 측 접근 조건을 확인해야 합니다. 이를 곧바로 .conf 문법 오류로 판단하지 마세요.
7. 자주 묻는 질문: 파일을 저장했는데 왜 결과가 그대로인가요?
Rule을 수정했는데 웹사이트 트래픽이 전부 프록시로 가요.
먼저 Home → Global Routing이 Proxy로 설정되어 있는지 확인하세요. Config로 바꾼 다음 Config로 돌아가 방금 수정한 파일이 선택되어 있는지 확인하고, 다시 연결해 새 요청을 보낸 뒤 매칭 규칙을 점검하세요. 웹페이지가 열리는 속도만 보고 정책을 판단하지 마세요.
FINAL을 파일 첫 번째 규칙으로 작성해도 되나요?
Rule 섹션의 마지막에 두세요. 구체적인 도메인 및 주소 규칙을 앞에 배치하면 됩니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT를 먼저 쓰고 FINAL,PROXY를 뒤에 써야 해당 도메인이 직접 연결 규칙과 일치할 수 있습니다.
구독을 업데이트하면 직접 수정한 설정이 유지되나요?
먼저 Home의 서버 구독과 Config의 원격 설정을 구분하세요. 전자는 보통 서버 항목을 업데이트하고, 후자는 설정 텍스트를 다시 가져올 때 로컬 변경 사항을 덮어쓸 수 있습니다. 수정 사항을 계속 유지하려면 별도의 로컬 사본에 저장하고 업데이트 후 현재 선택된 파일을 확인하세요.
Host를 IP로 바꿨는데 HTTPS 오류가 발생하는 이유는 무엇인가요?
해당 IP에서 대상 도메인의 HTTPS 서비스가 실행 중인지, 인증서가 해당 도메인을 포함하는지 확인하세요. 먼저 Host 매핑을 되돌려 결과를 비교하세요. 도메인, 주소, 서버 설정을 바로잡는 대신 인증서 검증을 끄지 마세요.
설정을 저장한 뒤 최종적으로 세 가지를 확인하세요. 올바른 파일이 선택되어 있는지, Global Routing 모드가 맞는지, 새 요청이 예상한 규칙과 일치하는지입니다. 이 세 가지를 확인한 뒤 DNS, 대상 서비스, 재작성 범위를 점검하면 연결 문제를 파일 형식 오류로 잘못 판단할 가능성을 줄일 수 있습니다.