왜 Shadowrocket는
"특정 앱만 프록시"를 못 하나.

iOS VPN은 Apple 프레임워크를 탄다

iOS는 데스크톱처럼 타사가 네트워크 하층을 직접 잡고 트래픽을 마음대로 가로채거나 바꾸도록 두지 않습니다. 전달이 필요한 앱(Shadowrocket 포함)은 Apple 공식 Network Extension을 통과해야 하고, 전달의 핵심이 NEPacketTunnelProvider입니다. 처음 쓸 때 "VPN 구성" 허용이 뜨는 것은 이 공식 경로의 필수 단계이며, Shadowrocket가 만든 장치가 아닙니다.

동작 모드는 둘. 섞을 수 없다

Apple 공식 문서에 따르면 NEPacketTunnelProvider가 쓸 수 있는 라우팅은 다음 두 모드뿐이고, 배타적입니다.

모드	동작	제한
대상 IP로 라우팅 destinationIP	접속할 주소로 터널에 넣을지 정합니다. Shadowrocket의 전역 프록시와 규칙 분기는 이쪽입니다	이 모드에서 시스템은 "어느 앱의 요청인지"를 알려주지 않습니다. 도메인이나 IP로만 판단하고, 발신 앱은 보이지 않습니다
발신 앱으로 라우팅 sourceApplication	트래픽의 발신 앱으로 터널에 넘길지 정합니다	이 "Per-App VPN"에서는 어떤 앱 트래픽이 터널에 들어가면 전부 처리해야 하고, 일부만 프록시·일부는 직접 연결로 나눌 수 없습니다. 보통 MDM(기업 기기 관리)이 필요하고, 일반 사용자가 직접 설치한 앱에서는 쓸 수 없습니다

즉 Apple 설계에는 "앱으로 나눈 뒤, 같은 앱의 일부만 다시 나누는" 모드가 없습니다. 어느 프록시가 미구현인 문제가 아니라 시스템 API가 열려 있지 않습니다. 개발자 포럼 공식 답변에도 "Per-App VPN에서는 어떤 앱의 일부 트래픽만 처리하는 장치가 없다"고 명시돼 있습니다.

Shadowrocket가 실제로 쓰는 대체 수단

시스템에서 "이 요청이 어느 앱인지"를 못 받으니, Shadowrocket는 대상 도메인 / IP로 판정합니다. 규칙 파일의 DOMAIN-SUFFIX, IP-CIDR, GEOIP 등은 "그 앱이 자주 붙는 도메인이나 서버"로 앱 단위 분기에 가깝게 만드는 근사이며, 발신 앱을 식별하는 것이 아닙니다.

실제 사용에서 보는 다음 현상도 이것으로 설명됩니다.

• 규칙이 안 먹힘앱이 서버나 CDN을 바꾸면 적어 둔 도메인/IP가 더 이상 안 맞을 수 있습니다. 규칙을 갱신하면 돌아옵니다. 앱 고장이 아니라, 규칙이 기대던 정보가 바뀐 것입니다.
• 도메인을 공유하는 앱은 나누기 어려움다른 앱이 같은 도메인이나 같은 서버군(같은 CDN 등)을 쓰면 규칙으로는 구별할 수 없고, 같이 처리할 수밖에 없습니다.
• 전역 프록시가 가장 확실함"이 종류는 반드시 직접 연결, 나머지는 반드시 프록시"가 엄격하면 규칙보다 Proxy 모드가 일관됩니다. 직접 연결 속도는 일부 희생됩니다.

참고: 기술 세부사항은 Apple 공식 개발자 문서(Network Extension / Packet Tunnel Provider)와 개발자 포럼 공식 답변을 따릅니다. API 동작은 최신 공식 문서를 우선하세요.

관련 글: 규칙 구문 설명　·　사이트가 안 열릴 때 절차