nginx本身不自动同步文件，静态资源一致性依赖部署机制+缓存策略+路由控制协同实现：通过rsync+inotify推送构建产物并增量同步、url版本化（内容哈希）切断旧缓存、consistent_hash固定回源路由、gzip_static统一压缩响应。
Nginx 本身不自动同步文件或协调多节点状态，静态资源的一致性不是靠“Nginx 自动复制”，而是靠部署机制 + 缓存策略 + 路由控制三者协同实现。核心目标是：用户无论访问哪台 Nginx、哪个 CDN 节点，拿到的都是同一份正确、最新、格式一致的资源。
用 rsync + inotify 实现文件内容同步
多台 Nginx 服务器上的静态文件（如 JS/CSS/图片）必须物理一致，否则缓存再稳也白搭。推荐自动化方案： - 源服务器（CI/CD 或发布机）生成构建产物后，通过 rsync 推送至所有 Nginx 节点 - 配合 inotifywait 监听目录变更，触发增量同步，避免全量拷贝 - 使用 `-a --delete` 参数保证目标端与源端完全一致，包括权限、时间戳、软链接 - 传输走 SSH，无需额外服务，安全且兼容性强注意：不要依赖 scp 手动上传，也不要在各节点上单独 git pull —— 容易因分支、时间差、权限导致文件不一致。
用 URL 版本化切断旧缓存依赖
不靠“清缓存”，而让新资源天然走新路径，是最稳妥的一致性手段： - 构建时在文件名中嵌入内容哈希，例如 app.7f8a2c1e.js、style.b5d903ff.css - HTML 中引用该带哈希的路径，发布即生效 - Nginx location 只需简单匹配扩展名，无需修改配置或 reload - 浏览器、CDN、反向代理都会把新 URL 当作全新资源，旧缓存自然失效补充：若无法改文件名，可用统一版本参数，如 /logo.png?v=2.4.1，但需确保构建系统每次发布都更新该值。
用 consistent_hash 固定请求路由
当多台 Nginx 共享同一组后端源站（如对象存储或静态服务），需防止同一资源被不同 Nginx 反复回源、各自缓存不同副本： - 在 upstream 块中启用一致性哈希：hash $request_uri consistent;（Nginx 1.7.2+ 原生支持） - 使用 $request_uri（含查询参数）作为哈希键，精准绑定资源粒度 - 若参数含跟踪字段（如 ?utm_source=xxx），先用 map 归一化再哈希 - 避免混用 ip_hash 或 weight —— 它们与 consistent 模式冲突这样，/static/main.js?v=2.4.1 永远落到同一台 Nginx，它只需缓存一次，后续请求直接命中本地 cache，不重复拉取。
用 gzip_static + 固化缓存键保障压缩一致性
压缩版本若处理不当，会导致 CDN 缓存分裂或返回乱码： - 提前生成 .gz 文件（如 main.js → main.js.gz），与原文件同目录、同权限、mtime 尽量一致 - Nginx 启用 gzip_static on;，配合 try_files $uri.gz $uri =404 - CDN 回源时强制抹除 Accept-Encoding 头，Nginx 统一决策是否返回压缩体 - proxy_cache_key 设为 "$host$request_uri"，不包含 $http_accept_encoding这样，无论浏览器是否支持 gzip，对同一 URI 的请求都命中同一个缓存项，Nginx 内部按规则返回原始版或 .gz 版，响应体和响应头始终严格对应。
