17370845950

PHP获取当前完整URL的可靠写法是组合$_SERVER变量：用HTTPS或X-Forwarded-Proto判断协议，HTTP_HOST fallback SERVER_NAME获取域名，SERVER_PORT显式拼接非默认端口，REQUEST_URI补充路径与参数。

PHP 获取当前完整 URL 的可靠写法

直接拼接 $_SERVER 变量是最常用也最可控的方式，但必须注意协议、端口、代理等现实情况。很多网上抄来的“一行代码”在 HTTPS、反向代理或非标准端口下会出错。

• $_SERVER['REQUEST_URI'] 只返回路径 + 查询参数（如 /user/profile?id=123），不包含协议和域名，不能单独用作完整 URL
• 判断协议要用 $_SERVER['HTTPS'] === 'on' 或检查 $_SERVER['HTTP_X_FORWARDED_PROTO']（Nginx/Apache 代理场景）
• 端口不是总等于 80/443：如果 $_SERVER['SERVER_PORT'] 不是默认值，且 URL 显式写了端口（如 :8080），就得带上
• 推荐组合：$_SERVER['REQUEST_SCHEME']（PHP 5.5.7+）比手动判断更稳，但低版本需回退逻辑

兼容 PHP 5.3+ 的安全获取方式

下面这段代码能覆盖绝大多数部署环境（包括 Nginx + PHP-FPM、Apache、带 CDN 或负载均衡的场景）：

$protocol = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on') || (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') ? 'https' : 'http';
$host = $_SERVER['HTTP_HOST'] ?? $_SERVER['SERVER_NAME'];
$port = $_SERVER['SERVER_PORT'];
$request_uri = $_SERVER['REQUEST_URI'] ?? '/';
$url = $protocol . '://' . $host;
if (($protocol === 'http' && $port != 80) || ($protocol 
=== 'https' && $port != 443)) {
    $url .= ':' . $port;
}
$url .= $request_uri;
// $url 就是当前完整 URL

关键点：优先读 HTTP_HOST（防伪造）， fallback 到 SERVER_NAME；HTTP_X_FORWARDED_PROTO 必须显式检查，否则 HTTPS 请求经 Nginx 转发后会变成 http://

为什么 $_SERVER['PHP_SELF'] 和 $_SERVER['SCRIPT_NAME'] 不行

这两个变量只返回当前执行脚本路径（如 /index.php），不包含查询参数，也不反映重写后的 URL（比如 Laravel 的 /users/1 实际对应 /index.php）。它们本质是服务端路径，不是客户端看到的 URL。

• $_SERVER['PHP_SELF'] 还可能被恶意注入（如 /index.php/path%3Cscript%3E...），直接输出有 XSS 风险
• 若用了 URL 重写（.htaccess 或 nginx rewrite），SCRIPT_NAME 完全无法反映用户访问的真实路径
• 它们都不含 QUERY_STRING，而 REQUEST_URI 包含，这是核心差异

实际使用中容易忽略的坑

开发时本地测试一切正常，上线后 URL 拼错，大概率是这几个点没处理：

• Nginx 配置里没传 proxy_set_header X-Forwarded-Proto $scheme;，导致 PHP 拿不到真实协议
• CDN 或 WAF 层清除了 X-Forwarded-* 头，此时只能依赖 $_SERVER['SERVER_PORT'] 和硬编码协议（不推荐）
• HTTP_HOST 可被客户端篡改，若用于生成跳转链接且未校验，可能引发开放重定向漏洞
• CLI 环境下 $_SERVER 相关键名不存在，这段代码会报 undefined index，需提前判断运行模式

真正稳定的方案，得结合部署架构来定——没有“一劳永逸”的单行函数，只有适配你当前服务器链路的写法。