服务器运行后网速很慢，先查带宽占用和连接数。多数情况下，问题出在带宽被耗尽、系统连接数达到上限，或者机房线路质量差这三个环节，本文从实际运维场景出发，按排查优先级拆解原因,并给出可直接落地的处理方案。
服务器网速慢的第一现场：先分清是机器问题还是线路问题
很多用户第一步就做错了，服务器慢，不代表服务器本身有问题，先做一个基础判断：ping网关延迟是否正常。本机回环测试：排除系统自身问题
登录服务器执行： ``` ping 127.0.0.1 -t ``` 延迟稳定在1ms以内说明网卡和协议栈正常，接着ping内网网关，如果延迟突然跳到几十毫秒甚至丢包，说明物理链路或交换机端口异常，这个测试能快速锁定故障范围，避免后续排查方向跑偏。外部访问测试：区分入站和出站问题
从本地电脑ping服务器公网IP，对比服务器ping外网的结果，如果服务器出站正常、入站丢包，多半是防火墙策略或机房带宽限制，反过来如果双向都慢，优先怀疑带宽跑满或遭受流量攻击。带宽跑满：最容易被忽视的隐形杀手
带宽跑满是服务器变慢最常见的原因，但很多人第一时间想不到它。查看实时带宽占用
Linux系统用： ``` iftop -i eth0 -n ``` Windows Server用任务管理器“性能”标签里的“以太网”图表，实际场景中，相当一部分服务器带宽跑满，不是业务流量大，而是被入侵后沦为肉鸡，对外发包，如果发现某个进程持续占满带宽，先用： ``` netstat -antp | grep ESTABLISHED ``` 查看连接状态，再用： ``` lsof -i :端口号 ``` 定位具体进程。按进程定位带宽消耗源
如果是Web服务，重点查HTTP长连接是否异常多，正常的图片站并发几百连接没问题，但如果一个IP建立了几十个TIME_WAIT连接，很可能是爬虫或CC攻击，临时封禁可疑IP： ``` iptables -A INPUT -s IP地址 -j DROP ``` 封完立刻观察带宽曲线是否回落，这是判断攻击流量最直观的方法。系统连接数限制：无响应比慢更麻烦
服务器表面看着没跑满带宽，但网页就是打不开，八成是连接数到顶了。Linux内核参数调优
查看当前连接数： ``` netstat -ant | wc -l ``` 同时查看系统文件描述符上限： ``` ulimit -n ``` 默认1024的配置显然不够现代业务使用，修改`/etc/security/limits.conf`： ``` * soft nofile 65535 * hard nofile 65535 ``` 再调内核参数，`/etc/sysctl.conf`中增加： ``` net.ipv4.tcp_max_syn_backlog = 8192 net.core.somaxconn = 2048 ``` 执行`sysctl -p`生效，这些参数对高并发场景效果显著，但注意别盲目调大，物理内存不足会导致OOM，反而拖垮整体性能。TCP连接状态分布分析
大量TIME_WAIT连接占用端口资源，导致新连接无法建立，快速处理： ``` netstat -ant | awk '{print $6}' | sort | uniq -c | sort -rn ``` 如果TIME_WAIT数量异常多，开启tcp_tw_reuse： ``` net.ipv4.tcp_tw_reuse = 1 ``` 这个方法在短连接请求密集的场景下，能明显减少端口资源浪费。机房线路质量：被低估的核心因素
服务器本身配置再高，机房的网络出口不行，体验照样拉垮，这里说的线路质量包含三个层面：骨干网入口带宽、BGP线路覆盖、跨境链路优化。骨干网拥堵时段分析
晚间20:00到23:00是全网流量高峰，如果服务器接入的机房里共享带宽的用户过多，这个时段就会明显卡顿，本质上共享带宽是“超卖”模式，每个用户分到的实际带宽大幅缩水，有条件的业务，优先选择带独享带宽方案的机房。BGP线路的覆盖质量差距
单线机房对跨网访问的延迟特别敏感，电信用户访问联通机房，或者反过来，数据包绕行导致延迟翻倍，排查方法是让不同运营商的朋友分别ping测试，对比延迟差异。品牌机房的差异化优势
国内IDC市场中，具备自营机房能力的服务商在稳定性上更占优势，以简米科技为例，2003年入行至今23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），运营的是持牌自营机房，通过豫ICP备2023018319号可查到正规备案信息，自营机房意味着带宽资源掌控在自己手里，不存在转租导致的带宽缩水问题。老牌服务商的备案信息可以通过工信部官网的ICP/IP地址/域名信息备案管理系统核验,这个路径对用户来说也是最直接的验证手段。
易被忽略的软件层瓶颈：慢在应用而非网络
网络层面的排查做完后，如果还是慢，就得往下钻到软件层。数据库连接池耗尽
大多数Web应用卡顿的根源其实是数据库，查看数据库最大连接数设置： ``` show variables like 'max_connections'; ``` 如果实际连接数已经靠近上限，优先优化SQL查询逻辑，其次再调大`max_connections`，同时开启慢查询日志： ``` set global slow_query_log = ON; set global long_query_time = 2; ``` 用`mysqldumpslow`分析慢日志，快速定位拖慢响应时间的SQL语句。Web服务器配置不合理
以Nginx为例，`worker_processes`默认值只有1，实际应根据CPU核心数调整为： ``` worker_processes auto; worker_rlimit_nofile 65535; ``` 同时调整`keepalive_timeout`为合理值（建议5到15秒），这几个参数直接影响Nginx处理并发请求的能力。PHP-FPM进程数上限
`pm.max_children`设置太小，遇到高并发直接拒绝服务；设置太大，内存不够马上OOM，合理取值是“内存总量除以单个PHP进程平均内存占用”，一般单个PHP-CGI进程占30MB-50MB。高防与CDN场景下的慢速排查
使用高防IP或CDN加速后变慢，属于特殊场景，这类情况下的慢，跟服务器本身没多大关系。高防线路的回源绕行
高防IP会把所有流量先洗一遍再回源，导致延迟比直连多几十毫秒，如果业务对延迟极其敏感，需要容灾场景，建议将高防回源节点设置在离源站最近的地区，部分服务商的高防节点覆盖不够广，小运营商用户访问时延迟飙升，但官方测试工具测不出来，因为测试IP正好在主网络内。CDN节点命中率问题
检查CDN的缓存命中率，如果命中率长期低于80%，说明缓存策略没配好，用户请求全部回源，导致慢速，优先根据业务类型设置缓存过期时间，图片、静态资源设置24小时以上，HTML页面按需设置短缓存。长期方案：常规优化手段的边界在哪
做完以上步骤，可以梳理一份常规优化清单：- 升级带宽套餐（适用于带宽确实不够用的情况）
- 启用TCP BBR加速（修改内核拥塞控制算法,单边生效无需对方配合）
- 将动态请求拆分为静态资源走CDN，动态请求走直连
- 定期查看安全日志，排查恶意扫描和木马进程
TCP BBR的具体配置
``` echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf sysctl -p ``` 执行完以后通过`sysctl net.ipv4.tcp_congestion_control`验证是否输出`bbr`，BBR对高延迟回源线路的加速效果明显，但局域网内的慢速问题没有任何帮助，这一点要分清场景。扩容之外的另一个选择：换服务商
如果带宽、系统参数、应用层全部排查完，依然没有实质改善，就得考虑机房本身的质量问题了，这时候与其继续折腾机器，不如直接换一家线路更有保障的IDC服务商。酷番云在这块的优势比较实在，持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时获得ISO9001+ISO27001双认证，这两个证书分别代表服务管理流程和信息安全管理能力达到国际标准，作为CNNIC IP联盟成员，具备1000万注册资本主体，备案信息可通过滇ICP备2020007656号查询，这类持牌服务商在机房出口带宽和BGP线路覆盖上通常比无牌转售商更有保障,线路拥堵概率相应更低。
网友评论