可在 HTTP 请求处理阶段用 map 指令结合 $time_iso8601 实现时段分流，将时间映射为 offpeak、workhour、night 等标签，在 location 中用于限速、缓存、返回码等策略，避免在 if 中使用时间变量执行 proxy_pass 等不可靠操作。
不能在 SSL 层或连接建立阶段做时段判断，但可在 HTTP 请求处理阶段，结合 $time_iso8601 或 $date_gmt 变量配合 map 指令实现精准的时段分流与策略控制。核心是把“时间”当作一个可映射的请求特征，而非运行时条件分支。
用 map 提取并分类时间段
在 http 块中定义时间映射，将当前时间转为语义化标签（如 offpeak、workhour、night），避免在 location 中用 if 判断时间——Nginx 不支持在 if 中可靠使用时间变量：
- 匹配 ISO 8601 时间字符串中的小时部分：
map $time_iso8601 $time_period { "~^([0-9]{4}-[0-9]{2}-[0-9]{2})T(0[0-9]|1[0-1]):" "offpeak"; "~^([0-9]{4}-[0-9]{2}-[0-9]{2})T(1[2-7]):" "workhour"; "~^([0-9]{4}-[0-9]{2}-[0-9]{2})T(1[8-9]|2[0-3]|0[0-5]):" "night"; default "offpeak"; } - 注意：正则必须覆盖全 24 小时，且顺序影响匹配优先级；建议用
$time_local替代时需确保 Nginx 运行环境时区已设为业务所需（如export TZ=Asia/Shanghai）
按时段动态调整限速与响应行为
将 $time_period 用于限速、缓存、重定向等策略，实现资源调度层面的差异化：
- 非工作时间降低带宽限制：
limit_rate 128k;放在location /download/内，并配合limit_rate_after 1m;保障首屏体验 - 夜间关闭高开销功能：对
/api/analytics路径，用if ($time_period = "night") { return 403; }（仅限简单 return，不用于 proxy_pass 等复杂逻辑） - 工作时间启用强缓存：
location /static/ { proxy_cache_valid 200 302 2h; }，非工作时间降为10m，通过proxy_cache_valid配合 map 变量间接控制（需用map+set或 upstream 分流实现）
时段引导与降级策略
对管理后台或高敏路径，可主动引导用户避开高峰或提示维护窗口：
- 在
location /admin/中添加响应头：add_header X-Service-Hours "09:00–18:00 CST"; - 若检测到时段为
maintenance（可由 map 扩展定义），返回轻量提示页：error_page 451 /maintenance.html; if ($time_period = "maintenance") { return 451; } - 搭配日志记录时段行为：
log_format timed '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$time_period"';
注意事项与避坑点
时段策略易出错的关键不在配置本身，而在时间上下文理解：
-
$time_iso8601和$date_gmt是请求开始时生成的，不会随 rewrite 或内部跳转更新，适合一次性决策 - 不要在
if块中对时间变量做 proxy_pass、rewrite 或 limit_rate —— 这些指令在 if 中行为未定义，极易失效 - 若需跨多台 Nginx 同步时段逻辑，避免依赖本地系统时间；推荐统一 NTP 校时，并用
$date_gmt保证一致性 - 测试务必用真实请求触发，curl -H "Host: example.com" https://example.com/ —— 不要仅靠 echo 测试 map 输出
