你敢信？就在此时此刻，公网上仍然有一些数据库，因为没有做好访问限制，直接对着全世界敞着门。
有些被人闯进去以后，数据会被清空，只留下一张勒索纸条：打钱，不打，数据别想要回来。
干这事的，不一定是什么高级黑客。
自动化程序会挨个扫描公网里的 IP 地址和端口，扫到一扇没关严的门，就进去试一试。
更扎心的是，纯靠 AI 做出来的产品，也已经踩过这种坑。
2026 年 2 月，一个几乎完全靠 AI 做出来的社交产品 Moltbook，上线没多久，就被发现数据库访问权限没有锁好。
大约一百五十万个 API 认证令牌、三万五千个邮箱地址和大量私信，因此暴露了出去。
你先别慌。
这些听着吓人，但把服务器对外的门守好，对没技术背景的人，远没有想象中那么难。
一天一个 vibe coding 小技巧：这一篇，我们就把服务器对外的门，一扇一扇查清楚。
一、先分清代码安全和服务器安全
Moltbook 这个案例，本质上是应用没有把数据库访问权限锁好。
它属于代码和应用这一层的安全问题。
这一层先管别人能不能绕过页面，看到不该看的数据。
它还要管密钥有没有被写进前端，以及普通用户能不能做管理员才能做的事。
具体的代码安全问题，我在前面已经花了很多篇幅讲过，没看过的建议往前翻一翻。
而这一篇要补的是服务器这一层。
服务器这一层，涉及谁能登录这台机器，以及哪些服务能被整个互联网直接访问。
它还涉及外人能不能从网站上下载到配置和备份。
服务器里的软件有没有还停在存在已知高风险漏洞的版本，也属于这一层。
这两层安全谁也替不了谁。
代码写得再严，服务器的登录口和数据库直接对公网敞开，照样会出事。
反过来也一样。
服务器守得再严，代码自己把用户数据送出去，也拦不住。
二、先花一分钟，搞懂“端口”是什么
后面要反复说到“端口”，先用一分钟把它讲明白，不然听着容易懵。
你的服务器对外有一个 IP 地址，相当于一栋楼的门牌号。
可这栋楼里，同时跑着网站、数据库和远程登录等不同服务。
外面来的请求，怎么知道该找哪一个？靠的就是端口。
你可以把端口理解成这栋楼里的房间号。
IP 帮你找到这栋楼，端口帮你找到楼里具体哪个服务。
比如网站常用 80 和 443，MySQL 数据库常用 3306，Redis 常用 6379，SSH 远程登录常用 22。
如果数据库就运行在这台服务器上，应用连接 MySQL 时，可能会使用 127.0.0.1:3306 这个地址。
前面的 127.0.0.1 表示这台机器自己。
冒号后面的 3306 才是端口，告诉程序去找 MySQL 所在的那个“房间”。
那么，既然网站通常使用的是 80 和 443 端口，为什么你每次只输入 douyin.com，没有输入端口，也可以正常访问呢？
因为 80 是 HTTP 默认使用的端口，443 是 HTTPS 默认使用的端口。
浏览器会根据网址，自动使用对应的端口。
只有网站使用的不是默认端口时，才需要把端口号单独写出来。
所谓“开端口”“关端口”，说的就是外面能不能通过这个“房间号”，找到服务器里的服务。
不过，判断一个端口是不是真的暴露在公网，不能只看某一个防火墙开关。
程序监听的地址和 Docker 发布的端口，决定服务有没有对服务器外部开放。
服务器防火墙和云平台安全组，再决定公网请求能不能进来。
这里的安全组，就是云平台后台控制哪些端口可以从外面进入的规则。
所以修改完成以后，还要站在服务器外面再验证一次。
三、服务器上最该守住的四道门
第一道，也是最要命的一道，是数据库直接对着公网开放。
数据库里装着真实的用户和业务数据，通常没有必要让整个互联网都能直接连接。
如果应用和数据库在同一台服务器上，数据库可以只允许本机程序访问。
如果它们分开部署，也可以通过云平台的私有网络通信，或者只允许明确需要的服务器连接。
这样数据库仍然可以被应用访问，却不需要直接暴露给整个互联网。
还有些人为了测试功能或者排查问题，会临时打开数据库的公网访问权限，觉得问题找完以后，顺手再关上就行。
这种做法最不可取。
你打算只开一会儿，不代表这段时间没人扫描，更别说还有忘记关掉的可能。
真正危险的，是数据库监听了外部地址，服务器防火墙和云安全组也放行了它的端口。
如果使用 Docker，还要看容器有没有把数据库端口发布到服务器外部。
到了这一步，公网里的自动化程序就能找到它，再继续尝试密码或者利用已经公开的漏洞。
更稳妥的做法，是把开发、测试和生产环境分开。
开发和测试使用单独的数据库，生产数据库主要服务线上业务，不再拿它充当日常测试环境。
如果某个问题确实只能用生产环境里的数据复现，也不要为了图方便，把生产数据库直接开放到公网。
先从生产环境导出复现问题所必需的那部分数据。
这份数据离开生产环境以前，就要把姓名、手机号、邮箱、地址、令牌和支付信息等敏感内容替换或者删除。
这个过程就叫数据脱敏。
然后把处理后的数据，导入隔离的本地数据库或者测试数据库里排查。
问题解决以后，这份临时数据也要及时删除。
第二道，是远程登录服务器的 SSH。
SSH 是你从自己电脑进入服务器的通道，相当于服务器大门的钥匙。
如果 SSH 对公网开放，同时还允许使用密码登录，自动化程序就可能反复尝试账号和密码。
修改 SSH 端口，只能减少一部分无意义的扫描，不是主要防线。
更重要的是使用密钥登录。
先确认密钥确实可以正常登录。
确认以后，再关闭密码登录，同时禁止最高权限的 root 账号直接远程登录。
如果你有固定 IP 或可信网络，还可以进一步限制 SSH 只能从这些地方访问。
第三道，是把敏感文件放进了网站对外公开的目录。
服务器里有 .env、.git、日志和数据库备份，本身不代表一定有问题。
真正的问题，是这些文件如果能通过网址直接下载，里面的内容也会一起暴露。
这里面可能有数据库密码、支付密钥、AI 密钥，甚至整份用户数据。
别人拿你的密钥疯狂调用服务，最后账单还得你来付。
第四道，是没有用途的公网端口，以及存在已知高风险漏洞的旧服务。
一个服务根本不需要给外部使用，却一直对整个公网开放，就等于平白多留了一扇门。
如果这个服务当前使用的版本，刚好还有已经公开的高风险漏洞，攻击者甚至不需要猜中密码。
只要漏洞能够被利用，对方就可能借它进入服务器。
而且，这不是上线时检查一次就结束。
操作系统、Web 服务器、语言运行环境、数据库、缓存、Docker 和面板，后续都可能曝出新的漏洞。
真正要做的不是盲目追最新版，而是定期确认当前版本是否仍在维护，并及时安装官方安全更新。
更新以前先确认兼容性，备份配置和数据，准备好回退方案。
更新以后，再检查网站、后台和定时任务能不能正常运行。
好在，这四道门都可以让 AI 帮你一项项查清楚。
四、让 AI 先查清楚，再一项项处理
项目已经上线，服务器里跑的是真实业务。
所以第一轮只检查，不修改。
不要改防火墙，不要改 SSH，不要重启服务，也不要让 AI 自己连进生产服务器一通操作。
让 AI 给你只读命令，你自己执行，再把结果交给它分析。
不过，“只读”只代表命令不会修改服务器，不代表输出里没有密码、私钥和令牌。
结果发给 AI 之前，必须先把这些敏感内容遮住。
你可以把下面这段直接发给它：
“我的项目已经部署到 Linux 服务器并在正式运行。请帮我做一轮只读的服务器安全检查。
不要修改配置、安装软件、删除文件或重启服务。
先确认服务器系统和部署方式，再给我少量只读命令。
我来执行命令，并把脱敏后的结果发给你。
检查服务器实际监听了哪些端口、对应什么服务、监听的是本机还是外部地址。
如果使用 Docker，再检查哪些容器端口发布到了服务器外部。
检查数据库、缓存、SSH 和管理面板有没有不必要地暴露在公网。
提醒我去云平台后台核对安全组，不要把安全组和服务器防火墙当成同一层。
检查 .env、.git、日志和数据库备份能不能通过公开网址下载。
检查操作系统和关键运行组件是否仍在维护期内，有没有缺少重要安全更新。
涉及版本和漏洞时，以当前官方公告为准，无法确认的标为‘未验证’。
服务器内部检查完成后，再给我从自己电脑验证公网端口的方法，只检查我自己的 IP 和域名。
最后按风险高低列出问题，并写清证据、后果、处理方向和可能影响。
先不要修改，等我逐项确认。不要让我提供密码、私钥或完整令牌。”
拿到清单以后，别急着让 AI 一次性全改。
先让 AI 把每个问题用大白话讲清楚。
这扇门现在到底有没有对公网打开，证据是什么，关掉以后会不会影响正在使用的功能，都得说清楚。
哪一项 AI 自己都解释不清楚，就先别动。
确认确实需要处理，再一次只改一项。
你可以继续这样说：
“针对这条已经确认的问题：【粘贴单条问题】，请先给我处理方案，不要直接执行。
告诉我准备改什么、为什么要改、会影响哪些服务。
再说明修改前怎么备份当前配置、失败后怎么恢复，以及修改后怎么从服务器内部和外部分别验证。
如果涉及 SSH 或防火墙，先确认我有云平台控制台或其他救援入口，并提醒我保留当前 SSH 连接。
新的登录方式确认可用以后，才能关闭旧入口。
命令一次只给一小组。每执行完一步，等我把脱敏后的结果发给你确认，再继续下一步。”
否则，安全问题还没处理好，网站可能先被自己关停。
为了避免这种情况，每改完一项，都要重新验证：该关的入口，外面确实访问不到；正在使用的功能，也没有被误伤。
五、检查完成后，至少要看到这些结果
如果服务器运行的是普通网站，公网通常只需要开放网站使用的 80 和 443 端口。
SSH 如果必须对外开放，已经确认密钥可以正常登录。
确认以后，再关闭密码登录和 root 直接登录，并限制不必要的访问来源。
数据库和 Redis 只允许本机、私有网络或明确需要的服务器访问，而不是对整个公网开放。
.env、.git、日志和数据库备份，即使存在服务器里，也不能通过公开网址下载。
对公网运行的软件，已经按照实际版本和当前官方安全公告做过核对。
操作系统和承担项目运行的关键组件，都还在官方维护期内。
该安装的安全更新，已经在确认兼容性、备份和回退方案以后完成，更新后网站、后台和定时任务仍然正常。
最后再从服务器外面检查一次，确认公网真正能访问到的入口，和你的预期一致。
如果你使用的是可视化面板，这些检查很多可以在界面里完成。
但是你要知道的是，即便此刻你做到这些了，也只是关掉不该暴露的入口、缩小被攻击的范围，并不代表服务器从此绝对安全。
以后新增服务、修改 Docker 端口、调整安全组，或者运行环境曝出新的安全漏洞，都需要重新检查。
六、这些检查挡不住 DDoS
还有一种攻击，不是通过某个入口进入服务器，而是同时塞进来海量请求，把正常用户挤在外面。
这叫 DDoS。
真正的大流量攻击，通常要靠云厂商、CDN 或专门的上游防护处理，单靠服务器自己的防火墙扛不住。
前面这些检查，是在关掉不该暴露的入口，并不等于服务器已经具备抗 DDoS 能力。
七、最后
守服务器，听着吓人。
但互联网发展到今天，服务器安全早就不是一片没人走过的荒地。
这些坑，前人已经踩过无数遍。
操作系统、云平台和各种服务，也已经有了成熟的保护办法和检查方法。
你不需要自己发明一套安全方案，也不需要先把自己学成安全工程师。
把实际部署情况告诉 AI，让它按照成熟的做法给出检查命令、判断依据和处理方案。
你来执行，它来分析。
修改之前留好后路，修改以后再从公网验证。
这当然不能保证服务器永远不出问题，但足以帮你避开很多常见的坑。
所以真的不用太担心。
把门一扇一扇查清楚，你完全有能力把自己的服务器管起来。
