nginx upstream 不能直接配置 deepseek 官方 api 地址，因其仅提供网关入口（如 https://api.deepseek.com），需用反向代理透传 host、authorization 等头，并关闭缓冲、调长超时以支持流式响应。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
nginx upstream 配置里不能直接写 DeepSeek 的 API 地址
DeepSeek 官方不提供可直连的公网后端服务地址，所有请求必须走其官方网关（如 https://api.deepseek.com），你没法把它的服务器 IP 加进 upstream 块做传统负载均衡。硬加会 502 或连接拒绝。
真正能做的，是用 Nginx 反向代理 + 请求级分流，比如按 Authorization 头、路径前缀或客户端 IP 做路由决策。
- 别在
upstream里填api.deepseek.com—— Nginx 不支持 HTTPS upstream 直连（除非编译时加--with-http_ssl_module且配proxy_ssl_*参数） - 若真要多实例分担自身服务压力（比如你起了多个本地 DeepSeek 推理服务），才需要
upstream；但 DeepSeek 官方 API 本身不开放自托管模型节点 - 常见错误：
upstream server api.deepseek.com:443;→ 直接报invalid port while resolving upstream
proxy_pass 必须带协议和完整路径，否则 Host 头错乱
DeepSeek API 对 Host 和 Authorization 头敏感，Nginx 默认转发时可能丢掉原始 Host，或把路径拼错，导致 400 Bad Request 或 401 Unauthorized。
- 正确写法：
proxy_pass https://api.deepseek.com/;（结尾斜杠不能少） - 错误写法：
proxy_pass https://api.deepseek.com;（缺末尾 /，Nginx 会把 location 路径硬拼上去，比如/v1/chat/completions变成/v1/chat/completions/v1/chat/completions） - 必须显式透传头：
proxy_set_header Host api.deepseek.com;，否则对方网关无法识别来源 - 别漏掉
proxy_set_header Authorization $http_authorization;，Bearer Token 否则传不过去
跨域（CORS）问题不是加 add_header 就能解决的
浏览器前端直连 DeepSeek API 会触发预检（OPTIONS），而 DeepSeek 网关不响应 OPTIONS 请求，所以你在 Nginx 层加 add_header Access-Control-Allow-Origin "*" 没用——预检失败，后续请求根本发不出。
- 真实可行方案：只在 Nginx 上处理非浏览器场景（如后端服务调用），或用中间层（如 Next.js API Route）中转，避开浏览器 CORS
- 如果坚持用 Nginx 模拟响应 OPTIONS：
if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin "*"; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS"; add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Auth-Token,Content-Type,Authorization,Accept,Origin"; add_header Access-Control-Max-Age 1728000; add_header Content-Type 'text/plain; charset=utf-8'; add_header Content-Length 0; return 204; } - 但注意：DeepSeek 的实际响应头（如
X-RateLimit-Limit）不会被浏览器读取，因为预检没过，add_header只影响 Nginx 自己返回的内容
超时和缓冲区不调大会卡死长响应
DeepSeek 的 /v1/chat/completions 流式响应（stream=true）可能持续几十秒，Nginx 默认超时只有 60 秒，且默认关闭流式支持，容易截断响应或返回空内容。
- 关键配置三件套：
proxy_read_timeout 300;（匹配 DeepSeek 最大响应时间）、proxy_buffering off;（必须关，否则流式数据全缓存完才吐给客户端）、proxy_http_version 1.1;（启用 keepalive，避免流中断） - 别碰
proxy_buffer_size和proxy_buffers—— 流式响应下缓冲区大小反而影响实时性，设太小会频繁 flush，太大延迟高 - 错误现象：
curl -N看到响应卡在中途不动，或者返回{"error": {"message": "Connection closed", ...}}，基本就是proxy_buffering on或超时太短
DeepSeek 的响应体结构依赖完整流，Nginx 层任何缓冲、重写或 header 干预都可能破坏 SSE 格式。最稳的做法是尽量少动原始响应，只做路由和透传。
