PHP stream_socket_client TCP 探活怎么做：超时、DNS 与连接诊断

线上服务偶尔报「上游不可用」的时候，PHP 代码排查往往先盯着业务接口看，其实第一步就该把 DNS 解析、TCP 建连异常、远端端口拒绝这三类故障分开定位。stream_socket_client() 你可以写个极简的探活器实现这类检测，但如果返回的失败信息、超时参数和日志字段没做规范，监控侧最后只能拿到一条毫无参考价值的「连接失败」提示。

先把 TCP 探活的边界说清楚

探活的核心目标，是确认某个地址的 TCP 连接能不能在约定时间内正常建立。比如 PHP-FPM 进程要检查内部缓存服务的 6379 端口，最小的判断逻辑只有三步：解析目标域名、发起连接请求、记录成功状态或具体失败原因。它不会发送 Redis 指令，也不会替你验证应用层响应的正确性。

示例代码里只做连接动作之后就立刻关闭，适合作为独立的端口探活逻辑使用。不要把它误包装成「缓存服务完全可用」的判断依据，不然哪怕探活返回成功，业务还是有可能在认证、协议校验或者连接池环节出问题。

超时、拒绝和 DNS 失败要分开记录

同样是 false，三类故障对应的处理动作完全不一样：解析不到主机名先排查 DNS 配置；目标主动拒绝请求通常查端口监听状态或者安全组规则；连接超时则要检查网络路径、服务负载以及探活的超时阈值是否合理。把 $errno 与 $errstr 写入结构化日志，才能让告警直接落到具体的排查方向上。

如果有多个 PHP-FPM worker 同时执行探活，日志里还应该带上目标地址、耗时、当前 SAPI 类型和请求追踪号。探活器本身不要打印完整的远端地址凭据，目标配置也不能直接从用户输入直接拼接生成。

用 socket context 控制连接选项

对于需要明确约束超时和连接行为的场景，可以把相关选项放到 socket context 里。这样配置项和代码调用逻辑分开，后续要接入 TLS 或者代理规则的时候也更容易排查校验。

$context = stream_context_create([
    'socket' => [
        'tcp_nodelay' => true,
        'so_reuseport' => false,
    ],
]);

$startedAt = microtime(true);
$errno = 0;
$errstr = '';
$socket = @stream_socket_client('tcp://db.internal:3306', $errno, $errstr, 1.2, STREAM_CLIENT_CONNECT, $context);
$elapsedMs = (microtime(true) - $startedAt) * 1000;

$result = $socket === false
    ? ['ok' => false, 'errno' => $errno, 'error' => $errstr]
    : ['ok' => true, 'errno' => 0, 'error' => ''];
$result['elapsed_ms'] = round($elapsedMs, 1);

if (is_resource($socket)) {
    fclose($socket);
}
var_export($result);

这里特意在成功分支把错误字段清空，并用 is_resource() 保护关闭动作。生产环境的代码还应该提前限制允许探活的目标列表，避免探活接口被恶意利用，做成任意内网端口扫描的工具。

探活结果怎样接入监控才不误导

建议返回的探活结果至少包含 target、ok、elapsed_ms、errno、reason 和 checked_at。超时阈值不要直接照搬开发机的配置：内网数据库可能要求 300 毫秒内就能建立连接，跨可用区的服务则要结合实际的网络基线来设置合理阈值。

• 连接成功但耗时超过阈值：标记为降级状态，继续持续采集数据，不要直接判定为完全不可用。
• 连续 DNS 失败：告警指向解析配置和服务发现模块，不要只通知 PHP 应用侧的开发人员。
• 连续端口拒绝：优先检查监听进程状态、端口占用情况和最近的发布变更记录，保留最近一次连接成功的时间。
• 探活成功之后还需要单独做协议级的检查，比如 TLS 握手校验、HTTP 状态码判断或者 Redis PING 指令验证。

常见问题

stream_socket_client 能检查 HTTP 接口是否正常吗？

不能。它只确认 TCP 连接可以正常建立；HTTP 状态码、响应体内容和业务字段的校验，需要使用对应的 HTTP 客户端做协议级检查。

连接超时参数用整数还是浮点数？

可以使用浮点秒数，例如 0.8 或 1.2，但实际阈值要结合网络基线和告警策略做验证之后再上线。

为什么 DNS 失败也拿不到有意义的端口错误？

因为主机名还没有解析成具体的 IP 地址，TCP 连接流程根本没有开始。出现这类问题应该优先检查 DNS 配置、容器搜索域设置和服务发现配置。

探活连接成功后需要一直保持 socket 吗？

短探活场景一般连接建立之后就立刻关闭，避免占用服务端过多连接资源；长连接的管理属于连接池或者专属协议客户端的职责范畴。

把「能连上」拆成可追踪的证据

PHP 实现 TCP 探活最有价值的输出，从来不是一个简单的绿色可用状态，而是能明确标记出失败发生在 DNS 解析阶段、建连阶段还是后续的协议交互阶段。保留耗时、错误号和目标别名这些字段，再配合独立的 HTTP/TLS 检查逻辑，告警就不会把网络问题、端口问题和应用问题混在一起，排查效率会高很多。