PHP 获取当前页面完整 URL 的方法通常涉及使用 $_SERVER 超全局数组中的几个关键变量。以下是一个常见的实现方式：✅ 获取当前页面完整 URL 的 PHP 代码

2026-05-25 15:46:24 0浏览 收藏

本文深入解析了在 PHP 中安全、准确获取当前页面完整 URL（含协议、域名、路径及查询参数）的正确方法，重点揭示了仅依赖 $_SERVER['HTTPS'] 等原始变量的常见陷阱——如反向代理环境下协议判断失效、Host 头被伪造导致 XSS 风险、PATH_INFO 污染 PHP_SELF 等问题；给出了兼顾 Nginx/Apache 代理兼容性、HTTPS 准确识别（优先读取 X-Forwarded-Proto 并用 filter_var 校验）、主机名可靠性选择（HTTP_HOST 优于 SERVER_NAME）以及强制 HTML 转义防注入的生产级实现方案，帮你避开本地调试正常、上线即崩溃的隐蔽坑点。

不能直接用 $_GET['url'] 拼出当前完整 URL，它只是重写规则传入的路由参数，不是原始请求地址。真正可靠的方式是组合 $_SERVER 中的几个关键字段，但必须注意协议判断、代理兼容性和 XSS 防御。

怎么拼出带协议的完整 URL（HTTP/HTTPS）

核心逻辑是：协议 + 主机 + 请求路径（含查询字符串）。但 $_SERVER['HTTPS'] 的值不统一（可能是 'on'、'1' 或不存在），硬判 === 'on' 在 Nginx+PHP-FPM 或反向代理下容易出错。

• 优先检查 $_SERVER['HTTP_X_FORWARDED_PROTO']（若可信代理已配置 ProxyPreserveHost On）
• fallback 到 $_SERVER['HTTPS']，用 filter_var($_SERVER['HTTPS'], FILTER_VALIDATE_BOOLEAN) 更稳妥
• 始终用 $_SERVER['HTTP_HOST']，不用 $_SERVER['SERVER_NAME']——前者来自请求头，含端口；后者依赖配置，可能不一致
• $_SERVER['REQUEST_URI'] 已包含路径和查询字符串，无需再拼 $_SERVER['QUERY_STRING']

示例：

$scheme = $_SERVER['HTTP_X_FORWARDED_PROTO'] ?? ($_SERVER['HTTPS'] ?? 'off');
$scheme = filter_var($scheme, FILTER_VALIDATE_BOOLEAN) ? 'https' : 'http';
$host = $_SERVER['HTTP_HOST'] ?? $_SERVER['SERVER_NAME'];
$uri = $_SERVER['REQUEST_URI'] ?? '/';
$current_url = $scheme . '://' . $host . $uri;

为什么 $_SERVER['PHP_SELF'] 和 $_SERVER['SCRIPT_NAME'] 不适合拼完整 URL

这两个变量只反映 PHP 脚本自身路径，不含查询参数，且在 PATH_INFO 存在时会被污染（比如访问 /index.php/user/123，$_SERVER['PHP_SELF'] 可能变成 /index.php/user/123，而实际脚本仍是 index.php）。

• $_SERVER['PHP_SELF'] 可被构造恶意路径触发 XSS，例如 /index.php/%3Cscript%3Ealert(1)%3C/script%3E
• $_SERVER['SCRIPT_NAME'] 不包含查询字符串，也不反映重写后的路径语义
• 二者都不携带协议信息，硬加 http:// 会导致 HTTPS 页面出现混合内容警告

反向代理（Nginx/Apache）下常见失效场景

当 PHP 运行在 Nginx 后面、或 Apache 前还有一层 CDN/负载均衡时，$_SERVER['HTTPS'] 和 $_SERVER['HTTP_HOST'] 往往为空或错误，因为原始请求被代理覆盖了。

• 必须启用代理透传：Nginx 需加 proxy_set_header X-Forwarded-Proto $scheme; 和 proxy_set_header Host $host;
• PHP 代码中要主动读取 $_SERVER['HTTP_X_FORWARDED_PROTO'] 和 $_SERVER['HTTP_X_FORWARDED_HOST']
• 忽略 $_SERVER['SERVER_PORT'] 直接拼端口——443 或 80 应由协议决定，而不是从端口数字反推协议

输出前必须做 HTML 转义

$_SERVER 中的任何字段都可能被客户端控制（比如通过篡改 Host 头），直接 echo 到 HTML 里等于给 XSS 开后门。

• 仅在调试日志中可裸用 var_dump() 或 error_log()
• 前端展示或生成链接时，一律用 htmlspecialchars($current_url, ENT_QUOTES, 'UTF-8')
• 不要用 urldecode() 再处理 $_SERVER['REQUEST_URI']——它本身已是解码后的原始值，重复解码可能破坏 UTF-8 字符

最易被忽略的是代理环境下的协议判定逻辑和 Host 头校验，这两点一旦漏掉，本地测试全过，上线就出错。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。