Android 上开 VPN 时 MMS 发不出去：先看运营商的路径
图片消息走的是运营商自己的路径和网络能力，所以能上网并不能说明什么。在动 VPN 之前，先把 SMS、MMS 和 RCS 分开。
网页能打开、电话能打通，可一条图片消息却卡在发送中，也不报任何可以处理的错误。这种组合并不是断网。MMS 是运营商的服务，有自己的配置和自己的投递路径，而在 Android 上平台可以为它请求一条特定的网络，而不是复用浏览器走过的那条路由。由此有三个判断：真正失败的是哪种消息、传输归谁负责，以及 VPN 到底有没有牵扯其中。
真正失败的是哪种消息
SMS、运营商 MMS 和 RCS 是共用同一个会话窗口的三种不同服务。会话里的气泡并不告诉你用了哪一种，修好一种也不会碰到另外两种。一条实际上属于 RCS 的失败图片消息，改 APN 设置是修不好的；一条从未离开手机的 MMS，重新注册 RCS 也修不好。
用现有最朴素的说法把故障定下来：只有文字的 SMS 能不能收到，小图片是在发送、接收还是两头都失败，以及这个故障是不是在开 VPN 之前就有。如果答案只有收到的图片失败，那你看到的是下载路径，它在受限网络上的表现和上传路径并不一样。
MMS 要的是一条网络，而不只是路由
Android 通过 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 手机上要分别查两件事：当前由哪张卡持有移动数据，以及这条消息是从哪张卡发出的。常见的情况是，在碰巧有数据的那张卡上测试，而出问题的会话却绑在另一张卡上。较旧的三方短信应用也可能使用自定义或遗留的网络路径，表现和系统集成的路径不同，所以应优先采用仍在维护的应用文档中给出的模式，而不是凭旧版本记住的菜单名称。
把对比收窄
除了你要测的那一个变量，其余全部保持一致：同一个应用、同一个收件人、同一个订阅、同一张小而不敏感的测试图片。记下是发送、接收还是两者都失败，确切的错误文字是什么，以及 VPN 开着时结果会不会变化。
如果在个人设备上策略允许，短时间关掉 VPN 做一次对比，就能把依赖关系隔离出来。这是诊断，不是建议在无保护状态下使用；在受管或锁定设备上，受支持的流程来自管理员，而不是论坛帖子。不要为了复现一次就能复现的故障，反复发送私人媒体。
该交给支持什么，不该假设什么
如果只有开着 VPN 的那种情况失败，有用的报告应包含客户端名称和版本、短信应用版本、网络类型、正在使用的订阅，以及故障的确切本地时间。有了这五项事实，别人就能把故障与运营商和客户端日志对上，而不是靠猜。
不要以为把短信应用排除在外就是解决办法。系统电话组件可能拥有一部分操作，而“无 VPN 时阻断”这种策略的行为不同于简单排除，所以应用看起来被豁免，却仍然可能失败。把排除当作假设去测，保留结果，如果证据不支持就改回来。