Shadowrocket 설정 파일 작성법: .conf 문법과 분기 규칙 실전

1. .conf 파일의 역할과 적용 범위 이해하기

Shadowrocket은 iPhone과 iPad를 중심으로 사용하는 Apple 플랫폼용 유료 앱이며, App Store에서 구매할 수 있습니다. 앱 구매와 연결 서비스 이용은 별개입니다. 이 글은 본인이 이미 보유한 설정 파일이나 연결 정보를 사용하는 경우를 전제로 하며, 서버나 구독을 제공하거나 추천하지 않습니다.

.conf 파일은 연결 항목과 트래픽 처리 규칙을 텍스트로 정리한 구성 파일입니다. 파일에 서버 정보가 들어 있을 수도 있지만, 규칙만 정의한 파일도 있습니다. 따라서 파일을 불러왔다고 해서 사용할 서버가 자동으로 준비되거나 모든 요청이 원하는 경로로 처리되는 것은 아닙니다. 연결 정보, 정책 이름, 규칙 순서를 각각 확인해야 합니다.

파일의 섹션 이름은 대괄호와 영문 표기를 그대로 사용합니다. 값은 등호나 쉼표로 구분하며, 임의의 따옴표나 전각 문장부호를 섞으면 파싱이 달라질 수 있습니다. 편집할 때는 파일 원본을 복사해 별도 테스트본을 만들고, 한 번에 한 종류의 변경만 적용하세요.

2. 섹션별 문법과 값의 연결 관계

각 섹션은 서로 다른 역할을 합니다. 예를 들어 [Proxy]에 정의한 이름을 [Proxy Group]의 구성원으로 사용할 수 있고, 그룹 이름은 [Rule]에서 정책으로 지정할 수 있습니다. 이름을 바꿀 때는 참조하는 위치도 함께 확인하세요. 아래는 구조를 보여 주는 예시이며, 실제 서버 주소나 인증값을 포함하지 않습니다.

[General]
# 전역 옵션은 필요한 항목만 설정합니다.

[Proxy]
Example-Server = ss, server.example.com, 443, encrypt-method=chacha20-ietf-poly1305, password=YOUR_PASSWORD

[Proxy Group]
Proxy = select, Example-Server, DIRECT

[Rule]
DOMAIN-SUFFIX,example.com,Proxy
GEOIP,CN,DIRECT
FINAL,Proxy

[Host]
localhost = 127.0.0.1

• [General]: 전역 동작 옵션을 설정합니다. 옵션 이름과 지원 여부를 확인하지 않은 채 다른 형식의 설정 값을 복사하지 마세요.
• [Proxy]: 개별 연결 항목을 정의합니다. 프로토콜 이름과 필드 형식은 해당 항목의 실제 매개변수에 맞아야 합니다. 위의 서버 주소와 암호는 설명용 자리표시자입니다.
• [Proxy Group]: 여러 항목을 선택하거나 정책으로 묶습니다. 예시의 Proxy는 그룹 이름이고 Example-Server는 앞에서 정의한 항목 이름입니다.
• [Rule]: 대상 조건과 처리 정책을 연결합니다. 규칙의 정책 이름은 실제 서버 또는 그룹 이름과 정확히 일치해야 합니다.
• [Host]: 지정한 호스트 이름에 대한 주소 매핑을 설정합니다. 필요하지 않은 매핑을 무심코 추가하면 이름 해석 결과가 예상과 달라질 수 있습니다.

3. 사용자 규칙 순서와 원격 RULE-SET 적용

[Rule]은 일반적으로 위쪽부터 조건을 확인하므로, 더 구체적인 조건을 넓은 조건보다 먼저 배치하는 편이 확인하기 쉽습니다. 예를 들어 특정 도메인을 별도 정책으로 보내려면 그 규칙을 넓은 도메인 조건보다 위에 둡니다. FINAL은 앞선 조건과 일치하지 않은 요청을 처리하므로 보통 목록 끝에 둡니다. 중간에 놓으면 그 아래 규칙이 실행되지 않을 수 있습니다.

원격 규칙 목록은 RULE-SET으로 참조할 수 있습니다. 주소와 정책은 실제로 보유한 구성에서 확인해야 하며, 다음 주소는 문법 예시용 자리표시자입니다. 원격 목록의 각 행이 Shadowrocket에서 지원되는 규칙 형식인지, 지정한 정책 이름이 현재 설정에 존재하는지 확인하세요.

[Rule]
DOMAIN,login.example.com,DIRECT
RULE-SET,https://rules.example.com/sample.list,Proxy
GEOIP,CN,DIRECT
FINAL,Proxy

RULE-SET 한 줄이 모든 규칙을 대신하는 것은 아닙니다. 참조 주소를 가져오지 못하거나 목록 형식이 호환되지 않으면 기대한 조건이 적용되지 않을 수 있습니다. 원격 목록을 바꾸기 전에는 기존 파일을 보관하고, 수정 후 요청 로그에서 해당 도메인이 어떤 규칙에 의해 처리됐는지 확인하세요. 인증 정보가 들어간 주소는 공개 게시물이나 공개 진단 도구에 붙여 넣지 마세요.

• 우선 처리할 예외: 개별 도메인이나 좁은 범위의 규칙을 위쪽에 배치합니다.
• 넓은 조건: 여러 목적지에 영향을 주는 규칙은 예외 규칙 뒤에 둡니다.
• 기본 처리: FINAL을 마지막에 배치하고, 그 정책이 실제 의도와 맞는지 확인합니다.
• 정책 참조: 규칙의 목적지에 적은 이름이 정의된 서버 또는 그룹과 일치하는지 점검합니다.

4. 설정을 복사해 수정하고 동작 확인하기

처음부터 전체 파일을 새로 작성하기보다 현재 적용 중인 Config를 복사해 테스트용으로 수정하세요. 메뉴 구성은 앱 버전에 따라 달라질 수 있지만, Config에서 파일을 선택하거나 편집한 뒤 Home에서 Global Routing을 확인하는 흐름으로 점검할 수 있습니다. 연결 스위치를 켤 때 시스템 VPN 구성 추가 안내가 나타나면 요청을 보낸 앱이 Shadowrocket인지 확인하고 시스템 안내에 따라 승인하세요.

1. 원본 보관

   Config에서 현재 사용하는 파일을 확인하고 별도 복사본을 만드세요. 편집 전 파일 이름과 활성 Config를 기록해 두면 변경 전후를 구분하기 쉽습니다.

2. 한 줄 추가

   테스트할 도메인 규칙 하나를 [Rule]에 넣으세요. 정책 이름이 실제 Proxy 항목이나 Proxy Group과 일치하는지 확인하고, FINAL보다 위에 배치합니다.

3. Config 선택

   저장한 파일이 Config에서 선택되어 있는지 확인하세요. 파일을 편집했더라도 다른 Config가 활성화되어 있으면 새 규칙이 적용되지 않을 수 있습니다.

4. 요청 확인

   Home에서 필요하면 Global Routing을 Config로 설정하고 연결을 켭니다. 요청 로그에서 테스트한 도메인과 적용 정책을 살펴보고, 기대한 규칙이 보이는지 확인하세요.

5. 변경 비교

   규칙이 적용되지 않으면 먼저 활성 Config, 규칙 위치, 정책 이름, 원격 목록 갱신 여부를 순서대로 점검하세요. 결과를 기록한 뒤 다음 변경을 진행합니다.

요청 로그는 실제 요청이 기록되고 표시되는 경우에 유용한 확인 자료입니다. 앱이나 시스템의 동작에 따라 모든 요청이 같은 방식으로 나타난다고 가정하지 말고, 로그에 없는 항목만으로 특정 규칙이 실행되지 않았다고 단정하지 마세요. 먼저 재현 가능한 도메인 요청을 한 번 발생시키고 시간, 대상, 표시된 정책을 함께 확인하세요.

5. 요청 로그와 MITM 인증서의 보안 점검

일반적인 규칙 확인에 MITM 인증서는 필요하지 않습니다. MITM을 사용하면 설정된 대상의 HTTPS 연결을 중간에서 검사할 수 있도록 인증서와 기기 신뢰 설정이 관여합니다. 인증서를 설치하거나 신뢰하도록 설정하기 전에 어떤 목적으로 필요한지, 어떤 호스트에 적용되는지 확인하세요. 인증서가 있다고 해서 모든 앱의 암호화 통신을 안전하게 검사할 수 있다는 뜻은 아닙니다.

• 대상 범위 제한: [MITM]의 hostname에는 확인이 필요한 호스트만 지정하세요. 와일드카드 범위를 넓히면 예상보다 많은 통신에 영향을 줄 수 있습니다.
• 인증서 신뢰 확인: Shadowrocket에서 인증서를 설치한 뒤 시스템의 인증서 신뢰 설정이 필요한 경우, 본인이 시작한 절차인지 확인하고 안내를 따르세요. 인증서를 모르는 사람에게 전달하거나 공개 저장소에 올리지 마세요.
• 앱별 제약 고려: 인증서 고정이나 앱 자체 검증을 사용하는 서비스는 MITM 연결을 거부할 수 있습니다. 그런 앱에서 오류가 나더라도 인증 검사를 무리하게 우회하려 하지 마세요.
• 사용 후 정리: 진단 목적이 끝나면 MITM 대상 설정과 더 이상 필요하지 않은 인증서 신뢰 설정을 검토하고 정리하세요. 요청 로그에는 방문한 호스트 등 민감한 정보가 남을 수 있으므로 외부에 공유하기 전에 확인해야 합니다.

요청 로그를 공유해야 한다면 전체 설정 파일, 인증 토큰, 비밀번호, 개인 키, 구독 주소를 함께 보내지 마세요. 문제를 재현하는 데 필요한 시각과 오류 문구, 민감 정보를 제거한 도메인 정보만으로 원인을 설명할 수 있는지 먼저 검토하세요.

6. 자주 묻는 질문