配置了 RouterOS 端口转发后，从外网访问服务正常；但连在家里的 Wi-Fi 时，使用公网固定 IP 和同一个端口访问，浏览器一直加载，页面没有内容。直接使用服务器的内网 IP 和端口则能正常打开。
上游光猫持有公网固定 IP，并把入站连接通过 DMZ 转给 RouterOS。RouterOS 上也已经有对应的 TCP DNAT 规则，将外部端口转发到内网服务器。
这类现象很容易先归因于路由器不支持 NAT 回环（Hairpin NAT）。但这次检查发现，NAT 回环规则实际上已经存在；真正的问题是策略路由把流量送错了出口。
文中的公网 IP、内网网段、设备地址和端口均为示例，请替换成自己的配置。
随着 AI 编程代理大量参与开发，代码审查面对的最大问题已经从“如何审查一份代码”变成了“如何在代码数量快速增长时，合理分配有限的人类注意力”。
Claude Code 团队在官方博客中分享了他们的实践：不取消代码审查，而是把大部分机械性检查交给机器，把人类时间留给架构、风险和产品方向等更需要判断力的问题。
本文是对原文的中文整理与总结，并非官方翻译。原文：How the Claude Code team does code review。
MikroTik RouterOS 是一套非常强大的路由操作系统，但在日常使用中，总会遇到一些 RouterOS 原生功能不方便处理的需求：使用标准 Linux 命令排查网络、通过 SSH 执行自动化脚本、使用 curl/tcpdump/dig 诊断网络，或者运行轻量级 Python 和 Shell 工具。
RouterOS 7 提供了 Container 功能，可以在支持的硬件上运行 Linux 容器。我决定在两台 MikroTik RB5009 上分别部署 Debian 12，让路由器兼具 RouterOS 网络能力与 Linux 运维能力。
本文记录部署过程、关键配置、遇到的问题及解决方式。
手上的 SD-WAN iWAN 客户端(sdwand)官方只给了裸机部署方式：一个二进制+ 一份配置文件，配 systemd 拉起来就行。但我想把它塞进 MikroTik RouterOS的 /container 里跑——路由器本身就是流量的枢纽，隧道建在路由器自己的容器环境里，比额外接一台旁路设备更省事。
这个想法本身没问题，sdwand 装进 Debian 容器里确实能跑起来。真正麻烦的是后面那步：怎么让局域网里其他设备的流量，经过容器里的这条隧道出网。容器有自己独立的网络命名空间，RouterOS 的主路由表根本看不到容器内部那张隧道网卡，这中间要打通的环节比想象中多得多，而且一个坑套着下一个坑，最后那个根因差点让我以为是硬件问题。
最近给一台 2019 款 Mac Pro（MacPro7,1）安装 macOS 更新时，连续遇到了同一个严重问题：更新进行到重启阶段后无法正常完成，机身状态指示灯橙色闪烁，最后只能拔掉电源才能重新开机。系统虽然还能回到桌面，但版本没有更新成功。
这不是一次普通的下载失败。系统日志最终证明，真正失败的是 Apple T2 安全芯片内部的 BridgeOS 固件升级。通过另一台 Mac 执行一次不抹除数据的 DFU Revive 后，T2 固件成功更新，随后 macOS 也顺利完成升级。
今天回来,要帮同学远程运维一下之前的服务器(他忘记续费了),忽然发现运维脚本执行后没反应(往常1分钟一台跑完的).
手上有两个云盘：115 网盘存了大量影视资源，123 云盘有不错的带宽和直链能力。日常需求很简单——让 媒体库的文件,可以通过 115 和 123 的通道播放和下载。