小实例网络变慢，先分清是本机、云内还是对端

前言：昨天那篇是分清 CPU、内存、磁盘谁是瓶颈，结尾留了一句：四处都正常、还是慢，再看网络那一侧。今天就把网络这一侧补上。小实例网络变慢，第一反应往往是“带宽不够，升带宽吧”。先别急，慢可能出在本机、出在云内链路，也可能出在对端——升带宽只对其中一种管用。按下面顺序分段定位，再决定动哪处。

第一处：本机有没有在发包，先看出口通不通。命令：ping -c 4 223.5.5.5；curl -o /dev/null -s -w "总耗时 %{time_total}s\n" https://www.example.com。判断标准：ping 看的是基础连通和延迟，curl 看的是真实访问耗时。两个都慢，问题可能在更底层；ping 正常、curl 很慢，先怀疑 DNS 解析或对端响应慢，别急着升带宽。

第二处：DNS 是不是拖了后腿。命令：cat /etc/resolv.conf；nslookup www.example.com。判断标准：nslookup 如果解析一次要等好几秒、甚至超时，而解析出地址后直接访问并不慢，慢的就是 DNS 这一环，不是带宽。先记下解析耗时，再往下查，别把 DNS 的慢算到带宽头上。

第三处：本机端口和连接状态，先排除自己这边。命令：ss -tlnp；ss -s。判断标准：ss -tlnp 看服务是不是真的在监听、端口对不对；ss -s 看连接总数是不是异常高。小实例连接数被打满时，新连接会排队，看起来就像“网速慢”，其实是本机连接到了上限，跟带宽无关。

第四处：路由走到哪一步变慢，分段看。命令：ip route；traceroute www.example.com。判断标准：traceroute 一跳一跳看延迟是在哪一段突然变大。前面几跳就高，问题在云内或出口附近；最后几跳才高，问题更可能在对端或中间链路。只看最终延迟下结论容易找错方向，要看是哪一段开始变慢。

小结：顺序是：出口通不通 → DNS 解析快不快 → 本机连接满没满 → 路由哪一段变慢。只有“各段延迟都正常、下载大文件时速率长期顶满带宽”这一种，才是升带宽能解决的。先分段，再花钱。