本来只是想修个 DNS 泄露，结果把整个 Hugo 博客装修了一遍

发表于 November 5, 2026 分类于

有时候，事情的发展就是这么离谱。

原本只是想给 Clash 加几条规则，顺便解决 DNS 和 WebRTC 泄露。结果一路折腾下来，不仅把代理配置修好了，还顺手给自己的 Hugo 博客换了套排版、加了目录和图片灯箱、改了暗色模式，最后甚至把主题拆出来，用 Git Submodule 独立维护。

开始时，我只想让 DNS 不泄露；结束时，我竟然又想写文章了。

一、一切从那张 DNS 检测截图开始

事情起因很普通：给 Mihomo Party 加载了 Niklaus88/Clash-Config 的 JS 覆写脚本。代理能用，公网出口也正常，可检测网站还是能看到国内 DNS，WebRTC 的 STUN 测试甚至返回了中国联通的公网 IP。

当时的第一反应是：不是已经开了全局代理吗，怎么还能这样？

后来才明白，网页出口 IP 正常，不等于 DNS 和 UDP 流量都按预期经过代理。更关键的是，这份脚本中的 WebRTC 防护依赖分流规则，而全局模式并不会按规则模式执行那些规则。

切回 规则（Rule）模式，再把 WebRTC防护 设为 REJECT-DROP，Mihomo Party 的检测终于符合预期：DNS 改为 Cloudflare，STUN 探测没有再返回真实公网 IP。

本以为到这里就结束了。

结果换到 FlClash 0.9.x，同一份脚本、同样的策略组，DNS 又显示中国联通。

二、FlClash 的问题，藏在严格路由里

一开始我怀疑 JS 覆写根本没把 DNS 配置写进去。翻开最终配置一看，fake-ip、Cloudflare/Google DoH 都在，甚至 dns-hijack 也配了。

问题不在于“有没有写 DNS”，而在于 Windows 11 上 TUN 接管和路由行为是否符合预期。

最后真正带来变化的操作，是在 FlClash 里开启 严格路由（strict-route），并补充了 TCP 53 的 DNS 劫持规则：

tun:
  enable: true
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

保存后重新检测，DNS 从中国联通变成了 Cloudflare；WebRTC 测试也变成了连接错误，没有再显示之前的真实公网 IP。

当然，这只是当时环境下的有效排查结果，不代表开启这些选项就能保证所有应用、所有协议绝对不会泄露。WebRTC 的“连接错误”也可能意味着 STUN 被主动拦截，并不是浏览器坏了。

更完整的配置步骤，我单独写在了上一篇：Windows 11 上 Mihomo Party 和 FlClash 的 DNS / WebRTC 泄露排查记录。

三、既然踩过坑，那就写篇博客吧

排查结束后，我觉得这种问题以后肯定还会遇到：重装系统、换机场、换客户端，任何一个环节都可能让之前的配置失效。

于是决定写篇博客，给未来的自己留份说明书。

文章写完，问题又来了：截图大小各不相同。DNS 检测图又宽又长，FlClash 设置图却比较窄；直接塞进 Markdown，整个页面忽大忽小。

于是开始改 Hugo 的 CSS。

先给图片加统一边框和间距，再调整 object-fit，确保截图不会被裁掉。接着发现文章正文太窄、标题断行不漂亮、代码块不够醒目、表格看起来也有点朴素……

这就像原本只是想换个灯泡，结果发现墙面颜色不对，顺手换了窗帘，最后连书桌都搬了。

四、Noteworthy 被我一点点改成了 Shape Noteworthy

我原来使用的是 Hugo 的 Noteworthy 主题。它简洁、安静，有一种老式个人博客的味道。我不想把它改成满屏动画的炫技页面，只希望它更适合中文技术文章。

于是逐步做了这些改动：

阅读排版：加宽正文，优化中文字体、标题层级和段落留白。
图片展示：截图按比例自适应，统一边框，点击能看大图。
长文阅读：增加文章目录，方便从 DNS 排查跳到 TUN 配置。
代码体验：代码块更清晰，还能一键复制。
主题外观：加入明暗模式，但把切换按钮放得低调一些，不打扰阅读。

改完再打开那篇排坑记录，感觉和之前完全不同。

文章内容没变多少，但终于有了“这是我自己的地方”的感觉。

五、真正麻烦的不是 CSS，而是怎么维护

刚开始的改法很直接：把 custom.scss 和 JS 放在博客源码仓库里。能用，部署也方便。

但改着改着，文件越来越多，新的问题出现了：以后是改博客，还是改主题？

恰好我之前已经 fork 了 hugo-theme-noteworthy。既然如此，不如让主题真正成为独立项目。

于是把样式、脚本和模板迁移进自己的主题仓库，再通过 Git Submodule 让博客引用它：

ixxmu.github.io.source/
├── content/                   # 文章
├── config.yaml                # 站点配置
├── themes/
│   └── hugo-theme-noteworthy/ # Git Submodule
└── .github/workflows/         # 自动部署

这里还有个很容易误会的地方：更新主题仓库，并不会自动更新博客使用的主题版本。 Submodule 锁定的是具体提交，不是“永远最新”。

以后升级主题，需要在博客仓库里更新引用：

git submodule update --remote themes/hugo-theme-noteworthy
git add themes/hugo-theme-noteworthy
git commit -m "Update theme"
git push

优点是版本可控，出问题也容易回退。

六、当然，中间也不是没有翻车

最典型的一次，GitHub Actions 直接报错：

TOCSS: failed to transform "css/main.scss"
"calc(100vw - 1275px)" is not a number for `min`

原因是我使用的 Hugo Extended 版本较旧，SCSS 编译器把 CSS 的 min() 当成了 Sass 数学函数。

修复思路并不复杂：不用那种写法，改成兼容性更稳的 width 和 max-width。

另一回，明明把主题的新文件推到 GitHub 了，博客却完全没变化。查了一圈才发现，不是 CSS 没生效，而是博客仓库仍然指向旧的 Submodule 提交。

这些坑本身不难，但它们很能说明一个道理：页面上看起来只是一点样式变化，背后可能串着构建工具、主题优先级、Git 引用和部署流程。

七、折腾的终点，居然是想写更多文章

到最后，我拥有了两个各司其职的仓库：博客源码负责文章，主题仓库负责外观和交互；GitHub Actions 负责把它们构建成网站。

比起某个按钮圆了几像素、某张截图多了多少留白，我更喜欢这种感觉：整套东西终于变得清楚、可控，而且属于自己。

有句话越想越有道理：人类终究还是视觉动物。

一个博客好不好看，当然不能代替文章本身的价值。但当你打开自己的页面，觉得标题舒服、图片顺眼、代码清楚、夜间阅读也不刺眼，就会更愿意把新学到的东西留下来。

也许个人博客最有意思的地方就在这里：它不只是发布文章的工具，也是一个可以被慢慢打磨的私人空间。

本来只是想修个 DNS 泄露。

没想到最后，连写作的动力都一起修好了。

相关项目：Clash-Config · Shape Noteworthy 主题 · 博客源码