ArcGIS Online 在防火墙允许列表中需要哪些域名？

DNS 应答只告诉你查询那一刻主机名解析到了哪个地址。它不能说明该地址是永久的，也不会列出地图触及的所有内容。当出站流量被限制为某人凭一次查询敲出的短名单时，这一区别最为关键。先梳理工作流，再依据提供商当前的要求推导名单。反复出现的例子是企业 GIS 客户端通过受限的 VPN 出站访问 ArcGIS Online。

列出地图操作触及的每一个组件

把操作拆成几部分：组织的门户与项目访问、底图瓦片、托管的要素或分析服务，以及任何项目下载。每一部分都可能位于不同的端点之后。一张引用外部 ArcGIS Enterprise 服务或 OGC 端点的地图，会引入网络团队从未听说过的依赖。在任何人提交允许列表申请之前，先把这些都写下来。清单里漏掉的组件，之后会以看起来像凭据问题的方式失败。

The Domain and FQDN Requirements document is where those families come from, and two of them carry most of the workflow: *.arcgis.com covers the organization portal, its items and the hosted services behind them, while *.arcgisonline.com serves basemaps and static tiles. Everything else is organization-specific, because an ArcGIS Enterprise service you host, an OGC endpoint or a custom domain in front of the portal has to be added by name. Take those entries from the same revision you read, since the regional storage hosts change between versions.

门户登录成功是弱证据。它只能证明从获批路径可以访问门户端点，对瓦片、分析或下载一无所知。

从当前文档中选择通配符或 FQDN

Esri 发布 Domain and FQDN Requirements，版本很关键，因为区域存储条目会随版本变化。当前文档同时提供域级通配符做法和更严格的主机名级清单。它还点明区域存储主机，并警告外部系统和自定义域会加入组织特有的条目。把你实际阅读的版本连同日期一并抄进变更记录。

更严格的名单耗费维护时间；更宽的放行耗费安全范围。这一取舍属于网络负责人，应当依据文档决定，而不是依据某人在一次工作会话中抓取的一组地址。

把静态底图选项收窄

Esri 的防火墙常见问题指出，加速的底图分发可能返回动态地址。该条目还专门为底图记录了一种静态 IP 方案，它会离开加速路径，并可能降低性能。这两句话都不能把门户、托管数据和存储主机变成单一静态地址。如果必须执行仅允许 IP 地址的策略，应向 Esri 获取受支持的方案，而不是扩大你猜出来的范围。

旧的 DNS 应答不是受支持的方案，而且它会腐烂。

把路由与权限分开

VPN 路由只选择路径；出站规则决定该路径能否到达目的地。这是两种不同的控制，健康的隧道对第二项毫无说明。正因如此，地图可能在某个网络上的某位用户那里失败，却能在同一账号的另一位用户那里正常工作。在责怪服务之前，分别检查规则和路由。

如果清单不完整，两者都正确时工作流仍会失败。

逐个组件验证，然后给名单指定负责人

复现失败的操作，并记录是哪个组件失败：门户、瓦片、要素服务、下载还是外部服务。然后改变一个策略要素并重复。修好瓦片的改动对分析服务毫无说明。正是这份逐组件记录，把下一次区域更新变成依赖变更，而不是又一轮猜测。在把诊断 URL 粘贴到任何地方之前先检查，因为查询字符串可能携带令牌和项目标识符。

给需求名单指定负责人，并设定与文档版本绑定的复核日期。当 Esri 新增存储区域或服务主机时，该负责人会重新运行清单，而不是在事故中才发现缺口。