📌 问题概述

扩展的自定义 AI 网关在内置浏览器中点击测试时，约 0.3 秒 内立即抛出 Failed to fetch 错误，未显示任何具体的报错原因或状态码。

🛠️ 测试环境

• 运行环境：内置 Chromium / CEF 浏览器

• 扩展版本：v0.11.78

• 接口类型：兼容 OpenAI 标准对话接口的自定义网关（包含模型名称与 Bearer 鉴权）

• 脱敏说明：已确认未在正文或截图中泄露任何 API Key

🔄 复现步骤

1. 打开扩展的 AI 服务设置 页面。

2. 填入自定义网关地址、模型名称及相应的密钥（API Key）。

3. 点击 测试 按钮。

4. 页面几乎瞬间（~0.3s）返回 Failed to fetch。

⚖️ 对照测试（关键现象）

相同网关、模型及鉴权配置下：

• ❌ 扩展内置浏览器：请求立即失败。

• ✅ 桌面端 AI 客户端：可以正常请求并正确返回结果。

结论：网关本身可用，问题更倾向于浏览器权限限制或跨域（CORS）处理机制。

🔍 初步原因分析

1. 扩展权限限制（Host Permissions）：扩展可能仅声明了少数固定的 API 主机白名单，自定义域名未获得请求权限。

2. CORS 预检拦截：浏览器发送预检请求（Preflight）时，若网关未完整返回允许的 Method / Headers / Origin，请求会被底层直接拦截。

3. 错误捕获粒度过粗：当前捕获逻辑过于单一，将权限拒、CORS、TLS 证书错误、网络断开等统一吐出为 Failed to fetch，排查成本极高。

💥 影响范围

所有使用 自建反向代理、局域网模型服务（如 Ollama/LocalAI） 及 第三方聚合网关 的用户均受影响。依赖固定白名单严重限制了扩展的可移植性，且模糊的报错极易引导用户误以为是“模型或密钥错误”。

💡 改进建议

1. 权限与域名处理

• 对自定义网关提供可选的域名授权流程，或在用户保存配置时动态申请必要权限（chrome.permissions.request）。

2. 细化错误诊断与提示

• 分级排查：测试前先校验权限；将 权限缺失、跨域预检失败、TLS 证书报错、网络断连 与 服务端 HTTP 错误 进行清晰区分。

• 状态码与 Body 保留：对非 2xx 响应，保留 HTTP 状态码及有限的 Response Body 内容，方便定位网关问题。

• 响应流与超时处理：兼容常见的流式响应（SSE），并在请求超时或 Response Body 为空时给出明确提示。

3. 安全防护

• 严格保证 API Key 仅用于 Request Header，切勿在 Log、错误提示或 UI 页面中明文回显。

🧪 本地验证结果

在本地手动扩大扩展的自定义 API 主机权限（Host Permissions）后，原先的 Failed to fetch 报错不再出现，证实权限范围限制是主要诱因之一。

期望：希望后续版本能将自定义网关作为正式场景支持~