阿里云 + WSL + Tailscale:我没买第二台服务器,低成本把博客系统部署上线了

目录 0. 项目内容 需求说明 第一步:先了解该项目的整体软件架构组成 关于数据库的说明 任务拆解 一、背景:我为什么不买第二台服务器 二、项目架构 2.1 Tailscale 在这里起什么作用 2.2 两台机器的角色分工 2.3 架构 2.4 五个关键设计决策 三、实施过程 3.0 修改主机名 3.1 node1 安装相关软件 3.2 node2 上面相关软件的安装 3.3 安装 Tomcat 四、测试 nginx 反向代理和 node2 的博客访问 验收清单 五、遇到的问题以及解决思路 5.1 JDK 安装包版本号不兼容 5.2 数据库的导入顺序 5.3 JDK 环境变量问题 5.4 WSL 里 ssh node2 被"掐断",IP 却是 198.18.0.22 5.5 Tailscale 的 DNS 问题 总结与思考 阅读范围:本篇只写博客系统本身的搭建与排错。报警部分虽然已经跑起来了,但那是我借助 AI 助手完成的,里面不少逻辑我还没吃透;等我把它研究清楚、自己亲手重搭一遍,再单独写一篇。这个项目我会拆成几篇来写,本篇是其中一篇。 本篇不展开、放到下一篇的:Prometheus / Grafana 监控栈与 node_exporter 采集、alert-check 告警(钉钉 + 邮件)、mysql-backup 备份、tailscale-watchdog 自愈、云监控兜底;以及 Tomcat 的 systemd 托管与 JVM 参数、Nginx 的主备切换与超时压缩。 ...

October 10, 2026 · 6 分钟 · 1242 字

一次"钻牛角尖"的 Linux 实践:清空目录,到底该用 `rm -rf /*` 还是 `find ... -exec rm -rf {} +`?

目录 ⚠️ 先看安全警告 一、最朴素的写法:rm -rf /root/* 二、先分清:-maxdepth 限制的是 find,不是 rm 三、-delete:另一种清空方式,但差别不小 四、我踩的最大一个坑:想用 grep 过滤 find 的结果 为什么会错? xargs 本身也不安全 五、怎样真正地"反选隐藏项”? 六、find ... ! -name '.*' -exec rm -rf {} + 和 rm -rf /root/* 到底啥区别 七、再进一步:去掉 -maxdepth 1 会怎样? 八、又一个"看起来很聪明"的写法:ls -a | grep -vE '^\.+' | xargs rm -rf 问题一(致命):ls 输出的是"显示名",不是"可操作的路径" 问题二:grep -vE '^\.+' 排除的是所有隐藏项,不只是 . 和 .. 问题三:xargs 默认按空白拆分,文件名有空格就出事 问题四:以 - 开头的文件名会被 rm 当成选项 正确写法对比 九、我最后总结出的两套安全写法 1. 清空目录下所有内容(含隐藏项),保留目录本身 2. 只清除非隐藏内容,保留第一层隐藏项 十、我算不算钻牛角尖? 十一、关于"培训课为什么不讲这个" 总结 起因很简单:我想把 /root 目录里的东西清空,但保留 /root 本身。 结果一路从 rm -rf 研究到 find 的 -mindepth、-maxdepth、-delete,还踩了个"用 grep 过滤文件名"的大坑。 这篇文章就是这次探究的完整记录。 ...

September 28, 2026 · 6 分钟 · 1152 字

grep 的引号、反斜杠与正则方言:一次讲清我踩过的坑

目录 1. 问题背景 1.1 先准备一份测试数据 1.2 第一条命令 2. 先记住一件事:你敲的字符,要过两道关卡 3. 疑惑一:引号加不加、加哪种,到底有没有区别 3.1 简单字符串:结果一样,但原因值得知道 3.2 包含空格:Shell 会把一个参数切成两个 3.3 包含通配符:Shell 会先把 *.txt 展开 3.4 包含变量 $:双引号会展开,单引号不会 3.5 三种写法小结 4. 疑惑二:/example/ 在 grep 里为什么不好使 4.1 现象 4.2 原因:/ 不是 grep 的定界符 4.3 顺带踩的大坑:命令敲下去"没反应" 4.4 续行符:\ 放在什么位置才不翻车 5. 疑惑三:都是反斜杠,为什么有的匹配有的不匹配 5.1 三方对照表 5.2 三条核心原则 6. 疑惑四:+ 在 BRE 和 ERE 里完全是两回事 6.1 打开 ERE 的开关是 -E 6.2 \d 为什么用不了:这是 -P 的事 7. 疑惑五:为什么两条不同的命令,结果一模一样 7.1 先看一个坑:字符集 [example]+ 7.2 分组 (example)+ 和字面量 example 7.3 照妖镜 -o:把藏起来的差别照出来 8. 疑惑六:grep -w 和 \b 是一回事吗 9. 疑惑七:grep 和 awk 的边界在哪 10. 总结与速查表 摘要:这篇文章记录我复习 Linux grep 时踩过的一串坑:引号加不加到底有没有区别、反斜杠什么时候生效什么时候被吃掉、/example/ 为什么在 grep 里不好使、命令敲下去为什么"没反应",以及 BRE / ERE / PCRE 三套方言的区别。全文按「现象 → 原因 → 结论」组织,一共 7 个疑惑,末尾附一张速查表。 ...

September 13, 2026 · 8 分钟 · 1500 字

仅主机 node 能 ping 通 jumper,却同步不上 NTP?删掉一行公网 pool 就好了——chrony 选源逻辑排错全过程

目录 0. 先看答案(赶时间的人只看这一节) 1. 实验环境 2. 现象复现(问题长什么样) 2.1 node1_copy 上:ping 通 2.2 node1_copy 上:NTP 同步失败 2.3 对照:WSL 里同样混配公网源,却正常 3. 排错总思路:把链路分层,一层层排除 4. 排查过程(每一步:命令 + 输出 + 解读) 4.1 第 1 层:先排除客户端 4.2 第 2 层:确认 jumper 的 NTP 服务到底通不通(关键一步) 4.2.1 宿主机上,用 w32tm 对 jumper 三个 IP 发 NTP 探测 4.2.2 再从 WSL 里发一个「手工构造」的原始 NTP 请求 4.3 第 3 层:模拟「仅主机网段」的源 IP 去访问,排除防火墙 / allow 在拦 4.4 第 4 层:收窄到源头——node1_copy 自己的 chrony 配置 4.5 验证:删掉公网 pool 那一行,立刻恢复 5. 为什么删掉一行就好了?(核心原理,三个原因叠加) 5.1 原因一:仅主机节点没有公网出口,公网源「永远不可达」 5.2 原因二(重点中的重点):chrony 是「平滑优先」,不是「故障切换」 5.3 原因三:pool 是动态源,会不断「换人」,让选择过程更不稳定 5.4 为什么删掉那行就立刻 OK? 5.5 为什么 WSL 可以?(对照实验的真正价值) 6. 怎么彻底修好 & 加固 6.1 仅主机节点:只留内网源(本次修复) 6.2 以后 node2_copy 怎么做? 6.3 如果非要保留公网源做冗余,按推荐程度排序 7. 常用命令速查表(以后直接抄) 7.1 chrony 状态查看 7.2 chronyc sources 输出列含义(这次排错靠它) 7.3 服务管理 7.4 排查网络路径 8. 如果现象不一样:对照表(按你的现象找答案) 9. 复习要点(避坑清单) 前言 ...

August 26, 2026 · 8 分钟 · 1630 字

仅主机 node 能 ping 通 jumper,却同步不上 NTP?删掉一行公网 pool 就好了——chrony 选源逻辑排错全过程

目录 1. 实验环境与拓扑 2. 现象:ping 通,NTP 不通 3. 排查过程:一层一层剥开 3.1 第一层:是不是 MobaXterm / 客户端的问题? 3.2 第二层:jumper 的 NTP 服务到底通不通? 3.3 第三层:模拟「仅主机网段的源 IP」去访问,是不是防火墙 / allow 在拦? 3.4 收窄:问题只剩 node1_copy 自己 3.5 验证:删掉公网 pool 那一行 4. 为什么删掉一行就好了?(核心原理) 4.1 原因一:仅主机节点没有公网出口,公网源永远不可达 4.2 原因二:chrony 不是「故障切换」逻辑,而是「平滑优先」逻辑(重点) 4.3 原因三:pool 是动态源,会不断「换人」,让选择过程更不稳定 4.4 为什么删掉那行就立刻 OK? 4.5 为什么 WSL 可以?(对照组的价值) 5. 正确姿势与加固建议 6. 避坑清单(复习用) 前言 跟着黑马课程做到「时间同步」这一节,我的环境是上一篇文章里的那套拓扑:一台 jumper 双网卡/三网卡当网关,node1_copy、node2_copy 是仅主机模式的节点。 现象非常诡异:node1_copy 能 ping 通 jumper,但 chrony 就是同步不上 NTP;而同一台宿主机里的 WSL(AlmaLinux)里跑 chrony 却好好的,公网源都能用。 ...

August 26, 2026 · 5 分钟 · 874 字

VMware 仅主机 + NAT 模式下 iptables 转发失败的排错全过程(MASQUERADE 挂错网卡)

目录 1. 实验环境 2. 故障现象 3. 排查过程 3.1 检查默认网关 3.2 确认 node1 到 jumper 的内网连通性 3.3 确认 jumper 自己能上外网 3.4 确认内核转发已开启 3.5 确认 FORWARD 链放行 3.6 抓包定位(关键转折点) 3.7 查看 NAT 规则(真相浮出水面) 3.8 核对真实的外网网卡名 4. 根因分析 5. 正确配置(最终生效) 6. 避坑清单(收藏备用) 7. 写在最后 前言 今天上午做 VMware 内网流量转外网的实验,照着教程一行一行敲命令,结果 node 能 ping 通网关,却死活 ping 不通百度。 我查了路由表、翻了 iptables 规则、确认了内核转发、关了 firewalld……几乎把 Linux 网络栈翻了个底朝天,几度想直接跳过这个实验。直到最后敲下 ip route get 8.8.8.8,盯着输出沉默了三秒——教程里写的是 ens160,而我的外网网卡,叫 ens33。更讽刺的是,之前加过的重复规则把真正的问题掩盖了整整一上午。 一个网卡名的错位,一次规则的冗余,让我怀疑人生了大半天。如果你也在做 NAT 转发实验,遇到"node 能 ping 通网关却上不了外网",希望这篇排坑记录能帮你省下这几个小时——因为"低级错误"从来不低级,它只是隐蔽得恰到好处。 ...

August 18, 2026 · 5 分钟 · 1005 字
本站访客 · 访问量