碎碎念
这波网络架构的大改,纯粹是被现实逼出来的。
之前趁着阿里云的新用户优惠,79块钱搞了一台 200M 带宽、2C2G 的轻量应用服务器。这机器用来做公网入口简直起飞,但一年到期后,续费价格直接翻了几倍。权衡之下,我买了一台 99 元(续费同价)的 2C2G3M 服务器来接班。


计算资源倒是没降级,但这 3Mbps 的上行带宽 作为整套系统的出口,直接成了致命瓶颈。博客里稍微高清一点的图片,加载起来就全是“转圈圈”。之前虽然写过一篇《用 JS 给图片强行直连的邪道方案》来缓解,但在 3M 的硬性物理限制面前,这种缝缝补补的体验依然很糟糕。
看着这可怜的加载速度,我突然想起了之前帮课题组处理境外数据库加速任务时部署的边缘计算方案(参考前文:课题组境外数据库加速部署记录)。
既然边缘节点能加速数据库,为什么不直接拿来缓存我的博客?手里刚好有之前白嫖的腾讯云 EdgeOne(EO),加上最近研究的免费获取阿里云 ESA 套餐的方法,我决定彻底抛弃云服务器中转,直接让边缘节点与我成都家里的物理机通信。
0x01 架构演进:从“集中中转”到“边缘直连”
为了讲清楚这套逻辑,我们对比一下新老网络拓扑:
老架构:流量全卡在云服务器(FRP内网穿透)
因为家庭宽带虽然有动态公网 IP,但 80 和 443 端口是被运营商物理封禁的。之前的做法是:
链路: 访客 (80/443) -> 云服务器 Nginx -> FRP Server -> FRP Client -> 家庭服务器。
问题: 云服务器(已备案)对外暴露标准端口并承载所有流量。不管家庭宽带的上传有多快,最终访客拿到的速度上限被死死卡在了云服务器那可怜的 3Mbps 上。
graph TD
%% 定义组件
User(("🌐 公网访客"))
subgraph Internet ["🌐 互联网 / 公网"]
direction TB
CloudVPS(["☁️ 云服务器 (端口 80/443 开放 / 已备案)"])
FRPS["[FRP Server]"]
NginxVPS["[Nginx 反向代理]"]
User ==>|"访问标准端口\n(HTTP 80 / HTTPS 443)"| NginxVPS
NginxVPS ==>|"内部流量转发"| FRPS
end
%% 致命带宽瓶颈部分
FRPS ==>|"⛔ 速度上限:3Mbps\n所有业务流量需加密中转"| FRPC
subgraph HomeNet ["🏠 家庭服务器 (家庭内网)"]
direction TB
FRPC["[FRP Client]"]
LocalServices["本地应用集群\n(如 Halo 博客 / Nginx 容器)"]
FRPC ==>|"端口映射分发"| LocalServices
end
%% ISPs Constraint annotation
note_isp["[运营商限制]\n物理封禁家用宽带 80/443 端口\n导致域名解析到家宽 IP 无法提供 Web 服务"]-.->FRPC
%% 样式美化
classDef bottleneck fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#c62828,font-weight:bold;
classDef vps fill:#f0f4c3,stroke:#827717,stroke-width:1px,color:#33691e;
classDef home fill:#e8f5e9,stroke:#388e3c,stroke-width:1px,color:#1b5e20;
classDef public fill:#e3f2fd,stroke:#1565c0,stroke-width:1px,color:#0d47a1;
classDef user fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#e65100;
class CloudVPS vps;
class HomeNet home;
class Internet public;
class FRPS,FRPC bottleneck;
class User user;新架构:边缘节点接管 80/443,高端口回源
新架构中,云服务器不再参与网站的流量分发:
家庭宽带侧: 继续保留动态公网 IP + DDNS,映射到一个专用子域名(如 home.yourdomain.com)。
路由映射 (NAT): 在家里的路由器上做端口转发,将外部的一个高危/非标准端口(比如 28443)转发到局域网内 Halo 博客的端口。
边缘加速侧 (ESA/EO): 访客直接访问主域名,请求命中 ESA/EO 的边缘节点。节点如果未命中缓存,则通过 home.yourdomain.com:28443 直接向我家里的物理机发起拉取请求。
核心优势: 访客走的是大厂边缘节点的 CDN 宽带,回源走的是我家庭宽带的上行,直接跳过了 3M 的云服务器!
graph TD
%% 定义组件
User(("🌐 公网访客"))
%% 边缘计算/加速层
subgraph EdgeNet ["⚡ 阿里云 ESA / 腾讯云 EO (边缘计算网络)"]
direction TB
dns_control["[域名托管 DNS 服务]"]
edge_node{{"엣 边缘计算节点\n(监听 80/443)"}}
cache_l1[("[L1 边缘缓存]")]
cache_l2[("[L2 区域缓存]")]
dns_control -.-> edge_node
edge_node -.-> cache_l1
edge_node -.-> cache_l2
cache_l1 ==>|"命中数据"| edge_node
cache_l2 ==>|"命中数据"| edge_node
end
%% 致命带宽瓶颈已移除
CloudVPS_off[/"<s>🚫 阿里云 3M 云服务器\n不再参与 Web 业务分发</s>"\]
-.-> dns_control
User ==>|"访问主域名\n(HTTP 80 / HTTPS 443端口)"| edge_node
edge_node == "极速返回\n无需回源" ==> User
%% 高端口回源路径
back_origin == "❌ 未命中缓存 / 动态请求\n利用 DDNS 解析域名向源站发起回源" ==> origin_path_high
origin_path_high == "🚀 高端口直连回源:\nhome.yourdomain.com:28443\n(跳过 3M 中转,直接榨干家宽上行)" ==> HomeRouter
subgraph HomeEnv ["🏠 家庭内网 (拥有 30M~50M 真实上行带宽)"]
direction TB
HomeRouter["家用路由器\n(NAT / 端口转发)"]
LocalServices["本地应用集群\n(如 Halo 博客 / Docker容器)"]
HomeRouter ==>|"转发外部 28443 端口到内网局域网 Halo 端口"| LocalServices
end
%% ISPs Constraint annotation
note_isp["[运营商限制]\n物理封禁家宽 80/443\n但高端口封禁不严格\n导致此架构跑通核心"]-.->HomeRouter
%% 样式美化
classDef edge fill:#e3f2fd,stroke:#1565c0,stroke-width:1px,color:#0d47a1,font-weight:bold;
classDef vps fill:#f0f4c3,stroke:#827717,stroke-width:1px,color:#33691e;
classDef home fill:#e8f5e9,stroke:#388e3c,stroke-width:1px,color:#1b5e20,font-weight:bold;
classDef bottleneck fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#c62828;
classDef removed fill:#f5f5f5,stroke:#bdbdbd,stroke-width:1px,color:#757575,stroke-dasharray: 5 5;
classDef highlight fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#e65100;
classDef cache fill:#e8f5e9,stroke:#a5d6a7,stroke-width:1px,color:#2e7d32;
class EdgeNet edge;
class HomeEnv home;
class CloudVPS_off,link_vps_off removed;
class edge_node,cache_l1,cache_l2 cache;
class User highlight;0x02 核心踩坑与配置细节
实际部署这套架构时,并不是简单填个 IP 就能跑通的,以下是我实操总结的几个关键点:
在 ESA 或 EO 的控制台中添加回源规则时:
回源地址: 绝对不能填当前的公网 IP,必须选择 域名回源,填入你的 DDNS 域名。这样哪怕家里 IP 变了,边缘节点依然能解析到最新地址。
回源端口: 填入你在路由器上暴露的非标准端口(例如 28443)。
回源 Host 设置(极易踩坑): 边缘节点向家里发起请求时,请求头里的 Host 必须重写为你的博客主域名(例如 yanchang.pw),而不是你的 DDNS 域名。否则家里的 Nginx/Halo 会因为匹配不到 Server Name 而报 404 或返回默认页面。

2. 回源协议与 SSL 证书
因为家里的 443 被封,我们只能用非标准端口。
3. Halo 动态博客的缓存规则调优
边缘加速的灵魂是缓存,但 Halo 是一个动态博客,全站缓存会导致后台无法登录或评论无法提交。需要在 ESA/EO 的“缓存规则”或“规则引擎”中做精细化配置:
绕过缓存 (Bypass): 针对 /admin*、/api*、/login* 等路径,设置为 不缓存 或直接回源。
强缓存 (Cache): 针对静态资源后缀(如 .jpg, .png, .css, .js, .woff2),强制在边缘节点缓存 30 天以上。这样文章里的那些大图,基本瞬间秒开。

0x03 3M 服务器的新归宿:带外管理跳板
完成了建站流量的重构后,那台 99 块钱的 3M 云服务器并没有吃灰。
它现在卸下了沉重的流量包袱,专注于作为整个 Homelab 集群的内网穿透跳板机。 我将家庭服务器的 SSH(22端口)、各种面板的管理端口,通过跳板机隐蔽地暴露出来。3Mbps 的带宽,用来敲终端命令、跑代码、看日志监控简直绰绰有余。
这样一来,对外的“业务流量”(博客)走了大厂的边缘计算,速度拉满;对内的“管理流量”(SSH/控制台)走独立公网 IP 的跳板机,物理隔离,既安全又稳定。
0x04 总结
对于咱们这种既要数据攥在自己手里(自建服务),又不想被昂贵的高带宽云主机持续“吸血”的折腾玩家来说,这套 “家庭动态公网IP + 高端口DDNS + 大厂边缘加速回源” 的组合拳,绝对是当前性价比极高的版本答案。
感谢各路云厂商的免费额度,让这台小机器和我的 Homelab 迎来了新生。
这样的语气和技术深度,更符合一个技术大佬做总结复盘的风格。你觉得这段博文中,是否需要我再帮你补充一段具体的 Nginx server 块配置示例,或者边缘节点规则引擎的具体配置代码,让这篇博客更加保姆级一点?