核心内容摘要
革新象棋AI辅助：VinXiangQi如何通过YOLOv5技术重构棋局分析体验
Qwen3-VL-8B生产环境部署防火墙/Nginx反代/HTTPS认证完整配置你已经成功跑通了本地版Qwen3-VL-8B聊天系统界面流畅、响应迅速——但当你要把它真正用起来比如给团队共享、嵌入内部知识库或者对外提供轻量AI服务时就会发现http://localhost:8000/chat.html这个地址根本走不出你的开发机。
它缺的不是能力而是生产就绪性安全的访问入口、稳定的网络暴露、可信的身份验证、可审计的流量路径。
本文不讲怎么启动vLLM也不重复start_all.sh里那几行命令。
我们要做的是——把那个“能跑”的系统变成一个“敢上生产”的服务。
从关闭危险端口开始到Nginx反向代理落地再到Let’s Encrypt自动签发HTTPS证书最后加上基础访问控制。
每一步都经过真实服务器验证所有配置可直接复制粘贴无需二次调试。
生产环境安全第一课关闭裸露端口默认部署中vLLM监听3001端口proxy_server监听8000端口两者均绑定
0.
0.
0——这意味着只要服务器有公网IP全世界都能直连你的推理API和前端资源。
这在生产环境中是严重风险。
1 禁止vLLM对外暴露vLLM只需对本机代理服务开放绝不应监听公网地址。
修改run_app.sh中的vLLM启动命令强制绑定
127.
0.
1vllm serve $ACTUAL_MODEL_PATH \ --host
127.
0.
1 \ --port 3001 \ --gpu-memory-utilization
6 \ --max-model-len 32768 \ --dtype float16关键点--host
127.
0.
1确保vLLM只接受来自本机的请求外部无法绕过代理直连模型。
2 防火墙策略仅放行必要端口使用ufwUbuntu或firewalldCentOS/RHEL收紧入口规则。
以下以ufw为例# 默认拒绝所有入站 sudo ufw default deny incoming # 只允许SSH必须保留否则会锁死 sudo ufw allow OpenSSH # 允许Nginx使用的443HTTPS和80HTTP重定向 sudo ufw allow 443/tcp sudo ufw allow 80/tcp # 禁止直接访问8000和3001端口即使proxy_server.py监听
0.
0.
0防火墙也会拦截 sudo ufw deny 8000/tcp sudo ufw deny 3001/tcp # 启用防火墙 sudo ufw enable验证效果sudo ufw status verbose # 输出应显示8000/tcp DENY IN, 3001/tcp DENY IN, 443/tcp ALLOW IN此时从外部执行curl http://your-server-ip:8000或curl http://your-server-ip:3001/health将直接超时或被拒绝而curl https://your-domain.com则可正常访问——说明流量已完全收束至Nginx入口。
3 补充加固禁用root运行与进程隔离不要用root用户启动服务。
创建专用用户并赋予最小权限sudo adduser --disabled-password --gecos qwen-user sudo usermod -aG docker qwen-user # 若使用Docker部署 sudo chown -R qwen-user:qwen-user /root/build/ sudo su - qwen-user -c cd /root/build ./start_all.sh同时在supervisord配置中指定用户/etc/supervisor/conf.d/qwen-chat.conf[program:qwen-chat] command/root/build/start_all.sh userqwen-user autostarttrue autorestarttrue redirect_stderrtrue stdout_logfile/var/log/supervisor/qwen-chat.log重启Supervisor生效sudo supervisorctl reread sudo supervisorctl update sudo supervisorctl restart qwen-chat
Nginx反向代理统一入口与静态资源托管Nginx不再只是“转发器”而是整个AI服务的流量网关。
它承担三项核心职责静态文件服务chat.html、API请求路由/v1/chat/completions → vLLM、以及后续HTTPS与认证的载体。
1 安装与基础配置Ubuntu系统安装sudo apt update sudo apt install nginx -y sudo systemctl enable nginx sudo systemctl start nginx清空默认站点新建配置文件/etc/nginx/sites-available/qwen-chatupstream qwen_backend { server
127.
0.
1:3001; } server { listen 80; server_name your-domain.com; # 强制HTTPS跳转启用HTTPS后取消注释此行 # return 301 https://$server_name$request_uri; # 静态文件服务直接由Nginx提供chat.html及相关资源 location / { root /root/build; try_files $uri $uri/ /chat.html; index chat.html; } # API请求全部转发至vLLMOpenAI兼容接口 location /v1/ { proxy_pass http://qwen_backend/; 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; # 透传原始请求头确保vLLM能正确解析Content-Type等 proxy_http_version
1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # 调整超时避免长对话被中断 proxy_read_timeout 300; proxy_send_timeout 300; proxy_connect_timeout 300; } # 健康检查端点供监控系统调用 location /health { return 200 OK; add_header Content-Type text/plain; } }启用配置sudo ln -sf /etc/nginx/sites-available/qwen-chat /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx此时访问http://your-domain.com将直接加载/root/build/chat.html发送POST /v1/chat/completions请求将被精准转发至http://
127.
0.
1:3001/v1/chat/completions全程无额外跳转、无路径错乱。
2 静态资源优化缓存与压缩为提升前端加载速度添加以下配置到location /块内# 启用Gzip压缩 gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript; # 静态资源强缓存HTML除外因chat.html本身极小且需实时 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2|ttf)$ { expires 1y; add_header Cache-Control public, immutable; try_files $uri 404; }
3 CORS问题终结方案前端若部署在其他域名如admin.your-company.com浏览器会因CORS拦截请求。
不要在proxy_server.py中加Access-Control-Allow-Origin: *——这是开发阶段的权宜之计生产环境必须由Nginx统一管控在location /v1/块中追加# 严格限制CORS来源替换为你的真实前端域名 add_header Access-Control-Allow-Origin https://admin.your-company.com always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS always; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization always; add_header Access-Control-Expose-Headers Content-Length,Content-Range always; # 处理预检请求 if ($request_method OPTIONS) { add_header Access-Control-Allow-Origin https://admin.your-company.com always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS always; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization always; add_header Access-Control-Max-Age 17280000; add_header Content-Type text/plain; charsetutf-8; add_header Content-Length 0; return 204; }
HTTPS全链路加密Let’s Encrypt自动签发没有HTTPS一切安全配置都是纸糊的。
我们采用certbot配合Nginx插件实现证书申请、部署、自动续期三步闭环。
1 安装Certbot与Nginx插件sudo apt install certbot python3-certbot-nginx -y
2 申请并部署证书确保你的域名DNS已解析到服务器IP然后执行sudo certbot --nginx -d your-domain.comCertbot会自动暂停Nginx通过HTTP-01挑战验证域名所有权生成证书并写入/etc/letsencrypt/live/your-domain.com/修改Nginx配置添加HTTPS server块并重定向HTTP到HTTPS生成的HTTPS配置示例Certbot自动插入server { server_name your-domain.com; listen 443 ssl http2; ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # 其余location配置同上/、/v1/、/health ... } server { if ($host your-domain.com) { return 301 https://$host$request_uri; } listen 80; server_name your-domain.com; return 404; }执行后https://your-domain.com即可安全访问浏览器地址栏显示绿色锁形图标所有流量加密传输。
3 自动续期与验证Let’s Encrypt证书90天有效期Certbot已配置systemd定时任务。
手动测试续期sudo certbot renew --dry-run若输出Congratulations, all simulated renewals succeeded说明自动续期机制正常。
无需人工干预。
访问控制基础认证与IP白名单HTTPS解决了传输加密但未解决“谁可以访问”。
我们叠加两层防护HTTP Basic Auth简单有效与IP白名单适合内网场景。
1 HTTP Basic认证一行命令启用生成密码文件首次运行sudo apt install apache2-utils -y sudo htpasswd -c /etc/nginx/.htpasswd admin # 输入密码两次如A1b2C3d4!在Nginx的HTTPSserver块中对/和/v1/添加认证# 对整个站点启用基础认证 auth_basic Qwen3-VL-8B Admin Access; auth_basic_user_file /etc/nginx/.htpasswd; # 若只想保护API注释掉上面两行改为 # location /v1/ { # auth_basic Qwen3-VL-8B API Access; # auth_basic_user_file /etc/nginx/.htpasswd; # ...原有proxy_pass等配置... # }重载Nginxsudo nginx -t sudo systemctl reload nginx访问https://your-domain.com时浏览器将弹出登录框输入admin和对应密码即可进入。
2 IP白名单仅允许可信网络访问适用于企业内网部署。
在server块顶部添加# 允许的IP段示例公司办公网
192.
168.
1
0/24运维跳板机
10.
0.
100 allow
192.
168.
1
0/24; allow
10.
0.
100; deny all; # 注意必须放在location之前否则无效警告若同时启用Basic Auth和IP白名单deny all会优先于认证生效导致合法用户也被拒绝。
二者选其一即可推荐生产环境优先用IP白名单。
日志与监控让服务状态一目了然生产环境不能靠tail -f救火。
我们整合Nginx日志与vLLM健康检查构建轻量可观测性。
1 Nginx日志格式增强编辑/etc/nginx/nginx.conf在http块内定义自定义日志格式log_format qwen_combined $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent rt$request_time uct$upstream_connect_time uht$upstream_header_time urt$upstream_response_time;在server块中应用access_log /var/log/nginx/qwen-access.log qwen_combined; error_log /var/log/nginx/qwen-error.log warn;创建日志目录并赋权sudo mkdir -p /var/log/nginx sudo touch /var/log/nginx/qwen-access.log /var/log/nginx/qwen-error.log sudo chown www-data:adm /var/log/nginx/qwen-*.log
2 健康检查集成将vLLM健康端点纳入Nginx状态页可选location /nginx_status { stub_status on; access_log off; allow
127.
0.
1; deny all; }更实用的是用curl脚本定期探测服务可用性# /root/build/health-check.sh #!/bin/bash set -e DOMAINhttps://your-domain.com # 检查Nginx是否响应 if ! curl -s -o /dev/null -w %{http_code} $DOMAIN | grep -q 200; then echo $(date): Nginx down | mail -s Qwen Service Alert adminyour-company.com exit 1 fi # 检查vLLM API是否就绪 if ! curl -s -o /dev/null -w %{http_code} $DOMAIN/v1/models | grep -q 200; then echo $(date): vLLM API down | mail -s Qwen Service Alert adminyour-company.com exit 1 fi echo $(date): All services OK加入crontab每5分钟执行(crontab -l 2/dev/null; echo */5 * * * * /root/build/health-check.sh) | crontab -
6.
总结从“能跑”到“敢用”的关键跨越部署Qwen3-VL-8B不是终点而是起点。
本文覆盖的四个核心环节构成了生产环境的基石安全收敛通过--host
127.
0.
1 防火墙策略彻底切断vLLM与外界的直接联系消除最大攻击面流量统管Nginx不仅是代理更是静态服务、API路由、CORS治理、超时控制的统一网关让架构清晰可控信任建立Let’s Encrypt自动HTTPS让每一次对话都在加密通道中完成用户无需质疑连接安全性访问可控Basic Auth或IP白名单确保只有授权人员能触达AI能力避免资源滥用与数据泄露。
这些配置没有一行是“可有可无”的装饰。
它们共同回答了一个问题当你的AI服务承载真实业务、处理敏感信息、面向真实用户时你能否拍着胸脯说——它足够稳、足够安、足够可信答案就藏在你刚刚敲下的每一行sudo命令里。