DNS 解析与反向代理：为什么你配好了网站还是访问不了？

引言

刚接触建站时，有两个问题困扰了我很久：

DNS 解析只填 IP，为什么不填端口号？
DNS 已经把域名指向服务器了，为什么还要配反向代理？

这两个问题本质上是同一个问题：从你输入网址到看到页面，中间到底发生了什么？ 搞清楚之后你会发现，答案并不复杂。

本文用 blog.example.com 代替真实域名，203.0.113.1 为示例 IP，具体软件以 1Panel + Nginx 为例，原理适用于所有建站环境。

一、DNS：互联网的电话簿

DNS 做什么？

DNS（域名系统）能存很多种记录（邮件用的 MX、验证用的 TXT、别名用的 CNAME 等），但在建站这件事里，它最核心的工作只有一件：把域名翻译成 IP 地址。

你输入：blog.example.com
DNS 返回：203.0.113.1

它就像一个电话簿——你查”张三”，得到一串电话号码。至于这个号码是手机还是座机、找的是张三本人还是他秘书，电话簿不管。

端口号从哪来？

我们建站时添加的 A 记录（IPv4）和 AAAA 记录（IPv6）里只有 IP 地址，没有端口这一项。端口是浏览器根据协议自动补齐的：

你输入	浏览器实际连接
`http://blog.example.com`	`203.0.113.1:80`
`https://blog.example.com`	`203.0.113.1:443`

所以 A 记录不可能把 blog.example.com 解析成 203.0.113.1:8080。如果服务跑在非标准端口，就必须把端口手动写进 URL：http://blog.example.com:8080。

DNS 里其实也有能携带端口的记录类型（如 SRV、HTTPS 记录），但浏览器访问普通网站时基本不靠它们指定端口，建站时可以不考虑。

小结：DNS 只负责”这个域名对应哪台服务器”，不负责”到了服务器之后找哪个门”。

二、反向代理：服务器门口的接待员

问题出在哪？

DNS 告诉浏览器服务器在哪，浏览器再按 https 协议默认去敲服务器的 443 端口。但你的博客程序（Typecho 之类）实际跑在 8080 端口，443 端口上根本没人。

你做的事	结果
访问 `https://blog.example.com`	❌ 连接失败，443 端口没有程序在监听
访问 `http://203.0.113.1:8080`	✅ 防火墙放行 8080 时能打开，但暴露了 IP 和端口、没有 HTTPS

反向代理怎么解决？

在 443 端口放一个”接待员”——Nginx（1Panel 默认使用的 OpenResty 就是基于 Nginx 的发行版）。它的核心工作是：看请求里访问的是哪个域名，转发给对应的后端服务。

访客 → https://blog.example.com（443 端口）
          ↓
     Nginx 接待（443 端口）← SSL 证书在这里统一解密
          ↓
     按域名转发：blog.example.com → http://127.0.0.1:8080
          ↓
     博客服务（8080 端口）← 真正干活的

它解决的不止是端口问题

问题	没有反代	有反代
多站共存	443 端口只能给一个程序用，只能跑一个站	按域名分流，一台服务器跑 N 个站
HTTPS	每个后端服务各自配证书	Nginx 统一处理，后端不需要关心
安全	用户直连后端，暴露真实端口	用户只接触 Nginx，后端可以只对本机开放
换端口	后端换端口，所有链接里的端口号都得跟着改	只改 Nginx 里的转发地址，访客无感知

注意： 后端”藏起来”不是自动的。如果后端监听的是 0.0.0.0:8080，外网照样能直接访问。要么让它只监听 127.0.0.1，要么在防火墙/安全组里不放行 8080。用 Docker 的话尤其要小心：端口映射写成 8080:8080 会绕过 ufw 等防火墙规则，应写成 127.0.0.1:8080:8080。

小结：DNS 解决了”找到服务器”的问题，反向代理解决了”到服务器后找哪个服务”的问题。

三、全流程串联

把上面两步拼起来，一次完整的访问是这样的：

① 浏览器问 DNS：blog.example.com 的 IP 是多少？
② DNS 回答：203.0.113.1
③ 浏览器按 https 补上默认端口，连接 203.0.113.1:443
        │
        ▼
   [ 可选：CDN / 云防火墙 ]
        │
        ▼
④ Nginx（监听 443）：解密 HTTPS，看访问的域名是 blog.example.com
        │
        ▼
⑤ 按反向代理规则，转发到 127.0.0.1:8080
        │
        ▼
⑥ 博客服务处理请求，响应沿原路返回给浏览器

如果开启了 CDN（比如 Cloudflare 的”小黄云”代理），第 ② 步 DNS 返回的是 CDN 节点的 IP，而不是你服务器的 IP，再由 CDN 回源连接你的服务器。

整个流程里需要你亲手配置的只有两处：在 DNS 服务商处添加解析记录，以及 在 Nginx 中配置反向代理规则。其余都是自动完成的。

四、少了谁都不行

搞懂了各自的作用，自然就能回答”缺一个会怎样”。

场景一：只有 DNS，没有反向代理

用户 → DNS → 服务器:443 → 没有程序监听 → 连接失败 ❌

请求成功到达了服务器，但 443 端口空空荡荡，没人接待。就像快递到了小区门口，但没有门卫告诉你具体哪栋楼。

如果服务器上 Nginx 已经在运行（比如装了 1Panel 的 OpenResty），只是没给这个域名配规则，表现就不是连接失败，而是打开了默认站点、出现 404，或者浏览器提示证书与域名不匹配。

场景二：只有反向代理，没有 DNS

用户 → 查询 DNS → 查无此域名 → 浏览器直接报错 ❌
                （DNS_PROBE_FINISHED_NXDOMAIN）

DNS 查询失败，浏览器不知道该连哪台服务器，请求根本到不了你的服务器，Nginx 配得再好也是自娱自乐。就像公司内部有完美的前台接待系统，但你的电话号码根本没登记在号簿上。

对比一览

缺了谁	请求到哪一步停了	报错表现
缺 DNS	浏览器 → DNS → 断在这	`无法访问此网站`（`DNS_PROBE_FINISHED_NXDOMAIN`）
缺反代	浏览器 → DNS → 服务器 → 断在这	`连接被拒绝`；若防火墙直接丢包则是 `连接超时`
都不缺	浏览器 → DNS → 服务器 → Nginx → 服务 ✅	正常打开

总结

把整篇文章浓缩成一段话：

你寄一个快递—— DNS 是查地图找到小区地址，反向代理 是小区门卫根据收件人姓名把快递送到具体的楼栋单元。没有地址，快递员出不了门；没有门卫，快递堆在大门口找不到你。

建站时你需要做的两件核心的事：

在 DNS 服务商处添加一条 A 记录（IPv6 则是 AAAA 记录）→ 让域名指向服务器 IP
在 Nginx 配一条反向代理规则 → 让服务器知道这个域名对应哪个本地端口

此外还有几件容易漏的事：

放行端口：云服务器的安全组和系统防火墙都要放行 80 和 443。
申请证书：要用 HTTPS，得给域名申请 SSL 证书（1Panel 里可以一键申请 Let’s Encrypt 证书）。
备案：如果服务器在中国大陆，域名需要先完成 ICP 备案，否则 80/443 端口的访问会被拦截。
等待生效：新加的解析记录可能要几分钟才能生效，修改已有记录则要等旧记录的缓存（TTL）过期。

这些都搞定，你的网站就能被全世界访问了。