Shadowrocket의 .conf 파일은 서버 목록이 아니라 섹션별 설정을 관리합니다. 이미 보유한 서버나 구독을 사용하면서 기존 설정을 파악하려는 분을 위한 안내입니다. 먼저 현재 선택된 설정 파일과 Global Routing을 확인하고, 전역 매개변수와 규칙 순서, 로컬 매핑, 요청 재작성을 차례로 점검한 뒤 한 번에 한 항목씩 변경해 결과를 확인하세요.
1. 먼저 .conf 파일이 현재 연결에 적용되는지 확인
파일을 편집했다고 해서 현재 연결에 해당 파일의 규칙이 적용되는 것은 아닙니다. 먼저 Config에서 선택된 설정을 확인하고 Home으로 돌아가 Global Routing을 확인하세요. [Rule]을 테스트하려면 Config를 선택해야 합니다. Proxy와 Direct는 전체 라우팅 방식이므로 특정 분기 규칙의 정상 작동 여부를 확인하는 데 사용할 수 없습니다.
Home에서는 서버를 선택하고 연결을 제어하며, Config에서는 설정 파일을 관리하고 Settings에서는 앱 설정을 관리합니다. 서버 구독 업데이트와 .conf 편집은 서로 다른 작업입니다. 전자는 주로 서버 항목을 업데이트하고, 후자는 파싱과 트래픽 분기 등의 동작을 정의합니다. 구독을 정상적으로 가져왔더라도 설정 파일에서 참조하는 정책 이름이 반드시 존재하는 것은 아닙니다.
| Global Routing 옵션 | 확인할 때의 의미 |
|---|---|
| Proxy | 전체 트래픽을 프록시로 보내 현재 서버를 테스트합니다. 개별 규칙의 분기 여부를 확인하는 데는 적합하지 않습니다. |
| Direct | 전체 트래픽을 직접 연결해 네트워크를 테스트합니다. 이 결과만으로 PROXY 규칙이 작동하지 않는다고 판단할 수 없습니다. |
| Config | 현재 설정에 따라 트래픽을 분기합니다. 이 글의 규칙 검증에 사용할 옵션입니다. |
| Scene | 시나리오 설정에 따라 라우팅 동작이 달라집니다. 문제를 확인할 때는 먼저 어떤 시나리오가 선택되어 있는지 살펴보세요. |
- Config에서 현재 파일을 백업한 다음 수정할 사본을 여세요.
- Home에서 정상 작동이 확인된 서버를 선택하고 Connectivity Test로 기본 연결 상태를 확인하세요.
- Global Routing을 Config로 설정하고 변경 사항을 저장한 뒤, 테스트할 파일이 계속 선택되어 있는지 확인하세요.
- 연결을 다시 설정하고 동일한 대상 주소에서 변경 전후의 결과를 비교하세요.
2. 섹션 제목과 기본 작성법: 구조를 먼저 파악한 뒤 수정
섹션 제목에는 영문 반각 대괄호를 사용합니다. 제목 아래의 각 행은 다음 섹션 제목이 나올 때까지 해당 섹션에 속합니다. [General]은 일반적으로 키-값 형식으로 작성하고, [Rule]은 쉼표로 구분된 규칙 필드를 사용합니다. 모든 섹션을 같은 형식으로 작성하거나 영문 쉼표 대신 한국어 쉼표를 사용하면 안 됩니다.
[General]
dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
[Host]
lab.example.com = 192.0.2.10
[URL Rewrite]
^http://www\.example\.com/ https://www.example.com/ 302이 예시는 문법 설명용이며 모든 네트워크에 적합한 권장 설정이 아닙니다. example.com은 예시 도메인이고 192.0.2.0/24는 문서용 예시 주소 대역이므로 실제 연결 가능한 서버 주소로 사용하면 안 됩니다. 실제로는 직접 관리하는 도메인과 네트워크에 맞게 수정하고, 필요하지 않은 Host와 URL Rewrite 행은 삭제하세요.
서식을 자동으로 바꾸는 편집기를 피하고 일반 텍스트 .conf 파일로 저장하세요. 주석은 별도 행에 작성하면 확인하기 쉽습니다. 규칙을 복사할 때 설명 문구가 필드에 함께 들어가지 않도록 주의하세요. 파일을 가져올 수 있다는 것은 기본 형식이 허용되었다는 뜻일 뿐입니다. 정책 참조와 실제 동작도 확인해야 합니다.
3. [General]: 전역 매개변수는 트래픽 분기 규칙이 아닙니다
[General]은 설정의 전반적인 동작에 영향을 줍니다. 위 예시의 dns-server = system은 시스템 DNS를 사용한다는 뜻이며, ipv6 = false는 이 설정에서 IPv6 사용을 제어합니다. IPv6 비활성화를 모든 상황에 적용할 수 있는 해결책으로 여기지 마세요. DNS 변경, 규칙 수정, 서버 전환을 한꺼번에 하면 결과에 영향을 준 항목을 파악하기 어렵습니다.
General 확인 항목
- 섹션 제목
- [General]
- DNS 예시
- dns-server = system
- IPv6 예시
- ipv6 = false
- 필드 형식
- 키 = 값
한 번에 매개변수 하나만 바꾸고, 테스트 전에 기존 값을 기록하세요.
연결 동작 확인 항목
- 연결 제어 위치
- Home 상단 스위치
- 필요 시 연결
- Settings → On Demand
- 규칙 테스트
- Home → Global Routing → Config
- 설정 선택
- Config에서 현재 파일 확인
On Demand는 조건에 따라 연결을 관리하며 Rule의 트래픽 분기를 대신하지 않습니다.
DNS 조회 성공, 대상 연결 성공, 올바른 정책 적용은 각각 별도로 확인해야 합니다. 도메인이 열리지 않으면 먼저 예상한 주소로 DNS가 응답하는지 확인한 뒤 연결 기록을 살펴보세요. DNS 조회가 성공했더라도 서버에 연결할 수 없거나 대상 포트가 닫혀 있거나 정책이 잘못 선택되면 접속에 실패할 수 있습니다.
- DNS 테스트 중에는 Wi-Fi와 셀룰러 네트워크를 번갈아 전환하지 말고 네트워크와 서버를 고정하세요.
- DNS 또는 Host를 변경한 뒤에는 대상 연결을 다시 설정하고 앱이나 시스템에 이전 DNS 결과가 캐시되어 있는지 확인하세요.
- Settings → On Demand가 자동 연결을 실행하는 경우, 문제를 확인하기 전에 조건을 기록해 두세요. 자동 재연결을 설정 미저장으로 오해하지 않도록 주의하세요.
4. [Rule]: 위에서부터 순서대로 매칭하고 FINAL은 마지막에 배치
[Rule]은 연결에 적용할 정책을 결정합니다. 일반 규칙은 보통 규칙 유형, 매칭 대상, 정책으로 구성되며 FINAL에는 매칭 대상 필드가 없습니다. 규칙은 순서대로 검사되므로 앞에서 이미 매칭된 연결은 뒤에 더 구체적인 규칙이 있어도 다시 선택되지 않습니다. 따라서 구체적인 예외를 포괄적인 조건보다 앞에 배치해야 합니다.
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY| 키워드 | 예시가 뜻하는 내용 |
|---|---|
| DOMAIN | api.example.com과 정확히 일치합니다. 아래의 도메인 접미사 규칙보다 먼저 적용됩니다. |
| DOMAIN-SUFFIX | example.com과 그 하위 도메인에 매칭됩니다. 문자열의 어느 위치에나 포함되는 조건은 아닙니다. |
| IP-CIDR | 지정된 IPv4 주소 대역에 매칭됩니다. no-resolve는 이 규칙을 매칭하기 위해 도메인 조회를 별도로 실행하지 않도록 합니다. |
| GEOIP | IP 지리 데이터베이스를 기준으로 CN에 매칭합니다. 결과는 주소와 데이터베이스 내용에 따라 달라집니다. |
| FINAL | 앞선 규칙에 매칭되지 않은 경우 PROXY를 사용합니다. 규칙 목록의 마지막에 배치해야 합니다. |
이 순서에서는 api.example.com이 먼저 DOMAIN에 매칭되고, 접미사 조건에 해당하는 다른 하위 도메인은 DIRECT로 연결됩니다. 앞의 두 행 순서를 바꾸면 포괄적인 접미사 규칙이 먼저 적용되어 기존의 정확한 예외 규칙이 작동하지 않습니다. 여기서 PROXY는 정책 참조이며 프로토콜 이름이나 서버 주소가 아닙니다.
요점: 규칙을 더 추가하기 전에 순서부터 바로잡으세요
특정 도메인이 계속 잘못된 정책으로 연결되면 먼저 위쪽의 DOMAIN-SUFFIX 또는 FINAL 규칙에 매칭되는지 확인하세요. 정확한 규칙을 포괄적인 규칙보다 앞에 옮긴 뒤 연결을 다시 시도해 확인하세요. 같은 규칙을 중복해서 추가하지 마세요.
사용자 지정 정책 그룹 이름을 사용한다면 현재 설정에 해당 이름이 실제로 정의되어 있는지 확인해야 합니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 서버 연결 프로토콜입니다. 규칙 끝에 프로토콜 이름만 입력한다고 해당 연결 경로를 사용할 수 있는 것은 아닙니다. 규칙은 정책을 선택하고 서버 항목은 프로토콜 매개변수를 지정하므로 각각 따로 확인해야 합니다.
5. [Host]: 로컬 매핑은 강제 직접 연결이 아닙니다
[Host]는 지정한 도메인의 로컬 주소 매핑에 사용하며, 관리 범위가 제한된 환경에서 고정 주소를 테스트할 때 주로 활용합니다. 아래 예시는 lab.example.com을 문서용 예시 주소인 192.0.2.10에 매핑합니다. 포트나 DIRECT 또는 PROXY를 지정하지 않으므로 최종 연결 경로는 라우팅 방식과 규칙을 함께 확인해야 합니다.
[Host]
lab.example.com = 192.0.2.10- 왼쪽에는 도메인만 입력하고
https://, 경로 또는 쿼리 매개변수는 넣지 마세요. - 오른쪽에는 대상 IP를 입력하고
:443을 주소의 일부로 취급하지 마세요. - HTTPS 연결에서는 기존 도메인을 기준으로 인증서를 확인합니다. 다른 주소에 매핑해도 인증서 불일치가 자동으로 해결되지는 않습니다.
- 확인하기 전에 연결을 다시 시도하세요. 앱 자체 캐시나 별도의 이름 해석 방식이 결과에 영향을 줄 수 있습니다.
매핑 후 연결 시간이 초과되면 먼저 대상 IP에 실제로 연결할 수 있는지 확인한 다음 포트와 규칙 적용 여부를 살펴보세요. DNS 결과가 바뀌었다는 이유만으로 설정이 정상이라고 판단하지 마세요. 테스트가 끝나면 임시 매핑을 삭제하세요. 실제 서버 주소가 바뀐 뒤에도 이전 고정 매핑이 남아 정상적인 주소 조회를 덮어쓸 수 있습니다.
6. [URL Rewrite]: URL을 매칭하며 연결 경로를 바꾸지는 않습니다
[URL Rewrite]는 정규식으로 요청 URL을 매칭한 다음 대체 대상과 동작을 지정합니다. 아래 예시는 http://www.example.com/으로 시작하는 요청을 고정된 HTTPS 홈페이지로 302 리디렉션합니다. 302는 HTTP 상태 코드이지 포트 번호가 아닙니다. 또한 이 규칙은 원래 경로와 쿼리 매개변수를 유지하지 않습니다.
[URL Rewrite]
^http://www\.example\.com/ https://www.example.com/ 302^는 URL의 시작부터 매칭하도록 제한해 다른 위치에 있는 동일한 텍스트가 잘못 매칭되는 것을 방지합니다.\.는 도메인 안의 마침표 문자를 뜻합니다. 이스케이프하지 않은.은 정규식에서 임의의 문자 하나를 나타냅니다.- 두 번째 필드는 고정 대상 주소이고, 세 번째 필드인
302는 리디렉션 동작을 지정합니다. - 관리 가능한 테스트 주소로 규칙을 하나씩 검증하고 반복 리디렉션이 없는지 확인한 뒤 유지하세요.
URL 재작성 규칙은 프록시 정책이 아니며 서버 연결 실패를 해결하지도 않습니다. 이 예시는 HTTP 요청을 매칭 대상으로 사용합니다. 이를 근거로 모든 HTTPS 요청의 전체 경로를 직접 읽고 수정할 수 있다고 가정하지 마세요. 암호화된 요청의 표시 여부와 인증서 처리는 별도의 설정 영역이며, 이 HTTP 예시를 테스트하기 위해 인증서 설정을 추가로 변경할 필요는 없습니다.
경로를 유지하려면 캡처 그룹과 대체 참조를 명확하게 설계하고 홈페이지, 하위 경로, 쿼리 매개변수가 있는 요청을 각각 테스트해야 합니다. 범위가 지나치게 넓은 정규식을 모든 웹사이트에 적용하지 마세요. 로그인, 결제, 서명된 URL은 경로와 매개변수 변경에 민감해 잘못 대체하면 요청 검증에 실패할 수 있습니다.
7. 저장 후 검증하는 방법: 증상에 맞춰 확인하고 전체 설정을 바꾸지 않기
검증할 때는 네트워크, 서버, 테스트 대상을 그대로 유지하고 설정을 한 번에 하나씩만 변경하세요. 먼저 Connectivity Test로 기본 연결 문제를 배제한 다음 대상 요청의 연결 기록과 적용된 정책을 확인합니다. 지연 시간 테스트가 성공해도 대상 웹사이트 접속이 보장되는 것은 아닙니다. 기존 연결이 이전 상태를 계속 사용할 수도 있으므로 대상 페이지를 닫고 요청을 다시 보내세요.
파일을 저장했는데 규칙이 여전히 적용되지 않는 이유는 무엇인가요?
먼저 Config에서 현재 선택된 파일을 확인한 다음 Home → Global Routing에서 Config를 선택하세요. 연결을 다시 설정한 뒤 같은 대상에 접속해 보세요. 여전히 잘못된 정책으로 연결된다면 해당 규칙보다 앞에 더 포괄적인 규칙이 매칭되는지 확인하세요.
Host를 추가했는데도 HTTPS 오류가 발생하는 이유는 무엇인가요?
매핑된 IP의 서비스가 기존 도메인 요청을 처리하고 그 도메인과 일치하는 인증서를 제공하는지 확인하세요. Host는 주소 매핑만 바꾸며 인증서의 신원은 변경하지 않습니다. 먼저 매핑을 제거해 결과를 비교하고, 인증서 검증을 끄는 방식으로 설정 오류를 감추지 마세요.
구독 업데이트는 성공했는데 PROXY 연결이 실패하는 이유는 무엇인가요?
Home으로 돌아가 현재 선택된 서버를 확인하고 Connectivity Test를 실행하세요. 구독 업데이트 성공은 서버 항목을 가져왔다는 뜻일 뿐입니다. 서버 연결 가능 여부, 인증 매개변수의 정확성, 규칙에서 참조하는 정책의 존재 여부는 각각 확인해야 합니다.
URL Rewrite를 추가하자마자 리디렉션이 반복됩니다. 어떤 항목을 먼저 삭제해야 하나요?
먼저 방금 추가한 재작성 규칙을 제거하고 다른 설정은 그대로 둔 채 다시 테스트하세요. 그런 다음 대체 대상이 동일한 표현식에 다시 매칭되는지, 웹사이트가 원래 주소로 다시 이동시키는지 확인하세요. 매칭 범위를 좁힌 뒤 해당 규칙만 따로 활성화하세요.
마지막으로 업데이트 유형을 구분하세요. 서버 구독을 업데이트한 뒤에는 현재 선택된 항목이 바뀌었는지 확인하고, 원격 설정을 업데이트한 뒤에는 로컬 편집 내용이 덮어쓰였는지 확인해야 합니다. 계속 유지할 변경 사항은 별도의 로컬 사본에 저장하고 수정 목적을 기록하세요. 되돌릴 때는 검증되지 않은 매개변수를 계속 추가하기보다 이전에 검증한 설정을 복원하는 편이 원인을 찾기 쉽습니다.