你有没有过这样的经历？网站突然打不开，服务器响应慢得像蜗牛，或者某个服务莫名其妙地断了。这时候第一反应可能是重启，但问题可能还会再来。其实，真正该做的，是看看系统留下的“痕迹”——日志。
命令行里的日志侦探
很多人觉得日志分析得靠专业软件，其实Linux下几个常见的网络命令工具就能搞定大部分排查工作。比如你怀疑是某个接口被频繁请求拖垮了服务，netstat 或 ss 就能帮你快速查看当前的连接情况。
ss -tuln | grep :80这条命令会列出所有监听在80端口的TCP连接，一眼就能看出是否有异常连接堆积。如果发现某个IP连得特别多，再结合tail和grep去翻Web日志，基本就能定位到源头。
从日志里捞关键信息
日志文件动辄几百MB，逐行看不现实。这时候grep就是你的筛子。比如你想查出所有包含“500 Internal Server Error”的记录：
grep "500" /var/log/nginx/error.log还可以加个时间范围缩小排查面：
grep "2024/04/05.*500" /var/log/nginx/error.log如果日志已经被压缩归档，别急着解压。zgrep可以直接在.gz文件里搜索，省时又省空间。
zgrep "timeout" /var/log/nginx/access.log.1.gz把零散信息串起来
单看一条日志可能看不出什么，但把时间、IP、状态码串起来，规律就出来了。比如用awk提取访问日志中的IP和次数，找出访问最频繁的客户端：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10结果一出来，某个IP占了八成请求，那它大概率就是问题来源。这时候结合iptables临时封禁，再深入查程序逻辑，问题往往迎刃而解。
日常备份也得聪明点
日志越积越多，硬盘迟早告急。定期压缩备份是必须的，但别一股脑全打包。可以按日切分，只保留最近7天的明文日志，更早的自动压缩归档。
find /var/log/app -name "*.log" -mtime +7 -exec gzip {} \;这样既节省空间，又不影响紧急排查。万一哪天真出了问题，也能快速调取对应时间段的日志进行分析。
说到底，网络命令工具不是高手专属，它们就像螺丝刀、扳手，用熟了，修起问题来又快又准。下次遇到异常，别急着重启，先看看日志说了什么。