$_server['http_host']在nginx与apache下行为不一致的根本原因是web服务器对host头的传递机制不同：apache默认原样传递，nginx需显式配置fastcgi_param http_host $http_host;，否则可能返回localhost、空值等错误值；$_server['server_name']由服务器静态配置决定，不可用于获取用户访问域名；https判定需nginx手动注入fastcgi_param https $https if_not_empty;；安全获取域名应优先取校验后的http_host，辅以可信代理头和白名单过滤。
$_SERVER['HTTP_HOST'] 在 Nginx 和 Apache 下行为不一致
根本原因不是 PHP 本身，而是 Web 服务器如何传递 Host 请求头给 PHP。Apache 默认将原始请求中的 Host 头原样注入 $_SERVER['HTTP_HOST']；Nginx 则依赖 fastcgi_param 配置，若未显式设置，可能 fallback 到 server_name 或空值。
常见错误现象：$_SERVER['HTTP_HOST'] 在 Nginx 下返回 localhost、127.0.0.1，甚至为空，而同一请求在 Apache 下正常返回用户访问的域名。
- Nginx 配置中必须包含：
fastcgi_param HTTP_HOST $http_host;（推荐）或fastcgi_param HTTP_HOST $host; -
$http_host保留端口（如example.com:8080），$host自动剥离端口，更接近浏览器实际 Host 值 - 若使用 HTTPS 反向代理，还需确认 Nginx 是否透传了
Host头（proxy_set_header Host $host;）
$_SERVER['SERVER_NAME'] 不可靠，别用它取用户访问域名
$_SERVER['SERVER_NAME'] 完全由 Web 服务器配置决定：Apache 读取 ServerName 指令，Nginx 读取 server_name 指令 —— 它们都是静态配置项，与客户端实际请求的域名无关。一旦站点绑定多个域名（如 www.example.com 和 example.com），SERVER_NAME 只会返回配置里写死的那个。
典型误用场景：用 SERVER_NAME 拼接跳转 URL 或生成绝对链接，结果在多域名共存时出错。
立即学习“PHP免费学习笔记（深入）”；
- 永远不要用
$_SERVER['SERVER_NAME']替代$_SERVER['HTTP_HOST']来获取用户访问域名 - 如果需要标准化域名（比如强制 www），应在应用层判断
HTTP_HOST后重定向，而非依赖 SERVER_NAME - 某些 Nginx + PHP-FPM 组合下，
SERVER_NAME还可能被fastcgi_param SERVER_NAME $server_name;覆盖为配置值，加剧误导
HTTPS 场景下 $_SERVER['HTTPS'] 的判定差异
Apache 通常能自动识别并设置 $_SERVER['HTTPS'] = 'on'；Nginx 默认不设置该变量，需手动注入。若没配，哪怕请求是 HTTPS，PHP 也认为是 HTTP，导致生成的 URL 协议错误（如 http:// 替代 https://）。
- Nginx 必须添加：
fastcgi_param HTTPS $https if_not_empty;（推荐）或fastcgi_param HTTPS on;（仅限全站 HTTPS） - 若 Nginx 前还有 CDN 或负载均衡（如阿里云 SLB），需确认是否透传了
X-Forwarded-Proto: https，并在 PHP 中检查该 header - 安全起见，建议统一用
isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on'或$_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '' === 'https'判断协议
跨服务器部署时最稳妥的域名获取方式
没有银弹，但可以组合判断降低风险。核心原则：优先信任客户端传来的 Host 头，辅以可信代理头校验，最后 fallback 到白名单内的已知域名。
示例逻辑（可直接嵌入入口文件）：
// 先尝试从 Host 头取
$host = $_SERVER['HTTP_HOST'] ?? $_SERVER['SERVER_NAME'] ?? '';
// 清洗端口（如 example.com:443 → example.com）
if (($pos = strpos($host, ':')) !== false) {
$host = substr($host, 0, $pos);
}
// 若走代理，且有 X-Forwarded-Host，且来源可信（比如只接受内网 IP），可考虑覆盖
$trusted_proxies = ['127.0.0.1', '10.0.0.0/8'];
if (isset($_SERVER['HTTP_X_FORWARDED_HOST']) &&
in_array($_SERVER['REMOTE_ADDR'], $trusted_proxies)) {
$host = $_SERVER['HTTP_X_FORWARDED_HOST'];
}
// 最终限制在合法域名范围内，防 Host 头攻击
$allowed_hosts = ['example.com', 'www.example.com'];
$host = in_array($host, $allowed_hosts) ? $host : 'example.com';
真正容易被忽略的是 Host 头伪造风险 —— 攻击者可任意构造 Host: evil.com，所以任何基于 HTTP_HOST 的输出（尤其是重定向 Location、邮件链接）都必须校验或白名单过滤。
