Werkzeug 3.1.9 可信列表含 IPv6 地址，仍报 Host is not trusted

Werkzeug 升到 3.1.9 后，通过 http://[::1]:5017/ 访问应用返回 400，可信主机列表明明包含 [::1]。如果错误是 Host '[::1]:5017' is not trusted.，要核对可信项的 IPv6 解析，而不只是检查服务有没有监听 IPv6。

3.1.9 的请求侧会把 [::1]:5017 解析成主机 [::1]；比较可信项时，却仍在第一个冒号处截断 [::1]，得到 [。两边因此不相等，已允许的地址仍被拒绝。带不带端口都可能触发。

方括号不能按普通域名的冒号规则拆

下面是说明条件的配置形态，不是可直接覆盖整个应用的配置：

trusted_hosts = ['[::1]']
request_host = '[::1]:5017'

IPv6 字面量里的冒号属于地址。去掉请求 URL 的方括号、把可信项改成 [，都不正确。Host 校验发生在应用收到请求之后，与 Nginx 连接 [::1] 被拒绝、DNS 指到了错误服务器等问题不同。

不要为了让请求通过而清空可信列表、允许任意 Host，或直接回退到旧版解析行为。旧版的两侧截断方式碰巧相同，不代表它正确校验了 IPv6 主机。

暂时使用已经受控的域名入口

当前正式 3.1.9 仍保留上述可信项拆分方式。应用可以使用受自己控制的域名访问时，将该确切域名加入原有可信列表，客户端也使用这个域名发起请求。端口仍按原服务配置保留，不应借此扩大可信子域范围。

例如测试环境已有 app.example.test 的解析、路由及必要证书，可以把它作为应用的受控入口；该名称只是占位示例，不能直接拿去访问公网。HTTPS 应保持对应域名的 SNI 与证书验证，不要关闭证书校验来配合一次 Host 调整。

已经通过反向代理提供受控域名的应用，核对代理实际传给应用的 Host，并保留现有可信代理数量及转发头约定。不要为了绕过此错误，无条件相信客户端自带的 X-Forwarded-Host；只有受信代理才能提供用于安全判断的转发信息。

如果业务必须直接以 IPv6 字面量作为 Host，域名入口并不满足需求，应保留此限制并等待或评估明确包含解析修正的正式版本。不能把主分支的改变当作当前安装包已经修复，也不应在业务启动时猴子补丁安全校验函数。

修改后用实际受控域名核对正常入口，并确认未列入可信列表的 Host 仍被拒绝。将来恢复 IPv6 字面量访问时，分别检查有端口、无端口、非可信地址和正常域名，不能只测一条成功请求。若需回退，恢复本次新增的精确域名配置；不要为恢复可用性撤掉整项 Host 保护。