PHP filter_var 验证 URL 时为什么会放过奇怪主机名

接口收到一个 URL 后，filter_var($url, FILTER_VALIDATE_URL) 返回字符串，并不等于“这个地址真实存在”或“业务允许访问”。它主要判断输入是否符合 PHP 采用的 URL 语法，因此 https://intranet、https://example.invalid 这类主机名可能通过；某些非 HTTP scheme 也可能通过。真正的校验要拆成协议、主机名格式、业务白名单三层。

为什么 filter_var 会放过看起来奇怪的主机名

最容易误判的地方，是把一个函数的返回值当成了完整安全结论。PHP 手册把 FILTER_VALIDATE_URL 定义为 URL 校验过滤器，并说明它按 RFC 2396 判断；返回值为原字符串或 false。这套规则关注 URL 的组成形式，不负责确认主机是否能解析，更不负责判断它是不是公司的域名。

例如，下面三类输入的含义完全不同：

相反，foo_bar.example 可能被拒绝，并不代表所有“奇怪域名”都会拒绝；下划线、非 ASCII 国际化域名、保留域名和内网短名分别属于不同问题。不要根据一个例子推断过滤器的业务边界。

先拆出 scheme 和 host，再判断每一层

排查时不要只打印 true 或 false。先记录输入，再把结构拆开：scheme 是访问协议，host 是主机名，path 和 query 是资源定位部分。这样才能知道到底是格式校验通过，还是业务白名单误放行。

 false, 'reason' => 'URL 结构无法解析']; // 结构层失败
    }

    $scheme = strtolower((string)($parsed['scheme'] ?? ''));
    $host = strtolower(rtrim((string)($parsed['host'] ?? ''), '.'));
    if ($scheme !== 'https') {
        return ['ok' => false, 'reason' => '只允许 HTTPS']; // 协议层失败
    }
    if ($host === '' || filter_var($host, FILTER_VALIDATE_DOMAIN, FILTER_FLAG_HOSTNAME) === false) {
        return ['ok' => false, 'reason' => '主机名格式不符合要求']; // host 层失败
    }

    return [
        'ok' => true,
        'scheme' => $scheme,
        'host' => $host,
        'path' => (string)($parsed['path'] ?? ''),
    ]; // 返回结构化证据，交给下一层策略判断
}
?>

FILTER_FLAG_SCHEME_REQUIRED 和 FILTER_FLAG_HOST_REQUIRED 不应该再被当成“打开必填开关”的方案；PHP 官方资料说明它们早已被废弃并在 PHP 8 中移除，因为 URL 校验本身已经隐含这些要求。协议允许列表仍然要由业务代码明确写出。

用白名单把语法判断收紧到业务规则

如果业务只允许公司站点或 CDN，最可靠的判断是完整比较。允许根域名和它的子域时，拼接一个点号边界：$host === $domain 或 str_ends_with($host, '.' . $domain)。这样 example.com.evil.test 不会因为文本末尾碰巧出现域名而通过。

这段代码只解决“字符串主机名是否属于允许集合”。如果 URL 后续会触发服务端请求，还要单独设计重定向、解析 IP、内网地址和 DNS 变化的访问策略；不能把这个函数宣传成 SSRF 防护。若业务接收国际化域名，还需先按项目支持的 IDN 规则转成 ASCII 再做同一套白名单匹配，不能直接假设过滤器会替你完成转换。

用反向验证确认“放行”真的有理由

修复后至少准备一组正向和反向样本，并把拒绝原因写进日志，而不是只记一个布尔值。正向样本可以是 https://example.com 与 https://api.example.com/v1；反向样本应包括 http://example.com、https://example.com.evil.test、javascript://payload、https://example.invalid 和带端口的未知主机。

• 格式层：输入是否能被 filter_var 和 parse_url 同时解析。
• 协议层：是否只接受业务明确允许的 scheme。
• 主机层：是否通过 FILTER_VALIDATE_DOMAIN，并命中完整域名或点号子域边界。
• 访问层：只有确实需要服务端访问时，才继续做 DNS/IP、跳转和网络出口控制。

常见问题

filter_var 返回原字符串，能说明域名存在吗？

不能。它只表示过滤器接受该值；DNS、HTTP 可达性和业务授权都需要独立判断。

为什么不直接用正则匹配 example.com 结尾？

简单的后缀匹配会把 example.com.evil.test 等无关主机混进来。应比较完整 host，或比较带前置点号的子域后缀。

FILTER_VALIDATE_DOMAIN 能替代 URL 校验吗？

不能。它针对的是域名字符串；完整 URL 仍需先拆解并限制 scheme、端口和其他业务字段。

因此，看到“PHP filter_var 验证 URL 放过奇怪主机名”时，先问清楚你要验证的是 URL 结构、主机名格式，还是允许访问的业务目标。把三层判断分开，返回值就不再承担它没有承诺的职责。