centos 7 中 network.service 默认启动超时90秒，易因dhcp延迟等导致失败；需编辑/usr/lib/systemd/system/network.service添加timeoutstartsec=300并执行systemctl daemon-reload。
修改 network.service 启动超时阈值（防止 systemctl restart network 卡住）
CentOS 7 的 network.service 默认启动超时是 90 秒，若网卡初始化慢（比如 DHCP 响应延迟、虚拟机 NAT 网络不稳定），systemctl restart network 会直接失败并报 Timeout start-limit hit 或卡在 Starting LSB: Bring up/down networking...。这不是网络本身不通，而是 systemd 等不及。
解决方法是延长服务启动超时时间：
- 编辑
/usr/lib/systemd/system/network.service（不要改/etc/下的副本，它会被覆盖） - 在
[Service]段下方添加：TimeoutStartSec=300 - 执行
systemctl daemon-reload生效
注意：这个配置只影响 systemctl 对 service 的等待时间，不改变底层网络协议行为。
调整 SSH 连接空闲超时（避免终端断连）
用户登录后长时间无操作被踢，常见于 ssh 客户端连接或 sshd 服务端主动断连。这不是“连接建立超时”，而是保活机制触发的断开。
分两端控制：
- 服务端（
/etc/ssh/sshd_config）：设置ClientAliveInterval 300和ClientAliveCountMax 3，表示每 5 分钟发一次心跳，连续 3 次无响应才断开 - 客户端（
/etc/ssh/ssh_config或~/.ssh/config）：加ServerAliveInterval 300和ServerAliveCountMax 3，效果类似但由客户端发起 - 改完必须运行
systemctl restart sshd，否则不生效
别混淆 ClientAlive*（服务端发心跳）和 ServerAlive*（客户端发心跳），参数名反直觉但逻辑固定。
修复 ifup 脚本级连接超时（DHCP 获取 IP 卡死）
当使用 DHCP 时，ifup ens33 可能卡在 dhclient 等待响应阶段，默认超时长达 5 分钟（实际是 dhclient 自身行为）。这会导致 systemctl restart network 表面成功，但网卡没真正 up 起来。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
根本解法是约束 dhclient 行为：
- 编辑对应网卡配置文件，如
/etc/sysconfig/network-scripts/ifcfg-ens33 - 添加一行：
DHCP_TIMEOUT=15（单位秒，建议 10–30） - 同时确认已存在
BOOTPROTO=dhcp且ONBOOT=yes - 该参数仅被 CentOS/RHEL 的 ifup 脚本识别，非通用 dhclient 参数
如果仍失败，可临时用 dhclient -timeout 10 -v ens33 手动测试，验证是否是 DHCP 侧响应慢。
绕过内核 TCP 连接重传限制（应对弱网或防火墙拦截）
当出现 Connection timed out 错误（如 ssh: connect to host x.x.x.x port 22: Connection timed out），本质是三次握手 SYN 包未得到 ACK，Linux 内核默认重试 6 次，总耗时约 127 秒（指数退避：1s, 2s, 4s, 8s, 16s, 32s）。
缩短重试窗口可更快失败并报错，便于脚本判断：
- 临时修改：
echo 'net.ipv4.tcp_syn_retries = 3' >> /etc/sysctl.conf && sysctl -p - 3 次重试总耗时约 15 秒（1+2+4+8），适合自动化探测场景
- 注意：此设置影响所有 TCP 连接，生产环境慎调；不要设为 1，否则可能误判瞬时丢包
真正的连接不可达问题（如目标主机关机、防火墙 DROP）无法靠调参解决，只能结合 telnet x.x.x.x 22 或 nc -zv x.x.x.x 22 验证端口层通路。
最易忽略的是：这些超时参数分布在 systemd、SSH、网络脚本、内核四个层级，改错位置毫无效果。先用 journalctl -u network -n 50 或 ssh -v user@host 确认具体卡在哪一环，再针对性调整。
