建议放弃通过 Api 获取流式结果，改用前端模拟

[lqzhgood]

基于网络质量及疑似官方 Api 降速的考虑。

通过 streaming 获取到的 response 太长且都是重复内容，在持续获取的过程中很容易因为网络问题造成回答只有一部分 再加上疑似的 Api 降速导致返回的结果耗时更长。

建议后端去掉 streaming 返回，直接返回全文 https://github.com/Chanzhaoyu/chatgpt-web/blob/ddc7066f4e4491b3bd80cefc83ea30b490fce20c/service/src/chatgpt/index.ts#L113-L115

前端拿到全文通过 typed.js 等库去模拟打字机效果

以上应该能极大避免因网络质量造成的问题，同时降低 nginx 等反代部署的复杂度

[smartfat]

有测试过吗？现在超时设定100000，比之前好一点了，但是还是会中断

[Chanzhaoyu]

有测试过吗？现在超时设定100000，比之前好一点了，但是还是会中断

你设置为 0 的话也行，不过也和网络情况有关

[lqzhgood]

用 streaming 的话就是一个长连接
接收的时间和内容大小是要大于一个普通请求的~ 我认为通过发送普通请求降低接收的时间和内容大小就能减少弱网络造成的影响~

GPT 请求时间越长，越会受到网络波动的影响，毕竟都是代理几层过去的

我通过发送大约4000字左右的文章在普通账号下进行测试，样本量约为10篇左右，等待时间约为60s~120s+

• streaming 大部分回答一半就截断了
• 普通请求完整获取成功率更高

（因为 GPT限速的不确定性，两者的请求时间无法统计比较）

小文本量的回答应该区别不大。

[git-syl]

有测试过吗？现在超时设定100000，比之前好一点了，但是还是会中断

你设置为 0 的话也行，不过也和网络情况有关

@lqzhgood @Chanzhaoyu 断流是网络问题。在用户浏览器到你的外海服务器之间，套个CDN支持长连接加速的就行。 然后把项目的后端VITE_GLOB_API_URL换成你CDN加速的地址就好了

[lqzhgood]

有测试过吗？现在超时设定100000，比之前好一点了，但是还是会中断

你设置为 0 的话也行，不过也和网络情况有关

@lqzhgood @Chanzhaoyu 断流是网络问题。在用户浏览器到你的外海服务器之间，套个CDN支持长连接加速的就行。 然后把项目的后端VITE_GLOB_API_URL换成你CDN加速的地址就好了

是网络问题呀，所以要降低网络影响呀~ 套 CDN 是治标（而且不是人人有条件）~

减少网络传输的大小是治本

// by the way

其实我有网络质量很好的服务器，但还是断流，我都怀疑官方是不是对免费用户 Api 的长连接时长有限制

• A 故意延长返回时间（基本证实）
• B 限制单次长连接的时长 （怀疑）

如果 B 的怀疑正确的话，因为 A 的影响，可能从官方出口就断流了 当然网络环境很复杂，GFW 也可能影响，需要更多样本才能说明~

但去掉 streaming 从而减小单次传输内容好像没什么坏处 ;)

[git-syl]

有测试过吗？现在超时设定100000，比之前好一点了，但是还是会中断

你设置为 0 的话也行，不过也和网络情况有关

@lqzhgood @Chanzhaoyu 断流是网络问题。在用户浏览器到你的外海服务器之间，套个CDN支持长连接加速的就行。 然后把项目的后端VITE_GLOB_API_URL换成你CDN加速的地址就好了

是网络问题呀，所以要降低网络影响呀~ 套 CDN 是治标（而且不是人人有条件）~

减少网络传输的大小是治本

// by the way

其实我有网络质量很好的服务器，但还是断流，我都怀疑官方是不是对免费用户 Api 的长连接时长有限制

• A 故意延长返回时间（基本证实）
• B 限制单次长连接的时长 （怀疑）

如果 B 的怀疑正确的话，因为 A 的影响，可能从官方出口就断流了 当然网络环境很复杂，GFW 也可能影响，需要更多样本才能说明~

但去掉 streaming 从而减小单次传输内容好像没什么坏处 ;)

套 CDN 是治标，因为要治本的话要废掉GFW🤣 我试这边测试相反：长文本，去掉流的，网络不好要等很久，最后还可能因为报错啥结果都没有。。 而用SSE这种流的，不用等待，马上就有一个个字输出的结果，有掉线但是支持重连和自动恢复数据传输，等等就有继续输出的结果了。

CDN免费的话有：AWS、Azure的云函数、或者Cloudflare Workers等把聊天的那个响应接口套一层，就稳定很多了。 我用后者免费账号每天100,000次，根本用不完。

[lqzhgood]

@git-syl

GFW 和 CDN 对普通请求和流式请求的影响是一致的。所以讨论这两者没意义~

我说的是因为官方导致网络弱化的情况下，尽可能拿到完整结果的讨论。

在官方故意延迟的情况下

• 流式请求可能更容易达到接口的timeout从而断连
• 传输内容更多的流式请求可能更容易断连

现在官方放开限制后，就无所谓了。