macOS 26.5 RCS 消息发送失败(Mac、iPad 和 Watch):隐藏的蜂窝网络修复方法
升级 macOS 26.5 后无法从 Mac 发送 RCS 消息?本指南提供完整修复方案,包括 iPhone 深处的「限制 IP 地址追踪」设置、运营商特定说明,以及 E2EE 握手机制解析。
如果你本周更新了 macOS Tahoe 26.5,突然发现发给 Android 好友的短信出现了醒目的红色「消息发送失败」提示——但仅在你从 Mac、iPad 或 Apple Watch 发送时才出现——请放心,这不是你的幻觉,你并没有被对方拉黑,你的账户和硬件也完全没有问题。这是 2026 年 5 月 11 日发布的 macOS 26.5(以及同期发布的 iOS 26.5)引入的一个真实回归 bug。更新公开后数小时内,MacRumors 论坛中追踪该问题的帖子(帖子编号 2482378,标题为「iOS 26.5 和 macOS 26.5 下 RCS 有问题吗?」)已超过四百条回复。用户投诉几乎如出一辙:在 Mac 上发送的消息出现红色感叹号;拿出 iPhone 向同一联系人发送同样的文字,却完全正常。消息在 iPhone 的输入框中甚至显示为「RCS」。因此,Mac 与 iPhone 之间的 RCS 桥接断开了,但 SMS 和 iMessage 的接续链路仍然正常,而你只能在想用笔记本电脑回复消息时,不得不在设备之间来回切换。
好消息是确实有修复方法,而且只需拨动一个开关。坏消息是,这个开关深藏在 iPhone 三级菜单之下,表面上与「信息」应用毫无关联,而且截至本文撰写时,Apple 尚未在任何发行说明或支持文档中承认这一回归问题。这是隐私与功能性之间的权衡,在你拨动开关之前,你有权利充分了解自己究竟关闭了什么。本指南将带你完成修复过程,解释导致故障的底层 E2EE 握手变更,涵盖运营商特定的问题(T-Mobile 用户受影响最严重),并在主要开关无法解决你的特定情况时,提供备用修复方案的阶梯。
核心要点
- 症状:在 macOS 26.5 / iOS 26.5 上,从 Mac、iPad 或 Apple Watch 发送 RCS 消息时出现红色「消息发送失败」。同一条消息直接从 iPhone 发送则完全正常。
- 单开关修复方法:在你的 iPhone 上,进入「设置」→「蜂窝网络」→ 你的号码线路 →「蜂窝数据选项」→ 关闭「限制 IP 地址追踪」。
- 原因:macOS 26.5 新的端对端加密(E2EE)RCS 握手通过 Apple 中继路由加密数据包。该中继与蜂窝线路上的 iCloud 私有中继式 IP 地址屏蔽不兼容,在消息离开 iPhone 之前就悄无声息地中断了握手。
- 受影响群体:T-Mobile US 用户反映的故障率最高,其次是 Verizon 和 AT&T。Google Fi 用户基本不受影响,因为 Fi 使用 Google 的 RCS 路径,而非 Apple 的。国际运营商中,已启用 E2EE RCS 的用户视具体情况受到影响。
- 权衡取舍:关闭「限制 IP 地址追踪」后,你的运营商(以及 iPhone 通过蜂窝网络访问的网站)将更清晰地看到你的 IP 地址。这不会影响 iMessage、FaceTime 或任何 iCloud 流量——如果你已启用私有中继,这些流量仍会使用私有中继。
- Apple 的可能对策:基于 Apple 最近处理握手级回归的惯例,在五月中旬至六月初窗口期内发布重建 E2EE 握手以兼容 IP 屏蔽的 26.5.1 小版本是合理预期。
- 验证是否成功:从 Mac 向已知 RCS 联系人发送测试消息;你应该看到气泡下方显示「已送达」(以及对方下次回复时的正在输入指示),而不是红色错误提示。
确切症状:你实际看到的是什么
让我精确描述这种故障模式,因为至少有另外四种看起来表面相似但与此 bug 毫无关系的情况。
当你在 Mac(或 iPad、Apple Watch)上的「信息」应用中向 Android 设备联系人发送消息时,消息气泡以绿色 RCS 样式出现——不是蓝色的 iMessage 样式,也不是旧版 SMS/MMS 的浅绿色。你点击发送。消息在对话界面中向上滑动。然后,在一到三秒内,气泡旁边出现一个带感叹号的小红圈,气泡下方的小号红字显示「未送达」或「消息发送失败」。点击红色感叹号会弹出标准的「重试」或「以短信方式发送」提示。选择「以短信方式发送」会将消息通过 SMS 发出,确实能发送——但你会失去加密、已读回执、正在输入指示、高清媒体文件,以及所有让 RCS 物有所值的功能。
以下关键现象能确认你遇到的正是这个特定回归,而非其他接续问题:拿起你的 iPhone,打开「信息」,找到同一个对话,输入同样的文字,点击发送。消息立即发出,显示「已送达」,整个过程中输入框底部始终显示 RCS 标签。同一个 Apple ID、同一部 iPhone、同一个运营商连接——但从 Mac 发送失败的消息,从 iPhone 发送却成功了。这种不对称性正是 macOS 26.5 RCS 握手回归的特征指纹。这不是网络问题(你的手机使用同一个网络或至少同一个运营商);不是账户问题(你在两台设备上是同一个用户);也不是联系人问题(拨打对方号码时,从 iPhone 完全正常)。
如果你的症状包括从 iPhone 本身发送也失败,那你面对的是不同的问题——很可能是运营商配置问题或 iMessage 激活故障——本指南无法修复它。如果你的 iMessage(蓝色气泡,Apple 到 Apple)从 Mac 也发送失败,那是接续认证问题,而非 RCS 问题。如果在 26.5 更新发布之前你的消息给 Android 好友就已经发送失败,这也超出了本文的范围。我们要解决的确切回归是:macOS 26.5 + iOS 26.5,RCS 气泡(绿色,iPhone 上可见「RCS」标签),从副设备发送失败,从 iPhone 直接发送正常。

RCS 在 macOS 上的工作原理:接续桥接
要理解为什么这个特定开关能修复这个特定问题,你需要对 RCS 消息如何到达 Mac 有一个基本的认知模型。与 iMessage 不同——iMessage 有自己的原生协议和 Apple 自己的服务器,并从你的每台 Apple 设备直接连接到 Apple 的 iMessage 基础设施——RCS 在 Apple 设备上是一个以手机为锚点的协议。就运营商而言,你的 iPhone 是 RCS 端点。你的运营商只知道一台设备(iPhone)在你的手机号码上配置了 RCS。你的 Mac、iPad 和 Apple Watch 完全没有配置 RCS——运营商甚至不知道它们的存在。
那么 macOS 的做法是,通过处理 SMS/MMS 转发的同一条接续桥接来路由 RCS 消息。当你在 Mac 上输入消息并点击发送时,「信息」应用不会直接联系你的运营商。而是将消息打包,用接续传输协议加密,通过 Apple 的接续基础设施(即处理「短信转发」、iPhone 通话中继和 Handoff 的同一通道)发送到你的 iPhone。你的 iPhone 收到数据包,识别为待发出的 RCS 消息,并将其交给自己的蜂窝无线电,使用 iPhone 自己的 RCS 凭证通过运营商的 RCS 服务器发送出去。
这就是为什么 Mac 上的 RCS 始终需要:(1) 你的 iPhone 登录同一个 Apple ID;(2) 在 iPhone「设置」→「信息」→「短信转发」中为你的 Mac 启用短信转发;以及 (3) 你的 iPhone 开机并可通过网络访问。缺少这三个条件中的任何一个,Mac 的 RCS 就会中断。你可以将 Mac 看作一个让你撰写消息的瘦客户端,但实际发送始终从 iPhone 完成——你的 Mac 本质上是在将你的 iPhone 用作所有非 iMessage 流量的远程调制解调器。
在 iOS 26.5 以及美国 Apple 设备 E2EE RCS 引入之前,这个桥接对 SMS、MMS 和未加密 RCS 运行良好。接续数据包结构相当简单——发送方、接收方、正文、元数据——iPhone 可以将其中继到运营商的 RCS 服务器,几乎无需额外处理。你的 Mac 与 iPhone 之间的握手通过 Apple 标准的接续传输完成,该传输本身已加密,但不会对蜂窝层施加任何约束。
26.5 中为何出现故障:E2EE RCS 握手
以下是 26.5 改变的根本之处。从 iOS 26.5 和 macOS 26.5 版本开始,Apple 开始为支持 GSMA E2EE RCS 规范(带有 MLS——消息层安全——的通用配置文件 3.0)的运营商推出端对端加密 RCS。T-Mobile US 是全球首批在 Apple 设备上全面启用 E2EE RCS 的主要运营商之一,而 Verizon 和 AT&T 自该版本发布以来一直在按地区逐步激活。Apple 支持文档 HT127115(26.5 发行说明)在安全更新部分包含一行提及「受支持运营商的 RCS 端对端加密消息传递支持」的内容——没有关于握手架构的进一步细节。
E2EE RCS 握手比未加密版本复杂得多。为了协商用于端对端加密消息正文的密钥(这样 Apple 和运营商都无法读取),发送方设备和接收方设备通过专用握手服务器交换基于 MLS 的密钥材料。对于 iPhone 直接发送 RCS,这个握手在 iPhone 与运营商的 MLS 握手端点之间进行,Apple 位于注册层。然而,对于通过接续发送 RCS 的 Mac,Apple 引入了一个中继步骤:Mac 生成 MLS 握手材料,打包后通过接续桥接发送到 iPhone,iPhone 将其转发到 Apple 中继端点,中继再转发到运营商的握手服务器。中继步骤是 26.5 中的新内容,它让 Apple 有了一种整洁的方式来处理 iPhone 可能暂时离线或处于低功耗状态的情况——中继可以短暂缓存握手材料。
问题在于,这个 Apple 中继端点是通过 iPhone 的蜂窝接口连接的。从 iOS 14 开始,Apple 添加了一项名为「限制 IP 地址追踪」的隐私功能——一个按线路设置的蜂窝配置,在 iPhone 使用蜂窝网络时向已知追踪者隐藏你的 IP 地址。它的工作原理是通过 Apple 运营的代理(类似于 iCloud 私有中继)路由某些流量。对于 SMS、MMS、常规网页浏览和 26.5 之前的 RCS,这个代理透明运行,没有人注意到。但新的 E2EE RCS 握手对 IP 层的敏感程度是旧协议所没有的——具体而言,中继端点的身份验证使用了连接级属性,当流量通过 Apple 的 IP 屏蔽基础设施代理时,这些属性会发生变化。握手在中继的身份验证检查中静默失败,消息始终无法获得用于加密的密钥,因此 iPhone 通过接续桥接向你的 Mac 返回一个通用的「发送失败」。
从你的 Mac 视角来看,这个失败是不透明的:红色感叹号,没有有用的错误消息。从 iPhone 的视角来看,它知道握手失败了,但不向用户显示,因为 iPhone 不是发起发送的设备。从运营商的视角来看,从未传输过任何消息——失败完全发生在运营商的 RCS 服务器上游。
这也解释了为什么直接从 iPhone 发送同一条消息能成功:当 iPhone 自己撰写消息时,它使用的握手路径不经过中继(iPhone 本身就是运营商配置的 RCS 端点,所以它直接与运营商协商密钥,无需 Apple 中继)。「限制 IP 地址追踪」隐私代理不会破坏 iPhone 直接发送路径,因为运营商的 RCS 握手服务器使用不同的身份验证模型,对代理连接有更高的容忍度。
修复方法:隐藏的蜂窝开关
以下是确切路径。请仔细阅读,因为有多个名称相近的设置,只有其中一个是正确的。
-
在你的 iPhone 上(不是 Mac——这是 iPhone 端的设置,因为故障发生在 iPhone 用于访问 Apple 中继的蜂窝接口上),打开**「设置」**应用。
-
点击**「蜂窝网络」**(在双 SIM 卡手机上,根据你所在地区,这可能标记为「蜂窝网络」或「移动数据」)。
-
在「SIM 卡」部分,点击处理你 RCS 消息的特定线路。如果你只有一张 SIM 卡,只会有一个条目——点击它。如果你有两张 SIM 卡(实体 SIM 卡和 eSIM,或两张 eSIM),点击设置为 iMessage 和手机号码主线路的那张。你可以通过返回「设置」→「信息」→「iMessage 与 FaceTime」来确认正确的线路——查看哪个手机号码被列为 iMessage 的主号码;那就是 RCS 设置中需要修改的线路。
-
在线路详情页面,点击**「蜂窝数据选项」**(在旧版 iOS 中有时标记为「数据模式」——但在 26.5 中是「蜂窝数据选项」)。
-
你会看到一个标记为**「限制 IP 地址追踪」的开关,下方有简短说明:「通过在邮件和 Safari 中对已知追踪者隐藏你的 IP 地址来减少追踪。」将其拨到关闭**。
-
完全退出「设置」(向上滑动关闭,或按下主屏指示器/按钮)。
-
拿起你的 Mac,打开「信息」,找到发送失败的对话,发送一条测试消息。一两秒内,你应该看到气泡下方出现「已送达」,红色感叹号不再出现。
这就是修复方法。在 iPhone 上正确的 SIM 卡中拨动一个开关。更改立即生效——你不需要重启任何设备,不需要退出任何账户,也不需要等待传播时间。

双 SIM 卡说明
如果你有两张 SIM 卡且不确定哪张处理 RCS,规则如下:iPhone 上的 RCS 与当前设置为 iMessage 线路的号码绑定(「设置」→「信息」→「iMessage 与 FaceTime」→ 主号码)。它也与在「设置」→「应用程序」→「信息」→「RCS 消息」(或在稍旧版本中「设置」→「信息」→「RCS 消息」)中主动启用了 RCS 消息的线路绑定——在双 SIM 手机上,这里会显示每条线路的开关。已开启 RCS 开关且与你的 iMessage 主号码匹配的那条线路,就是你需要关闭「限制 IP 地址追踪」的线路。
如果两张 SIM 卡都启用了 RCS(不常见但可能,如果你同时使用两者发送消息),请为两者都关闭「限制 IP 地址追踪」。对于仅用于数据或热点的 SIM 卡,可以保持开启。
诚实的隐私权衡
你应该了解拨动这个开关实际上放弃了什么,因为网上的一些讨论对此含糊其辞,而你有权获得真实的答案。
当某条蜂窝线路的「限制 IP 地址追踪」开启时,你的 iPhone 会将一部分蜂窝流量——具体是「邮件」和 Safari 中已知追踪者的流量,以及与 Apple 追踪者名单匹配的某些域名的流量——通过 Apple 运营的代理路由,从而对这些目的地隐藏你的真实 IP。这是 iCloud 私有中继功能的一个子集(私有中继覆盖范围更广,涵盖更多流量,但需要 iCloud+ 订阅)。蜂窝级别的开关适用于所有人,不仅仅是 iCloud+ 订阅者,并且在多个 iOS 版本中默认开启。
当你将其关闭时,该线路的代理被绕过。你的 iPhone 通过蜂窝网络通信的追踪者(嵌入 Safari 页面的分析端点、邮件追踪像素、某些应用程序遥测)将看到你的真实蜂窝 IP 地址。你的运营商也会对你的流量模式有稍微更清晰的认知,尽管无论这个开关处于何种状态,你的运营商已经在网络层面看到你所有的蜂窝流量。
不会改变的内容:
- iMessage:Apple 的 iMessage 流量根本不经过蜂窝追踪代理——iMessage 有自己的端对端加密和自己的基础设施路由。关闭「限制 IP 地址追踪」对 iMessage 没有任何影响。
- FaceTime:与 iMessage 相同——独立路由,不受影响。
- iCloud 私有中继:如果你有 iCloud+ 并启用了私有中继,Safari 浏览仍会通过私有中继的双跳架构。「限制 IP 地址追踪」是一个独立的、更窄的功能。
- VPN 流量:你通过 VPN 路由的任何内容均不受影响——VPN 流量绕过「限制 IP 地址追踪」和私有中继。
- 应用程序特定的隐私设置:每个应用的权限(位置、联系人等)不受影响。
因此,权衡是:为了能够从 Mac 发送 RCS,你的蜂窝线路上的 IP 地址对网页追踪者和邮件追踪者的暴露略有增加。对于大多数人来说,这是一个合理的交换——特别是如果你已经有 iCloud+ 私有中继覆盖 Safari 浏览的话。如果你处于蜂窝网络上的 IP 级别隐私至关重要的情况(敏感司法管辖区的记者、活动人士等),这可能不是可接受的权衡,你可能需要使用下面的替代修复方案之一,或者直接从 iPhone 发送 RCS,等待 Apple 发布 26.5.1。
主要开关不起作用时的替代修复方案
IP 追踪开关能为 T-Mobile、Verizon 和 AT&T 上的绝大多数用户解决问题。但一小部分情况——特别是使用地区性运营商的用户、iMessage 账户状态异常的用户,或接续桥接之前被错误配置的用户——即使在关闭开关后仍然看到失败。以下是额外修复方案的阶梯,按我建议尝试的顺序排列。
1. 在 iPhone 上退出并重新登录 iMessage
RCS 桥接以 Apple 未完全记录的方式依赖于 iMessage 激活令牌。当 iMessage 进入异常状态时,RCS 通常也会随之出现问题。在 iPhone 上:「设置」→「应用程序」→「信息」→「iMessage 与 FaceTime」→ 关闭 iMessage,等待整整 30 秒(越长越好——如果可以的话等一分钟),然后重新开启。可能会提示你重新验证手机号码,这是正常的。一旦在「你可以通过以下方式接收消息」下方的手机号码旁看到绿色复选标记,就再次尝试从 Mac 发送。
2. 为 Mac 禁用并重新启用短信转发
接续的 Mac 短信转发条目可能会变得陈旧。在 iPhone 上:「设置」→「信息」→「短信转发」。在列表中找到你的 Mac,将其关闭。等待 15 秒。重新开启——你的 Mac 随后会显示一个六位数代码,你在 iPhone 上输入该代码以重新配对转发链接。重新配对后,从 Mac 发送一条测试消息。
3. 在运营商菜单中重启 RCS
RCS 本身可以在 iPhone 上切换,切换操作会强制向运营商重新注册。在 iPhone 上:「设置」→「应用程序」→「信息」→「RCS 消息」→ 关闭,等待状态降为「不可用」或类似状态(这可能需要 30-60 秒),然后重新开启。你会看到它循环经过「正在注册」,然后稳定在「就绪」或「可用」状态。这比退出 iMessage 更重,应该在该步骤之后尝试。
4. 在 iPhone 上重置网络设置
这更具破坏性——它会清除保存的 Wi-Fi 密码和 VPN 配置——但它可以清除卡住的接续相关网络状态。「设置」→「通用」→「传输或重置 iPhone」→「重置」→「重置网络设置」。手机将重启。你需要重新连接 Wi-Fi 网络。恢复后,从 Mac 发送一条测试消息。
5. 按顺序重启两台设备
令人惊讶的是,相当多的接续问题通过顺序重启得以解决:先关闭 Mac,再关闭 iPhone,然后开启 iPhone 并等待其完全连接到蜂窝网络和 Wi-Fi(给它两分钟),最后开启 Mac。顺序很重要,因为 Mac 根据从 iPhone 看到的内容重新建立接续链接,所以 iPhone 需要先完全上线。
6. 最后手段:对该联系人回退到 MMS
如果其他方法都不起作用,而你有一条紧急消息需要发出,你可以为特定联系人对话禁用 RCS——在 iPhone 上长按对话顶部的联系人姓名,点击「以短信发送」,对话将回退到 MMS。质量下降(无高清媒体、无已读回执、字符限制),但消息将从 Mac 可靠地发出,因为 MMS 不使用新的 E2EE 握手。
如何判断是 RCS 还是 SMS 发送失败
三个快速视觉检查可以告诉你正在使用哪种协议:
- 气泡颜色:绿色 RCS 气泡比绿色 SMS/MMS 气泡颜色略深。色调差异细微但一致——RCS 气泡还有纯 SMS 气泡所没有的轻微渐变。如果你长按气泡并选择「详细信息」,消息元数据将明确显示「RCS」或「SMS」。
- 输入框标签:在 iPhone 文字输入框底部,你会看到一个小标签,显示「RCS」、「iMessage」、「SMS/MMS」或「短信」。在 Mac 上,当你点击消息输入框时,这个标签出现在输入框页脚。如果标签在你点击发送前显示「RCS」,但你仍然收到发送失败提示,那么你遇到的就是本文所涵盖的回归问题。
- 加密指示器:特别对于 E2EE RCS,你会在 iPhone 输入框的 RCS 标签旁看到一个小锁图标。锁表示握手已成功完成,消息将被端对端加密。如果锁不见了但 RCS 标签存在,则握手失败,消息本将以未加密方式发送(在 26.5 之后的 T-Mobile US 上,运营商会拒绝未加密的 RCS,以强制使用 E2EE——这会加剧故障)。
如果你根本看不到「RCS」,只看到「SMS/MMS」或「短信」,那么本文不适用于你的情况——你联系人的设备不支持 RCS,或者你的线路上没有激活 RCS,这需要另行排查。
运营商特定说明
T-Mobile US
T-Mobile US 是在 Apple 设备上推出 E2EE RCS 最积极的运营商,因此 T-Mobile 用户在 26.5 更新后报告的故障率最高。T-Mobile 社区论坛和支持帖子自 5 月 11 日起就一直很热闹,许多用户最初将问题归咎于他们的账户,或认为是 SIM 卡问题,然后才发现 IP 追踪修复方案。T-Mobile 的 RCS 基础设施要求 E2EE 握手在任何 RCS 消息传输之前完成——他们不会优雅地回退到未加密的 RCS——这意味着握手失败是全面的而非部分的。如果你在 T-Mobile 上,主要开关不能修复你的问题,运营商端的第 3 步(切换 RCS 关闭和开启)比其他运营商更有可能有所帮助,因为 T-Mobile 的 MLS 注册对注册时设备的网络状态非常敏感。
Verizon
Verizon 的 E2EE RCS 推出是按地区进行的,不如 T-Mobile 全面。一些 Verizon 用户看到了故障;另一些则没有,即使使用相同的 iOS 和 macOS 版本,因为他们所在的基站地区尚未激活 E2EE RCS。如果你在 Verizon 上且没有遇到故障,你现在可以保持「限制 IP 地址追踪」开启——你所在地区的 RCS 还没有使用新握手。如果你确实看到了故障,IP 追踪开关的修复方式与 T-Mobile 用户相同。
AT&T
AT&T 在推出进度上介于 T-Mobile 和 Verizon 之间。AT&T 上的故障报告是真实的,但不那么普遍,AT&T 的 RCS 路径会在更多情况下静默回退到 MMS(比 T-Mobile 更多),这有时会掩盖潜在问题(你的消息发出去了,但作为 MMS 而非 RCS)。如果你的 AT&T RCS 从 Mac 发送看似成功,但你注意到它们显示为 SMS/MMS 气泡而不是 RCS 气泡,你可能正在遇到故障,只是得到了一个无声的回退而非可见的错误。
Google Fi
在 iPhone 上使用 Google Fi 的用户报告此回归基本不受影响。Fi 的 RCS 路径使用 Google 的 RCS 服务器(Jibe Mobile)而非 GSMA 通用配置文件 3.0 E2EE 规范所针对的运营商直接路径,因此 Fi 消息不经过新的 Apple 中继。Fi 有自己的 E2EE 实现,早于 Apple 的实现,iPhone-on-Fi 和 Apple 接续之间的桥接通过不同的代码路径工作。如果你在 Fi 上且看到 Mac 上的 RCS 失败,这几乎肯定是一个不同的问题——可能与账户有关——本文无法帮助你。
国际运营商
在美国以外,Apple 设备上的 E2EE RCS 推出参差不齐。欧洲、英国和澳大利亚的主要运营商在 2025 年和 2026 年初一直在特定线路上启用它,但大多数国际运营商上的大多数用户仍在使用未加密的 RCS,它使用旧握手且不受此回归影响。如果你在美国以外且看到了故障,请向你的运营商支持确认他们是否在你的线路上启用了 E2EE RCS;如果是,IP 追踪修复适用;如果否,这可能是一个不同的问题。

Apple 可能会做什么(以及何时做)
根据 Apple 最近处理握手级回归的记录——iOS 17.4 iMessage 送达 bug、iOS 18.2 FaceTime 认证回归、macOS Sequoia 15.1 AirDrop 接续中断、macOS 26.4 iPhone 镜像中断——对修复的现实预期是在五月中旬至六月初窗口期内推出 26.5.1 小版本。Apple 通常在 .x 发布后的 10 至 21 天内推出 .x.1 补丁,前提是存在已明确识别的、具有可见用户影响的故障模式的回归,而 RCS 握手问题轻松达到了这个门槛。
Apple 端的修复很可能会重建中继侧身份验证,使其兼容 IP 屏蔽连接。他们可以通过几种方式做到这一点:(a) 专门针对 RCS 中继端点的连接绕过 IP 追踪代理,类似于 iCloud 流量已经从私有中继豁免的方式;(b) 将中继的身份验证模型从连接级属性更改为设备级认证;或 (c) 完全消除接续桥接案例的中继步骤,让 Mac 的握手材料直接通过 iPhone 的运营商直接路径。选项 (a) 最简单也最有可能;(c) 在架构上最清晰,但需要更多测试。
在此期间,你有两个选择:为受影响的 SIM 卡关闭「限制 IP 地址追踪」并接受隐私权衡,或直接从 iPhone 发送 RCS 消息直到 26.5.1 发布。截至 2026 年 5 月 15 日,Apple 支持团队尚未就此回归发布任何公开声明,除了对直接联系支持的用户回复标准的「我们已知晓并正在调查」。请关注 HT127116(下一个小版本的典型命名惯例)的 Apple 支持发行说明页面,在接下来的几周内留意更新。
如果 26.5.1 在六月初前没有发布,最可能的原因是 Apple 正在更深入地重建握手架构(上述选项 c),这需要更长时间测试。在这种情况下,预计 26.5.1 会在六月底或七月初推出,并考虑在此之前是否值得维持 IP 追踪权衡。对于 T-Mobile、Verizon 或 AT&T 上的大多数用户来说,这是值得的——隐私暴露适度,而消息传递的便利性显著。
当此 Bug 与其他接续问题叠加时
一小部分但真实存在的用户在已有接续问题的基础上又遇到了这个 RCS 回归,叠加的症状让诊断更加困难。如果你在同一台 Mac 上已经看到 iPhone 镜像问题,那是 macOS 26.4 引入的独立回归,我们在 iPhone 镜像在 macOS Tahoe 26.4 上无法正常工作的修复指南中有详细介绍——修复镜像可能影响也可能不影响 RCS,反之亦然,但它们是具有独立修复方案的独立问题。同样,如果 AirDrop 在 Mac 和 iPhone 之间一直不稳定,这在 AirDrop 在 Mac 上无法工作的修复指南中有介绍,解决 AirDrop 不会自动解决 RCS。
对于消息传递相关故障更广泛的视角(「信息」、「邮件」和各种 Apple ID 认证问题之间的界限可能模糊),Mac 邮件无法正常工作的完整故障排除修复指南涵盖了大量在消息传递失败中也会出现的底层 Apple ID 和接续认证模式。
如果你从 26.4 更新到 26.5,并且从未完全确定两个版本之间有什么变化,macOS Tahoe 26.4 / 26.4.1 完整更新指南回顾了先前的发布周期以及进入 26.5 时已经损坏或已修复的内容。
常见问题
问:关闭「限制 IP 地址追踪」会暴露我的 iMessages 吗?
答:不会。iMessage 根本不使用 IP 追踪代理——它有自己的端对端加密和自己的路由基础设施。该设置只影响 Safari 和「邮件」中已知追踪者的蜂窝网络流量。你的 iMessage 内容、联系人列表和消息元数据不受影响。
问:我需要在 Mac、iPad 和 Apple Watch 上也关闭这个设置吗?
答:不需要。「限制 IP 地址追踪」是仅适用于 iPhone 的设置(它专门针对蜂窝接口,通常意义上只有 iPhone 拥有)。故障发生在 iPhone 尝试访问 Apple 中继时的蜂窝层,因此修复只需在 iPhone 上进行。在 iPhone 上关闭后,你的三台副设备(Mac、iPad、Watch)都将能够再次通过接续桥接发送 RCS。
问:我的 iPhone 在 Wi-Fi 上,没有使用蜂窝数据——为什么蜂窝设置重要?
答:无论你是否在使用蜂窝数据进行常规浏览,中继端点都是通过蜂窝接口访问的。iPhone 的蜂窝无线电通过运营商配置的数据通道处理 RCS 握手流量,而不是通过 Wi-Fi,因为 RCS 是一个需要向运营商的 RCS 服务器注册的运营商锚定协议。因此,即使你坐在家里使用 Wi-Fi,中继握手也会通过蜂窝路径进行,而该线路上的 IP 追踪设置也会适用。
问:我关闭了设置,但还是不起作用。现在怎么办?
答:按顺序尝试替代修复方案:(1) 在 iPhone 上退出并重新登录 iMessage,(2) 为 Mac 禁用并重新启用短信转发,(3) 在运营商菜单中切换 RCS 消息开关,(4) 在 iPhone 上重置网络设置,(5) 按顺序重启两台设备。如果这些都不起作用,你可能面对的是一个不同的问题——可能在运营商侧——你最好的办法是直接联系你运营商的 RCS 支持团队。T-Mobile 特别提供了专用的 RCS 支持渠道。
问:这样做安全吗?我的账户是否真的有问题?
答:你的账户、硬件、SIM 卡、Apple ID 或运营商配置完全没有问题。这是 macOS/iOS 26.5 引入的软件回归,最终会通过 Apple 更新修复。关闭「限制 IP 地址追踪」是 Apple 随设备附带的有据可查的用户设置——你不是在越狱任何东西,也没有做任何不受支持的事情。隐私影响是真实的但适度的,如上述权衡部分所述。
问:这会影响我的 Apple Watch 在不依赖 iPhone 时独立发送消息的能力吗?
答:Apple Watch 的 RCS 通过与 Mac RCS 相同的接续桥接——通过 iPhone 中继。因此,一旦你在 iPhone 上应用了修复,你的 Apple Watch 也应该能够再次发送 RCS 消息。如果你的 Watch 是蜂窝型号,而你在远离 iPhone 时从 Watch 发送消息(使用 Watch 自己的蜂窝计划),情况更为复杂,取决于你的运营商是否专门在 Watch 线路上配置了 RCS——大多数运营商没有,所以大多数处于蜂窝模式的 Watch 无论如何都会回退到 SMS。
问:我是否应该等待 Apple 在 26.5.1 中修复这个问题,而不是更改我的设置?
答:如果你从 Mac/iPad/Watch 发送的消息量很少,可以舒适地拿起 iPhone 发送为数不多的 RCS 消息,这是一个合理的选择。等待大概只需几周。如果你每天从 Mac 发送几十条 RCS 消息,不便之处相当显著,那么现在应用修复,并在 26.5.1 发布后恢复设置,是更实际的做法。
结语
macOS 26.5 RCS 回归是那种令人沮丧的 Apple 生态系统 bug:症状戏剧性且可见(每条消息上都有醒目的红色错误),原因则是不可见的、架构性的(与一个不相关的隐私设置之间的中继级认证不匹配),而修复方案则深藏在显示错误的设备之外的另一台设备上的四层菜单深处。这一切都不是你的错,也丝毫不反映你作为用户的技能。即使是 MacRumors 论坛读者——他们往往比普通 Apple 用户具有更强的技术素养——也花了将近两天时间集体逆向工程发生了什么,才让「限制 IP 地址追踪」这个解决方法作为一致的修复方案浮现出来。
如果你应用了修复,RCS 消息又从你的 Mac 正常流转,请给自己一个小小的提醒:在五月底或六月初时查看 Apple 关于 26.5.1 的发行说明,当它发布时,重新启用「限制 IP 地址追踪」。隐私权衡在现在是合理的,但一旦 Apple 发布了正式修复,你不妨恢复该设置。如果 26.5.1 发布后重新开启设置又导致 RCS 中断,这意味着 Apple 的修复没有完全解决中继/代理交互问题,你可以简单地将其关闭,并在下一个小版本上再次尝试。
对于相关的接续故障排除——iPhone 镜像、AirDrop、反映 RCS 失败的邮件认证模式——请参阅我们的 iPhone 镜像修复指南、AirDrop 修复指南、Mac 邮件故障排除指南以及 macOS Tahoe 26.4 / 26.4.1 更新指南。Apple 支持页面 HT127115 记录了 26.5 发行说明(未直接承认此回归),MacRumors 论坛帖子 2482378 仍然是最好的社区驱动追踪帖,如果你想关注其他用户的经历和 Apple 回应的任何最新动态。
你给 Android 朋友发的短信很重要,对话中的绿色气泡不应该成为你的烦恼来源,你也不应该仅仅为了发送一条消息而在面前摆放两台设备。在 iPhone 正确的 SIM 卡上拨动一个开关——你就可以回到你真正想用的键盘上打字了。
