43.2 分钟，是「99.9% 可用率」在一个月里允许掉的时长。这意味着即使平台完全兑现承诺，你的线每月也可能断上几次，而断在凌晨三点和断在你要交单的下午，损失不是一回事。所以掉线这件事得自己盯：探活脚本不用买，一条备用线 2.6 元/月起，一年 31 元。
下面这套东西，讲的是「怎么在 5 分钟内知道自己的线断了、断在哪一层、手里有没有能拿去报障的证据」。不涉及任何平台的内部探针，全部在你自己的机器上跑。
🔗 快速入口：一站式注册入口（聚合 20+ 平台） ｜ 全平台价格中心 ｜ 代理工具中心
| 探活三层 | 端口（TCP 握手）→ 出口（SOCKS5 握手 + 出口 IP）→ 业务（目标站真实响应） |
| 建议频率 | 3~5 分钟一次（1440 次/天 → 288~480 次/天） |
| 计数规则 | 连续 2 次失败才算掉线，单次失败只记通报 |
| 备线成本 | 2.6 元/月起（SK5 1M 档）｜沧海 4 元/月起（B 档），年成本 31~48 元 |
「99.9% 可用率」是平台对自己探针的承诺
先把这个数字拆开看。99.9% 的时间可用率，换算过来是每月 43.2 分钟、每年 8.76 小时。这个换算本身没问题，问题在于「不可用」是怎么被定义的——绝大多数平台的探针只做一件事：定时去连一下你的代理端口，能建立连接就算活着。
可你的业务不是这么判定的。端口能连上，不代表握完手能拿到正确的出口 IP；出口 IP 对了，不代表目标站不给你弹验证；目标站能打开，也不代表连接能撑过十分钟（长连接被回收是另一套机制，站内已经单独写过）。所以真实的落差常常是这样的：平台后台一片绿，你的脚本在报 407 或者 502。
站内那篇讲可用率口径的文章把「时间可用率 / 提取成功率 / 可用条数率」三个口径拆过了，本篇不重复定义，只解决一件事：怎么在你的机器上，把平台没探到的那两层补上。
三层探活：端口通、出口对、业务走得通
三层不是三选一，而是排错顺序。上层的失败往往在下层就已经有征兆，但下层成功不能推出上层成功——这一点是整套方案的地基。
| 层级 | 探什么 | 「正常」长什么样 | 最容易出现的假象 |
|---|---|---|---|
| A 端口层 | 能不能和 IP:端口 建立 TCP 连接 | 握手在几百毫秒内完成 | 平台限流时端口会假死，过几分钟自己恢复 |
| B 出口层 | SOCKS5 握手（RFC 1928）＋ 认证（RFC 1929）＋ 取回出口 IP | 返回的出口 IP 与你买的那条一致 | 认证失败或本机 IP 变了（白名单模式），端口却一直是通的 |
| C 业务层 | 用这条线去请求你真正要打的目标站 | HTTP 200，且页面里没有验证/拦截标记 | 目标站维护或改版，会被误判成线路断 |
一句话记住三者的分工：只有 C 层能告诉你「业务真的断了」，只有 A、B 层能告诉你「断在哪」。只探 A 层的人，平台一限流就以为线死了；只探 C 层的人，目标站一改版就换了一堆线。
探到哪一层，取决于断了你会损失什么
不是所有业务都值得三层全上。探针本身也占并发和流量，探得越深越贵。
| 业务形态 | 至少探到 | 原因 |
|---|---|---|
| 端游挂机、在线时长类 | B 层 ＋ 低频 C 层（15 分钟一次） | 挂的是「一直在」，掉线影响的是时长，不是单次请求 |
| 数据采集、批量请求 | C 层为主 | 真正掐你的是目标站风控，出口 IP 通不通意义不大 |
| 店铺后台、支付、登录 | A＋B＋C 三层，且人工复核 | 误判就换线，反而增加账号层面的风险，宁可慢一步 |
| 离线任务、跑完就走的脚本 | A 层就够 | 任务时长短，断了重跑的成本低于维护探针 |
频率：一分钟一次是浪费，五分钟一次刚好
把次数算出来就知道为什么。一天 1440 分钟，一分钟一次就是 1440 次/天；三分钟一次 480 次/天；五分钟一次 288 次/天。每一次探活都是实打实的一次连接，会占你的并发额度（并发和连接数的关系站内单独写过），探针跑得太勤，业务反而被自己的探针挤掉。
| 频率 | 一天次数 | 一个月约 | 适合 |
|---|---|---|---|
| 1 分钟 | 1440 | 4.3 万次 | 不建议，除排障期临时开 |
| 3 分钟 | 480 | 1.4 万次 | 挂机类、需要较快发现 |
| 5 分钟 | 288 | 8,600 次 | 多数业务的默认档 |
| 15 分钟 | 96 | 2,900 次 | 低频业务、探针与业务共额度 |
配套两个参数：单次超时给 8~10 秒（低于 5 秒在跨境线路上假失败会明显变多），连续 2 次失败才计入掉线。这两条一起用，能把夜间抖动造成的误报压掉大半。
什么才算「真掉线」：四条判定
误报比漏报更烦人——一次假警报就可能让你半夜爬起来换线，把本来好的线路换掉。四条规则按顺序过一遍，能挡掉大部分假警报。
| 看到的现象 | 结论 | 下一步 |
|---|---|---|
| 单次失败，下一次就通了 | 算抖动，不算掉线 | 记一条日志，不改配置 |
| 端口通，但 B 层认证失败或出口 IP 变了 | 认证/白名单问题，不是线路死 | 核对账密与白名单里的本机 IP |
| 同一平台同一段的多条线一起断 | 大概率平台侧 | 别急着换，先报障并等 |
| 换成已知好的线打同一个目标站也失败 | 问题在目标站或本机网络 | 换目标 URL 复测，排除线路嫌疑 |
断点日志只留三个字段就够
很多人报障时只能说出「连不上」，平台客服也没法往下查。日志不需要复杂，三个字段就够用，而且都是脚本能自动写出来的。
| 字段 | 填什么 | 为什么必须有 |
|---|---|---|
| 时间 | 精确到分，带时区（如 2026-10-17 03:12 +08:00） | 平台查日志是按秒对齐的，没有时区会对不上 |
| 对象 | 出口 IP:端口 ＋ 你请求的目标 URL | 同一条线打不同目标站，结论可能完全不同 |
| 原始错误 | curl 退出码或 HTTP 状态码原文 | 「连不上」没有信息量，退出码会直接指向原因 |
curl 的退出码值得单独记一下，照着查比猜快：5 是代理地址解析不了，7 是连不上代理（端口不通或被拒），28 是超时，56 是连上了但收数据失败。这四个码基本覆盖了你在代理场景会遇到的绝大多数失败。
报障单带这七项，平台才可能当天回你
客服第一句通常问「您用的是什么工具、什么网络」。把这七项一次性发过去，能省掉两三轮往返，也避免被当成「用户自己的问题」挂在队列里。
| 要填的 | 具体内容 |
|---|---|
| 账号 | 注册手机号或邮箱，别只发昵称 |
| 订单/套餐 | 套餐名 ＋ 购买时间，方便定位到批次 |
| 线路标识 | 出口 IP:端口，一次只报一条，别一锅端 |
| 首次异常时间 | 含时区，精确到分 |
| 失败情况 | 连续失败几次、间隔多长、是否 100% 失败 |
| 原始错误 | 退出码或 HTTP 状态码原文，附一行复现命令 |
| 已排除项 | 换线复测结果、换设备复测结果、白名单是否已加本机 IP |
该等还是该换：三条阈值线
判断标准写死在数字上，就不用每次靠感觉。
| 指标 | 阈值 | 动作 |
|---|---|---|
| 单条线日均失败率 | 连续 3 天高于 5% | 换线，并向平台申请调换 |
| 同平台全段不可用 | 持续 30 分钟以上 | 等，换线也一样，别浪费额度 |
| 通断交替（每小时都在断） | 一天超过 5 次 | 先查本机端口与连接数，再谈换线 |
| 目标站验证码率上升 | 同一 IP 连续命中 3 次 | 换 IP 段，别换平台 |
两个落地方案：Windows 计划任务与 Linux cron
不需要装任何软件，系统自带的工具就够。Windows 端用 PowerShell，Linux 端用 curl，两边判据一致：能连上端口、能取回出口 IP、目标站返回 200。
Windows（存成 probe.ps1，再用「任务计划程序」设成每 5 分钟跑一次）：
$ip = "1.2.3.4"
$port = 1080
$out = "D:\probe\probe.log"
$t = Get-Date -Format "yyyy-MM-dd HH:mm:ss zzz"
$ok = (Test-NetConnection -ComputerName $ip -Port $port -InformationLevel Quiet)
$line = "$t | $ip`:$port | TCP=$ok`n"
Add-Content -Path $out -Value $line -Encoding utf8Linux（写进 crontab -e，每 5 分钟一次；出口 IP 用 SOCKS5 带域名解析去取，避免本机 DNS 干扰）：
*/5 * * * * curl -s --max-time 10 -x socks5h://用户:密码@1.2.3.4:1080 \
https://socks5ip.com.cn/ip-check-center/ -o /dev/null \
-w "%{time_local} exit=%{exitcode} http=%{http_code}\n" \
>> /var/log/probe.log 2>&1两段脚本都只做一件事：把「什么时候、哪条线、什么结果」写进文件。告警可以后加——先跑一周把日志攒出来，看看自己这条线本来有多少抖动，再决定阈值，比一上来就设「失败一次发通知」靠谱得多。想先人工看一眼线路状态，站内的代理线路检测页可以直接批量测，不必等脚本跑完一轮。
官方入口与相关页面
| 类型 | 入口 |
|---|---|
| 价格中心 | 全平台价格中心：20+ 家代理IP 横向比价，全部免费测试 |
| 代理工具中心 | 代理工具中心：SSTap / NekoBox / 老鱼等客户端下载与配置 |
| 自测工具 | IP 综合检测中心：IP 质量 / 线路 / 测速 / 业务模拟 |
| 线路检测 | 代理线路可用性检测：SK5/HTTP 真实握手、延迟分级、出口归属 |
| 聚合注册 | 一站式注册入口：各平台邀请码汇总，注册即享优惠价 |
常见问题
Q：平台说 99.9%，我自己测出来只有 95%，谁的数字对？
A：两个都对，只是探的不是同一件事。平台探的是「端口能不能连上」，你探的是「业务能不能跑」。中间隔着认证、白名单、目标站风控、本机端口与长连接寿命这几层，任何一层出问题，你的数字都会低于平台的数字。要对比，得先把自己的探针口径写清楚再比。
Q：自己探活会不会被平台当成攻击，或者把额度用光？
A：按 3~5 分钟一次、单并发、8 秒超时的节奏，一天不到 500 次请求，对平台来说是正常量级。真正需要注意的是两个：一是探针与业务共用并发额度，别在业务高峰期跑全量探测；二是不要用 30 秒一次的频率去扫整个 IP 段，那种量级才容易被限流。
Q：我买的是客户端型产品，后台导不出 IP，还能探吗？
A：只能探 C 层——用客户端连上之后，访问一个固定 URL 看结果，同时记录本机出口。A、B 两层在客户端型产品上你拿不到 IP:端口，探不了也不必探，因为客户端自己会重连。这类产品的判断重点应转向「重连后出口是否变化」。
Q：断一分钟就换线，为什么反而更糟？
A：三个原因。一是单次失败多为抖动，换掉的是好线；二是频繁换 IP 本身是风控信号，账号层面的风险比断线更大；三是换线要重新配置客户端、更新白名单，操作期间业务照样断。建议按阈值来：连续 2 次失败记录、连续 3 天日均失败率超 5% 再动手。
Q：探针应该放在本机还是放在服务器上？
A：两个都要，看你要证明什么。放本机证明的是「你的业务环境能不能用」；放服务器证明的是「这条线在别的出口上通不通」。报障时两份日志一起给，平台就很难把问题归到你本地网络上——这也是很多人报障被「测试正常」挡回来的原因。
Q：我报障了，平台回复「这边测试一切正常」，怎么办？
A：把七项报障信息补齐再回一次，特别是原始错误和复测结果。对方测的是端口，你测的是业务，两边结论不冲突。如果连续两轮都是这个答复，按阈值处理：换线或申请调换，同时把自己的日志留档，后续申诉时有据可查。
📚 相关阅读
📄 Quantumult X 是什么？它在你链路里干哪一段活
更多帮助
如需获取更多帮助，请访问官网：socks5ip.com.cn
🛠️ IP综合检测中心：IP质量/线路/测速/业务模拟免费测
📝 聚合注册入口（各平台邀请码汇总）：https://linkdd.cn/socks5ip
💬 微信：17720135827 — 7×24h在线
全网低价IP｜聚合20+代理IP平台，全部免费测试，先测后买零风险
