今天登录飞塔防火墙遇到一个比较奇怪的 FortiGate 故障：管理界面突然提示：
无法连接到 FortiGuard 服务器
刚开始我以为是普通的网络或者 DNS 问题，因此按照常规思路进行了排查。
甚至连续重启了 3 次设备，但问题依然存在。
之后又检查了 Internet 连通性、Ping 公网 IP、Ping FortiGuard 服务器，并且更换了 DNS，但还是没有解决。
最后在继续排查的过程中，我查到了 Fortinet 官方社区发布的 Technical Tip，才发现这是 2026 年 9 月 FortiGuard Anycast 的 CRL Scope 问题。
最终通过 Fortinet 官方给出的方式重新初始化 FortiGuard Anycast，问题恢复。
本文记录整个排查和解决过程，希望能够帮助遇到相同问题的 FortiGate 用户。
1. 故障现象
FortiGate 管理界面出现：
Unable to connect to FortiGuard servers
中文界面则类似：
无法连接到 FortiGuard 服务器
同时 FortiGuard 相关服务出现异常，安全数据库也无法正常更新。
这类问题第一反应通常是：
- Internet 是否断了？
- DNS 是否异常？
- 默认路由是否有问题？
- FortiGuard 服务器是不是故障了？
- 上游防火墙是不是拦截了 FortiGuard？
- FortiGate 是否需要重启？
因此我也是按照这个思路开始排查。
2. 第一步：重启设备
最简单的方法当然是重启。
但是这次比较尴尬的是：
重启一次没有解决。
于是又重启了一次。
还是没有解决。
最后甚至连续重启了 3 次，问题依然存在。
这时候基本可以确定：
这不像是简单的 FortiGate 临时状态异常。
如果只是某个进程或者临时连接状态卡住，正常情况下重启应该有一定概率恢复。
但连续重启仍然无法解决，说明需要进一步从网络和 FortiGuard 服务本身进行排查。
3. 检查 Internet 是否正常
首先通过 FortiGate CLI 测试公网 IP：
execute ping 8.8.8.8
可以正常收到响应。
例如：
4 packets transmitted, 4 packets received, 0% packet loss
这说明：
- WAN 正常
- 默认路由正常
- FortiGate 可以访问 Internet
因此可以基本排除：
FortiGate 完全无法访问 Internet。
4. 检查 FortiGuard 服务器
接下来测试 FortiGuard 相关域名：
execute ping service.fortiguard.net
然后：
execute ping update.fortiguard.net
以及：
execute ping guard.fortinet.net
这些域名都可以正常解析，并且可以收到服务器返回的数据。
例如：
PING update.fortiguard.net
可以正常解析到 Fortinet 的服务器地址，并收到 ICMP 响应。
这时候就出现了一个非常奇怪的现象：
Internet pass
DNS pass
FortiGuard 域名解析 pass
Ping FortiGuard pass
FortiGuard 服务 error
也就是说，FortiGate 明明可以访问 Fortinet 的服务器，但是 FortiGuard 依然提示无法连接。
5. 更换 DNS
既然 FortiGuard 出现问题，第二个怀疑对象就是 DNS。
于是又更换了 DNS 服务器进行测试。
例如：
1.1.1.1
8.8.8.8
更换 DNS 后重新测试：
execute ping update.fortiguard.net
域名依然能够正常解析。
但是：
FortiGuard 仍然无法正常连接。
所以到这里，基本可以排除普通 DNS 故障。
6. 手动执行 FortiGuard 更新
接下来通过 CLI 强制执行一次 FortiGuard 更新：
execute update-now
这个命令用于立即触发 FortiGuard 数据库更新。
需要注意：
execute update-now是更新 FortiGuard 安全数据库，并不是升级 FortiOS 固件。
执行之后没有看到特别明显的错误信息。
但是检查数据库版本后发现，FortiGuard 数据库依然没有正常更新。
这时候就越来越不像普通的网络故障了。
7. 最终发现：CRL Scope 错误
如果基础网络正常，但 FortiGuard 仍然无法连接，可以进一步打开更新服务 Debug：
diagnose debug application update -1
diagnose debug application forticldd -1
diagnose debug enable
[...]
[365] __ssl_crl_verify_cb: Cert error 44, different CRL scope. Depth 2
[1436] SSL_dump_handshake_err: Certificate failed verification. Error: 44 (different CRL scope), depth: 2, subject: /C=US/O=DigiCert Inc/OU=http://www.digicert.com/CN=DigiCert High Assurance EV Root CA.
[...]
Debug 中出现：
Cert error 44, different CRL scope
Certificate failed verification.
Error: 44 (different CRL scope)
继续排查之后，我也发现了 Fortinet 官方社区发布的相关 Technical Tip。
官方确认，2026 年 9 月出现了一起 FortiGate 无法访问部分 FortiGuard 服务的问题。
Fortinet 官方说明，这个问题影响使用特定 DigiCert 证书链的 FortiGuard Anycast 服务。
这也解释了为什么：
Ping FortiGuard pass
DNS pass
Internet pass
FortiGuard TLS error
问题并不是网络层无法到达服务器，而是TLS 连接建立过程中，证书撤销检查出现了问题。
8. CRL 是什么？
CRL 的全称是：
Certificate Revocation List
中文一般叫：
证书吊销列表
它用于检查一个数字证书是否已经被证书颁发机构吊销。
FortiGate 在与 FortiGuard 建立 TLS 连接的时候，会对服务器证书链进行验证，其中就涉及证书撤销检查。
而这次问题与 DigiCert 对相关 CRL 文件进行调整有关。
Fortinet 官方说明，2026 年 9 月 9 日，DigiCert 更新了相关 CRL 的内容，并增加了：
Issuing Distribution Point
也就是：
IDP
扩展。
FortiGate 在执行证书撤销检查时触发了 CRL Scope 校验问题，最终出现：
Error 44: different CRL scope
导致 TLS 握手失败。
需要特别注意：
这并不意味着相关 DigiCert 证书真的被吊销。
Fortinet 官方明确说明，这次问题不是证书被吊销，而是 CRL / IDP 的变化触发了 FortiGate 当前证书撤销检查机制中的问题。
9. 为什么重启和换 DNS 都没用？
现在回头看整个故障过程，就比较容易理解了。
我的排查过程实际上是：
FortiGate
│
├── Internet ───────────── pass
│
├── DNS ─────────────── pass
│
├── Ping FortiGuard ──────── pass
│
├── FortiGuard TCP/TLS ───── error
│
└── Certificate / CRL
│
└── Error 44
different CRL scope
所以：
重启设备
只能解决设备自身进程、连接状态等临时问题。
但是无法解决远端证书链和本地 CRL 验证逻辑之间的问题。
更换 DNS
只能解决域名解析问题。
但 DNS 本身就是正常的，所以换 DNS 自然也不会解决 TLS 证书验证失败。
Ping FortiGuard
只能证明 ICMP 网络可达。
Ping 通并不代表 HTTPS/TLS 一定能够正常建立。
这也是这次故障最容易误判的地方。
10. Fortinet 官方解决方法
幸运的是，在排查过程中发现了 Fortinet 官方社区的 Technical Tip。
Fortinet 后续更新说明，DigiCert 已经撤回了相关 CRL 的 IDP 修改，因此 Anycast FortiGuard 服务本身的问题已经得到缓解。
对于仍然受到影响的设备，Fortinet 建议清理 FortiGate 上的相关 CRL Cache。
官方给出的操作非常简单。
首先关闭 FortiGuard Anycast：
config system fortiguard
set fortiguard-anycast disable
end
然后重新开启：
config system fortiguard
set fortiguard-anycast enable
end
最后执行一次：
execute update-now
执行之后，FortiGuard 恢复正常。
也就是说，最终并没有修改：
- DNS
- WAN
- 默认路由
- 防火墙策略
- Internet 出口
而是通过重新初始化 FortiGuard Anycast，让设备清理相关 CRL Cache，恢复了 FortiGuard 的连接。
11. 如果仍然无法解决
Fortinet 官方还提供了一个更直接的临时 workaround：
关闭 Anycast，改用 Unicast FortiGuard。
config system fortiguard
set fortiguard-anycast disable
set protocol udp
set port 8888
set sdns-server-ip 208.91.112.220 173.243.140.53 210.7.96.53 200.91.112.220
end
execute update-now
Fortinet 说明，这种方式通过切换到 Unicast FortiGuard 来绕开受影响的 Anycast 服务。
同时，这些设置不会影响 FortiGate 正常的生产转发流量。
不过现在 DigiCert 已经撤回相关 CRL 的 IDP 修改，因此如果重新启用 Anycast 后已经恢复正常，通常没有必要长期关闭 Anycast。
12. 这次故障给我的一个经验
这次问题其实挺有意思。
一开始我认为是：
“FortiGuard 连不上，是不是我的网络有问题？”
于是：
- 重启设备；
- 再次重启；
- 第三次重启；
- 检查 Internet；
- Ping
8.8.8.8； - Ping FortiGuard；
- 检查 DNS；
- 更换 DNS；
- CLI 手动执行更新。
结果全部没有解决。
还好最后继续查了 Fortinet 官方社区。
才发现原来 2026 年 9 月 Fortinet 官方已经针对这个问题发布了 Technical Tip。
这也让我意识到：
遇到 FortiGuard 这类云服务异常时，不要只盯着本地网络排查，也要及时检查 Fortinet 官方社区和官方服务状态。
尤其是当：
Internet 正常
DNS 正常
Ping FortiGuard 正常
但 FortiGuard 仍然不可用的时候，就应该开始考虑：
- TLS
- 证书
- CRL
- FortiGuard Anycast
- FortiGuard 服务端变化
而不是一直重复修改 DNS 或重启设备。 真正的问题是 2026 年 9 月 FortiGuard Anycast 与 DigiCert CRL / IDP 变化引发的 CRL Scope 验证问题。 这次排障也再次说明：
网络能通 ≠ 应用层服务一定正常。
尤其是涉及 HTTPS、TLS、证书链和 CRL 的服务，仅仅 Ping 通服务器远远不够。