Linux下用ping命令实时检测丢包率最可靠，推荐动态获取网关后执行ping -W 2 -c 3，连续3～5次失败才触发重启，并配合systemd定时器、状态校验与防雪崩机制保障稳定性。
丢包率怎么用命令行实时获取
Linux 下没有直接返回“丢包率”的现成命令，但 ping 是最可靠、最通用的检测手段。关键不是追求高精度，而是让脚本能稳定抓到异常信号——比如连续 3 次 ping -c 3 都返回非零退出码，或丢包数 > 0。
注意：ping 必须指定目标（如网关或 DNS），不能只 ping 本机；建议用 ip route | awk '/default/ {print $3}' 动态取网关，避免硬编码；ping -W 2 -c 3 中的 -W 2 能防卡死，比默认超时更可控。
- 别用
curl或wget替代ping：HTTP 层失败不等于网络层丢包，且依赖 DNS 和远端服务状态 - 避免用
ethtool查rx_missed_errors等计数器：那是硬件队列溢出统计，和实际业务丢包无直接对应关系 - 如果网关不可达，优先检查物理链路或上联设备，而不是立刻重启接口
怎么判断是否该触发重启
单次丢包不等于故障，误触发反而会中断连接。合理策略是：在固定周期（如每 30 秒）执行一次探测，连续失败 N 次才行动。N 建议设为 3～5，取决于你的网络稳定性。
脚本里用一个计数器变量（如 fail_count）记录连续失败次数，成功则清零；达到阈值后执行重启动作，并重置计数器。不要用后台循环 + sleep 拼凑，应配合 systemd 定时器或 cron 控制节奏，避免进程失控。
- 重启前加
ip link show dev eth0 | grep 'state DOWN'校验接口当前状态，防止重复操作 - 用
ip link set eth0 down && sleep 2 && ip link set eth0 up比systemctl restart networking更轻量、更可控 - 重启后必须等待 3～5 秒再测连通性，否则
ping可能立即失败，导致二次误触发
脚本里怎么安全执行重启而不锁死自己
最危险的情况是：脚本运行在 SSH 会话中，重启网卡后连接断开，脚本残留进程卡住、日志写满、或定时任务不断拉起新实例。必须做三件事：脱离终端、限制并发、记录状态。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
启动脚本时用 nohup ./netwatch.sh > /var/log/netwatch.log 2>&1 &，并用 pgrep -f netwatch.sh | wc -l 在开头检查是否已在运行；每次重启前写时间戳到 /tmp/netwatch.last_restart，10 分钟内禁止再次触发，防雪崩。
- 不要用
service network restart：在 Ubuntu 20.04+ 或使用systemd-networkd的系统上会失败甚至崩溃 - 接口名不能写死，用
ip -br a | awk '$1 !~ /^lo|docker/ && $2 == "UP" {print $1; exit}'自动选第一个活跃物理口 - 所有
ip、ping、systemctl命令前加command -v校验是否存在，避免在最小化系统中静默失败
为什么 systemctl 定时器比 cron 更适合这个场景
cron 只保证“按时启动”，不管上次脚本是否还在跑；而 systemd 的 OnUnitActiveSec + StartLimitIntervalSec 能天然限频、防堆积。更重要的是，systemd 日志可追溯：journalctl -u netwatch.service 直接看到每次丢包值、重启原因、时间戳。
把检测逻辑写进 /usr/local/bin/netwatch.sh，然后配一个 netwatch.service（Type=oneshot）和对应的 netwatch.timer（比如 OnBootSec=30, OnUnitActiveSec=30），比手动维护 while true; do ...; sleep 30; done 可靠得多。
- timer 启动前务必加
WantedBy=multi-user.target，否则 reboot 后不会自启 - service 文件里设
Restart=on-failure没意义——脚本本身就要处理失败，不应让 systemd 反复拉起 - 如果系统没启用
systemd（如某些容器或嵌入式环境），才退回到crontab -e，且必须加flock -n /tmp/netwatch.lock排他
真正难的不是写几行 ping 和 ip link set，而是让脚本在网卡反复闪断、SSH 连接抖动、磁盘满、权限丢失等各种边缘状态下仍不越界——所有判断都要有兜底，所有操作都要可逆，所有状态都要可查。不然，自动化的初衷，就变成了自动制造事故的开关。
