用自定义HTTP头（如X-Env-Tag）实现PHP流量染色，需在Nginx中启用fastcgi_pass_request_headers，PHP中通过getallheaders()或$_SERVER['HTTP_X_ENV_TAG']读取，并在Laravel中配置TrustProxies白名单；调用下游服务时须手动透传该头，确保全链路一致。
怎么用 HTTP 头给 PHP 请求打染色标记
流量染色本质就是让请求携带可识别、可传递的元信息，PHP 本身不自动透传外部头，得靠你主动读取和转发。最常用也最可靠的方式是约定一个自定义请求头，比如 X-Env-Tag 或 X-Traffic-Color，后端直接从 $_SERVER 里取。
- 别用
HTTP_X_*直接访问 —— Apache 会把-转成_，但 Nginx 默认不改，行为不一致；统一用getallheaders()（需 CLI/SAPI 支持）或手动映射：$_SERVER['HTTP_X_ENV_TAG'] ?? $_SERVER['HTTP_X_ENV_TAG'] ?? null - 如果走 nginx + php-fpm，确保 nginx 配置里有
fastcgi_pass_request_headers on;，否则自定义头根本进不到 PHP - 染色头值建议限制长度和字符集（如只允许
[a-z0-9_-]{1,32}），避免被滥用为注入点或日志污染源
在 Laravel/Lumen 中如何安全透传并路由染色请求
框架会封装原始请求，但默认不信任用户头，X-Env-Tag 这类头需要显式“白名单”才能进 Request 对象。否则你在控制器里调 $request->header('X-Env-Tag') 拿到的是空。
- Laravel：在
App\Http\Middleware\TrustProxies的$headers属性里加上Request::HEADER_X_ENV_TAG，或者更干脆，在bootstrap/app.php之前加$_SERVER['HTTP_X_ENV_TAG'] = $_SERVER['HTTP_X_ENV_TAG'] ?? null; - 灰度路由别写死在中间件里 —— 把染色判断抽成独立服务，比如
TrafficColorDetector::isGray($request)，方便单元测试和后续对接配置中心 - 注意：Laravel 的
cache:clear不清 config cache 里的路由缓存，改了染色逻辑后记得跑php artisan route:clear
PHP-FPM 级别做染色分流容易踩哪些坑
想绕过应用层，在 FPM 池或响应头层面做简单分流？可行，但边界非常窄，多数时候反而增加运维复杂度。
- FPM 的
slowlog和access.log不记录自定义头，没法靠日志反查染色行为；得自己在php_admin_value[error_log]里补日志逻辑 - 不能依赖
$_SERVER['REMOTE_ADDR']做灰度 —— CDN、LB 之后看到的全是内网 IP，必须依赖头，且头要在最外层入口（如 nginx）就校验并重写fastcgi_param - 如果用
auto_prepend_file注入染色逻辑，注意它在所有脚本执行前运行，但此时$_SERVER可能还没完全初始化，推荐用register_tick_function或直接在入口文件顶部处理
染色标识怎么往下游 HTTP 服务透传
你的 PHP 服务如果要调其他 API（比如用 curl 或 Guzzle），染色头不会自动带上，必须手动追加。漏掉这步，整个链路就断了。
立即学习“PHP免费学习笔记（深入）”；
- 用
curl时，明确设置：curl_setopt($ch, CURLOPT_HTTPHEADER, ['X-Env-Tag: ' . $tag]);，别只拼在 URL 后面当 query 参数 - 用 Guzzle 时，别只改
headers配置项 —— 如果用了RetryMiddleware，重试时可能丢失头，得用on_stats回调重新注入 - 下游如果是 Node.js 或 Go 服务，注意它们对 header 名大小写的处理差异（HTTP/2 强制小写），PHP 发出去的
X-Env-Tag到那边可能变成x-env-tag，提前对齐规范
染色不是加个头就完事，关键是整条链路每个跳点都得识别、保留、传递。最容易被忽略的是反向代理层（nginx / ALB）的头透传开关和框架对非标准头的默认过滤策略 —— 这俩没调通，后面所有逻辑都是空中楼阁。
