固定 IP 稳定性如何检测？使用 Python 实现网络连通性与耗时监控

在网络运维和固定 IP 管理中，经常会遇到这样的问题：一个 IP 地址可以正常连接，但运行一段时间后却出现访问超时、响应变慢或者连接失败。

这类问题并不一定意味着 IP 地址发生了变化。网络路由、目标服务器状态、防火墙策略以及链路拥塞，都可能影响最终的访问结果。

因此，判断一个固定 IP 是否稳定，不能只看一次 Ping 的结果，也不能仅凭某次网页访问成功就得出结论。更合理的方法是建立一套可重复的检测流程，分别观察网络连通性、TCP 连接情况和应用层请求耗时。

本文以 Linux 和 Python 为例，介绍如何逐步完成这些检测，并将结果保存为 CSV 文件，方便后续分析。

一、固定 IP 稳定性应该关注哪些指标？

在开始编写检测程序之前，需要先明确检测目标。

1. 连通性

连通性用于判断当前环境是否能够到达目标。

常见工具包括 ping、nc 和 curl，分别可以用于观察 ICMP 响应、TCP 端口连接和应用层请求结果。

需要注意，这三种检测并不能互相替代。例如，ICMP 请求没有响应，不一定代表 HTTPS 服务不可用。

2. 连接耗时

连接耗时可以帮助判断建立网络连接是否顺畅。

对于 TCP 服务，可以观察连接建立时间；对于 HTTPS 请求，还可以进一步分析 TLS 握手和首字节响应时间。

3. 丢包与波动

单次请求成功并不能说明网络一直稳定。

如果同一个目标在连续测试中反复出现超时，或者请求耗时波动很大，就需要进一步检查网络路径、目标服务和本地环境。

4. 长期变化

对于固定 IP，除了观察连接质量，还应确认地址是否在预期周期内保持不变。

不过，地址固定与网络性能稳定是两个不同的问题。IP 地址没有变化，并不意味着底层路由和服务响应始终保持一致。

二、使用 Ping 进行基础检测

Linux 环境下，可以先通过 Ping 查看目标是否响应：

ping -c 10 -W 2 目标IP

参数说明：

• -c 10：发送 10 次请求。

• -W 2：设置等待响应的超时时间。

• 输出结果通常包含丢包率以及往返时延统计。

例如，如果测试结果显示有 10% 的丢包，就说明本次测试中有部分 ICMP 请求未收到响应。

但这并不能直接证明目标 IP 的业务连接存在 10% 的故障。ICMP 可能受到限速或过滤，应该结合 TCP 和应用层检测进一步判断。

另外，如果目标地址属于自己管理的固定 IP 或代理服务，应确认检测方式与服务实际开放的协议相匹配。

三、使用 TCP 检测目标端口

当业务依赖 HTTPS、SSH 或其他 TCP 服务时，可以直接检测对应端口。

例如，检查某个目标的 443 端口：

nc -vz -w 5 example.com 443

如果连接成功，说明当前环境能够与目标建立 TCP 连接。

如果出现超时或连接拒绝，需要区分具体情况：

现象	可能原因
Connection refused	目标端口未监听，或目标主动拒绝连接
Connection timed out	网络路径、防火墙策略或目标状态等因素可能导致超时
Name resolution failed	域名解析失败
Connection succeeded	TCP 建连成功，但不代表应用层一定正常

以上只是常见排查方向，并非一一对应的故障结论。建议结合目标服务日志、防火墙配置及重复测试结果进行判断。

如果需要检测的是代理服务，应使用服务商提供的协议、端口和认证信息进行连接测试，而不是默认代理出口 IP 的 443 端口一定开放。

四、使用 curl 分析 HTTPS 请求耗时

Ping 和 TCP 测试无法完整反映 HTTPS 请求的表现。

可以使用 curl 观察请求不同阶段的耗时：

curl -sS -o /dev/null \
  --connect-timeout 5 \
  --max-time 15 \
  -w '\nDNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\nHTTP状态: %{http_code}\n' \
  https://example.com/

其中：

• time_namelookup：名称解析阶段耗时。

• time_connect：从请求开始到 TCP 连接完成的累计耗时。

• time_appconnect：从请求开始到 TLS 握手完成的累计耗时。

• time_starttransfer：从请求开始到收到首字节的累计耗时。

• time_total：整个请求的累计耗时。

这些指标是累计时间，不应直接相加。

例如，TCP 建连耗时较低，但首字节响应时间较高，可能说明耗时主要发生在 TLS 之后的等待阶段，也可能与服务器处理时间有关。需要结合重复测试和服务端状态继续分析。

五、使用 Python 自动检测 TCP 连接

如果需要持续监控多个目标，手动执行命令并不方便。

下面编写一个简单的 Python 程序，通过 TCP Socket 检测目标端口，并记录连接是否成功以及连接耗时。

import socket
import time
import csv
from datetime import datetime

TARGETS = [
    ("example.com", 443),
    ("python.org", 443),
]

TIMEOUT = 5
OUTPUT_FILE = "network_check.csv"


def check_tcp(host, port, timeout=5):
    start = time.perf_counter()

    try:
        with socket.create_connection(
            (host, port),
            timeout=timeout
        ):
            elapsed = time.perf_counter() - start

            return {
                "success": True,
                "elapsed_ms": round(elapsed * 1000, 2),
                "error": ""
            }

    except (OSError, TimeoutError) as exc:
        elapsed = time.perf_counter() - start

        return {
            "success": False,
            "elapsed_ms": round(elapsed * 1000, 2),
            "error": str(exc)
        }


def main():
    with open(
        OUTPUT_FILE,
        "a",
        newline="",
        encoding="utf-8-sig"
    ) as file:
        writer = csv.writer(file)

        if file.tell() == 0:
            writer.writerow([
                "time",
                "host",
                "port",
                "success",
                "elapsed_ms",
                "error"
            ])

        for host, port in TARGETS:
            result = check_tcp(host, port, TIMEOUT)

            row = [
                datetime.now().isoformat(timespec="seconds"),
                host,
                port,
                result["success"],
                result["elapsed_ms"],
                result["error"]
            ]

            writer.writerow(row)
            file.flush()

            print(row)


if __name__ == "__main__":
    main()

运行程序：

python3 network_check.py

程序会将检测结果追加写入 network_check.csv，记录测试时间、目标地址、端口、连接结果和耗时。

这里使用的是 TCP Socket 检测，并没有执行 HTTP 请求，也没有完成 TLS 证书校验。因此，连接成功只能说明 TCP 建连成功，不能直接判断网站业务是否正常。

代码中的目标是公开示例网站。实际使用时，可以替换为自己有权检测的服务地址。

六、如何根据检测记录判断异常？

有了 CSV 记录后，就可以观察一段时间内的变化。

例如：

测试时间	TCP 结果	耗时
10:00	成功	35 ms
10:05	成功	38 ms
10:10	成功	41 ms
10:15	失败	超时
10:20	成功	120 ms

从这组示例数据来看，目标大部分时间可以建立连接，但中间出现一次失败，随后耗时明显上升。

这时不应该立即认定 IP 地址存在问题，而应该继续检查：

1. 同一时间访问其他目标是否正常。

2. 目标服务本身是否发生异常。

3. 本地网络是否出现丢包或拥塞。

4. 重复测试后，异常是否仍然存在。

5. 如果经过代理访问，直连与代理连接的结果是否存在明显差异。

如果多个目标同时异常，问题可能位于本地网络或共享链路；如果只有某个目标异常，则需要重点检查目标服务、路由以及访问策略。

这是一种排查思路，而不是绝对的判断规则。

七、固定 IP 为什么需要长期监控？

对于短期测试，一次连接成功可能已经足够。但对于远程管理、固定出口访问、IP 白名单和长期运行任务来说，长期监控更有价值。

建议将检测拆成三个层次：

• 地址层： 检查使用的 IP 是否符合预期，地址变更是否有记录。

• 连接层： 观察 TCP 建连成功率、连接耗时和超时情况。

• 应用层： 通过实际 HTTP 或 HTTPS 请求确认目标服务是否正常响应。

如果需要进一步提高监控能力，还可以增加连续失败告警、耗时阈值告警以及历史数据统计。

需要注意，监控频率应根据业务需求合理设置。过于频繁的检测可能触发目标服务的限流策略，也会增加不必要的网络负载。

总结

判断固定 IP 是否稳定，不能只依赖单次 Ping 或某个测速网站的结果。

更可靠的方式是结合 ICMP、TCP 和应用层请求，从不同层面观察网络表现，并通过重复测试建立历史记录。

本文介绍的 Python 示例可以作为轻量级检测工具的基础。后续还可以扩展为多目标监控、失败告警和趋势分析程序。

对于实际运维来说，最重要的不是某一次测试得到多低的延迟，而是能否在一致的测试条件下，持续获得可重复、可解释的检测结果。