计算机网络基础与运维排障指南

计算机网络是运维排障中最基础、也最容易被低估的一层。很多看起来像“服务坏了”的问题，实际原因可能是 DNS 没解析、端口没监听、防火墙没放行、服务只绑定了 127.0.0.1，或者反向代理无法连接后端。

本文围绕日常运维最常见的网络概念与命令进行整理，并将它们放到真实部署场景中理解。

网络访问的基本链路#

访问一个网站时，通常会经过下面几个步骤：

1
输入域名
2
  ↓
3
DNS 解析域名为 IP
4
  ↓
5
客户端连接服务器 IP 的指定端口
6
  ↓
7
防火墙 / 安全组判断是否允许访问
8
  ↓
9
Nginx / Web 服务接收请求
10
  ↓
11
返回网页或转发给后端服务

如果页面打不开，需要沿着这条链路逐层排查，而不是只盯着应用本身。

IP 地址：定位哪一台机器#

IP 地址用于标识网络中的一台设备。

常见 IP 分为两类：

类型	说明	示例
私有 IP	内网使用，通常不能直接从公网访问	`10.0.0.5`、`172.16.0.10`、`192.168.1.20`
公网 IP	可以通过互联网访问，通常绑定在云服务器上	`119.28.14.125`

云服务器一般同时存在：

内网 IP：用于同一云厂商内网通信。
公网 IP：用于外部用户访问。

在 Linux 中查看本机 IP：

1
ip addr
2
ip a
3
hostname -I

hostname -I 输出更简洁，适合快速确认当前机器拥有的 IP 地址。

端口：定位机器上的哪一个服务#

如果 IP 是一台机器的地址，端口就是这台机器上不同服务的入口。

常见端口：

服务	默认端口
SSH	`22`
HTTP	`80`
HTTPS	`443`
MySQL	`3306`
PostgreSQL	`5432`
Redis	`6379`
Jenkins	`8080`
SonarQube	`9000`

例如：

1
119.28.14.125:80

表示访问 119.28.14.125 这台服务器上的 80 端口。

在个人博客部署中，浏览器访问域名时通常会连接：

80：HTTP
443：HTTPS

如果这两个端口没有开放，网站就无法正常访问。

localhost、127.0.0.1 与 0.0.0.0#

这是网络排障中非常重要的一组概念。

localhost#

localhost 表示“当前这台机器自己”，通常对应：

1
127.0.0.1

需要注意：localhost 的含义取决于命令在哪里运行。

场景	localhost 指向
Windows 浏览器	Windows 本机
WSL 终端	WSL 环境
Docker 容器	当前容器
远程服务器	远程服务器自己
Kubernetes Pod	当前 Pod

因此，不能简单认为“localhost 就是自己的电脑”。它永远代表“当前运行环境本身”。

127.0.0.1#

服务绑定到 127.0.0.1 时，通常表示只允许本机访问。

例如：

1
127.0.0.1:5000

这意味着服务只监听本机回环地址。其他机器即使知道服务器 IP，也无法直接访问这个服务。

0.0.0.0#

服务绑定到 0.0.0.0 时，表示监听本机所有网络接口。

例如：

1
0.0.0.0:5000

在防火墙和安全组允许的情况下，外部机器可以通过服务器公网 IP 访问该服务。

常见例子：

1
app.run(host="0.0.0.0", port=5000)

如果 Flask、Node.js、Spring Boot 等服务只绑定 127.0.0.1，外部访问失败是正常现象。

DNS：把域名转换成 IP#

DNS 的作用是将域名解析为 IP 地址。

例如访问：

1
tiancheng-blog.com

浏览器会先查询这个域名对应的 IP，然后再连接服务器。

常用 DNS 排查命令：

1
nslookup tiancheng-blog.com
2
dig tiancheng-blog.com
3
host tiancheng-blog.com

如果没有 dig 或 nslookup：

1
sudo apt update
2
sudo apt install dnsutils

常见 DNS 问题：

现象	可能原因
域名无法访问，IP 可以访问	DNS 没配置或未生效
域名解析到旧 IP	DNS 缓存未刷新
`www` 可以访问，根域名不能访问	只配置了 `www` 记录
根域名可以访问，`www` 不能访问	没配置 `www` 记录

个人博客常见 DNS 配置：

主机记录	类型	值
`@`	A	服务器公网 IP
`www`	A 或 CNAME	服务器公网 IP 或根域名

查看端口监听状态#

服务是否能被访问，首先要确认端口是否真的在监听。

1
ss -tuln

参数含义：

参数	含义
`-t`	TCP
`-u`	UDP
`-l`	listening，正在监听
`-n`	显示数字端口，不反查服务名

查看进程信息：

1
sudo ss -tulnp

示例：

1
LISTEN 0 511 0.0.0.0:80
2
LISTEN 0 511 0.0.0.0:443
3
LISTEN 0 128 0.0.0.0:22

含义：

80 正在监听：HTTP 服务可接收请求。
443 正在监听：HTTPS 服务可接收请求。
22 正在监听：SSH 可以连接。
0.0.0.0 表示监听所有网卡。

如果只看到：

1
127.0.0.1:3000

说明该服务只允许本机访问，外部不能直接访问。

ping：测试基础连通性#

ping 用于测试网络连通性和延迟。

1
ping -c 4 tiancheng-blog.com

-c 4 表示只发送 4 次请求。

ping 可以帮助判断：

域名是否能解析。
网络是否大致连通。
延迟是否异常。

但要注意：

Ping 不通，不一定代表网站不可访问。

原因是很多服务器、防火墙或云安全组会禁用 ICMP，但 HTTP/HTTPS 仍然正常。

因此，检查网站服务时，curl 往往比 ping 更直接。

curl：检查 HTTP / HTTPS 服务#

curl 是运维排查 Web 服务时最常用的工具之一。

查看网页内容：

1
curl https://tiancheng-blog.com

只查看响应头：

1
curl -I https://tiancheng-blog.com

常见状态码：

状态码	含义	运维排查方向
`200`	请求成功	服务正常
`301` / `302`	重定向	检查 HTTP 跳转 HTTPS、域名跳转
`400`	请求格式错误	检查请求参数或代理配置
`401`	未认证	检查登录认证
`403`	没有权限	检查目录权限、Nginx 配置、安全策略
`404`	页面不存在	检查文件路径、路由、静态资源
`500`	服务内部错误	检查应用日志
`502`	网关无法连接后端	检查后端服务是否启动、端口是否正确
`503`	服务不可用	检查服务状态和负载
`504`	网关等待后端超时	检查后端响应速度、代理超时配置

例如静态博客部署后出现 403 Forbidden，常见原因包括：

Nginx 的 root 指向目录没有 index.html。
文件权限不允许 Nginx 读取。
静态文件没有解压到正确目录。
Nginx 配置的站点目录和实际上传目录不一致。

防火墙与云安全组#

服务器上服务正常监听，不代表外部一定可以访问。请求还需要通过：

云平台安全组 / 防火墙
Linux 本机防火墙
Nginx 或应用本身配置

以云服务器部署网站为例，至少需要开放：

端口	用途
`22`	SSH 登录
`80`	HTTP 访问与证书申请
`443`	HTTPS 访问

查看 UFW 状态：

1
sudo ufw status

允许端口：

1
sudo ufw allow 80/tcp
2
sudo ufw allow 443/tcp

如果使用云服务器控制台，还需要在安全组里放行对应端口。只在服务器里开放端口，但云安全组没放行，外部仍然访问不了。

Nginx 场景下的网络排查#

静态博客部署时，Nginx 通常负责监听 80 和 443，并把请求映射到本地文件目录。

常用检查命令：

1
sudo nginx -t
2
sudo systemctl status nginx
3
sudo systemctl reload nginx

检查 Nginx 是否监听端口：

1
sudo ss -tulnp | grep nginx

检查网页是否能从服务器本机访问：

1
curl -I http://127.0.0.1
2
curl -I http://localhost

如果本机访问成功，但外部访问失败，通常重点检查：

云安全组是否开放 80 / 443。
DNS 是否解析到正确公网 IP。
服务器公网 IP 是否正确。
是否存在运营商、浏览器缓存或 DNS 缓存。

如果本机访问也失败，则重点检查：

Nginx 是否启动。
Nginx 配置是否正确。
站点目录是否存在。
目录内是否有 index.html。
文件权限是否正确。

一套常用排查流程#

网站无法访问时，可以按以下顺序排查：

1. 确认域名解析#

1
dig tiancheng-blog.com
2
nslookup tiancheng-blog.com

确认结果是否指向正确的服务器公网 IP。

2. 确认服务器端口监听#

1
sudo ss -tulnp

确认 80、443 是否处于监听状态。

3. 确认本机访问#

在服务器上执行：

1
curl -I http://127.0.0.1
2
curl -I https://tiancheng-blog.com

如果本机访问异常，优先查 Nginx 和站点文件。

4. 确认防火墙和安全组#

检查云控制台是否开放：

1
TCP 80
2
TCP 443
3
TCP 22

同时检查服务器防火墙：

1
sudo ufw status

5. 查看日志#

Nginx 日志通常在：

1
/var/log/nginx/access.log
2
/var/log/nginx/error.log

查看最近错误：

1
sudo tail -n 50 /var/log/nginx/error.log

实时查看日志：

1
sudo tail -f /var/log/nginx/access.log
2
sudo tail -f /var/log/nginx/error.log

日志能直接说明请求是否到达 Nginx，以及失败原因是什么。

常见故障与判断方式#

现象	优先检查
域名打不开，IP 可以打开	DNS 解析
IP 也打不开	防火墙、安全组、Nginx 是否监听
HTTP 可以，HTTPS 不行	证书、443 端口、Nginx SSL 配置
首页能打开，静态资源 404	资源路径、部署目录、构建产物
返回 403	文件权限、Nginx root、目录内是否有 index.html
返回 502	Nginx 代理的后端服务是否启动
返回 504	后端响应慢、代理超时
SSH 能连，网站不能访问	80/443 是否开放，Nginx 是否运行

运维视角下的核心理解#

网络问题不应只看“能不能打开页面”，而应该拆成几层：

1
DNS 是否正确
2
IP 是否可达
3
端口是否开放
4
服务是否监听
5
防火墙是否放行
6
代理配置是否正确
7
应用是否正常响应
8
日志是否有错误

每一层都有对应工具：

层次	常用命令
DNS	`dig`、`nslookup`、`host`
连通性	`ping`
HTTP / HTTPS	`curl -I`
端口监听	`ss -tulnp`
服务状态	`systemctl status`
Nginx 配置	`nginx -t`
日志	`tail -f`、`journalctl`

小结#

计算机网络基础在运维中主要解决三个问题：

请求有没有找到正确的机器。
请求有没有进入正确的端口。
请求进入服务后有没有被正确处理。

对应到核心概念：

IP：定位机器。
端口：定位服务。
DNS：把域名转换成 IP。
localhost / 127.0.0.1：当前机器本身。
0.0.0.0：监听所有网络接口。
ping：测试基础网络连通性。
curl：测试 HTTP / HTTPS 服务响应。
ss：查看端口监听情况。
防火墙 / 安全组：决定请求能否进入服务器。

在实际运维中，排查网络问题的关键不是记住单个命令，而是建立“从域名到服务”的链路思维。只要能按链路逐层定位，绝大多数网站访问异常、端口不通、反向代理错误和部署问题都可以被快速缩小范围。

音乐

音乐