第 4 章端口与反向代理：为什么是 443，Nginx 在门口排班

一台机器一个 IP，可上面同时跑着好几个程序——访客的请求进了楼，该敲哪扇门？答案是端口（Port）：IP 找到楼，端口找到房间。房间号从 0 到 65535，其中三个名门必须背下：80 = HTTP，443 = HTTPS，22 = SSH。浏览器里输网址不用写端口，是因为它默认拨 443；而你本地开发时那个 localhost:3000，此刻也彻底通了——你的开发服务器住在自己电脑的 3000 号房。

于是新问题来了：DO 上跑着一个监听 3000 的程序，总不能让全世界访问 我们的域名:3000 吧？而且 443 的门口需要 HTTPS 证书，谁来管？答案是在大门口安排一位前台：反向代理（Reverse Proxy），最常见的这位叫 Nginx。所有访客一律敲 443 的大门，Nginx 接待，按规则把请求转给屋里正确的房间，再把回答递出去。它的排班表长这样：

nginx

server {
  listen 443 ssl;
  server_name api.example.com;

  location / {
    proxy_pass http://localhost:3000;
  }
}

逐行读：听 443 号门（带加密）；只认这个域名的访客；一切请求，转给本机 3000 号房。为什么叫"反向"？一句话：正向代理替访客出门办事，反向代理替服务器在门口接客。Nginx 顺手还干几件事：挂 HTTPS 证书（配合 Let's Encrypt 这类免费证书自动续期）；一台机器伺候多个域名（不同 server_name 分流到不同房间）；静态文件不劳烦后面的程序、自己直接发。

现在可以做一次全景合龙了。把第一册第 1 章那"半秒钟"补成完整旅程：浏览器 → Cloudflare（橙云，第 1 章）→ 源站 443 号门 → Nginx 前台（本章）→ localhost:3000 的进程（第 3 章的管家看着它）→ 响应原路返回。这条链上的每一站，你现在都认识了。而 Vercel 呢？它把 443、证书、转发全部打包代劳了——平台的本质，就是替你雇好了这一整条链上的工作人员。用平台还是自己雇（DO + Nginx），是成本与控制的取舍，第 10 章见。

出事时想起我

502 Bad Gateway——前台在，后面的人死了（Nginx 活着，但 3000 号房没人应，去第 3 章 systemctl status）；Connection refused——那个端口根本没人在听（程序没起，或端口号对不上）；改了 Nginx 配置没反应——先 nginx -t 检查语法，再 reload，配置不会自己生效。

关键领悟

端口回答"找哪个房间"，反向代理回答"访客只需要知道大门"。443 门口那位 Nginx，就是把"一台机器上的很多程序"伪装成"一个体面网站"的全部秘密。

试一试（安全档：只读）

SSH 上 DO，跑 ss -tlnp 看看这台机器上谁在听哪些端口——每一行都是一个"房间与住户"。再找找 /etc/nginx/sites-enabled/：有，就把排班表逐行翻译给自己听；没有，也算重大发现——去问 AI："这台机器上的服务是怎么对外说话的？"

第 4 章 端口与反向代理：为什么是 443，Nginx 在门口排班 ​

第 4 章端口与反向代理：为什么是 443，Nginx 在门口排班