GPU 服务器防火墙配置：UFW 与 Docker

关闭所有用不到的端口，避开 Docker 端口陷阱，模型推理端点只在 TLS 和 API 密钥的保护下对外发布。

配置 GPU 服务器防火墙只有一个目标：只有您有意开放的端口才能被访问。每台 FullGPU 服务器都有一个公网 IPv4 地址和一个 IPv6 /64 网段，因此除非您加以过滤，任何监听所有接口的服务都会暴露在外。本页先配置 ufw，再说明 Docker 如何绕过它，最后介绍如何用反向代理、TLS 和 API 密钥保护 vLLM 推理端点。

配置 ufw，先放行 SSH

启用防火墙之前先放行 SSH，否则您会把自己锁在服务器外面：

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

当 ufw 警告该命令可能中断 SSH 连接时，输入 y。您应该会看到 Status: active、默认策略，以及一条对 IPv4 和 IPv6 放行 22/tcp (OpenSSH) 的规则。保持当前会话不要断开，并在另一个终端中测试新的 SSH 连接。

如果您有固定的办公室或 VPN 地址，可以只允许从该地址访问 SSH。请先添加新规则，再删除旧规则：

sudo ufw allow from 198.51.100.7 to any port 22 proto tcp
sudo ufw delete allow OpenSSH

较温和的做法是 sudo ufw limit OpenSSH，它会对来自同一地址的重复连接进行限速。不过，比这两种做法都更重要的是只允许密钥登录，详见 SSH 访问。

同样要过滤 IPv6

grep IPV6 /etc/default/ufw
sudo ss -tulpn

当 /etc/default/ufw 中包含 IPV6=yes（Ubuntu 的默认设置）时，ufw 会过滤 IPv6。如果设置为 IPV6=no，ufw 不会过滤 IPv6，监听 [::] 的服务仍然可以通过您的 /64 网段访问。请将其设为 yes，运行 sudo ufw disable && sudo ufw enable，然后重新添加您的规则，让每条规则都生成对应的 IPv6 副本。ss -tulpn 会列出所有处于监听状态的套接字及其进程：凡是监听在 0.0.0.0、* 或 [::] 上的，都在监听所有接口。请确认它确实需要在这些地址上监听，并且受到防火墙保护；否则，请把它绑定到 127.0.0.1。

Docker 发布的端口会绕过 ufw

Docker 会自行管理 iptables 规则。当您用 -p 8000:8000 发布端口时，Docker 会通过自己的规则把这部分流量转发到容器，这些流量根本不会经过保护主机的 ufw 规则。即使设置了 default deny incoming，该端口也会对互联网开放，许多 vLLM、Jupyter 和监控部署都掉进过这个陷阱。

只在回环接口上发布端口：-p 127.0.0.1:8000:8000，在 Compose 中则写作 "127.0.0.1:8000:8000"。
用 sudo ss -tlnp | grep 8000 检查绑定情况，应显示 127.0.0.1:8000。
在您的笔记本电脑上运行 curl http://203.0.113.10:8000/v1/models（换成您服务器的 IP），应当无法连接。
通过主机上的反向代理对外提供该服务，发往反向代理的流量会经过 ufw 过滤。

要让所有发布的端口默认绑定到回环接口，请在 /etc/docker/daemon.json 中添加 "ip": "127.0.0.1"，同时保留已有条目（例如 NVIDIA 运行时），然后重启 Docker。如需更精细的控制，可以利用 DOCKER-USER iptables 链：Docker 会先评估这条链，再处理自己的规则。

在前面部署带 TLS 的反向代理

将一个域名（此处为 llm.example.com）解析到您服务器的地址，并开放 Web 端口，然后选择 Caddy 或 nginx。下面两种配置都只对外开放 /v1/ API 路径。

sudo ufw allow 80,443/tcp

Caddy

Caddy 会自动申请并续期证书。Ubuntu 24.04 已收录 Caddy 软件包（sudo apt install -y caddy）；在 22.04 上，请从 Caddy 官方软件源安装。将 /etc/caddy/Caddyfile 的内容替换为：

llm.example.com {
    handle /v1/* {
        reverse_proxy 127.0.0.1:8000
    }
    handle {
        respond 404
    }
}

运行 sudo systemctl reload caddy 使配置生效。证书签发后，https://llm.example.com/v1/models 即可通过 HTTPS 响应。

nginx

sudo apt install -y nginx certbot python3-certbot-nginx

创建 /etc/nginx/sites-available/llm：

server {
    listen 80;
    server_name llm.example.com;

    location /v1/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }

    location / {
        return 404;
    }
}

启用该站点，然后申请证书。certbot 会添加 HTTPS 配置，并设置证书自动续期：

sudo ln -s /etc/nginx/sites-available/llm /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d llm.example.com

proxy_buffering off 让流式输出的 token 一生成就送达客户端，较长的超时时间则可以容纳耗时较长的生成任务。

为兼容 OpenAI 的服务器启用 API 密钥验证

TLS 保护传输中的流量；API 密钥则决定谁可以使用模型。用 --api-key 启动 vLLM 或设置 VLLM_API_KEY 后，vLLM 会要求客户端提供 Bearer 令牌：

openssl rand -hex 32    # generate a key
vllm serve Qwen/Qwen2.5-7B-Instruct --host 127.0.0.1 --port 8000 \
  --api-key YOUR_KEY

在您的笔记本电脑上测试：

curl https://llm.example.com/v1/models -H "Authorization: Bearer YOUR_KEY"
curl -i https://llm.example.com/v1/models

第一条命令应列出模型，第二条应返回状态码 401。vLLM 对 /v1 路由启用密钥校验，而 /metrics 等其他路由可能仍然开放，这正是反向代理不对外开放其他任何路径的原因。建议使用环境变量，就像用 vLLM 提供大语言模型（LLM）推理服务中的 systemd 配置那样：在命令行中输入的密钥，本机的其他用户可以在进程列表中看到。其他兼容 OpenAI 的服务器也有类似的选项。

服务器之间的私有网络

我们可应要求通过私有网络连接您的各台服务器。请用它承载服务器之间的流量：数据同步、NCCL 和 torchrun rendezvous、内部 API 和监控指标。在 ufw 中按子网或按网络接口放行这部分流量（用 ip -br addr 查找接口）：

sudo ufw allow from 10.0.0.0/24
# or
sudo ufw allow in on PRIVATE_INTERFACE

请将子网或接口替换为您私有网络的实际值。如需开通，请参阅私有网络。

已包含 DDoS 防护

您服务器上的每个公网 IP 地址都有 DDoS 防护，费用已包含在价格中。它可以抵御网络层攻击，但不能取代您自己服务上的防火墙、TLS、身份验证或限流措施。如果您发现异常流量，或认为服务器正在遭受攻击，请在控制台提交工单。更多信息请参阅 DDoS 防护。

故障排查

启用 ufw 后无法登录。不要反复重试。请在控制台提交工单（提交工单不需要 SSH），写明是哪台服务器以及您添加了哪些规则；参见工单如何运作。
Caddy 或 certbot 无法获取证书。请检查：域名是否指向该服务器，ufw 是否放行了 80 和 443 端口，以及是否有其他程序在监听这两个端口（sudo ss -tlnp）。
尽管启用了 ufw，容器端口仍可被访问。该端口发布在了所有接口上。请用 -p 127.0.0.1:PORT:PORT 重新创建容器。