当前位置：首页 > news >正文

对接AI大模型之nginx代理配置SSE接口

news 2026/5/11 3:06:04

一、背景

在对接AI大模型的时候，采用流式输出，可以较好地缓解用户等待的焦虑，但是，接口极其容易超时。

前端这时候会一直报错：

Expected content-type to be text/event-stream, Actual: text/html

而后端的错误显示是客户端断开了连接。

这里摘录其中的一段错误信息，如果你也遇到该错误，希望本文可以帮助到你。

Caused by: java.io.IOException: Broken pipe at java.base/sun.nio.ch.SocketDispatcher.writev0(Native Method)~[na:na]at java.base/sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:66)~[na:na]at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:227)~[na:na]at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:158)~[na:na]at java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:574)~[na:na]at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:162)~[xnio-nio-3.8.16.Final.jar!/:3.8.16.Final]at io.undertow.conduits.IdleTimeoutConduit.write(IdleTimeoutConduit.java:130)~[undertow-core-2.3.18.Final.jar!/:2.3.18.Final]

二、架构图

不通过内网域名访问后端服务：

三、排查过程

1、机房B的nginx配置

第一个被怀疑的对象是机房B的nginx超时时长，因为sse接口总是60秒即超时。

机房A的nginx,我看全局的配置nginx.conf已把连接超时调整为600秒。

vi /etc/nginx/nginx.conf

而接口每到了60秒的时候就断开了。
这一点，从机房B的nginx可以看到。

所以我们尝试改大机房B的nginx的超时，ingress的配置见下：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/proxy-connect-timeout:'600'nginx.ingress.kubernetes.io/proxy-read-timeout:'600'nginx.ingress.kubernetes.io/proxy-send-timeout:'600'

它无需重启，热加载配置生效。

2、机房A的nginx

既然机房B的nginx超时不能解决问题，试着从源头来排查。

首先，在机房A通过IP地址访问，不通过内网域名访问机房B的后端服务。

尝试后，无果。

在机房A，无论通过内网域名还是IP地址，测试后端服务的接口，都不会出现60秒即超时的异常。

curl-w"\n=== 耗时统计 ===\nDNS解析: %{time_namelookup}s\nTCP连接: %{time_connect}s\nSSL握手: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\nHTTP状态: %{http_code}\n"\-XPOST\-H"Accept:text/event-stream"\-H"Content-Type:application/json"\-d'...略'\"http://内网域名/api/v1/pub/.../chat/messages"\-o/dev/null\-s

你可以通过curl进行测试，这一点很关键，可以排查，非机房B的问题。

既然是机房A的问题，那就转换下思路。

因为机房B的后端服务，原本是kong代理对外提供服务正常的，不同的是机房A现在是使用nginx代理。

3、nginx配置

试着单独配置sse接口的反向代理，见下：

location ~ ^/ai(/api/v1/pub/.../chat/messages)${proxy_pass http://10.xxx.xxx.196:7209$1;proxy_http_version1.1;proxy_set_header Connection"";# sse 关闭缓存proxy_buffering off;proxy_cache off;chunked_transfer_encoding on;proxy_connect_timeout 600s;proxy_send_timeout 600s;proxy_read_timeout 600s;send_timeout 30s;proxy_set_header Host$host;proxy_set_header X-Real-IP$remote_addr;proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto$scheme;}

其他接口则走默认：

location /ai/{# 注意host末尾要加斜杆,否则访问后端接口的地址会被追加/aiproxy_pass http://10.xxx.xxx.196:7209/;}

当然，proxy_pass 也可以配置内网域名。

经测试，前端访问sse接口，终于不会60秒即断开了。

三、测试验证

同样，通过curl工具，对外网接口进行测试。

curl-w"\n=== 耗时统计 ===\nDNS解析: %{time_namelookup}s\nTCP连接: %{time_connect}s\nSSL握手: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\nHTTP状态: %{http_code}\n"\-XPOST\-H"Accept:text/event-stream"\-H"Content-Type:application/json"\-d'...略'\"http://外网域名/api/v1/pub/.../chat/messages"\-o/dev/null\-s