Codex额度用光？token管理与消耗优化，让ChatGPT不再卡壳
2026/10/14 7:36:06
1. 网络分层模型：把复杂问题拆成四层来想
1.1 用寄快递理解 TCP/IP 四层模型
Linux 网络基础这个话题，很多朋友问过我该从哪开始入手。其实我最初学习 Linux 时，对网络也是靠背命令：ifconfig、route、ss都会敲，可真遇到“应用连不上数据库”“服务器突然 ping 不通”这种问题，就抓瞎了。后来才明白，Linux 网络的地基不是命令，而是概念：网络分层、IP 寻址、路由转发、DNS 解析，这些只要串起来，再复杂的故障也能拆成步骤去查。这篇文章是《Linux_网络基础(一)》，我会把最基础的几个点讲透：TCP/IP 四层模型怎么理解、IP/掩码/网关/DNS 各管什么事、网卡配置怎么改才不丢、连通性排查该按什么顺序做。适合刚接触 Linux、或者工作里总要处理“网络不通”的运维、开发和测试朋友。
实际处理 Linux 网络问题时，建议先忘掉复杂的 OSI 七层模型，记住 TCP/IP 四层就够用了：应用层、传输层、网络层、链路层。很多人觉得分层抽象，我用寄快递打比方：链路层相当于街头跑的快递车和马路，它负责把数据从一个物理位置搬到另一个物理位置；网络层相当于快递单上的收件地址，负责把数据从源主机“按地址”送到目标主机所在网络；传输层相当于快递到达后快递员打电话确认是本人签收还是放驿站，它解决的是“数据到底是给哪个应用程序的”，对应 TCP 和 UDP 端口；应用层就是收件人拆开包裹真正使用里面的东西，比如你用浏览器访问网站，HTTP 协议就属于这一层。
这个类比不是说哪一层更重要，而是帮助你建立一种直觉：发送数据时，数据从应用层开始，每往下走一层就被包上一层“快递单”一样的信息，到了目标再一层层拆开。Linux 里你的程序发出一个请求，TCP 会加上端口信息，IP 层会加上源和目标地址，链路层再封装成以太网帧发出去。这个过程由一个个socket和协议栈完成，平时用tcpdump抓包看到的多层结构，其实就是这些“快递单”。
1.2 分层思维如何指导排查
分层模型最值钱的地方，是给排查网络问题提供了顺序。我见过不少朋友在“SSH 连不上服务器”时，上来就抓包、改防火墙，折腾半天发现网卡根本没起来。这种问题按分层来看就非常清晰：先看应用层需要的服务和端口，再看传输层是不是端口不通，然后看网络层 IP 路由通不通，最后看链路层网线、网卡状态。从高往低逐层检查，找到第一个异常层，问题往往就定位了。
举个例子。某个应用连不上数据库，你先ss -tlnp看数据库有没有监听 3306 端口，这是传输层；如果端口在监听，再ping数据库 IP 或者用ip route看路由，这是网络层；如果同网段内 ping 不通，就要去看交换机端口、网线这类链路层的东西了。这个思路一旦固定，你会发现大多数“网络不通”并不是真不通，而是某一层配置对不上，排查起来快很多。
1.3 为什么实际工作中不太提七层
OSI 七层模型不是没用，而是在日常 Linux 排障里，七层太细了。大家习惯把表示层、会话层合并进应用层，把物理层和数据链路层合并成链路层。我在tcpdump里看到的结构，基本就是以太网头、IP 头、TCP/UDP 头、应用数据，对应四层模型反而更容易对照。需要理解 TLS 握手、HTTP 报文细节时，再回到 OSI 的“表示层、会话层”去补充也不迟。所以这一篇只讲四层，后续聊网络工具和内核参数时，都会围绕四层展开。
2. 网络配置的核心要素：IP、掩码、网关、DNS
2.1 四个参数分别管什么，配错一个会怎样
Linux 网络配置里，IP 地址、子网掩码、网关、DNS 这四个参数几乎天天见。我用一个表格快速说清楚：
| 参数 | 类比 | 作用 | 缺失/配错的常见结果 |
|---|---|---|---|
| IP 地址 | 门牌号 | 标识主机在网络中的位置 | 无法寻址，数据不知道往哪送 |
| 子网掩码 | 街区范围 | 区分网络位和主机位，判断是否同网段 | 误判同网段/不同网段，路由行为异常 |
| 网关 | 小区大门 | 通往其他网络的默认出口 | 跨网段完全不通 |
| DNS | 通讯录 | 把域名解析成 IP | 域名无法访问，但 IP 直连正常 |
这四个参数通常是联动的。以192.168.1.100/24为例，/24就是255.255.255.0的简写，代表前 24 位是网络位，网络地址是192.168.1.0，主机位是最后 8 位，可用地址范围大概是192.168.1.1到192.168.1.254，其中192.168.1.255是广播地址。同一子网内的两台主机，比如192.168.1.100和192.168.1.200，可以直接通过二层通信；如果目标是192.168.2.x，就必须把数据交给网关192.168.1.1，由网关去转发。
有个坑我经常看到：有人把掩码配成255.255.0.0，结果本意是想让两台机器互通，却因为子网变大引入了意料之外的广播域和路由范围，甚至导致跨网段流量也尝试直连，行为变得很难解释。所以动手改配置前，先算清楚网络位，再确认网关在这个网络范围内，别凭感觉填。
2.2 用命令行查看当前网络配置
用现在的 iproute2 工具集，查看配置推荐这几个命令：
ip addr # 查看所有网卡和 IP 地址 ip route # 查看路由表 ip -br addr # 简洁模式，适合快速扫一眼 cat /etc/resolv.conf # 查看 DNS 配置重点读ip addr的输出。比如某块网卡的输出里有<BROADCAST,MULTICAST,UP,LOWER_UP>，其中UP表示接口逻辑上启用，LOWER_UP表示物理链路是通的，也就是网线插着、对端设备正常。再往下能看到inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0，这个字段就是 IP 地址和掩码。如果这里只有一个127.0.0.1/8，说明网卡根本没拿到配置，要么没启用，要么 DHCP 没成功。
老的ifconfig命令在很多旧教程里还会出现，但它默认显示的信息不够完整，而且有些版本不显示LOWER_UP这类链路状态。我现在基本只把ifconfig当成“习惯性看一眼”的辅助命令，真正判定还是要以ip为准。
2.3 判断 IP 配置是否合理的几个小技巧
一个很实用的技巧：同网段内先ping 网关，网关通了说明本机到路由器之间没问题；再ping 对端 IP，通了说明二层三层都通。如果网关不通，优先检查掩码和网关是否在同一网段，以及网卡是否UP。跨网段访问，先确认本地路由表里有没有default via，ip route如果只显示了直连网段而没有默认路由，那外面自然访问不了。
还可以用arping发 ARP 请求探测 IP 是否冲突。这个命令可能没预装，需要安装iputils-arping。比如你配了192.168.1.100，执行sudo arping -c 3 -I eth0 192.168.1.100，如果收到多个回包，极可能有人和你冲突了。这个场景在手动配静态 IP 的服务器上特别常见。
3. 网卡管理与 IP 配置实操
3.1 临时改配置：测试环境最快的办法
测试环境不想动文件，可以用ip命令临时修改：
sudo ip addr add 192.168.1.200/24 dev eth0 sudo ip link set eth0 up sudo ip route add default via 192.168.1.1这些命令是即时生效的，但也意味着重启后全部丢失，适合调试网络、模拟多 IP 场景时用。临时测试 DNS 就直接改/etc/resolv.conf，加一行nameserver 8.8.8.8就行。注意ip addr add是追加地址，不是覆盖，所以临时给一块网卡挂多个 IP 也是同样的命令。
这里分享一个我踩过的坑：有一次在测试机上临时加了多个地址，后来忘了记录，导致排查问题时看到网卡上有好几个 IP，分不清哪个才是真正的配置。后来我养成了习惯，临时改动前先cp /etc/resolv.conf /etc/resolv.conf.bak这类备份，或者添加地址后同步把改动写进任务记录，避免“灵异网络现象”。
3.2 永久配置：三种主流方式对照，别再被发行版搞晕
不同发行版管理网络的方式差异比较大，但主流的就三类，判断依据是系统里装的是哪个网络服务。先看cat /etc/os-release和systemctl status NetworkManager这类信息，确认用哪种，再动手改。
NetworkManager + nmcli：RHEL/CentOS/Fedora 桌面，以及不少现代化发行版默认用它。推荐用nmcli操作，它会直接写配置文件，并让 NetworkManager 重新加载：
nmcli connection show nmcli con mod eth0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "192.168.1.1 8.8.8.8" ipv4.method manual nmcli con up eth0注意nmcli con show里显示的连接名称不一定是eth0，也可能是System eth0之类，连接名和接口名是两回事。
netplan：Ubuntu 从 18.04 开始引入，配置文件在/etc/netplan/下，YAML 格式：
network: version: 2 ethernets: eth0: addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [192.168.1.1, 8.8.8.8]改完执行sudo netplan apply。YAML 对空格非常敏感，缩进错了配置文件会被拒，最好用sudo netplan try先试应用，避免改了之后把自己断网。
ifcfg 文件：老版本 CentOS/RHEL 比较常见，写在/etc/sysconfig/network-scripts/ifcfg-eth0：
DEVICE=eth0 BOOTPROTO=static ONBOOT=yes IPADDR=192.168.1.100 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 DNS1=192.168.1.1改完要重启网络服务，CentOS 6 用service network restart，CentOS 7 用systemctl restart network。
提示：改远程服务器的网络配置前，一定别最后一条命令直接重启网络，把自己锁在外面。正确做法是先把配置内容准备好，加上一条自动回滚的思路，比如写个脚本两分钟内恢复原配置，或者使用支持带外管理的控制台工具。远程操作网络配置翻车，是我见过最常出现的“服务器失联”案例。
3.3 静态 IP 和 DHCP 怎么选，以及冲突怎么避
服务器、虚拟机、网络设备之间的互连，我倾向用静态 IP，方便管理和排查；云主机直接用 DHCP 保留地址或云平台控制台分配就好，不要手动去改系统里的 IP，容易和平台管理冲突；桌面环境、临时测试机用 DHCP 最省心。判断系统当前用的 DHCP 还是静态，除了看配置，还可以看网卡地址租约信息，但最简单还是看配置文件：如果BOOTPROTO=dhcp或 netplan 里没写 addresses，基本就是 DHCP。
静态 IP 还要注意和 DHCP 地址池错开，否则可能冲突。比如路由器 DHCP 分配范围是192.168.1.100-192.168.1.200，你手动把服务器设为192.168.1.150，过阵子你就会发现另一台电脑莫名其妙上不了网，都是 IP 冲突闹的。配置前用arping先探测一遍是值得的好习惯。
3.4 子接口、多地址和 bond，先有点概念
Linux 的网卡能力比大多数人想象中强，一块物理网卡可以同时配多个 IP，这在ip addr add里直接就能实现，不用额外设备。还可以做 VLAN 子接口，用ip link add link eth0 name eth0.10 type vlan id 10给eth0加上 VLAN 10 的逻辑接口，常用于对接交换机上划分了 VLAN 的端口。多块物理网卡可以聚合做成 bond，提高带宽和冗余，常见模式有 mode 1（主备）和 mode 4（LACP 动态聚合）。
这一篇先不展开 bond 的具体配置，但你要知道：日常看到的eth0不一定是唯一入口，理解这些基础概念后，看“网络配置”就不再只是改一个 IP 那么简单，而是理解整台主机在网络里的身份。后面如果单独写路由和 bond，我会再深入。
4. 连通性诊断工具与排查顺序
4.1 ping：别高兴得太早，也别失望太快
ping 是最常用的连通性工具，但很多人对它的结果理解得太绝对。
ping -c 4 -W 2 192.168.1.1-c指定发几个包，-W指定每个包的超时秒数，-i可以调整间隔。如果看到64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.5 ms，说明本机到网关的三层链路是通的。
但 ping 不通不代表网络一定有问题。很多服务器为了安全会禁用 ICMP，或者防火墙规则里丢弃了 ICMP 包，这时 ping 会丢包，但 TCP 端口访问完全正常。所以判断连通性不能只看 ping，要结合ss、telnet、curl这些使用具体端口的工具一起看。反过来，ping 网关通了，也不代表到外网通，还要看路由和远端防火墙。
4.2 traceroute 和 mtr：看链路到底断在哪一跳
ping 只告诉你通不通，traceroute 能告诉你路是怎么走的：
traceroute -n -T -p 443 example.com-n不做反向解析，速度快很多；-T用 TCP 包探测，-p指定端口，比默认的 UDP 更贴近真实应用。输出里每一行是一个中转节点，如果某些节点显示* * *，可能是节点禁回了探测包，不代表线路断，只要最终能到目标就可以。
我更推荐用 mtr，它把 ping 和 traceroute 合并成一个持续更新的界面：
mtr -n 192.168.1.1能看到每一跳的丢包率和延迟。判断问题时，重点看最后一跳的丢包，以及哪一跳开始出现明显丢包。最后一跳丢包而前面正常，可能是目标设备自身限速；中间某跳丢包而最终还能通，可能是链路负载较高但还没断。这些细节比单个 ping 结果有说服力得多。
4.3 ss 和 netstat：端口和连接状态到底怎么看
应用层说“连不上”，多数时候问题出在传输层：端口没监听或被防火墙挡住。最常用的命令：
ss -tlnp # 查看所有 TCP 监听端口及对应进程 ss -tn state established # 查看已建立的 TCP 连接 netstat -tlnp # 旧命令，部分环境没装 ss 时备用ss -tlnp输出里有State、Local Address:Port、Process几列。LISTEN表示服务在等连接进入，ESTABLISHED表示连接已建立，TIME_WAIT是连接关闭后等一会儿再释放的状态，这是正常现象。如果端口显示在监听，但外面连不上，多半不是服务问题，而是防火墙；如果根本看不到监听，那先排查服务有没有起来。
想测试端口通不通，可以telnet 192.168.1.100 3306，或者用更现代的nc -vz 192.168.1.100 3306。注意有些环境没装这些工具，但只要有 bash，可以用timeout 3 bash -c 'echo >/dev/tcp/192.168.1.100/3306'判断端口通不通，这也是我常用的免安装办法。
4.4 一套适合大多数排障场景的排查顺序
结合前面的分层思路，我总结了一个排查网络故障的固定顺序，基本覆盖八成场景：
- 先看接口状态：
ip -br addr，确认网卡是UP且LOWER_UP。 - 看 IP 和掩码：确认地址属于预期的网段，网关地址也在同一网段。
- 看路由表：
ip route，确认有默认路由，且via地址是正确网关。 - ping 网关：确认二层链路和本机出口没问题。
- ping 远端 IP：确认三层路由和远端可达性。
- 解析域名：
dig example.com，确认 DNS 没问题。 - 用具体端口测试：
ss看服务监听，nc或telnet测端口。 - 以上都正常但应用还是不通，再抓包看实际交互。
这套顺序的精髓是：不要越级排查。很多人一上来就抓包改防火墙，大部分时候是在绕远路。我处理过的网络故障里，至少一半在前三步就已经暴露了问题。
5. DNS 解析与常见坑
5.1 一次域名解析到底发生了什么
DNS 解析的顺序并不像很多教程说的“先 hosts 后 DNS”那么死板，它由/etc/nsswitch.conf里的hosts:行决定，通常默认是files dns，意思是先查/etc/hosts，再走 DNS。应用调用getaddrinfo时，会按这个顺序去解析域名。所以你要排查“某个域名为什么解析到老 IP”时，先确认/etc/hosts里有没有覆盖条目。
/etc/resolv.conf里nameserver指定了向谁问 DNS，search表示访问不带点的主机名时自动附加的搜索域。比如配置了search example.com，你解析db时，系统会依次尝试db.example.com和db。这个东西能让你少打几个字，但也可能让解析多绕几轮，导致首包延时长。
5.2 解析慢、解析不到，怎么定位
最贴近应用的解析命令是：
getent hosts example.com它走的是和应用程序相同的解析流程，如果它能解析出正确 IP，但ping example.com不通，那问题大概率不在 DNS，而在网络层。dig和nslookup则直接查询 DNS 服务器，适合看具体响应：
dig example.com dig @192.168.1.1 example.com nslookup example.com 192.168.1.1dig结果里的Query time就是响应耗时。如果耗时一直在几秒，很可能是 DNS 服务器响应慢，或者它要去上游递归查询时网络延迟高。
5.3 我遇到过的几个 DNS 坑
第一个坑是resolv.conf里的 nameserver 指向一个已经下线或不通的内网 DNS，导致外网域名解析超时。排查时用dig @8.8.8.8 example.com对比，如果指定公共 DNS 秒回，而默认 DNS 超时，问题就很明显。但生产环境不一定能直接访问外网 DNS，可以把nameserver改成核心网里真正可用的 DNS 地址。
第二个坑是 systemd-resolved 的本地监听。有些 Ubuntu 系统的/etc/resolv.conf指向127.0.0.53，这是一个本地缓存服务，正常情况下没问题，但你直接修改/etc/resolv.conf会被 NetworkManager 或 systemd 覆盖。这时候要么通过 netplan/NetworkManager 改，要么关掉 systemd-resolved，别和系统服务抢文件。
第三个坑是 IPv6 解析导致超时。有的域名解析时先尝试 AAAA 记录，如果网络没有 IPv6 路由，等待超时后才回退到 IPv4，用户体感就是“打开慢”。排查时可临时把机器的 IPv6 关掉或调整gai.conf的优先级，看是否恢复正常。这个现象在新装的容器环境里尤其常见。
5.4 hosts 文件仍然好使
本地测试、临时切换、视线内屏蔽某些域名时，修改/etc/hosts是最快的办法：
192.168.1.100 db.example.com注意格式是“IP 空格 域名”，域名别加http://。改完立刻生效，不需要重启服务。/etc/hosts的优先级通常高于 DNS，这个特性偶尔会被运维用来做流量切换，但也可能造成“远程服务器已经迁移 IP 了，我这边还在连旧 IP”的误判。遇到解析诡异时，先grep -i 域名 /etc/hosts看一眼，别先怀疑 DNS 服务器。
6. 常见故障场景与排查记录
6.1 三种“不通”的区分
很多同事说“网络不通”，其实说的是完全不同的三种情况：
| 症状 | 底层原因 | 最常用排查 |
|---|---|---|
| 同网段 ping 不通 | 二层不通，可能是网卡、网线、交换机 VLAN | ip -br addr、arping |
| 跨网段 ping 不通 | 三层路由问题，网关没配或路由丢失 | ip route、ping 网关、traceroute |
| 端口连不上但 IP 通 | 四层问题，服务没监听或防火墙拦截 | ss -tlnp、nc、防火墙规则 |
分清类型很重要。因为“IP ping 得通但 3306 连不上”和“IP 根本 ping 不通”是两个排查方向，前者重点看防火墙和服务，后者重点看网络拓扑和路由。你连故障类型都没分清楚，就急着看抓包结果，很容易浪费时间。
6.2 一次“应用连接慢”的真实排查记录
有一次我遇到一个比较典型的慢连接问题，症状是某个运维平台访问后端服务时，偶尔要卡五六秒才返回。我按上面的排查顺序走了一遍：ss -tlnp看到服务端口在监听；ping后端 IP 只用了 0.2ms，延迟极小；traceroute链路也就一跳，没有丢包；试了curl直接访问 IP，几乎秒回。到这里基本锁定不是网络链路，而是域名解析环节。
接着getent hosts发现解析要 4 秒多，看了/etc/resolv.conf，nameserver 指向一个边缘防火墙上的内网 DNS，那个 DNS 对上层的递归查询经常超时。我把指向改成核心网一个健康的 DNS 地址，再测，解析和访问都恢复正常。整个过程最有价值的一步，是用getent hosts模拟了应用的真实解析路径，避免了在链路层瞎转。这个案例之后，我排查任何上层应用卡顿，都会先检查 DNS。
6.3 tcpdump 抓包：当其他手段都查不出问题时
tcpdump 是 Linux 排障的终极手段，它直接看网卡上实际收发的报文：
sudo tcpdump -i eth0 -nn -c 10 host 192.168.1.200 and tcp port 3306-i指定网卡，-nn不做端口和地址反解，-c抓 N 个包后自动退出，host加port是过滤条件。想看 HTTP 报文细节可以加-A，想把抓到的内容保存成文件分析，用sudo tcpdump -i eth0 -w /tmp/result.pcap，然后配合可视化工具读取。
实际困扰大家的是怎么根据抓包结果判断问题。最经典的场景是 TCP 连接建立超时，你抓到本机发出的 SYN 包，但一直看不到对端回 SYN-ACK，说明中间有设备把 SYN 丢了，通常是防火墙；如果对端回了 SYN-ACK，但本机没有回 ACK，那问题多半在本机内核或本机防火墙。有了这个对照，你就不再靠猜了。tcpdump 抓包要 root 权限，抓的时候注意过滤条件写具体点，否则流量稍大就是一屏刷屏，反而看不出重点。
写到这里，Linux 网络基础的第一篇差不多就到位了。我自己在实战里最大的体会是：网络排查不是一个命令技巧问题，而是一个“分层思维”问题。每次遇到网络故障，先别急着敲命令，花十秒钟想一下故障最可能在哪一层，再决定用什么工具，往往比乱敲一气高效得多。还有个小建议：配置任何网络参数前，先备份原始配置，改远程机器时想好回滚路径，这两句话能帮你挡住绝大多数灾难性事故。下一篇我打算顺着“路由”这个主题继续写，把静态路由、策略路由和 Linux 下常见路由坑讲透，也欢迎大家在评论里说说你遇到过的网络灵异事件，说不定就成了下一篇文章的素材。