.conf는 설정 텍스트 파일이며 서버 구독을 다른 이름으로 부르는 것이 아닙니다. 이미 본인의 구독을 보유하고 Config를 읽거나 수정하려는 사용자를 위한 안내입니다. 조작 경로는 iPhone / iPad 화면을 기준으로 설명하며, Mac, Windows, Android, Linux에서는 해당 버전의 설정 메뉴를 확인하세요. 글을 읽고 나면 전역 매개변수, 트래픽 분기 규칙, 로컬 매핑, 요청 재작성의 차이를 이해하고 백업, 항목별 수정, 재연결, 기록 확인 순서로 검증할 수 있습니다.
1. Config, 서버, Global Routing 구분하기
Shadowrocket의 Home에서는 기존 서버를 확인하고 선택하며, Config에서는 설정 파일을 관리합니다. 서버 항목에는 연결에 필요한 주소, 포트, 프로토콜, 인증 정보가 저장됩니다. 이 글에서 다루는 네 섹션은 요청 처리, 트래픽 분기, 주소 재작성 방식을 지정합니다. 네 섹션이 포함된 .conf 파일만 가져와서는 사용할 수 있는 서버가 생기지 않으며, 기존 구독을 대신하지도 않습니다.
수정하기 전에 Home → Global Routing을 확인하세요. Proxy, Direct, Config, Scene은 서버 프로토콜의 네 가지 종류가 아니라 서로 다른 라우팅 방식입니다. 이 글의 [Rule]을 검증하려면 먼저 Config를 선택하세요. Proxy나 Direct 상태에서 연결 결과만 확인해서는 특정 규칙이 적용됐는지 판단할 수 없습니다.
| 라우팅 방식 | 확인할 항목 | 이 글과의 관계 |
|---|---|---|
| Proxy | 전역 프록시 라우팅 | 이 설정만으로는 [Rule]의 분기 결과를 판단할 수 없습니다. |
| Direct | 전역 직접 연결 라우팅 | 이 방식에서는 서버 사용 가능 여부를 직접 검증하기 어렵습니다. |
| Config | 현재 활성화된 설정 파일 | 이 글의 규칙 순서와 정책을 검증할 때 사용합니다. |
| Scene | 시나리오 조건 및 연결된 설정 | 시나리오에서 실제로 사용하는 라우팅 방식과 설정을 확인하세요. 이를 고정된 Config와 동일하게 취급하면 안 됩니다. |
이 순서는 설정 수정과 검증 절차를 나타내며, 네트워크 처리 흐름을 뜻하지는 않습니다. 실제 연결에서는 DNS 조회, 도메인 매칭, IP 매칭이 서로 영향을 줄 수 있습니다. [URL Rewrite]도 모든 트래픽이 반드시 거치는 단계가 아닙니다. Settings → On Demand는 조건에 따른 연결 동작을 관리하며, Config의 트래픽 분기 규칙을 대신하지 않습니다.
2. .conf 섹션 문법과 안전한 수정 순서
섹션 이름은 한 줄에 단독으로 쓰고 영문 대괄호로 묶습니다. 매개변수에는 보통 영문 등호를, 규칙 필드에는 보통 영문 쉼표를 사용합니다. 한글 입력기의 쉼표나 괄호를 문법에 섞지 마세요. 아래는 구조 예시입니다. 사용하지 않는 섹션을 생략해도 설정이 손상된 것은 아닙니다. 텍스트 배치만 보여 주는 예시이며 서버 인증 정보는 포함하지 않습니다.
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
[Host]
lab.example.com = 192.0.2.10
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302- Config로 이동해 현재 정상 작동하는 파일을 복사해 두세요. 원격 설정 파일이라면 원본 주소와 로컬에서 수정한 내용도 함께 기록합니다.
- 수정할 파일의 편집 메뉴를 열고, 편집 대상과 활성화할 파일이 일치하는지 확인하세요. 편집 버튼의 위치는 플랫폼마다 다를 수 있습니다.
- 한 번에 한 종류의 내용만 수정하세요. 예를 들어 DOMAIN-SUFFIX 규칙 하나만 조정하고 DNS 설정, 매핑 추가, 재작성 규칙 변경을 동시에 하지 않습니다.
- 저장한 뒤 해당 파일이 활성화됐는지 확인하세요. Home으로 돌아가 Global Routing이 Config인지 확인한 다음 연결을 다시 설정하고 새 테스트 요청을 보내세요.
주석은 별도 줄에 작성하는 것이 좋습니다. 예를 들어 #으로 시작해 규칙의 용도를 설명할 수 있습니다. 해당 위치에서 줄 끝 주석을 지원하는지 확인하지 않았다면 설명을 매개변수 값 뒤에 붙이지 마세요. 파일 확장자는 .conf로 유지하고, 텍스트 편집기가 끝에 .txt를 추가하지 않도록 확인하세요.
3. [General]: 전역 매개변수와 DNS 조회
[General]에는 설정 전반에 적용되는 전역 매개변수를 지정합니다. 아래의 dns-server = system은 시스템 DNS 설정을 사용한다는 뜻이며, system이라는 서버를 설정하는 것이 아닙니다. 현재 네트워크에서 DNS 조회가 반드시 성공한다는 보장은 없습니다. 연결에 실패하면 DNS 조회 실패인지, 라우팅 오류인지, 대상 서비스의 응답 없음인지 구분해야 합니다.
[General]
dns-server = system다른 사람의 매개변수 목록을 보고 전체를 그대로 복사하지 마세요. IPv6, DNS, 우회 설정은 서로 다른 부분에 영향을 줍니다. 예를 들어 DNS를 바꿔도 잘못된 서버 인증 정보는 해결되지 않으며, 특정 주소 유형의 조회를 비활성화해도 모든 시간 초과를 설명할 수는 없습니다. 현재 정상 작동하는 매개변수는 유지하고, 원인을 파악할 수 있는 증상에 맞춰 한 항목씩 조정하세요.
[General] 확인 항목
- 섹션
- [General]
- 매개변수
- dns-server = system
- 검증 대상
- 새 요청의 도메인 조회 결과와 오류 기록
먼저 DNS 조회가 성공했는지 확인한 다음 연결 경로를 판단하세요.
[Rule] 확인 항목
- 섹션
- [Rule]
- 매칭 항목
- DOMAIN-SUFFIX,example.com,PROXY
- 기본 처리 규칙
- FINAL,DIRECT
규칙은 연결 정책을 결정하며 서버 인증 정보를 제공하지 않습니다.
확인할 때는 새 연결을 만들어야 합니다. 이미 연결된 장시간 연결은 기존 연결 상태를 계속 사용할 수 있고, 브라우저와 시스템에 DNS 캐시가 남아 있을 수도 있습니다. 페이지를 한 번 새로 고치는 것만으로 새 DNS 설정이 적용됐는지 증명할 수 없으며, 저장 실패라고 단정할 수도 없습니다.
4. [Rule]: 위에서부터 매칭하고 FINAL은 마지막에 배치
[Rule]은 위에서부터 순서대로 매칭합니다. 앞쪽 규칙이 적용되면 일반적으로 뒤쪽 규칙은 해당 연결의 정책 선택에 참여하지 않습니다. 따라서 범위가 좁은 예외 규칙을 포괄적인 규칙보다 앞에 두세요. 아래 예시는 특정 도메인을 먼저 DIRECT로 연결하고, 같은 도메인 접미사를 사용하는 나머지 요청은 PROXY를 사용하도록 합니다.
[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN은 도메인과 정확히 일치하는 항목을 매칭합니다. 예시에서는 status.example.com이 먼저 DIRECT에 매칭됩니다.DOMAIN-SUFFIX는 example.com과 그 하위 도메인을 매칭합니다.*.example.com으로 쓸 필요가 없으며, 전체 웹 주소를 입력해서도 안 됩니다.IP-CIDR은 대상 IP가 속한 네트워크 대역을 매칭합니다.192.168.50.0/24는 해당 사설 네트워크 대역을 뜻하며 모든 로컬 네트워크를 의미하지는 않습니다.no-resolve는 이 IP 규칙을 위해 도메인 조회를 새로 수행하지 않도록 합니다. 설정 전체의 DNS를 끄는 스위치가 아닙니다.GEOIP,CN,DIRECT는 대상 IP의 지리 정보 데이터베이스상 국가를 기준으로 판단합니다. 웹페이지 언어나 도메인 접미사를 기준으로 하지 않습니다.FINAL,PROXY는 앞선 규칙에 매칭되지 않은 연결을 처리합니다. 이 항목을 맨 앞에 두면 뒤의 일반 규칙은 매칭될 기회를 잃습니다.
PROXY와 DIRECT는 정책 키워드이지 프로토콜 이름이 아닙니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 서버 연결 방식을 나타내며, 규칙 끝에 정책처럼 임의로 입력할 수 없습니다. 사용자 지정 정책 이름을 사용한다면 설정에 해당 정의가 실제로 있는지, 철자가 정확히 일치하는지 확인하세요.
요약: 도메인 하나를 먼저 검증한 뒤 범위를 넓히세요
복사본에서 직접 관리하는 테스트 도메인에 DOMAIN 규칙 하나를 추가하고 FINAL 앞에 배치하세요. 다시 연결한 뒤 새 요청의 매칭 기록을 확인하고, 결과가 올바르면 DOMAIN-SUFFIX로 범위를 넓힙니다. 이렇게 하면 문법 오류와 매칭 범위가 지나치게 넓은 문제를 따로 확인할 수 있습니다.
5. [Host]: 도메인 매핑과 라우팅 정책은 다릅니다
[Host]에서는 로컬 도메인 매핑을 설정합니다. 왼쪽에는 도메인, 오른쪽에는 사용할 주소를 입력하세요. 브라우저 주소창의 프로토콜, 포트, 경로까지 함께 붙여 넣지 마세요. 매핑은 대상 주소 조회 방식을 바꾸지만 해당 연결을 자동으로 DIRECT로 전환하지 않으며, 대상 웹사이트의 인증서 문제도 해결하지 않습니다.
[Host]
lab.example.com = 192.0.2.10
api.example.com = 192.0.2.20| 입력 방식 또는 증상 | 문제 | 해결 방법 |
|---|---|---|
https://lab.example.com/path | URL을 도메인 키로 입력함 | 왼쪽에는 lab.example.com만 남기세요. |
192.0.2.10:443 | IP 매핑 값에 포트를 붙임 | 매핑에는 주소만 입력하세요. HTTPS의 443 포트는 연결 대상 정보입니다. |
| 매핑 후 인증서 오류가 발생함 | 해당 주소의 서비스가 그 도메인에 유효한 인증서를 제공하지 않을 수 있습니다. | 서버 인증서와 도메인이 일치하는지 확인하세요. 인증서 오류를 무시해 매핑 문제를 덮지 마세요. |
| 여전히 프록시를 거침 | 주소 매핑은 DIRECT를 지정하지 않습니다. | [Rule]로 돌아가 해당 도메인이나 대상 주소에 적용되는 정책을 확인하세요. |
예를 들어 직접 관리하는 테스트 도메인을 내부 서버로 연결했다면 현재 네트워크나 선택한 프록시에서 해당 주소에 접근할 수 있는지도 확인해야 합니다. 서비스가 로컬 네트워크에서만 접근 가능하다면 관련 직접 연결 규칙을 별도로 확인하세요. 매핑이 올바른지, 주소에 도달할 수 있는지, 포트가 열려 있는지, 인증서가 유효한지는 각각 독립된 조건입니다. 한 가지만 확인해서는 충분하지 않습니다.
6. [URL Rewrite]: 정규식 매칭과 리디렉션
[URL Rewrite]는 요청 주소를 처리하는 기능이지 서버 구독 업데이트 도구가 아닙니다. 아래 규칙은 example.com의 일반 HTTP 주소만 매칭하고 경로를 유지한 채 HTTPS 주소로 302 리디렉션합니다. 요청 주소의 처리 방식을 바꾸는 기능이며, [Rule]에서 PROXY 또는 DIRECT를 선택하는 기능은 아닙니다.
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302^는 주소의 시작부터 매칭하고$는 끝까지 매칭하도록 제한해 다른 주소에 의도치 않게 적용될 가능성을 줄입니다.example\.com에서는 점을 이스케이프해 문자 그대로의 점을 나타냅니다. 정규식에서 이스케이프하지 않은 점은 일반적으로 임의의 문자 하나를 뜻합니다.(.*)는 슬래시 뒤의 내용을 캡처합니다. 대체 주소의$1은 캡처한 내용을 가리킵니다.302는 리디렉션 상태 코드이지 포트 번호가 아닙니다. 서버에서 사용하는 443으로 바꾸지 마세요.
테스트 주소는 직접 관리하는 서비스로 설정하세요. 예를 들어 경로와 쿼리 매개변수가 포함된 HTTP 요청을 보내고 리디렉션의 Location에 예상한 내용이 유지되는지 확인합니다. 브라우저의 HTTPS 자동 업그레이드나 HSTS 때문에 요청이 HTTP로 전송되지 않을 수 있습니다. 따라서 브라우저에서 최종적으로 HTTPS 페이지가 열렸다는 사실만으로 규칙이 적용됐다고 판단할 수는 없습니다.
흔한 오류로는 매칭 범위가 지나치게 넓거나, 대체 대상이 같은 규칙에 다시 매칭되거나, 규칙을 [Rule] 섹션에 작성하는 경우가 있습니다. 리디렉션이 반복되면 새 재작성 규칙을 먼저 비활성화하고 원래 요청을 복원한 뒤 정규식 범위를 좁히세요. 하나의 순환 문제를 해결하려고 리디렉션 규칙을 여러 개 추가하지 마세요.
7. 저장 후 적용되지 않을 때: 파일, 라우팅 방식, 매칭 조건 확인
문제 해결은 먼저 사용 중인 파일을 확인하고, 다음으로 요청이 테스트 조건에 맞게 처리되는지 살펴봐야 합니다. 서버 구독 업데이트와 원격 설정 업데이트는 서로 다른 작업입니다. 전자는 주로 기존 서버 항목에 영향을 주고, 후자는 설정 텍스트를 바꿀 수 있습니다. 원격 설정을 로컬에서 수정했다면 업데이트 전에 복사본을 보관하세요. 덮어쓴 결과를 편집기가 저장하지 못한 것으로 오해하지 않도록 주의해야 합니다.
규칙을 저장했는데 왜 모든 웹사이트가 같은 정책을 사용하나요?
먼저 Config에서 방금 저장한 파일이 활성화됐는지 확인한 다음 Home → Global Routing에서 Config를 선택하세요. 이어서 FINAL이 마지막에 있는지 확인하고, 기존 테스트 연결을 종료한 뒤 새 요청을 보내 실제 매칭 기록을 살펴보세요.
[Host]를 추가했는데 왜 웹페이지가 열리지 않나요?
먼저 매핑 값이 본인 서버의 실제 주소와 한 글자씩 일치하는지 확인한 다음 현재 네트워크에서 대상 주소와 포트에 접근할 수 있는지 살펴보세요. HTTPS의 443 포트를 사용한다면 사이트 인증서도 확인해야 합니다. 본문의 192.0.2.10은 문법 설명용 주소이며 실제 서비스 주소로 사용할 수 없습니다.
구독을 업데이트했는데 왜 새 규칙이 나타나지 않나요?
Home으로 돌아가 서버 목록을 확인하고 Config에서 규칙 파일을 살펴보세요. 서버 구독 업데이트는 설정 파일 업데이트와 다릅니다. [Rule]을 수정하려면 활성화된 설정 파일을 편집해야 합니다. 규칙을 서버 주소 입력란에 붙여 넣지 마세요.
설정을 바꾸고 연결을 끊었는데 왜 다시 자동으로 연결되나요?
Settings → On Demand에서 현재 조건을 확인하세요. 수동으로 비교 테스트할 때는 관련 자동 연결 조건을 잠시 중지해도 됩니다. 검증이 끝나면 원래 설정을 복원하세요. On Demand는 연결 시작 조건을 제어할 뿐 [Rule]의 순서를 바꾸지 않습니다.
원인을 찾지 못하면 백업 설정을 복원하고 같은 서버, 네트워크, 테스트 대상을 유지하세요. 백업은 작동하지만 수정본이 실패한다면 변경 사항을 하나씩 추가해 보세요. 두 파일 모두 실패한다면 규칙 범위를 더 넓히기보다 서버 연결과 대상 서비스를 먼저 확인하세요. 다른 사람에게 진단 자료를 전달하기 전에는 구독 주소의 토큰, 인증 정보, 기타 개인 데이터를 삭제해야 합니다.
- 전역 매개변수가 의심되면 먼저 [General]의 원래 값을 복원하세요.
- 연결 경로가 예상과 다르면 Global Routing, 현재 파일, 규칙 순서, 정책 이름을 확인하세요.
- 특정 도메인만 조회에 실패하면 [Host], DNS 캐시, 새 연결의 조회 결과를 확인하세요.
- 요청이 반복해서 리디렉션되면 새 [URL Rewrite]를 비활성화하고 규칙을 하나씩 복원하며 테스트하세요.