服务器端口暴露风险清单：11434/7860/8188/

知识分享

2026-08-31 10:01

15 阅读

如果你在服务器上跑过 Ollama、Stable Diffusion WebUI、ComfyUI、n8n 之类的自建服务，大概率会用到 11434、7860、8188、5678、4000 这些默认端口。
它们本身没有错，错的是直接暴露在公网：任何人都能扫到，轻则被刷流量，重则被调用接口、消耗算力，甚至拿到未授权访问。
本文我会先带你看清楚这些端口对应哪些服务，再按顺序教你自查、封禁和改造，最后给出验证方法。
整个过程不需要很深的基础，跟着命令走即可。

这些端口背后是什么服务？

先明确端口和服务的对应关系，方便你判断自己的服务器是否存在暴露风险：

11434：Ollama 的 API 默认监听端口。Ollama 本身没有强校验，暴露后任何人都能调用你本机的模型生成结果。
7860：Stable Diffusion WebUI（AUTOMATIC1111）默认端口，暴露后会被人直接打开操作界面。
8188：ComfyUI 默认端口，同样是 AI 绘图工具，暴露后影响力更大，因为 ComfyUI 支持工作流，容易被人利用执行恶意节点。
5678：n8n 自动化工具的默认端口，此外也可能被其他服务占用。n8n 暴露后，工作流、密钥、数据库连接信息都可能泄露。
4000：很多 Web 服务的备选端口，比如部分 Node.js 应用、CrewAI UI、Jupyter 等。不同服务风险不同，但同样不建议直接对公网开放。

这些端口都属于高价值目标，扫描器每天都在全网探测。只要你的服务器 IP 出现在公网，就可能在几小时内被扫描到。

第一步：自查你的服务器是否已经暴露

登录服务器后，先查一下当前监听端口和对外开放情况。

先看本机监听端口：

ss -tlnp | grep -E '11434|7860|8188|5678|4000'

出现 0.0.0.0:7860 或 :::7860 这类结果，说明服务正在所有网卡上监听，包括公网 IP。
如果只看到 127.0.0.1:7860，表示只绑定了本地回环，外网暂时访问不到。

再检查这些端口是否真的能从外部访问。
最简单的方法是：用另一台电脑或手机流量，打开浏览器访问 http://你的服务器IP:端口。
能打开就是实锤暴露。

注意：直接访问公网 IP 测试时，请先确认这是你本人的服务器，否则可能违法。

第二步：立刻封掉公网访问

没有反代、没有认证、没有固定访问来源的情况下，不要直接把这些端口映射到公网。
你可以按优先级做三件事。

1. 修改服务监听地址

把服务绑定 IP 从 0.0.0.0 改成 127.0.0.1，让服务只接受本机访问。
以 Ollama 为例：

# 设置监听地址为本地回环
OLLAMA_HOST=127.0.0.1:11434 ollama serve

如果你用 systemd 管理，可以编辑 service 文件里的 Environment 行，然后重启。
改完再用 ss -tlnp 确认监听地址已经变成 127.0.0.1。

2. 配置防火墙或云安全组

无论服务是否只能本机访问，都建议在防火墙层再加一道限制。

使用 firewalld 的 CentOS/Rocky 系统：

firewall-cmd --permanent --remove-port=11434/tcp
firewall-cmd --permanent --remove-port=7860/tcp
firewall-cmd --permanent --remove-port=8188/tcp
firewall-cmd --permanent --remove-port=5678/tcp
firewall-cmd --permanent --remove-port=4000/tcp
firewall-cmd --reload

使用 UFW 的 Ubuntu/Debian：

ufw deny 11434/tcp
ufw deny 7860/tcp
ufw deny 8188/tcp
ufw deny 5678/tcp
ufw deny 4000/tcp

如果你用的是阿里云、腾讯云、华为云等云服务器，还需要登录云控制台，在安全组入方向规则中删除对应端口的放行规则，或设置为只允许你自己的 IP 访问。
云安全组是云服务器的最外层防线，只改服务器本地防火墙不够。

第三步：需要外网访问时，用反向代理替代裸奔

有些场景你确实需要从外部访问，比如家人用 ComfyUI、手机连 n8n。
此时不要直接开端口，而是用 Nginx 反向代理加访问认证。

下面是一个 Nginx 配置片段，假设你的域名是 ai.example.com，需要访问内网的 ComfyUI（8188）：

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

    # 基础认证，登录后才能访问
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:8188;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

用 htpasswd 创建用户：

sudo apt install apache2-utils  # Ubuntu/Debian
sudo htpasswd -c /etc/nginx/.htpasswd yourname

之后再配合 HTTPS 证书，就能在安全的前提下正常使用。不要跳过认证步骤，否则等于给公网开了一个后门。

验证与避坑指南

加固后务必验证是否生效。

本地检查监听地址：ss -tlnp | grep 8188，确认只在 127.0.0.1 上监听。
从外部访问测试：用手机流量访问 http://IP:11434，应该打不开或超时。
通过域名访问反代服务：如果能打开，说明反代正常；再检查是否出现了登录认证框。

常见误区有两个：

只改了云安全组，没改服务监听。重启服务后可能恢复成 0.0.0.0，所以两个地方都要改。
只改监听地址，没关本地防火墙。部分服务会覆盖监听配置，导致监管失效。所以安全组、本地防火墙、服务监听三层都查一遍才稳妥。

另外，如果你用 Docker 启动这些服务，注意 -p 11434:11434 这类映射会把容器端口直接绑到宿主机所有网卡。
建议改用 -p 127.0.0.1:11434:11434，或者直接使用 --network host 再配合监听绑定。

总结建议

11434、7860、8188、5678、4000 端口默认都不应该裸奔在公网。 正确做法是：先修改服务监听为 127.0.0.1，再关闭云安全组对应的入方向端口，最后用 Nginx + 认证 + HTTPS 提供受控访问。
如果你现在服务器上已经跑着这些服务，花十分钟按本文检查一遍，能省掉后续被扫描和滥用的麻烦。安全加固不是一次性的，每次重启服务、迁移服务器后都要重新确认监听状态。

SSRF漏洞在AI中转、Agent系统中高发场景完整复现

Nginx配置错误导致目录穿越漏洞