'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
> sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
> sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
> sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
> sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
> sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
> sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
>
> ```
任何想法、建议等都非常欢迎。
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2025年二月21日 15:43 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/4 "2025-02-21T15:43:54Z")
> [@oznyet](#):
>
> 所有 OpenAI 模型在使用 LLM 调用时，错误消息为“Connection Reset by Peer”的错误率约为 70-80%。有些聊天可以进行，有些则在中途失败。Embedding 调用因 `Faraday::ConnectionFailed` SSL 错误而失败。
我们在上个月在这个网站上对 OpenAI API 发送了超过 2000 次请求，我们的日志中没有此类错误。
我查看了我们托管的另一个大量使用 OpenAI 的网站，上个月有 80,000 次请求，他们没有 Faraday 错误，在此期间只有两个“Connection Reset by Peer”错误。
您是否可能在服务器的网络方面存在问题？我曾经因为有故障的 NIC 驱动程序而遇到过 `Errno::ECONNRESET (Connection reset by peer)`。
> [@oznyet](#):
>
> no1-mini 和 o1-preview 由于代码错误（“developer”不是有效角色）而无法测试/保存 LLM，因为 developer 角色仅对 `o1` 和 `o3` 模型有效，而不是它们的 `-mini` 版本。源代码 [github.com/discourse/discourse-ai/…/chat\_gpt.rb:61](https://github.com/discourse/discourse-ai/blob/f9220124991357d5f3044c6cce4a9f62a4a5763a/lib/completions/dialects/chat_gpt.rb#L61) 需要更新，以进行精确的模型名称匹配，而不是 `starts_with` 匹配。对于第 73 行的 `else` 情况，不再有 `system` 用户，需要更新为简单的 `user`。截至今天，`o1-mini` 无法使用工具。
我会看看这个问题。
---
### Author:  [@oznyet](https://meta.discourse.org/u/oznyet)
#### Post date: [2025年二月23日 23:33 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/5 "2025-02-23T23:33:13Z")
正如您所写，我最初认为这是一个网络堆栈问题，但从同一个容器中重复调用 OpenAI API 却可以正常工作。
这也是在 2 月 21 日的最新提交中完成的。
为了证明这一点（不惜消耗 token），我编写了一个快速脚本来检查 OpenAI 网络堆栈。
- 运行 600 秒（10 分钟）
- 每秒进行一次聊天补全调用
- 更改提示以避免缓存
在容器中执行 `./launcher enter app`，保存以下脚本，使用 `chmod +x test_openai.sh` 使其可执行，然后使用 `OPENAI_API_KEY=.... ./test_openai.sh` 调用它。
> **test\_openai.sh**
>
> ```bash
> #!/bin/bash
>
> # 运行持续时间
> DURATION_SECS=600
>
> # 初始化计数器
> successful=0
> unsuccessful=0
> declare -A error_messages
>
> # 计算百分比的函数
> calc_percentage() {
> local total=$(($1 + $2))
> if [$total -eq 0]; then
> echo "0.00"
> else
> echo "scale=2; ($2 * 100) / $total" | bc
> fi
> }
>
> # 打印统计信息的函数
> print_stats() {
> local percent=$(calc_percentage $successful $unsuccessful)
> echo "-------------------"
> echo "成功调用次数: $successful"
> echo "失败调用次数: $unsuccessful"
> echo "失败率: ${percent}%"
> echo "错误消息:"
> for error in "${!error_messages[@]}"; do
> echo " - $error (${error_messages[$error]} 次)"
> done
> }
>
> end_time=$((SECONDS + DURATION_SECS))
>
> counter=1
> while [$SECONDS -lt $end_time]; do
> # 带超时进行 API 调用
> response=$(curl -s -w "\n%{http_code}" \
> -X POST \
> -H "Content-Type: application/json" \
> -H "Authorization: Bearer $OPENAI_API_KEY" \
> -d "{
> \"model\": \"gpt-4o-mini\",
> \"messages\": [{\"role\": \"user\", \"content\": \"Use this number to choose a one word response: $counter\"}]
> }" \
> --connect-timeout 5 \
> --max-time 10 \
> https://api.openai.com/v1/chat/completions 2>&1)
>
> # 获取最后一行（状态码）和响应体
> http_code=$(echo "$response" | tail -n1)
> body=$(echo "$response" | sed '$d')
>
> # 检查调用是否成功
> if ["$http_code" = "200"]; then
> ((successful++))
> else
> ((unsuccessful++))
> # 提取错误消息
> error_msg=$(echo "$body" | grep -o '"message":"[^"]*"' | cut -d'"' -f4)
> if [-z "$error_msg"]; then
> error_msg="Connection error: $body"
> fi
> # 增加错误消息计数器
> ((error_messages["$error_msg"]++))
> fi
>
> # 打印当前统计信息
> print_stats
>
> ((counter++))
>
> # 等待 1 秒后进行下一次调用
> sleep 1
> done
>
> ```
对于测试脚本，我的失败率低于 0.5%，在这个规模下是可以接受的。
这表明问题出在 Discourse 软件本身，而不是为其供电的容器或网络堆栈。
如果最近的提交没有修复它，我将进一步研究。
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2025年二月24日 05:40 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/6 "2025-02-24T05:40:05Z")
我在这里修复了 o1-mini 和 o1-preview 的回归问题：
>
>
> 1. Legacy reasoning models (o1-preview / o1-mini) do not support developer or sy…stem messages, do not use them.
> 2. LLM editor form not showing all provider params due to missing remap
不过我对 SSL 问题感到困惑，我们并没有更改底层库。
也许这与流式传输有关，尝试禁用你的 OpenAI LLM 上的流式传输，看看问题是否会自行解决？你那里的测试使用的是 gpt-4o-mini，但没有使用流式传输。
---
### Author:  [@oznyet](https://meta.discourse.org/u/oznyet)
#### Post date: [2025年二月25日 10:05 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/7 "2025-02-25T10:05:23Z")
> [@sam](#):
>
> 我在这里修复了 o1-mini 和 o1-preview 的回归问题：
>
> [FIX: legacy reasoning models not working, missing provider params by SamSaffron · Pull Request #1149 · discourse/discourse-ai · GitHub](https://github.com/discourse/discourse-ai/pull/1149)
太棒了！干得好！
在诊断过程中，我发现了另一个错误——在 LLM 配置页面（`/admin/plugins/discourse-ai/ai-llms/%/edit`），选择“禁用原生工具支持（使用基于 XML 的工具）（可选）”或“禁用流式完成（将流式请求转换为非流式请求）”并点击保存会显示一个临时的“成功！”提示，但重新加载页面后，这两个选项或其中一个选项会处于未选中状态。
连接重置问题仍然存在，我还在深入研究，但看起来是 Ruby 代码（FinalDestination / DNS 解析 / Faraday）套接字处理与 Debian 12 容器在 Ubuntu 24.04 VM 上的组合问题。
我启动了一个测试用的 Ubuntu 22.04 VM，没有出现任何问题，所有的嵌入和推理都工作得很完美。从未见过一次重置。
我会继续努力，也许这与 Ubuntu 24.04 管理 netplan 的 TCP 堆栈的新方式有关。
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2025年二月25日 10:07 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/8 "2025-02-25T10:07:59Z")
谢谢，今天已经解决了持久性问题，您可以升级并重试。
---
### Author:  [@oznyet](https://meta.discourse.org/u/oznyet)
#### Post date: [2025年二月26日 06:45 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/9 "2025-02-26T06:45:43Z")
好的，稍微更新一下——我们无法在公司 IP 地址范围内成功建立直接的 OpenAI API 连接。Cloudflare 会在 TLS 建立后大约 1 毫秒发送 RST 数据包。
因此，我们设置了一个 [Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/) 作为 OpenAI API 端点的 URL 替换方案，它与 LLM 配置配合使用效果完美。
看起来 Cloudflare 对未知 IP 地址范围（例如非 Azure、AWS、GCP 等）有一个未公开的速率限制策略，该策略会被触发。Embeddings 的 100 个连接池会触发该限制。
另外，Cloudflare 有一个 [Authenticated Gateway](https://developers.cloudflare.com/ai-gateway/configuration/authentication/) 功能，可以添加一个特殊的标头令牌。
来自他们的文档：
```bash
curl https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai/chat/completions \
--header 'cf-aig-authorization: Bearer {CF_AIG_TOKEN}' \
--header 'Authorization: Bearer OPENAI_TOKEN' \
--header 'Content-Type: application/json' \
--data '{"model": "gpt-4o" .......
```
如果在 LLM 配置屏幕中为每个 LLM 添加标头，那就太棒了。
这样我们就可以为每次调用 LLM 添加 `cf-aig-authorization` 键和值了。
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2025年二月26日 20:47 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/10 "2025-02-26T20:47:09Z")
这是一个棘手的问题，为了处理边缘情况，需要考虑很多用户界面。
您有没有可能尝试 openrouter.ai，这或许也能解决此问题？
我并非绝对反对允许任意标头，但这属于非常高级的配置。也许如果将其隐藏在站点设置后面会比较好（站点设置用于启用高级用户界面）。
您公司是否可以为这个开源插件提供帮助？
---
### Author:  [@oznyet](https://meta.discourse.org/u/oznyet)
#### Post date: [2025年四月5日 09:32 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/11 "2025-04-05T09:32:27Z")
我还没有获得对贡献的批准，但我们会继续努力。谢谢你到目前为止的帮助！
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2025年十二月2日 14:24 UTC](https://meta.discourse.org/t/discourse-ai-causing-new-ssl-and-connection-reset-by-peer-errors/353600/12 "2025-12-02T14:24:20Z")