自从《网站已迁移至自建 NAS 服务器》之后，我始终没能抽出完整时间，好好梳理一篇关于内网穿透的实操说明。此前依赖的飞牛系统，仅能覆盖 NAS 内部环境的穿透需求，对于后续额外部署的各类私人服务，始终无法实现稳定的远程落地。我也不想为了适配多服务访问而开放过多端口，避免带来不必要的安全风险。
期间我也对比过不少穿透方案，无论免费还是付费类型均有诸多限制，比如：域名备案，成本过高，流量配额不足，始终难以兼顾 “易用性、安全性与性价比”。综合考量后，最终选择了 Cloudflare Tunnels 作为核心穿透方案。尽管受国内网络环境客观影响，可能会出现延迟、阻断等问题，但经过优选地址的链路优化后，不仅能稳稳支撑网站正常运行，还能为 NAS 额外增加一条负载线路，完美平衡了安全性、可用性还能降低不少成本。
之前写过一篇《使用 Nginx 反代 Google Analytics 加速访问》通过在 nginx 配置文件中设置替换规则，将脚本内的 /g/collect 网址替换为反代服务器的地址，从而实现数据的转发 。然而，随着 Google Analytics 脚本的更新以及内部变量的动态更新，其网址结构也可能发生变化。
因我将服务器全面迁移至本地环境，反带时需要先让 Google Analytics 经过本地路由搭建的代理进行访问。但代理的稳定性一直是一个难题，尤其是在网络环境复杂的情况下，代理经常会出现连接中断、延迟过高的问题，而且，代理的不稳定还会导致数据丢失，因为当代理连接中断时，正在上报的数据可能会被丢弃，从而影响数据的完整性。
近期给博客更新主题功能时，在边栏显示文章分类环节遇到了个小困扰。我使用的是官方默认主题提供的 listCategories(); 函数，它能正常输出所有分类，但由于我的“强迫症”原因，提前预留了 100 个分类，目的是防止后续标签占用数据表而导致分类 ID 隔断不连续，但这就出现了一个明显问题：该函数会把未启用的分类也一并列出。
自 2016 年注册域名以来，我一直在探索各种网站托管解决方案，从最初的虚拟主机到后来的云服务器，经历了老薛虚拟主机、DigitalOcean、Vultr、Linode、Google Cloud、Amazon Web Services 以及搬瓦工等多个平台。然而，在国内复杂的网络环境下，这些服务器都或多或少地存在一些问题，例如网络不稳定、延迟高、甚至出现 TLS 阻断等情况，严重影响了网站的访问体验。
网站虽然没访问量，但一直使用 Google Analytics 做为统计，近期收到 Google 通知 Universal Analytics 即将停止服务将由 Google Analytics 4 做为新的迭代方案。在更替使用 GA4 过程中前端统计代码和旧版差别不大，最大区别就是 ID 格式已经变更了，后端接口也有小改动。