重建体会

这次网站系统再次经历了全面调整——已经不记得是第几次了。

核心变化之一，是将建站系统从 WordPress 迁移到了 Halo。搬迁并非一时兴起，而是因为逐渐对 WordPress 感到“审美疲劳”：它主题虽多，但对个人博客的实际体验并不友好，显得有些“两面三刀”——表面丰富，内在却臃肿且过于商业化。最终，我以技术站点（https://ctuhub.top）先行试水，完成了这次切换。

目前（2025-12-29）网站仅公开了几篇近期文章，历史内容暂时存档，未来可能逐步发布，也可能永久沉淀。虽然网站主体已基本稳定，但整个系统仍在持续优化中，重点围绕以下三方面展开：

1. 全面强化安全措施
   所有后台登录及涉及敏感信息的子站服务，均已启用双因素认证（2FA），实行“账户密码 + 动态验证码”的双重登录验证，大幅提升访问控制的安全性。不过实施过程中也遇到一些“反骨仔”：

   • Authelia的自身上锁难题：作为统一认证中心的Authelia，其管理界面本身也暴露在外网，不得不应用自家的2FA进行保护——颇有几分自己给自己上锁的意味。

   • Vaultwarden的“罢工”困境：为密码库Vaultwarden启用2FA尤为棘手。这不仅会让部分浏览器插件和手机App无法正常工作，更曾直接导致Vaultwarden自身的登录功能完全“罢工”。

   最终，一个“天才般”的解决方案浮现：通过域名进行访问隔离。我为Vaultwarden设置了随机生成的子域名（不强制认证），而主域名则维持严格的2FA保护。这样一来，既保证了日常密码填充的便捷性，又为核心管理入口加上了牢固的锁。

2. 重构子站服务架构
   明确规划子站后续的工作流，将其归纳为 “收集 → 整理 → 发布” 的标准化框架，确保内容管理更清晰、高效。

3. 子域名体系的梳理与重构：为确保所有子域名命名规范统一且易于识别，对其命名规则进行了全面梳理与重构。这一调整影响范围较广，目前方案已制定，正待后续实施。

在技术部署上，原本致力于将所有应用容器化（基于 LXC），但在具体实践中遇到了挑战。尝试通过 NATAPP + NGINX 在单一 LXC 容器中部署服务时，发现 NGINX 无法准确判断访问来源（内网或外网）。原因是 NATAPP 基于 TCP 转发，无法传递访问者真实 IP；尽管其文档提及可通过 HTTP 头获取，实际测试并不可行。为此，不得不重新规划并创建了新的 LXC 容器，以保障整个容器化架构的协调与可维护性。

总的来说，本次调整不仅是技术栈的更换，更是对安全性、工作流和基础设施的一次系统性重构。后续仍会持续迭代，让这套系统更贴合个人使用习惯与长期需求。