[Bug] 生图结果下载与 Clash Fake-IP 不兼容，0.15.3 仍报 IMAGE_UNSAFE_URL

[li1679]

What happened? / 问题描述

使用 Clash Verge 的 Fake-IP DNS 模式时，PI-Desktop 生图失败，错误码为 IMAGE_UNSAFE_URL。在 0.15.2 遇到此问题，升级到 0.15.3 后仍然存在。

独立接口测试表明，生图服务能够成功返回图片 URL，该 URL 也能正常下载；客户端的图片下载地址检查会拒绝本机解析出的 Fake-IP。

与 #775 相关，但本 issue 是生图结果下载，不是市场安装。#775 的维护者回复说明市场已有 Fake-IP 处理和 opt-in；生图下载路径似乎尚未覆盖。

Steps to reproduce / 复现步骤

1. 启用 Clash Verge，DNS 使用 enhanced-mode: fake-ip，地址池为 198.18.0.0/15，使本机解析图片域名时得到 Fake-IP。
2. 在 PI-Desktop 配置 OpenAI-compatible Images 服务和生图模型。
3. 发起生图请求，服务以 data[0].url 返回 HTTPS 图片链接。
4. PI-Desktop 显示 IMAGE_UNSAFE_URL，没有展示生成结果。

本次测试的模型是 gpt-image-2.5-sunburst，返回的图片域名是 aipro.hk.cn。不附 API 密钥或带访问 token 的图片链接。

Expected behavior / 预期行为

在明确支持的代理配置下，生图请求和结果下载能够正常完成，同时保留对真实内网、回环和云元数据地址的访问防护。

如果暂时不支持此场景，应解释是图片下载的 Fake-IP 地址检查失败，并提供处理提示，避免用户误以为模型或 API 密钥不可用。

Actual behavior / 实际行为

应用报 IMAGE_UNSAFE_URL。本机 Node DNS 解析 aipro.hk.cn 得到 198.18.0.10，运行源码中的 publicImageAddress() 检查返回 false，命中下载前的拒绝条件。

按照客户端请求格式进行的独立接口测试：

测试	结果
获取模型列表	HTTP 200，包含指定模型
POST /v1/images/generations，{model,prompt,n:1}	约 23 秒，HTTP 200，返回图片 URL
POST /v1/images/edits，单图 multipart 字段 image	约 37 秒，HTTP 200，返回图片 URL
POST /v1/images/edits，两图字段 image[]	约 33 秒，HTTP 200，返回图片 URL
独立下载文生图返回的 URL	HTTP 200，有效 PNG，620857 bytes

两图测试使用同一张图片作为两个附件，仅证明接口接受该字段格式，不代表已验证不同参考图的融合效果。上述是独立 HTTP 测试和源码检查，不是桌面端完整自动化测试。

App version / 应用版本

0.15.2、0.15.3（升级后相同错误仍存在）

Operating system / 操作系统

Windows

Extra environment / 其他环境信息

• 代理客户端：Clash Verge。
• DNS 模式：fake-ip。
• Fake-IP 地址池：198.18.0.0/15。
• 生图协议：OpenAI-compatible Images，结果以 URL 返回。

Logs / 日志

应用错误码：

IMAGE_UNSAFE_URL

本机 DNS 和源码地址校验的独立诊断输出：

{"hostname":"aipro.hk.cn","answers":[{"address":"198.18.0.10","family":4}],"publicAddressCheck":[false],"result":"IMAGE_UNSAFE_URL"}

源码定位

已对比 v0.15.2 和 v0.15.3，以下两个文件在这两个标签间没有差异：

• download.ts:38-50：publicImageAddress() 拒绝 198.18.0.0/15。
• download.ts:82-86：本地 DNS 解析后，只要有非公网地址就抛出 IMAGE_UNSAFE_URL。这是本次直接触发点。
• download.ts:88-97：图片下载独立创建 Undici Agent 并指定 dispatcher。
• network-proxy.ts:107-110：应用全局 fetch 使用 Electron net.fetch。图片下载没有沿用这一代理路径，是另一个相关兼容隐患；本次在下载连接建立前就已被地址校验拒绝。

建议的解决方向

1. 参考 [Bug] Openwrt中使用代理插件的fake-ip模式时，市场相关功能均不可用 #775 已有的市场 Fake-IP 策略，评估生图下载能否复用明确的代理支持和授权机制，并明确现有市场专用开关的适用范围。
2. 统一或协调生图请求与图片下载的代理行为，在实际使用的传输路径中继续保留 SSRF 防护、DNS rebinding 防护、重定向限制、大小限制和超时控制。不要仅删除地址检查，或默认放行整个 benchmark 网段。
3. 为 Fake-IP 拦截提供专门提示和脱敏诊断，包含图片域名、解析地址和处理建议；不要记录图片链接里的访问 token。
4. 对明确支持 response_format=b64_json 的服务，可考虑通过能力配置接收图片数据，避免二次 URL 下载；不应向所有模型无条件添加该参数。
5. 增加 Fake-IP、显式应用代理及 URL 返回路径的回归测试，同时验证真实私网地址仍被拒绝。

临时绕过思路

将 aipro.hk.cn 追加到 Clash 现有 dns.fake-ip-filter 中，使其解析为真实 IP，再重载配置、清理 DNS 缓存并重启应用。

该配置调整后的桌面端结果尚未验证，也不保证能解决图片下载未沿用应用代理的其他问题。

[vastsa]

@hui455 辛苦看一下哦

[hui455]

好的，我看一下问题