PHP parse_url 如何区分缺失端口与默认端口：URL 解析结果和代理转发边界

在回调地址或反向代理配置里，最容易被忽略的不是 URL 能不能拆开，而是“没有写端口”和“明确写了默认端口”是不是同一件事。PHP 的 parse_url() 会保留这个差异：缺失端口得到 null，写出 :80 或 :443 才得到整数。需要转发到后端时，先把 URL 本身的事实读出来，再决定是否套用业务默认值。

不要用 empty(parse_url($url, PHP_URL_PORT)) 判断端口是否存在；先区分 null、显式的 0 和具体整数，再把代理提供的 SERVER_PORT 当作独立来源核对。

parse_url() 先拆事实，不负责替你验证 URL

parse_url() 的职责是把 scheme、host、port、path、query 等部分拆出来。PHP 官方手册明确提醒，它不是 URL 验证器，对相对 URL 或格式异常的输入可能给出不适合作为安全结论的结果。

因此，下面的变量只表示“解析结果里有没有 port”，不表示这个 URL 一定允许访问：

输入 https://demo.test/callback 时，数组里不会凭空出现 port => 443。这正是后面区分“原文未写端口”和“原文显式写了默认端口”的依据。

PHP_URL_PORT 的三个结果怎么判

只取端口时可以传入 PHP_URL_PORT。返回值的类型比真假更有用：null 表示没有这个组件，整数表示 URL 里确实写出了端口。

这里特意使用严格比较。empty() 会把数字零、空字符串和不存在的值揉成一个分支，后续很难解释“到底是输入没写，还是输入写了一个不符合业务规则的值”。在真正的允许端口校验里，还应继续检查端口是否位于业务白名单。

默认端口是业务决策，不是 parse_url() 的返回值

如果业务规定 HTTPS 未写端口时按 443 连接，可以在确认 scheme 后显式补值：

 80,
    'https' => 443,
    default => throw new InvalidArgumentException('不支持的 scheme'),
};

var_dump($port);          // NULL：原文没有端口
var_dump($effectivePort); // int(443)：业务采用的连接端口

$port 和 $effectivePort 必须保留成两个变量。前者用于审计和重建原始输入，后者用于后续连接策略；把它们混成一个字段，会丢失用户是否显式指定端口的信息。

反向代理中 HTTP_HOST 和 SERVER_PORT 各自说明什么

处理 Web 请求时，常见误区是把 $_SERVER['SERVER_PORT'] 直接当成客户端 URL 的端口。PHP 手册把它定义为 Web 服务器通信所使用的端口，并提醒不同服务器配置下可用性和含义会变化；CLI 运行时这些环境变量也可能不存在。

HTTP_HOST 来自请求的 Host 头，可能包含端口；SERVER_PORT 则来自服务器环境。代理终止 TLS 后转发到 PHP-FPM 时，两者会经过一个需要明确记录的代理边界，可能分别体现外部入口和内部监听端口，不能只看其中一个就拼出绝对 URL。

这段代码只做拆分和记录，没有把 Host 头当作可信授权依据。生成跳转地址或回调地址时，应使用应用配置里的允许域名；若必须接受代理头，则要先确认代理拓扑和 Web 服务器是否只允许可信代理注入这些头。

一段可落地的允许端口校验

将“原始端口”和“有效端口”分开后，校验逻辑会更清楚：

 80, 'https' => 443];
    if (!isset($defaultPorts[$scheme]) || $host !== 'demo.test') {
        throw new InvalidArgumentException('scheme 或 host 不在允许范围');
    }

    $effectivePort = $rawPort ?? $defaultPorts[$scheme];
    if ($effectivePort !== $defaultPorts[$scheme]) {
        throw new InvalidArgumentException('端口不在允许范围');
    }

    return [
        'scheme' => $scheme,
        'host' => $host,
        'raw_port' => $rawPort,
        'effective_port' => $effectivePort,
    ];
}

这个例子只允许 demo.test 的标准 HTTP/HTTPS 端口，适合说明判断顺序，不应直接复制成所有业务的 SSRF 防护。若场景涉及远程请求，还要继续处理 DNS 解析、重定向、内网地址和连接器实际采用的 URL 解析规则。

容易踩坑的判断方式

• 用 strpos($url, 'https://') 判断安全：这只能看字符串开头，无法验证 host、用户信息、端口和异常形式。
• 把 null 直接转成 443：连接可能没问题，但审计时失去“原文是否显式带端口”的事实。
• 只信 SERVER_PORT：代理链路中它可能是内部端口，并不等于用户看到的入口端口。
• 把 parse_url() 当作完整校验器：官方手册明确指出它只负责拆分，不负责满足某种 URL 标准。

相关问题

没有端口的 HTTPS URL 应该返回 443 吗？

在 PHP_URL_PORT 语义里不会，缺失端口是 null。只有业务在确认 scheme 后，才可以把有效连接端口计算为 443。

HTTP_HOST 没带端口时能直接读 SERVER_PORT 吗？

不能直接等同。两者来源不同，尤其在反向代理后可能分别对应外部 Host 和内部 Web 服务器端口。

用 parse_url() 校验回调地址够安全吗？

不够。它适合拆分字段，允许域名、scheme、端口和后续网络访问仍需单独限制，并按照实际请求库的解析行为复核。

小结

处理端口时，先记录 parse_url() 的原始结果，再计算业务采用的默认值；Web 请求里同时保留 HTTP_HOST 与 SERVER_PORT 的来源差异。只要不把“缺失”“显式默认值”和“代理环境值”压成一个真假判断，回调地址、跳转地址和审计日志就能保持一致。