内网资源加速可用Nginx自建私有CDN替代公有云CDN，通过边缘节点缓存、中心节点回源及轻量一致性机制实现低延迟高并发；核心在于合理缓存策略、清晰节点协同与可靠回源路径。
内网资源加速不一定要依赖公有云 CDN，用 Nginx 搭配自建私有云 CDN（如基于 OpenResty + Redis + Lua 的边缘缓存集群，或轻量级方案如 Nginx Proxy Cache + 内网多节点同步），完全可实现低延迟、高并发、可控性强的内网内容分发。关键不在组件多高级，而在缓存策略合理、节点协同清晰、回源路径可靠。
一、明确私有 CDN 架构与 Nginx 角色定位
典型内网私有 CDN 架构包含三类节点：
- 边缘节点（Edge）：部署在各办公区/机房前端，直面终端请求，由 Nginx 主导缓存与路由；
- 中心节点（Origin / Cache Hub）：统一存储原始资源（如静态文件服务器、内部对象存储），也承担二级缓存和缓存预热任务；
- 控制节点（可选）：负责缓存清理指令下发、健康检查汇总、热点统计——可用简单 HTTP API 或 Redis Pub/Sub 实现，非必需。
Nginx 在边缘节点中不只做反向代理，而是承担：缓存决策（Cache-Key 生成、过期判断）、缓存存储（proxy_cache）、跨节点缓存穿透防护（proxy_cache_lock）、以及基础灰度/AB 路由能力。
二、Nginx 边缘节点核心配置实录
以下为生产验证过的最小可行配置片段（/etc/nginx/conf.d/internal-cdn.conf），适配内网 HTTP 场景（如内部文档系统、前端构建产物、监控图表资源）：
proxy_cache_path /var/cache/nginx/cdn levels=1:2 keys_zone=CDN:256m inactive=3d max_size=20g use_temp_path=off;
<p>upstream origin_cluster {
server 192.168.10.100:8080; # 中心节点地址
keepalive 32;
}</p><p>server {
listen 80;
server_name cdn.internal;</p><pre class="brush:php;toolbar:false;"># 缓存 Key 定制：忽略无关参数，保留版本标识
proxy_cache_key "$scheme$request_method$host$uri$is_args$arg_v";
# 缓存策略：按响应头 + 手动规则双重控制
proxy_cache CDN;
proxy_cache_valid 200 302 1h;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_lock_timeout 5s;
# 防止缓存污染：不缓存带 Set-Cookie 或认证头的响应
proxy_ignore_headers Set-Cookie Cache-Control Expires;
proxy_hide_header Set-Cookie;
# 强制刷新支持（运维调试用）
location ~ \.refresh$ {
if ($arg_force = "1") {
add_header X-Cache-Status "BYPASS";
proxy_cache_bypass 1;
proxy_no_cache 1;
}
rewrite ^(.*)\.refresh$ $1 break;
}
location / {
proxy_pass http://origin_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}}
注意点：
-
proxy_cache_path 必须使用
use_temp_path=off减少磁盘 IO；inactive=3d表示 3 天未访问即自动淘汰，比仅靠 TTL 更稳妥； -
proxy_cache_key 中加入
$arg_v可支持前端通过?v=20240520控制版本，避免手动清缓存； - proxy_ignore_headers 是关键——内网服务常误设 Cache-Control:no-cache，需主动忽略才能启用 Nginx 缓存；
-
.refresh 后缀是实用技巧：访问
/js/app.js.refresh?force=1即可强制绕过缓存拉取最新版，无需重启或调 API。
三、多边缘节点缓存一致性简易保障法
私有 CDN 不追求强一致性，但需避免“同资源不同节点返回不同内容”的尴尬。推荐两种轻量方案：
-
时间戳+中心校验：所有边缘节点定时（如每 5 分钟）向中心节点 GET 一个
/cache-manifest.json，其中含各资源最后更新时间。若本地缓存时间早于该值，自动触发proxy_cache_purge（需加载 ngx_cache_purge 模块）； -
事件驱动广播：中心节点在资源更新后，向 Redis 发布消息
PUBLISH cdn:purge "js/app.js"；各边缘节点运行轻量 Lua 脚本监听（OpenResty 环境下），收到即执行 purge 操作——无中心依赖，扩展性好。
不建议直接 NFS 共享 cache_path：IO 瓶颈明显，且 Nginx cache manager 不支持多进程并发写同一目录。
四、真实场景调优建议
根据某 500 人研发团队内网实测反馈，以下调整显著提升命中率与稳定性：
- 对
.js/.css/.woff2/.png等静态资源，增加proxy_cache_min_uses 3;，防止冷门资源挤占缓存空间； - 开启
gzip_static on;并预压缩资源，让 Nginx 直接返回 .gz 文件，减少 CPU 压缩开销； - 用
log_format加入$upstream_cache_status字段，快速识别 HIT/MISS/EXPIRED/BYPASS，排查缓存失效根因； - 限制单 IP 连接数：
limit_conn perip 16;防止个别终端刷爆连接，影响整体响应。
不复杂但容易忽略。内网加速的本质，是把“就近”和“就缓存”真正落地，而不是堆功能。
