大模型Nginx代理配置：从零搭建API反向代理与密钥保护

如果你手头有多个大模型API，直接在前端或客户端调用会暴露密钥，而且难以统一管理。
用Nginx做反向代理，可以把密钥藏在服务器端，对外只暴露一个代理地址，同时还能做限流、日志和负载均衡。
下面按零基础能跟做的顺序，讲清楚配置和验证方法。

先确认你的环境和前置条件

开始之前，需要一台能运行Nginx的Linux服务器（本文以Ubuntu 22.04为例，其他发行版命令略有差异），并确保服务器能访问外网。
大模型API以OpenAI兼容接口为例，假设你已经有API Key和对应的接口地址（如https://api.openai.com/v1）。

服务器上安装Nginx：

sudo apt update
sudo apt install nginx -y
sudo systemctl status nginx

如果状态显示active (running)，说明Nginx已就绪。
下面确认服务器能访问目标API：

curl -I https://api.openai.com/v1/models

返回HTTP状态码（如401或200）都表示网络连通，401是因为没带密钥，属于正常现象。

配置Nginx反向代理大模型API

Nginx的配置文件通常位于/etc/nginx/sites-available/下。
新建一个配置文件，例如llm-proxy.conf：

server {
    listen 80;
    server_name your-domain.com;  # 换成你的域名或IP

    location /v1/ {
        proxy_pass https://api.openai.com/v1/;
        proxy_ssl_server_name on;
        proxy_set_header Host api.openai.com;
        proxy_set_header Authorization "Bearer sk-你的实际API密钥";
        proxy_set_header Content-Type $content_type;
        proxy_set_header Accept $http_accept;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 300s;
    }
}

关键点说明：

• proxy_pass末尾的/v1/和location的/v1/配合，确保路径正确转发。
• proxy_set_header Authorization把密钥写死在Nginx里，客户端就不需要携带密钥。
• proxy_buffering off对大模型流式响应很重要，否则可能卡住不输出。
• proxy_read_timeout适当调大，避免长回答超时。

保存后创建软链接并测试配置：

sudo ln -s /etc/nginx/sites-available/llm-proxy.conf /etc/nginx/sites-enabled/
sudo nginx -t

如果输出syntax is ok和test is successful，重载Nginx：

sudo systemctl reload nginx

避坑：密钥安全与访问控制

把密钥写在Nginx配置里虽然方便，但要注意文件权限。
建议将配置文件权限设为640，属主为root：

sudo chmod 640 /etc/nginx/sites-available/llm-proxy.conf
sudo chown root:root /etc/nginx/sites-available/llm-proxy.conf

另外，代理接口不要直接对公网开放。
可以在Nginx层加一个简单的访问令牌，或者用防火墙限制来源IP。
例如只允许公司出口IP访问：

location /v1/ {
    allow 203.0.113.0/24;  # 替换为你的IP段
    deny all;
    # 其余代理配置...
}

如果使用宝塔面板，可以在“网站”->“设置”->“配置文件”中直接编辑，但同样要注意权限和备份。

验证代理是否生效

用curl通过你的代理地址请求模型列表：

curl http://your-domain.com/v1/models

如果返回JSON格式的模型列表（包含data数组），说明代理成功。
如果返回401，检查Nginx配置中的Authorization头是否正确携带了密钥；
如果返回502，检查proxy_pass地址和服务器网络；
如果返回404，检查location路径和proxy_pass的斜杠匹配。

对于流式对话，可以用：

curl http://your-domain.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-3.5-turbo","messages":[{"role":"user","content":"你好"}],"stream":true}'

观察是否逐块返回数据。
如果一次性返回全部内容，说明proxy_buffering可能没关闭，检查配置并重载。

常见问题排查

代理后响应很慢或超时：先确认proxy_read_timeout是否足够大（建议300s以上），并检查服务器到API的网络延迟。
可以在Nginx配置中增加proxy_connect_timeout 60s;。

流式输出被缓冲：除了proxy_buffering off，还需要确保没有启用gzip压缩代理响应，可以在location中加gzip off;。

HTTPS证书问题：如果代理目标是https，proxy_ssl_server_name on必须开启，否则可能握手失败。
如果服务器时间不准，也会导致SSL错误，用date命令检查时间。

如何代理多个大模型：可以配置多个location，每个指向不同上游，或者用Nginx的upstream模块做负载均衡。
例如：

upstream llm_backend {
    server api.openai.com:443;
    # 可以加更多备用地址
}

然后在location中使用proxy_pass https://llm_backend/v1/;。

完成以上步骤后，你的客户端只需要请求http://your-domain.com/v1/...，无需接触真实密钥。
建议定期检查Nginx错误日志/var/log/nginx/error.log，以便及时发现代理异常。
如果后续需要更细粒度的密钥管理或用量统计，可以考虑在Nginx前再架设一个API网关，但基础的代理配置已经能满足大多数个人和小团队的需求。