Android에서 VPN을 켜면 MMS가 실패한다: 먼저 통신사 경로
사진 메시지는 통신사 자체 경로와 자체 네트워크 기능을 사용하므로, 브라우징이 된다고 해서 아무것도 증명되지 않습니다. VPN을 건드리기 전에 SMS, MMS, RCS를 구분하십시오.
웹 페이지는 열리고 통화도 되는데, 사진 메시지는 조치할 수 있는 오류도 없이 전송 중 상태로 멈춰 있다. 이런 조합은 인터넷 장애가 아니다. MMS는 통신사 고유의 설정과 고유한 전달 경로를 가진 서비스이며, Android에서는 플랫폼이 브라우저가 택한 경로를 재사용하는 대신 특정 네트워크를 요청할 수 있다. 여기서 세 가지 판단이 나온다: 어떤 메시지 유형이 실제로 실패했는지, 전송을 누가 소유하는지, 애초에 VPN이 관련되는지.
어떤 메시지 유형이 실제로 실패했는지
SMS, 통신사 MMS, RCS는 하나의 대화 창을 공유하는 세 가지 다른 서비스다. 스레드의 말풍선은 어느 것이 쓰였는지 알려주지 않고, 하나를 고쳐도 나머지에는 영향이 없다. 실제로는 RCS 메시지인 실패한 사진 메시지는 APN 설정을 바꿔도 고쳐지지 않고, 휴대폰을 떠난 적 없는 MMS는 RCS를 다시 등록해도 고쳐지지 않는다.
가장 평범한 말로 장애를 확정하라: 텍스트만 있는 SMS는 도착하는지, 작은 사진은 보내기에서, 받기에서, 아니면 둘 다에서 실패하는지, 그 장애가 VPN보다 앞서는지. 답이 들어오는 사진만 실패한다면, 당신은 다운로드 경로를 보고 있는 것이며, 제한된 네트워크에서는 업로드 경로와 다르게 동작한다.
MMS는 경로가 아니라 네트워크를 요구한다
Android는 MMS 작업을 SmsManager 와 플랫폼의 MMS 서비스를 통해 노출하며, 이 서비스는 특정 가입에 대해 MMS 기능이 있는 셀룰러 네트워크를 요청할 수 있다. 이는 앱이 기본 경로로 HTTPS 연결을 여는 것보다 좁은 요청이다. 그래서 모든 일반 트래픽을 나르는 VPN이 동작하는 MMS 경로와 공존할 수 있고, 반대 조합이 장애로 나타난다.
이 구분이 중요한 이유는 책임 소재가 다르기 때문이다. 플랫폼의 MMS 요청을 충족할 수 없다면 문제는 가입이나 통신사 쪽에 있다. 요청이 성공하지만 VPN이 켜져 있을 때만 전송이 멈춘다면, 앱의 네트워크 통합이나 VPN 정책이 더 나은 용의자다. 이 둘 사이에서 추측하는 것이 이런 종류의 보고서에서 가장 많은 시간을 낭비한다.
| What you observe | Where to look first |
|---|---|
| No mobile data at all, SMS also fails | Subscription, carrier data service, SIM state |
| Browsing works, MMS fails only with the VPN on | The app's network integration or the VPN policy |
| MMS fine, RCS will not register | RCS registration, unrelated to the MMS transport |
| MMS fails on one SIM but not the other | Which subscription owns mobile data, and which sent the message |
통신사 설정은 건드리지 말라
통신사가 의도한 APN, MMS 서버 주소, 프록시 설정을 그대로 둔다. VPN이 브라우징 동작을 바꾼다고 해서 낯선 APN이나 공용 DNS 서버를 붙여 넣을 이유는 없다—MMS는 브라우저가 선호하는 리졸버를 쓰지 않으며, 잘못된 APN은 작동하던 유일한 경로를 망가뜨린다.
듀얼 SIM 휴대폰에서는 두 가지를 따로 확인하라: 지금 어느 가입이 모바일 데이터를 소유하는지, 메시지가 어느 가입에서 전송되었는지. 우연히 데이터가 있는 SIM에서 시험하면서 실패하는 스레드는 다른 쪽에 묶여 있는 경우가 흔하다. 오래된 서드파티 메시징 앱은 시스템 통합 경로와 다르게 동작하는 사용자 지정 또는 구식 네트워크 경로를 쓸 수도 있으므로, 옛 버전에서 기억하는 메뉴 이름보다 유지 관리되는 앱의 문서화된 모드를 우선하라.
비교를 좁혀라
시험하는 하나의 변수만 빼고 모두 고정하라: 같은 앱, 같은 수신자, 같은 가입, 작고 민감하지 않은 시험용 사진 한 장. 보내기, 받기, 또는 둘 다 실패하는지, 정확한 오류 문구가 무엇인지, VPN이 켜져 있을 때 결과가 달라지는지 기록하라.
개인 기기에서 정책이 허용한다면, VPN 없이 짧게 비교하면 의존성을 분리할 수 있다. 이것은 진단이지 보호 없이 쓰라는 권고가 아니며, 관리 또는 잠금 기기에서는 지원되는 절차가 포럼 게시물이 아니라 관리자로부터 온다. 한 번만 재현할 수 있는 장애를 재현하려고 사적인 미디어를 반복 전송하지 말라.
지원팀에 무엇을 넘기고, 무엇을 가정하지 말아야 하는가
VPN이 켜진 경우에만 실패한다면, 유용한 보고서에는 클라이언트 이름과 버전, 메시징 앱 버전, 네트워크 유형, 사용 중인 가입, 장애의 정확한 현지 시각이 담긴다. 이 다섯 가지 사실이 있으면 누군가 추측 대신 장애를 통신사와 클라이언트 로그에 맞춰 볼 수 있다.
메시징 앱을 제외하는 것이 해법이라고 가정하지 말라. 시스템 전화 구성 요소가 작업의 일부를 소유할 수 있고, VPN 없이 차단하는 정책은 단순 제외와 다르게 동작하므로, 앱이 제외된 것처럼 보여도 계속 실패할 수 있다. 제외를 가설로 시험하고, 결과를 보관하고, 증거가 뒷받침하지 않으면 되돌려라.