Microsoft 正在更改 Teams 网页客户端的访问地址。2026 年 9 月期间，打开 teams.microsoft.com 的用户可能会被重定向到 teams.cloud.microsoft。Microsoft 将其描述为域名变更，而不是功能迁移：现有链接和书签预计仍可继续使用，终端用户也不需要安装新的客户端。

展示浏览器重定向经过企业防火墙、DNS、代理和嵌入式应用检查的编辑插图。

这件事听起来很普通，直到请求经过企业代理、安全 Web 网关、DNS 策略、浏览器允许列表、内容安全策略、应用清单或远程访问控制。在这些环境里，重定向并不天然安全无害。浏览器必须能够解析并访问目标地址，安全系统必须放行新的主机名，嵌入式 Teams 应用还必须识别新的来源。

眼下最直接的建议是：把 teams.cloud.microsoft 当作生产终端节点，检查组织使用的 Microsoft 365 终端节点数据，并在用户通过登录失败或空白标签页发现变化之前，测试完整的网页体验。这个案例的意义并不限于 Teams。即便供应商表示产品功能没有变化，SaaS URL 变更也应纳入终端管理和变更控制。

Microsoft 具体改变了什么

Microsoft 365 消息中心通知 MC1465764 表示，到 2026 年 9 月，Teams 网页用户将从 teams.microsoft.com 被重定向到 teams.cloud.microsoft。该通知将这项变化标记为会对管理员产生影响的重大变更。目标地址属于更广泛的 cloud.microsoft 域名家族；Microsoft 引入这一域名家族，是为了承载经过身份验证、面向用户的 Microsoft 365 体验。

这次迁移并没有被描述为新的 Teams 客户端，也不是新的账户系统。使用浏览器的人理论上仍会访问同一项服务，看到同样的对话、会议、文件和组织上下文。用户能直接看到的差异是浏览器地址发生变化；与此同时，地址变化带来的网络行为和 Web 应用行为也会随之变化。

Microsoft 表示旧 URL 会执行重定向，现有链接也会继续工作。这会降低普通用户受到的干扰，但并不能取消管理员测试的必要性。书签可以跟随 HTTP 重定向，而配置严格的代理可能分别评估第一个和第二个主机名。浏览器可能能够加载页面，但嵌入式标签页却因为尚未更新 frame-ancestors 策略而失败。防火墙可能允许 teams.microsoft.com，却拒绝 *.cloud.microsoft。

消息中心通知还表示，管理员可以使用一个临时控制项来禁用重定向，但该控制项会在 2026 年 12 月 31 日结束。因此，它是迁移期间的辅助措施，不是可以长期依赖的运行模式。使用该控制项的组织应记录例外，指定负责人，并安排移除时间。

Microsoft 的公开终端节点文档已经同时列出 Teams 使用的 *.teams.microsoft.com 和 *.teams.cloud.microsoft，以及 teams.microsoft.com 和 teams.cloud.microsoft。同一份文档还把 *.cloud.microsoft 列为经过身份验证的 Microsoft 365 体验所需的统一域终端节点。实际含义很关键：组织应更新自己的权威终端节点管理流程，而不是只在某一条防火墙规则里增加一个主机名。

为什么一次重定向可能变成服务中断

一次重定向会穿过多个控制点。每个控制点都可能制造不同的症状，而用户看到的结果可能只是“Teams 挂了”，即使 Microsoft 的服务本身完全正常。

防火墙和安全 Web 网关

传统的允许列表通常记录具体主机名。如果策略允许 teams.microsoft.com，却不允许 teams.cloud.microsoft，第一次请求可能成功，重定向后的请求却会被拦截。根据网关的行为，用户可能看到访问被拒绝页面、请求超时、身份验证循环，或者只加载出不完整的应用外壳。

有些组织使用基于类别的过滤、TLS 检查或显式代理路由。这些控制可能依赖证书名称、URL 类别，或者围绕旧域名编写的规则。新主机应当按照原本想实现的策略接受评估。未经审查就加入宽泛通配符，可能造成不必要的暴露；在不了解 Microsoft 终端节点指导的情况下拒绝通配符，则可能带来脆弱、难维护的运行方式。正确选择取决于组织的控制模型，但无论选择哪种方式，都应经过有意识的决策并留下记录。

DNS 与分流网络行为

新主机名还会进入 DNS 工作流。内部解析器、过滤服务、安全 DNS 产品和远程访问客户端，可能会对一个刚出现的域名应用不同策略。应分别从办公网络、连接 VPN 的设备、居家办公场景以及任何受管虚拟桌面环境进行测试。管理员笔记本上的成功结果，并不能证明所有出网路径都会以相同方式工作。

不要为了这次变更而硬编码 IP 地址。Microsoft 的终端节点指导是按服务域名和已发布的地址数据表达的，云服务底层基础设施可能发生变化。基于 IP 的临时绕过方案可能在正常服务变更期间失效，也可能绕过以主机名为基础的控制意图。

Teams 网页访问不仅依赖网络可达性，也依赖浏览器行为。Microsoft 关于 Teams 的故障排查指导指出，当浏览器控制限制 Cookie 或受信任站点时，可能需要信任包含 *.cloud.microsoft 在内的域名。禁止第三方 Cookie、强制部署浏览器站点列表或通过组策略管理浏览器的组织，应在重定向之后测试登录、发起会议和页面导航。

域名例外应限定在所需的 Microsoft 服务范围内，并按照其他身份验证相关例外的相同审查流程进行管理。不要为了让一次测试通过，就全局关闭浏览器隐私控制。应先确定问题究竟来自 Cookie 范围、受信任站点策略、TLS 检查、代理规则，还是某个被拦截的终端节点。

嵌入式 Teams 应用和标签页

Teams 同时也是应用的承载平台。自定义标签页、业务线工具或合作伙伴应用，可能会被加载在 Teams 网页客户端内部，而不是作为顶层页面打开。在这种情况下，新主机会改变浏览器来源，并暴露旧地址下不明显的假设。

Microsoft 的 Teams 开发者指导表示，应用负责人应将 Teams JavaScript 库更新到 2.19.0 或更高版本，并针对新主机初始化应用。指导还说明，使用内容安全策略响应头的应用，在迁移期间应把 *.cloud.microsoft 加入 frame-ancestors 指令，同时保留现有值，以维持向后兼容。

这并不是任意修改所有安全响应头的理由，而是一次核对机会：应根据实际支持的主机列表检查响应头，在 Teams 网页客户端中测试应用，并确认来源校验、validDomains 条目、Cookie 设置以及 postMessage 处理逻辑仍然符合预期的应用流程。

一种常见的故障模式是部分成功：Teams 外壳能够加载，但标签页出现空白框；标签页能够打开，但文件选择失败；或者身份验证返回应用后没有可用会话。在修改应用代码之前，先记录浏览器中显示的主机，以及网络追踪中出现的主机。

哪些团队会受到影响

最直接受到影响的是在浏览器中使用 Teams、并通过防火墙、代理、安全 Web 网关、DNS 过滤器或受管浏览器策略控制出站访问的组织。只使用桌面端或移动端客户端的人，对这次变更的感知可能较弱，但链接、身份验证交接以及嵌入式体验仍可能涉及浏览器组件。

Teams 应用负责人是第二类群体。这包括内部开发人员、软件供应商、内联网团队，以及维护标签页、消息扩展、嵌入 Teams 的网站或会校验 Teams 来源的集成负责人。他们面对的风险不止是最初的重定向。新主机可能影响框架策略、来源检查、重定向 URI 假设、Cookie 属性、遥测过滤器和支持文档。

网络团队和身份团队也应当参与。它们往往分别负责访问路径的不同部分：网络团队管理出站流量，终端团队管理浏览器策略，身份团队管理登录控制，应用团队管理嵌入内容。一个同时跨越四个负责人的变更，如果没人把它视为一次完整的服务变更，就可能在队列之间被遗漏。

小型组织也不能自动认为自己不受影响。小公司可能没有复杂代理，但仍可能依赖受管防火墙、外包 IT 服务商，或继承自母组织的浏览器策略。环境越简单，越应尽快测试，而不是假设简单就一定兼容。

需要关注的终端节点细节

Microsoft 的 Microsoft 365 URL 和 IP 地址文档表示，所需终端节点应当可达，并将 *.cloud.microsoft 标识为通过 TCP 443 和 UDP 443 访问的统一域目标。在 Teams 部分，文档列出 *.teams.cloud.microsoft、*.teams.microsoft.com、teams.cloud.microsoft 和 teams.microsoft.com，涉及 TCP 443、TCP 80 以及 UDP 443。

这些条目比从论坛帖子复制一份列表更有用，因为 Microsoft 会随着服务变化更新终端节点数据。文档说明，终端节点数据通常会提前发布，但为了处理支持升级、安全事件或其他需要立即响应的运营情况，也可能在月度周期内更新。这充分说明，在安全工具支持的情况下，组织应考虑自动化接收自己的终端节点数据。

这也提醒我们，终端节点类别本身很重要。Microsoft 区分必需、可选和默认目标，并解释某项功能可能依赖不同工作负载组中的终端节点。团队如果只在静态列表中搜索“Teams”，可能漏掉完整体验所需的通用身份验证或内容终端节点。

稳妥的运行顺序是：先把当前 Microsoft 终端节点数据与组织实际使用的各层控制进行比对，再进行测试。不要假设边界防火墙上的一份允许列表就代表全部策略。云访问安全代理、终端代理、浏览器配置、私有 DNS 区域或 VPN 分流规则，仍然可能阻止新主机。

一套可执行的验证计划

1. 找出真实用户和真实路径

从清点开始，而不是直接改规则。确认哪些用户群会在浏览器中打开 Teams，哪些群体使用虚拟桌面，哪些用户通过 VPN 连接，以及承包商或受管服务提供商是否使用单独的出网路径。如果共享工作站、类似信息亭的设备或会议室系统会打开基于浏览器的 Teams 链接，也应纳入范围。

为每条路径记录所应用的控制：DNS 过滤、代理、TLS 检查、防火墙、安全 Web 网关、浏览器策略、终端安全和身份条件访问策略。这样的路径图能帮助团队在后续更快区分服务问题与本地策略问题。

2. 检查组织使用的终端节点来源

使用 Microsoft 当前的 Microsoft 365 终端节点文档；如果条件允许，应使用其可下载数据或 Web 服务数据，而不是依赖本地维护的电子表格。确认必需的统一域条目和 Teams 条目，已经出现在真正执行访问控制的系统中。

如果组织有意只允许特定 FQDN，应与安全负责人共同决定：针对目前的 Teams 网页重定向，teams.cloud.microsoft 是否已经足够，还是组织更广泛的 Microsoft 365 使用场景需要文档中列出的通配符。通配符可以简化维护，单独列出主机名则能缩小范围，但会要求更频繁地维护。

3. 测试重定向本身

从每一条有代表性的网络路径打开旧 Teams URL，观察完整链路。确认请求确实到达 teams.cloud.microsoft，证书能够被接受，身份验证可以完成，应用也能加载结束。普通用户账户和管理员账户都要测试；特权账户可能采用不同策略，也可能拥有不同的缓存状态。

使用浏览器开发者工具或网关日志记录被阻止的请求、状态码和策略决定。目标不是收集一份庞大的数据包，而是回答四个具体问题：DNS 是否解析成功，连接是否通过，重定向是否完成，以及应用是否加载了全部所需资源。

只有记录第一次结果之后，才清除缓存的站点数据。清除缓存可能掩盖可重复的迁移问题，也可能制造普通用户不会遇到的假故障。至少进行一次干净配置文件测试，再进行一次受管生产配置文件测试。

4. 测试用户操作，而不只是落地页

看到绿色的登录页面还不够。应验证组织真正依赖的操作：打开聊天、加入会议、在启用时发起通话、打开共享文件、在适用时切换租户、加载自定义标签页，以及使用获准的 Teams 集成。直接使用浏览器书签和从邮件或日历邀请收到的链接，都要测试。

会议应从日历链接开始测试，因为浏览器可能还要经过额外的重定向和身份验证步骤。若文件工作流很重要，就打开并编辑一份有代表性的文档。对于自定义应用，要逐一测试关键业务标签页及其登录返回路径。

5. 检查嵌入式应用策略

应用负责人应在源代码和配置中搜索对 teams.microsoft.com 的硬编码引用、明确的来源比较、CSP frame-ancestors 值、受信任域列表、重定向 URI、Cookie 域假设和遥测过滤器。搜索范围应包括部署配置和文档，而不只是应用代码。

按照 Microsoft 的 Teams 应用指导检查 TeamsJS 版本和初始化行为。若需要向后兼容，保留旧主机值，并根据应用安全模型加入新主机。如果用户仍可能从旧 URL 进入，或其他 Microsoft 365 主机仍受支持，就不要盲目替换旧值。

修改响应头或清单之后，应在每一种受支持的主机上下文中测试。能在浏览器顶层标签页中工作的 CSP，仍可能拒绝嵌入框架。反过来，一个过于宽松的测试响应头，也可能掩盖生产响应实际由不同的反向代理或 CDN 生成这一事实。

6. 更新运行材料

搜索帮助台文章、入职指南、防火墙申请表、代理策略、浏览器策略、监控检查和事故运行手册，找出旧 Teams 主机名。历史记录中可以保留旧 URL，但应把它描述为重定向来源，而不是唯一的服务地址。

监控也要同步更新。如果合成检查写死了旧地址，即使服务正常，也可能因为最终主机名变化而开始报错。能够跟随重定向并验证最终页面的检查，更接近真实体验；同时，它还应在重定向链异常变化时发出告警。

不要采取的做法

不要把绕过代理、关闭浏览器保护或使用非受管设备作为标准解决方案。这些操作可能掩盖策略问题，并制造另一个安全问题。

不要仅仅因为应用团队尚未测试标签页，就永久关闭重定向。管理员临时控制项有明确的到期日，拖延工作会把受控变更变成临近截止日期的事故。只有在保护服务连续性确有必要、且已经安排具体修复时，才使用该控制项。

不要用固定 IP 地址替代主机名规则。Microsoft 的云基础设施会持续演进，IP 临时方案可能过时，或者把流量导向错误位置。

不要未经审查就允许所有 *.microsoft 目标。相关 Microsoft 文档确定了具体的域名家族和终端节点类别；超出业务需求扩大访问范围，会削弱控制本身的价值。

不要把第一个页面返回 HTTP 200 当成 Teams 正常工作的证明。故障可能发生在身份验证之后、API 调用期间、标签页加载时，或者打开文件时。

如何处理临时例外

Microsoft 的通知表示，用于禁用 Teams 重定向的管理员控制项会在 2026 年 12 月 31 日结束。如果组织使用它，例外应有清晰理由和明确负责人。一份有用的记录至少应包括受影响的租户或用户组、被阻止的依赖项、负责的应用或网络团队、目标测试日期，以及例外将被移除的日期。

例外不应变成终端节点维护的替代品。如果问题是代理规则，就修复代理规则；如果问题是自定义标签页的 CSP，就修复应用响应；如果问题来自第三方集成，就向其负责人询问受支持的迁移路径，并记录答复。

如果关键业务应用无法及时完成验证，应把风险分开处理。在现有控制能力允许的范围内尽量缩小例外，监控受影响的工作流，并把结束日期告知服务负责人。目标是在保持业务连续性的同时，让迁移风险持续可见。

为什么这属于基础设施变更

SaaS 供应商可以在不改变用户可见功能的情况下更换主机名。但对客户而言，主机名是由网络、浏览器和应用共同执行的服务契约的一部分。地址决定哪条策略匹配、检查哪个证书、发送哪些 Cookie、信任哪个来源，以及日志如何识别流量。

因此，域名迁移应当采用与其他生产变更相同的轻量化纪律：明确负责人，准备测试矩阵，安排回滚或缓解方案，更新监控，并建立沟通路径。这不需要一个庞大的项目，但必须有人验证用户和应用实际经过的完整链路，不能假设重定向在所有地方都透明可用。

这次变更也体现了云运营方式的变化。服务终端节点不再是部署时维护一次、以后不动的静态附录。Microsoft 表示，随着服务演进，终端节点数据会发生变化；在运营情况需要时，也可能在正常节奏之外更新。自动消费终端节点数据的组织可以减少人工延迟，但自动化仍需审查：数据源可以更新防火墙，而应用的 CSP 和运行手册仍然保持原样。

9 月份的简明检查清单

  • 确认组织是否使用基于浏览器的 Teams。
  • 在 Microsoft 365 管理中心查看 MC1465764，并确认租户的推出状态。
  • 确认 teams.cloud.microsoft 及相关 *.cloud.microsoft 终端节点已按照记录在案的网络策略获准访问。
  • 从办公网络、VPN、远程办公、虚拟桌面和受管浏览器路径进行测试。
  • 跟随重定向，验证登录、会议、文件和关键 Teams 标签页。
  • 检查 DNS 过滤、代理规则、TLS 检查，以及浏览器信任或 Cookie 策略。
  • 请应用负责人检查 TeamsJS、CSP frame-ancestors、来源校验、清单和重定向 URI。
  • 更新合成监控、文档和帮助台指引。
  • 在 2026 年 12 月 31 日之前，为任何临时重定向例外记录负责人和移除日期。

Microsoft 的 Teams 网页迁移，对不受管理的浏览器来说可能几乎没有感觉；对受管企业环境来说，却可能牵动多个控制层。正确的响应不是紧急地扩大防火墙范围，而是基于证据，沿着用户和应用真实采用的路径，对新终端节点进行一次短而完整的验证。完成这些工作后，重定向就应当成为 Microsoft 所说的那种变化：地址变了，可用性没有变。

来源

本文事实依据包括 Microsoft 365 消息中心归档中的 MC1465764《Teams 网页客户端用户将被重定向到 teams.cloud.microsoft》；Microsoft Learn 的《Microsoft 365 URL 和 IP 地址范围》；Microsoft Learn 的《构建标签页的要求》；Microsoft Learn 的《Teams 无法加载》故障排查指导；以及 Microsoft Community Hub 的《Introducing cloud.microsoft：Microsoft 365 应用和服务的统一域名》。相关行业讨论参考 Neowin 关于 Teams 网页域名变更及 IT 管理员验证工作的报道。