在香港CMIN2服务器上部署网站后，如果出现“静态文件打开很快、动态页面首字节很慢”“偶发502/504”“开启缓存后页面内容不更新”或“压缩开启后CPU升高”等现象，问题通常不在某一个参数，而在连接复用、缓存命中、压缩范围和上游响应之间的配合。香港CMIN2服务器这一环境名称本身不能直接决定参数值，仍需要结合Nginx配置、网站类型、上游应用和实际请求耗时判断。

建议按照“先确认现象，再检查连接与静态资源，随后处理压缩，最后调整上游超时”的顺序操作。每次只修改一类参数，先执行配置检查，再平滑重载Nginx；如果结果变差，优先回滚最近一次改动，而不是继续叠加参数。

先建立基线和回滚点

以下命令适用于常见Linux系统，执行前需要具备sudo权限。先确认Nginx版本、编译模块、服务状态和有效配置，不要直接覆盖整个配置文件。

nginx -v
nginx -V 2>&1
sudo nginx -t
sudo systemctl status nginx --no-pager
sudo nginx -T > /tmp/nginx-effective.conf

预期结果是nginx -t显示语法检查成功，服务处于active (running)状态。nginx -T会展开include文件，适合确认某个location是否真正生效，但输出可能包含域名、路径或敏感配置，应限制文件权限并在排查后删除：

sudo chmod 600 /tmp/nginx-effective.conf

如果服务器不是通过systemd管理Nginx，应先核实服务管理方式，不要直接猜测启动命令。可以使用以下命令确认监听端口、进程和文件描述符限制：

sudo ss -lntp
systemctl show nginx -p LimitNOFILE

修改前，至少备份本次准备调整的站点配置文件。例如已有配置位于/etc/nginx/conf.d/site.conf时：

sudo cp -a /etc/nginx/conf.d/site.conf \
  /etc/nginx/conf.d/site.conf.bak.$(date +%Y%m%d%H%M%S)

备份文件只用于回滚当前改动，不建议在未确认文件内容的情况下覆盖整个/etc/nginx目录。

第一优先级：确认延迟发生在哪一层

先从客户端或香港CMIN2服务器本机发起基准请求。将域名和路径替换为实际网站地址，静态文件路径应选择一个确定存在的CSS或JS文件。

curl -sS -o /dev/null \
  -w 'code=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

curl -sS -o /dev/null \
  -w 'code=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/assets/app.css

结果可以先作如下判断：

• connect或TLS耗时明显偏高，而ttfb相对正常，优先检查监听、连接复用、TLS配置和客户端到服务器之间的连接情况，不要先调大上游超时。
• 连接建立很快，但HTML的ttfb较高，通常应检查上游应用处理、数据库调用或PHP-FPM等后端服务。
• 静态文件的ttfb和总耗时都偏高，检查文件是否命中本地静态location、是否被错误转发给上游，以及磁盘读取和响应头设置。
• 返回502时，常见原因是上游端口或Unix Socket不可用、响应格式异常或上游进程已退出；返回504时，常见原因是Nginx等待上游响应超时。
• 返回499通常表示客户端在Nginx完成响应前主动断开，不能单凭499就认定上游一定故障。

如果静态文件本应由Nginx直接返回，却在日志中出现上游耗时，往往是location匹配或root路径不符合预期。使用sudo nginx -T检查最终生效的server和location，比只查看某个片段文件更可靠。

第二优先级：调整连接复用，而不是盲目增加并发

连接参数需要同时考虑客户端连接、Nginx工作进程和上游连接。worker_connections并不只计算用户连接，反向代理场景中还要为上游连接、日志和其他文件描述符预留空间；它大于系统服务的文件描述符限制时，提升数值也不会自动带来收益。

可以在现有配置基础上核对以下参数。不要重复添加已有的events或http配置块，避免产生冲突。

events {
    worker_connections 1024;
}

http {
    sendfile on;
    tcp_nopush on;

    keepalive_timeout 15s;
    keepalive_requests 1000;
}

这些是可用于观察的起始值，不代表所有香港CMIN2服务器都应固定使用它们：

• keepalive_timeout控制客户端空闲连接保留时间。连接数和文件描述符压力较大时，可适当缩短；如果页面包含大量资源且反复建立连接，可在资源允许时适当延长。
• keepalive_requests限制单条持久连接承载的请求数量。过低会增加握手和连接建立次数，过高则应结合连接空闲时间和资源限制观察。
• sendfile适合由Nginx直接发送本地静态文件。若网站静态内容全部由对象存储或上游返回，该参数的作用范围就有限。
• tcp_nopush通常与sendfile配合用于发送文件响应，但应以实际响应时间和系统行为验证，不要仅凭开启状态判断性能。

如果使用反向代理，还可以为上游启用连接复用。前提是上游服务支持HTTP持久连接，并且已有的上游定义允许这样配置：

upstream app_backend {
    server 127.0.0.1:8080;
    keepalive 32;
}

server {
    location / {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        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_pass http://app_backend;
    }
}

如果上游并非127.0.0.1:8080，应以现有配置和实际监听结果为准。若启用后上游日志显示连接复用不兼容、连接长期占满或请求异常，应先移除keepalive和对应的HTTP/1.1设置，再重新验证。

第三优先级：先处理静态资源缓存

静态资源缓存通常是风险较低、收益容易验证的调整。CSS、JS、字体和图片应与HTML、登录态页面分开处理。

对于文件名带内容哈希的资源，例如app.8f31c.js，文件内容变化时URL也会变化，可以使用较长缓存时间：

location ~* \.(?:css|js|mjs|woff2?|ttf|png|jpg|jpeg|gif|svg|webp|ico)$ {
    try_files $uri =404;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

这段配置只适用于资源确实位于当前站点root目录，并且文件名会随内容发布而变化。如果仍使用固定文件名，例如app.js，不宜直接设置长期缓存，否则用户可能持续读取旧文件。可以改用较短缓存，或在发布时更新资源版本参数：

location ~* \.(?:css|js|mjs)$ {
    try_files $uri =404;
    add_header Cache-Control "public, max-age=604800";
}

HTML、管理后台、购物车、个人中心和带登录Cookie的响应不应套用公共静态缓存策略。try_files $uri =404的作用是文件不存在时直接返回404，避免错误地把不存在的静态资源转发给应用；如果现有网站依赖上游动态生成这些路径，则不能直接套用这条规则。

谨慎使用反向代理缓存

公共、可重复生成的GET响应可以使用proxy_cache，但必须排除登录态和个性化内容。以下示例需要放在适合的配置上下文中，其中缓存目录、缓存区大小和有效期应根据磁盘空间及内容更新频率调整：

# 放在 http 上下文中，并确保缓存目录具备Nginx可写权限
proxy_cache_path /var/cache/nginx/site
    levels=1:2
    keys_zone=site_cache:10m
    inactive=10m
    max_size=1g;

server {
    location /public/ {
        proxy_cache site_cache;
        proxy_cache_methods GET HEAD;

        proxy_cache_bypass $http_authorization $cookie_session;
        proxy_no_cache $http_authorization $cookie_session;
        proxy_no_cache $upstream_http_set_cookie;

        proxy_cache_valid 200 10m;
        proxy_pass http://app_backend;

        # 仅用于短期排查，确认后建议移除
        add_header X-Cache-Status $upstream_cache_status always;
    }
}

缓存区域应尽量只覆盖明确的公共路径。首次请求出现MISS是正常现象，后续相同请求出现HIT才说明缓存命中。若响应带有Set-Cookie、依赖Authorization请求头，或页面内容随用户变化，就不应仅凭响应状态为200而缓存。

如果资源更新后仍返回旧内容，先检查是否使用了长期缓存和固定URL，再通过修改资源版本号或采用经过验证的缓存清理方式处理。不要在生产环境中未经确认直接删除整个缓存目录，这可能造成瞬时回源和磁盘、上游负载上升。

第四优先级：压缩要限定类型和范围

Nginx内置gzip模块是否可用，应先通过nginx -V确认。Brotli通常需要额外模块，不能因为配置文件中写了相关指令就假定当前Nginx支持。

常见文本响应可以采用以下起始配置：

gzip on;
gzip_vary on;
gzip_min_length 1k;
gzip_comp_level 5;

gzip_types
    text/plain
    text/css
    text/xml
    application/xml
    application/json
    application/javascript
    application/x-javascript
    image/svg+xml;

压缩适合HTML、CSS、JavaScript、JSON、XML和SVG等文本内容，不需要对JPEG、PNG、WebP、MP4、ZIP等已经压缩或不适合再次压缩的文件重复处理。

参数调整时重点看两个结果：

• gzip_vary on会让响应包含Vary: Accept-Encoding，避免缓存把压缩版本错误提供给不支持压缩的客户端。
• gzip_min_length用于跳过过小响应，避免压缩计算本身抵消收益。
• gzip_comp_level越高通常越耗CPU，不能只追求更小的响应体。若开启压缩后CPU升高、动态请求排队，先降低压缩级别或缩小压缩类型范围。

使用以下命令验证客户端协商结果：

curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: gzip' \
  https://example.com/

curl --compressed -sS -o /dev/null \
  -w 'code=%{http_code} size=%{size_download} total=%{time_total}s\n' \
  https://example.com/

支持压缩的文本响应通常会看到Content-Encoding: gzip和Vary: Accept-Encoding。如果没有压缩，检查响应的Content-Type是否在gzip_types中、响应长度是否低于最小值，以及请求是否经过了预期的Nginx实例。对于上游已经设置压缩的响应，不要重复引入压缩链路，避免响应头和CPU消耗异常。

第五优先级：按上游阶段调整超时

超时参数必须建立在上游实际耗时之上。常用代理参数的含义不同：

• proxy_connect_timeout：Nginx与上游建立连接的等待时间。过高会让不可用的上游连接长时间占用请求。
• proxy_send_timeout：向上游发送请求数据时，两个写操作之间允许的间隔。
• proxy_read_timeout：等待上游返回数据时，两个读操作之间允许的间隔，并不等于整个响应只能持续这么久。
• send_timeout：Nginx向客户端发送响应时，两个写操作之间允许的间隔。

普通网页代理可以先采用较为保守的配置，再根据日志调整：

location / {
    proxy_connect_timeout 3s;
    proxy_send_timeout 30s;
    proxy_read_timeout 30s;
    send_timeout 30s;

    proxy_pass http://app_backend;
}

如果网站通过FastCGI连接应用，则应使用对应的FastCGI参数，而不是同时套用代理参数：

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    fastcgi_connect_timeout 3s;
    fastcgi_send_timeout 30s;
    fastcgi_read_timeout 30s;

    fastcgi_pass <沿用现有的PHP-FPM地址或Socket>;
}

<沿用现有的PHP-FPM地址或Socket>不是可直接复制的路径，应保留当前站点已经验证过的fastcgi_pass值。不同发行版和PHP版本的Socket路径可能不同，先从nginx -T或PHP-FPM服务配置中核实。

如果只有导出报表、文件生成或长轮询接口需要更长时间，应为该路径单独设置更大的proxy_read_timeout或fastcgi_read_timeout，不要把全站超时统一调到几分钟。统一放大超时只能延后报错，不能修复上游进程阻塞、数据库慢查询或应用死锁。

用上游耗时日志做结果分支

默认访问日志往往只能看到总耗时，建议在确认现有日志格式后增加上游计时字段。以下配置应放在http上下文中，日志文件路径使用现有站点配置中的路径，不要直接猜测：

log_format timing_main
    '$remote_addr "$request" status=$status '
    'request_time=$request_time '
    'upstream_status=$upstream_status '
    'upstream_connect_time=$upstream_connect_time '
    'upstream_header_time=$upstream_header_time '
    'upstream_response_time=$upstream_response_time '
    'cache_status=$upstream_cache_status';

配合错误日志，结果可以这样分支判断：

变更、验证与回滚

完成一组配置修改后，先检查语法，再平滑重载。reload不会像直接停止服务那样主动中断所有现有连接，适合普通Nginx配置变更。

sudo nginx -t
sudo systemctl reload nginx

预期是语法检查成功且命令无错误返回。若nginx -t失败，Nginx不会应用这次配置，不应继续执行重载。若重载后服务状态异常，可查看最近日志：

sudo systemctl status nginx --no-pager
sudo journalctl -u nginx -n 50 --no-pager

验证应至少覆盖四类请求：

1. 用curl -I或实际GET请求确认静态文件返回200，并检查Cache-Control是否符合文件命名策略。

2. 带Accept-Encoding: gzip请求文本页面，确认Content-Encoding和Vary是否正确。

3. 连续请求启用代理缓存的公共URL，确认第一次和后续请求的缓存状态变化，同时确认登录态页面没有被缓存。

4. 重新执行基准请求并对照ttfb、total、502/504数量和上游计时，判断改善是否真实存在。

如果修改后出现配置错误、静态文件变成404、登录页面返回公共内容或504数量增加，先恢复最近一次备份的对应文件，再执行检查和重载：

sudo cp -a /etc/nginx/conf.d/site.conf.bak.YYYYMMDDHHMMSS \
  /etc/nginx/conf.d/site.conf
sudo nginx -t
sudo systemctl reload nginx

备份文件名必须替换为实际生成的文件，恢复前确认其中没有覆盖其他人的并行配置。修复完成后，继续观察访问日志、错误日志、上游响应时间和缓存命中状态；只有在单项参数经过复测后，再进入下一轮调整。