
故事是这样的。

我有个 Agent 团队，负责帮我处理各种自动化的事，有管情报的，有管电商的，有管内容创作的，分工挺细。

但我一直有个困扰，就是写代码这个活，一直没人专门干。

以前遇到要写代码的任务，都是我派给全栈开发，全栈开发同学啥都好，就是啥都管，又要做架构又要写方案又要管系统，任务一多就排队。

我就想，能不能招一个专职写代码的，不管别的，就埋头写，写完交付，简单粗暴。

然后我就真的招了一个，它叫 reasonix。

reasonix 是个独立编码执行 Agent，其实就是个纯代码执行器，重构、批量处理、代码生成、修复 bug，这些活它全包了。它的定位特别纯粹，就是只干编码这一件事。

配置也简单，deepseek-v4-flash 模型，YOLO 权限，啥都敢干，独立 workspace，有自己的小天地。

但真正让我头疼的，不是怎么配置它，而是怎么把它接进来。

reasonix 的接入方式，我前后折腾了三次，三次都翻车了，最后才找到一条稳定的路。

第一次，我打算用 ACP 协议手工对接。

ACP 是 Agent Client Protocol 的缩写，是个标准协议，reasonix 支持这个，我照着文档写了个 JSON-RPC 客户端，initialize 成功了，session 也建起来了，我以为成了。

结果 session 一 prompt，连接就提前关闭了，消息根本发不出去。

我又试了几次，每次都是同样的结果，initialize 能通，session 也能建，就是真正干活的时候断。

这条路走不通，我把它废弃了。

第二次，我打算用 OpenClaw 的 sessions_spawn 自建子会话。

reasonix 也是个 agent，理论上我可以 spawn 一个它的会话，然后让它干活。

结果发现，我的 worker 根本没有 sessions_spawn 这个工具，工具集限制死了，想用也用不了。

这条路也走不通。

第三次，我换了个思路，用 Workboard 卡片中转。

Workboard 是我的任务看板，我建一张卡片，指派给 reasonix，它认领之后执行卡片内容，干完汇报结果。

这个思路对了，但执行方式又有坑。

一开始我以为 reasonix 认领卡片后会自动启动程序本体去干活，结果它没有，它直接把卡片当普通会话，自己就开始写代码了。

后来我才明白，Workboard 卡片是 agent 唯一的任务输入，worker 启动只注入卡片内容，不会加载 agent 自己的 AGENTS.md 规则。你写在 reasonix 配置文件里的那些铁律，卡片路径下全都不生效。

所以解决办法是，建卡的时候，必须在卡片 notes 里把执行指令写清楚，让 reasonix 去调用程序本体，而不是自己动手。

我在 notes 里写的是，请通过 reasonix run 执行本任务，不要直接操作代码，运行命令是 /usr/bin/reasonix run --model deepseek-v4-flash --permission-mode auto --max-steps 100，把卡片完整内容作为任务传入。

这么一写，reasonix 认领卡片后就会乖乖调用程序本体去干活，而不是自己当普通会话写代码。

这个坑踩完之后，我算是彻底摸清了 reasonix 的路数，它就是个执行器，你给它清晰的指令，它跑任务，跑完回报，中间不掺和任何自己的判断。

到目前为止，reasonix 已经帮我干了不少活了，比如给虾米浏览器搭 BFF 直通渠道，四阶段交付，写了中转服务器、浏览器端入口、客户端插件，还修了五个 bug，全程没让我操过心。

还有知识库清理的技术评估、各种批量处理的活，都是它干的。

它干活有个特点，特别快，我实测过三路并行，三分半钟全跑完，这个速度人类程序员根本追不上。

当然它也不是完美的，它最大的问题是太老实，你说啥它干啥，如果指令没写清楚，它可能就理解偏了。

比如有一次我让它跑一个任务，它跑着跑着弹了个确认框，等用户确认，结果非交互环境里没人能确认，进程就退出了。它一看进程退了，就开始自己动手改代码，差点把活干岔了。

后来我在卡片模板里加了一条硬约束，ACP 进程等待交互确认后退出，必须携带自动确认参数重试，禁止直接修改代码，重试仍失败才允许标记 blocked 上报。

有了这条约束，它就老实多了。

还有个细节我觉得挺重要的，就是 reasonix 的上下文获取。

它是个独立 Agent，跟我的记忆系统不共享上下文，所以我给它接了 OpenViking 的 MCP，让它能检索共享记忆，用户画像、历史决策、踩坑经验都能查到。项目代码的话，我让它先读 README 和 AGENTS.md 再动手，避免盲改。

现在 reasonix 已经是我 Agent 团队里的正式一员了，专门负责写代码，我给它起的外号是，只会写代码的实习生。

为什么叫实习生呢，因为它跟实习生特别像，干活快，执行准，你说啥它干啥，但需要你把需求讲得非常清楚，差一个字它都可能理解偏。

不过话说回来，这恰恰是它的价值所在。

以前写代码的活都要占用全栈开发的时间，现在全部甩给 reasonix，全栈开发可以专心做架构和方案，两不耽误。

有时候我会想，我搭这个 Agent 团队，其实就是在复刻一个真实团队的运作方式，有负责动脑的，有负责动手的，有负责把关的，各司其职。

reasonix 就是那个动手的，它不聪明，但它听话，肯干，而且永不疲倦。

这大概就是 AI 时代团队的样子吧，一个人类，带着一群各有所长的 Agent，把活一件件干完。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。



我给我的 Agent 团队招了个只会写代码的实习生


故事是这样的。

前阵子我买了个云服务器，火山引擎的，2 核 3.8G 内存 20G 磁盘，配置不高，但对我来说够用了，就干三件事，frp 中转隧道、Caddy 反向代理、DDNS 动态解析。

一开始我挺心大的，觉得就一个个人服务器，上面也没啥值钱的东西，安全差不多得了。

然后现实就给我上了一课。

某个周五晚上，我突然发现 SSH 连不上服务器了，22 端口直接超时，ping 能通，端口全封。

我第一反应是，卧槽，被黑了？

后来一查才发现，是火山引擎的面板把 22 端口给封了，原因是检测到暴力破解，触发了自动防护。

我当时的心情挺复杂的，一方面庆幸云厂商有自动防护，另一方面又很无语，我才部署了几天，就开始有人扫我端口爆破我的 SSH 了？

这台服务器公网 IP 暴露在互联网上，就像在闹市区开了个门，门没锁好，路过的每个人都想推一下试试。

也就是从那天起，我开始认真对待这台服务器的安全，前后折腾了一周，把能想到的加固措施全做了一遍。

先说 SSH 这块。

22 端口被封了，我就把 SSH 端口换到了 8222，然后去改 sshd_config，结果发现改了没用，端口还是老的。

排查了半天，最后发现是 Ubuntu 24.04 的 systemd 激活模式在搞鬼，ssh.socket 激活模式下，sshd 根本不读 sshd_config 里的 Port 指令，你得去 /etc/systemd/system/ssh.socket.d/ 里加一个 override.conf，写上 ListenStream 才行。

这个坑挺隐蔽的，网上资料少，我翻了好几个论坛才找到答案。

端口换完之后，我又把密码登录关了，只留密钥登录，root 也禁止直接登录，必须用普通用户 su 上去。

然后装了个 fail2ban，三次失败就封 IP 24 小时。

这套组合拳下来，我的 SSH 才算是真正安全了。

不过光搞 SSH 还不够，我服务器上跑了好几个 Web 服务，Caddy 反代了一堆子域名，这些入口也得防护。

Caddy 那边我挂了 forward_auth 统一鉴权，所有子域名都要过一道认证才能访问，认证失败五次就封一小时，用的是 fail2ban 的 caddy-auth jail。

后来我又加了一个 caddy-login jail，专门盯主站的登录接口，5 次失败封 1 小时，防止有人拿脚本暴力撞库。

这里有个细节我觉得值得说，fail2ban 的 jail 配置，网上大部分教程都是抄来抄去的，用的都是默认的 sshd jail，很少有人认真去配 Web 层的防护。但对我来说，SSH 反而不是最危险的，毕竟我有密钥，最危险的反而是那些暴露在公网的 Web 登录页，那才是被爆破的重灾区。

然后是最硬核的一步，iptables 端口隔离。

我服务器上有 14 条 frp 隧道，映射了各种内部服务的端口，2222、4042、5000、8118、1933、8080、8888、4041、5174、18789、8456、9119、5678、5001，这些端口在云服务器上都是对外开放的，外面的人可以直接连。

想想就后怕，这些端口后面全是我的内部服务，等于把家里的门全敞开了。

我的做法是，用 iptables 把所有 frp 隧道端口都限制成只允许 127.0.0.1 访问，外网直连直接 DROP。反正 frp 隧道本身是服务器主动连出去的，外网用户访问也是先到 Caddy，再被转发到本地，根本不需要直接连这些端口。

这条规则加上去之后，我整个人都踏实了，14 个端口从完全暴露变成了完全封闭，外面扫描器看到的只是一堵墙。

iptables 规则写完之后记得持久化，我用的是 iptables-persistent + netfilter-persistent，重启不丢。

还有两个小细节，一个是 frps 的 Dashboard，7500 端口，原来是直接绑在公网上的，管理界面裸奔，我把它改成了只绑定 127.0.0.1，要看的时候用 SSH 隧道看。另一个是 frp 的 token，原来是个很弱的默认值，我换成了一个强随机的 64 位十六进制字符串。

做完这些，我又把 frp 从 0.62.0 升级到了 0.70.1，顺手把 journald 日志限制在 500MB 七天轮转，避免日志把磁盘塞爆。

这套流程走完，我再去看服务器日志，心态完全不一样了。

以前看 auth.log 是心惊肉跳的，几百条爆破尝试记录刷屏，现在再看，干干净净，偶尔有几条 fail2ban 的封禁记录，那都是被自动挡下来的。

说真的，这次被暴力破解的经历，虽然有点吓人，但收获特别大。我以前总觉得安全是那些大公司才需要操心的事，我一个个人开发者，服务器上就那么几个服务，谁看得上啊。

事实证明我错了，在互联网上，没有谁是无足轻重的。你的服务器暴露在公网上，就会被扫描，就会被爆破，这不是针对你个人，而是全网自动化脚本的例行公事。

你被攻击，不是因为你重要，而是因为你是公网上的一个 IP。

这次之后我总结了几条经验，算是给自己立了个规矩。

第一，任何暴露公网的服务，先想清楚要不要暴露，能不暴露就不暴露，能走内网就走内网。像我的 frp 隧道端口，其实根本不需要对公网开放，直接 iptables 封死就完事了。

第二，登录入口必须有防护，SSH 换端口加密钥加 fail2ban，Web 登录页加 fail2ban 盯防，这是最低配置，不是可选配置。

第三，安全配置做完一定要验证，改完 sshd_config 要重启服务测一下，iptables 规则加完要扫一下端口确认真的封了，别改了等于没改。

第四，也是最重要的一条，永远假设你的服务器正在被攻击，然后基于这个假设去做防御。

其实我后来想想，这次被爆破还挺及时的，它在我服务器上还没放什么重要东西的时候就发生了，等于提前给我敲了个警钟。

如果再过几个月，等我上面跑满了业务再被爆破，那损失就不只是换个端口这么简单了。

现在我每次部署新服务，都会下意识地问自己三个问题，这个服务必须暴露公网吗，它的入口有防护吗，它的端口被 iptables 管住了吗。

三个问题都答是，我才敢把服务上线。

有时候我也会想，做技术的人是不是都有点被害妄想，总觉得全世界都在盯着自己的服务器。

但转念一想，这不是被害妄想，这是对互联网的真实认知。你的服务器在公网上的每一秒，都在被无数脚本扫描着，这不是比喻，是事实。

与其被动挨打，不如主动防御，把门锁好，把窗户关严，把报警器装上，然后该干嘛干嘛。

毕竟，在问为什么会被黑之前，先问问自己，我锁门了吗。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。




一次暴力破解，让我把云服务器从里到外加固了一遍


故事是这样的。

今天下午 16 点 39 分，我把一条折腾了整整两天的通道彻底打通了，全链路实测通过的那一刻，我坐在电脑前说了句，成了。

这条通道叫 BFF，全称 Backend For Frontend，听起来特别唬人，其实干的事特别朴素，就是让 AI 直接操控浏览器。

我有个浏览器叫虾米，是个 Chrome 扩展，挂在浏览器里帮我干各种活，采集数据、投广告、管店铺。这玩意跟了我挺久，从 v5 一路迭代到 v6，功能越来越全，但我一直觉得哪里不对劲。

不对劲的地方在于，它跟我说话的方式太绕了。

以前虾米只能通过飞书跟我对话，我在飞书里发消息，它收到消息再执行，一来一回，中间隔着一层聊天软件。慢不说，还特别脆，飞书消息队列那种串行机制，一个活干完下一个才能上，中间要是断了还得重来，时间全耗在等上了。

我寻思，为啥不能搞一条直连通道，让 AI 直接把手伸进浏览器里呢。

然后就有了这个 BFF 直通渠道。

这条通道长什么样，说起来也简单，就三层。

最上面是 Agent 这端，装了一个叫 bff-client 的小插件，我这边调工具，它就往中间服务器发请求。中间是一台 Python 写的 WebSocket 中转服务器，叫 bff-server，跑在 19777 端口，负责认证、路由、排队。最下面是虾米扩展本身，它连上服务器，等着接活。

干活的时候流程是这样的，我在 Agent 里调一个 bffToolCall，说帮我打开某个网页，请求就到服务器，服务器验一下身份，然后丢给虾米扩展，扩展收到指令，在浏览器里真刀真枪地执行，最后把结果原路传回来。

整个过程走的是 WebSocket，实时双向，不经过任何聊天软件。

就为这个直连，我前后折腾了两天，踩的坑能写满一屏。

先说第一个坑，版本升级把 API 干没了。

bff-server 用的是 Python 的 websockets 库，一开始写的时候是按老版本写的，结果一跑就炸，报错说 send_json 不存在。

查了一下，17.0.1 版本把这个方法移除了，得改成 send(json.dumps(...))。

行，改。

改完又炸，process_request 的签名也变了，老版本返回三元组，新版本要返回 Response 对象，而且还得是 async 的。

行，继续改。

这种坑属于那种，你看着报错就知道是版本问题，但版本升级文档写得跟没写一样，全靠自己试。我一边改一边想，这大概就是维护开源依赖的宿命吧，它升级的时候可不会管你下游死活得。

然后是第二个坑，认证永远失败，查了半天发现是缺一个字段。

这个坑最阴。

两端都连上了，服务器也收到连接了，但客户端那边永远显示认证失败，试了各种姿势都不行。

我一度怀疑是 token 的问题，重新生成了好几个，都不行。最后把两端的代码摊开一行行对，才发现服务器返回的认证响应里少了一个 method 字段。

客户端是按 method 等于 auth 来识别认证响应的，服务器没返回这个字段，客户端就永远等不到认证结果。

就少一个字段，两边空转了半天。

这个事让我特别有感触，很多时候系统对不上，不是逻辑多复杂，就是接口契约两边没对齐，一个字段的差距，就是天壤之别。

基础链路通了之后，我以为差不多了，结果拉去真实 Chrome 一测，又爆出来五个 bug，一个比一个骚。

第一个是测试端口冲突，pytest 用固定端口跑并发，直接 Errno 98，改成自动随机端口才好。

第二个是幽灵连接，旧扩展连接失联了，但服务器不知道，新连接一注册，两条连接就打架。修复方式很暴力，注册新连接的时候强制把旧的关掉，简单粗暴，但管用。

第三个是队列丢消息，发送的时候一异常，消息就没了。修复是在发送异常时把消息放回队列，不丢。

第四个最有意思，保活 alarm 的周期设成了 0.4 分钟，结果 Chrome 扩展的 alarm 有最小合法值，0.4 分钟太短，直接被判非法。改成 0.5 分钟就好了。

第五个是 read_page 返回「标题未知」，原因是扩展刷新之后，旧标签页的 content script 没重新注入，而提取页面数据的函数没有重试机制。加了个 4 次乘以 500 毫秒的重试，跟执行其他动作对齐，就好了。

这五个 bug，每一个单拎出来都不算大，但合在一起就是一句话，真实环境永远是测试环境的爹。

你单测写得再漂亮，代码 review 再严格，拉到真实浏览器里一跑，该炸还是炸。这大概就是做浏览器自动化的宿命，你永远不知道用户的环境里藏着什么幺蛾子。

说到这我得讲一下我自己的一点点小坚持，就是这套东西的可靠性是拿测试堆出来的。

主仓库的 vitest 测试 171 个，全绿。服务器的 pytest 测试 17 个，全绿。bff-client 的测试 9 个，全绿。加起来快两百个用例，覆盖了认证、排队、超时、断线重连、并发、参数错误这些场景。

有人可能觉得，一个浏览器扩展搞两百个测试是不是有点过度了，但我的想法是，这种东西出一次 bug 的代价，比你写两百个测试的代价大得多。你想想，它是在真实浏览器里干活的，一旦在线上翻车，轻则数据采错，重则投放搞砸，那都是真金白银。

所以宁可测试写得多一点，也别让 bug 跑到线上去。

那为什么我觉得这条路值得走呢，说到底，BFF 直通渠道解决的是一个特别基础的问题，AI 怎么跟真实世界交互。

以前 AI 是隔着一层聊天软件跟浏览器对话，指令要翻译，结果要转述，中间任何一环断了，整个链路就废了。

现在直连了，AI 调工具，浏览器执行，结果原路返回，一气呵成。

我测了几个真实操作，打开网页、读取页面内容、获取属性、滚动页面，全部稳定通过。而且是在真实 Chrome 上跑的，不是模拟器，不是 mock，是真的把扩展装进浏览器里，一个指令一个指令地试。

那一刻我坐在电脑前，看着 AI 的指令在浏览器里变成真实的操作，页面自己打开了，内容自己读出来了，滚动自己滚了。

那个瞬间我就想，这才是 AI 该有的样子，不是停在对话框里跟你聊天，而是真的能伸手帮你干活。

说到这，我想到一个更大的东西。

我们一直在说 AI Agent，说智能体，但智能体的核心其实不是模型多聪明，而是它有多少只手可以伸出去，有多少条通道可以触达真实世界。

模型再聪明，如果只能输出文字，那它就是个聊天机器人。只有当你给它接上浏览器、接上代码环境、接上各种工具，它才真正开始干活。

BFF 这条通道，就是给虾米装的一只手。

而且这只手是双向的，AI 不仅能指挥浏览器，浏览器里的状态也能实时反馈给 AI，这就有意思了，AI 可以看着页面的变化做决策，像一个真的在操作电脑的人。

其实做这个事的过程中，我还想过一个更远的场景，就是多实例。

现在这套 BFF 是单浏览器跑的，但我的业务里其实有好几个浏览器要管，千川投放一个，抖店一个，直播一个，每个都是独立的账号体系。如果 BFF 能做成多实例的，一个中转服务器管多个浏览器，那 AI 就能在几个浏览器之间来回切换，像一个人同时盯着几台电脑干活一样。

这个方案我已经想好了，也写了评审，技术上完全可行，就等排期。

还有一个小细节我觉得值得说，就是这套通道的容错设计。

浏览器扩展有个头疼的问题，就是 Service Worker 会被 Chrome 回收，一回收，扩展就跟断了气一样。BFF 的解决方案是保活 alarm，每 0.5 分钟触发一次，让 Service Worker 一直活着。这个设计看着不起眼，但少了它，通道随时会断。

断线重连也是，指数退避，1 秒、2 秒、4 秒，一直退到 60 秒封顶，服务器一恢复，客户端自己就能爬回来，不用人工干预。

说实话我也不知道这套东西最后能长成什么样，但我知道一件事，今天下午 16 点 39 分，这条通道第一次全链路跑通的时候，我确定了一件事，方向是对的。

工具链的边界，就是 AI 能力的边界，而我在一点点把边界往外推。

可能很多朋友会问，这个东西我能不能用，能不能抄作业。我坦率的讲，这套代码就在我的仓库里，结构也清楚，三层架构，协议也简单，WebSocket 加 JSON，你只要有一个浏览器扩展，理论上都能照着搭一套。

但我得提醒一句，中间那些坑，版本兼容、字段对齐、真实环境翻车，一个都少不了，你踩的每一个坑，都会变成你代码里的一行注释。

这大概就是干这行的乐趣吧，永远有坑，永远在填坑，但每填完一个，系统就结实一分。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。


我给我的 AI 装了一条直达浏览器的通道

> 自驾 · 带弟弟 · 两天一夜

---

### 大概就是这样

7月30号下午从安溪出发，开车带弟弟去福州。

本来打算福州住一晚，第二天杀去平潭。结果31号临时改了主意，直接从福州回安溪了。

虽然就一天一夜，三坊七巷那灯笼是真好看，达明美食街人也够多——油钱不亏。

---

### Day 1 · 7月30号 — 到福州

**出发**

弟弟前一天过来找我，车上多个人，路上没那么闷。

**到酒店**

下午四点半左右到，住五一广场附近。放了个包就出门了。

**三坊七巷 & 达明美食街**

晚上直奔三坊七巷。

主街灯笼亮起来的时候，确实有点东西。但我更喜欢钻巷子——安静，灯光打在老墙上，比主街有味道。

然后晃到达明美食街。人是真的多，挤着走。摊位一个挨一个，看啥都想买，走一路吃一路。

> 南后街灯笼夜景值得蹲，巷子里比主街好看。

---

### Day 2 · 7月31号 — 回安溪

本来这天的剧本是早上出发去平潭——68海里看海峡，仙人井看海蚀，长江澳风车田拍日落，晚上坛南湾蹲蓝眼泪。

结果临时取消，直接开车回安溪了。

平潭嘛，不急。下次。

---

### 吃了啥

达明美食街一路吃过去，具体吃了多少种我也记不清。反正就是边走边买边吃。

**路过没吃上的**

永和鱼丸排长队，看了眼走了。同利肉燕也是人太多。后街捞化听说本地人爱吃，没找着在哪。

老福州的荔枝肉、佛跳墙、芋泥——算了，一个人也吃不了多少，下次带人来再点。

**平潭的账先记着**

- 时来运转，说是地瓜丸
- 天长地久，油炸甜饺
- 八珍炒糕
- 海鲜排档

下回去平潭一起清算。

---

*2026-07-31*

福州之行 — 2026.07.30 笔记

# 网站安全扫描翻车实录：扫别人的服务器，发现自己的问题

## 起因

单纯就是想看看某个 IP 上跑了什么服务。

一个顺手：`nmap -sV 118.196.xxx.xxx`。

然后就发现了一个脏乱差的配景，也照见了自己运维上的漏洞。

---

## 第一印象

扫描结果出来的时候，我心里咯噔了一下：

```
PORT     STATE SERVICE
22/tcp   open  SSH
80/tcp   open  HTTP (Django/Waitress)
3389/tcp open  RDP (Windows)
```

三个端口，三个问题：

**SSH（22）** — 开着，但没有做 IP 白名单。暴露在公网的 SSH，默认已经是被暴力破解的高危对象。

**HTTP（80）** — Django 应用通过 Waitress 跑着。HTTP，不是 HTTPS。没有证书、没有加密、一切明文传输。

**RDP（3389）** — 这个是最让人不安的。Windows 远程桌面直接暴露在公网，而且端口是默认的 3389。在 2025 年，RDP 暴露公网几乎等于"欢迎爆破"。

---

## 事后复盘

这个服务器不是我的，但看到这个配置的第一反应是——**我自己的服务器是不是也有类似的问题？**

回去检查了一圈：

### 1. SSH 配置

```
# 原来没注意的设置
Port 22                          # 默认端口，每天被扫几百次
PermitRootLogin yes              # root 账户直接暴露
```

修复：
```
Port 高位数端口（如 62222）       # 换端口，95% 的扫描脚本就废了
PermitRootLogin no               # 禁止 root 登录
PasswordAuthentication no        # 只允许密钥登录
Fail2Ban                         # 三次失败自动封 IP
```

换了端口之后，/var/log/auth.log 里的暴力尝试记录从每天几百条降到了零。

### 2. HTTPS

之前一直觉得"反正是个人博客/内部工具，HTTPS 无所谓"。

但仔细想想：如果登录表单没有加密，密码在公网上就是裸奔。何况我现在还在上面跑 Agent 系统、API 服务。

```
现状：Nginx + Let's Encrypt + certbot
效果：全站 HTTPS，自动续期
成本：0 元
投入时间：20 分钟
```

这件事最讽刺的地方是——运维了这么久，一直觉得"搞定 HTTPS"是个麻烦事，结果动手之后 20 分钟就搞完了。**很多安全坑不是因为难，而是因为不想动。**

### 3. RDP 防护

Windows 的 RDP 暴露问题：如果非要用 RDP 远程管理，至少应该做到：

- 换端口（非 3389）
- 加 VPN / 跳板机，不直接暴露公网
- 网络级认证（NLA）强制开启
- 强密码 + 账户锁定策略

最保险的方案：关掉公网 RDP，通过 WireGuard/OpenVPN 进内网再连。

---

## 学到的几件事

### 1. 知道有小偷和锁好门是两回事

安全知识大家都知道——SSH 换端口、关密码登录、开 HTTPS。但知道和做到之间的 gap，往往是因为"先这样吧，回头再搞"。这个"回头"可能永远不来。

### 2. 扫描别人之前，先扫自己

这次本来只是想看看一个陌生服务，结果最大的收获是发现自己的一堆漏洞。建议每个人都做一次：**用 nmap 扫一下自己的公网 IP 暴露了哪些端口。** 结果通常比预想的要多。

### 3. 安全不是流水线，是习惯

```
坏习惯：部署服务 → 能用就行 → 忘了 → 出事了才补救
好习惯：部署服务 → 做安全基线检查 → 定期自动扫描 → 告警处理
```

### 4. 最便宜的防护

最便宜的防护措施 LIST：
- ✅ SSH 换端口（免费，10 分钟）
- ✅ 关密码登录，用密钥（免费，5 分钟）
- ✅ Let's Encrypt 全站 HTTPS（免费，20 分钟）
- ✅ Fail2Ban（免费，15 分钟）
- ✅ 不暴露 RDP 到公网（免费）
- ✅ 定期 nmap 自检（免费，2 分钟跑完）

**以上全部加起来的时间成本：不到 1 小时。全部免费。**

---

## 最终状态

那个被扫的服务器后来怎么样了？我不知道，我也没义务通知对方——毕竟我只是路过看了一眼公网上公开暴露的服务。

但这个教训我记住了。

**在问"为什么会被黑"之前，先问问自己：我锁门了吗？**

---

## P.S.

这篇写出来不是为了装"我很懂安全"，恰恰相反——这件事证明了我之前也不懂。分享出来只是想说：安全其实没那么难，难的是迈出第一步。

从关掉 SSH 密码登录开始吧。