古法网络入门

• localhost 与等待的地址 ── 在 127.0.0.1 上等待手机访问不到，在 0.0.0.0 上就可以（实测）
• Docker ── 容器是电脑里的另一台电脑。-p 是改写目标地址（实测与 Wireshark）
• 容器里的 localhost ── 为什么用 localhost 连不上数据库，以及用名字访问的方法（实测）
• 代理 ── 公司代理的 CONNECT、NO_PROXY、开发服务器的代理为什么能消除 CORS（实测）

练习时，把云端的 Linux 当作“开发者的电脑”。在这台电脑上运行 Docker 29，用网络命名空间在家里的局域网放一台手机（192.168.1.20），在另一个地方做一个“公司”（公司内的电脑和代理）。申请 API 是练习用的，会返回请求来自谁（you）和自己是谁（me）。

电脑除了连到外面的口（局域网口、Wi-Fi），还有一个只折返回自己的口：环回（lo）。地址是 127.0.0.1。其实以 127 开头的地址全都是环回，在练习电脑上发往 127.0.0.2 也回到了自己。发到这里的数据包，既不上网线，也不上电波。

而 localhost 是名字。和第 9 讲的名字一样，通过操作系统的 hosts 等变成地址。通常是 127.0.0.1，但也可能是 IPv6 的环回 ::1。练习用的云端 Linux 没有 IPv6，所以只有这一部分是在另一台 Linux（Ubuntu 22.04）上试的。

# 让服务器只在 ::1（IPv6 的环回）上等待，用 localhost 访问
# curl 两个都试
pc$ curl -v http://localhost:18011/
    *   Trying 127.0.0.1:18011...
    * connect to 127.0.0.1 port 18011 failed: Connection refused
    *   Trying ::1:18011...
    * Connected to localhost (::1) port 18011
    < HTTP/1.0 200 OK
# Node.js 的 fetch 只试 127.0.0.1
pc$ node -e "fetch('http://localhost:18011/')"
    ECONNREFUSED
# 顺便一提，这台电脑的 hosts 里 localhost 只对应 127.0.0.1
pc$ grep localhost /etc/hosts
    127.0.0.1 localhost
    ::1 ip6-localhost ip6-loopback

同样是“localhost”，curl 在 127.0.0.1 被拒后又试了 ::1 并连上；Node.js 的 fetch 只试了 127.0.0.1，结果是 ECONNREFUSED。服务器只在 ::1 上等，调用方却去找 127.0.0.1——这是“服务器明明在运行却连不上”的典型。

服务器不仅决定端口，还决定在哪个口上等。把同一个 API 分别在 127.0.0.1 的 3000 号和 0.0.0.0 的 3001 号上启动。

# 让同一个 API 分别在 127.0.0.1:3000 和 0.0.0.0:3001 上等待
pc$ ss -ltn
    Local Address:Port
    127.0.0.1:3000
    0.0.0.0:3001
# 从电脑自身
pc$ curl http://localhost:3000/api/whoami
    {"you":"127.0.0.1","me":"pc","listen":"127.0.0.1:3000"}
pc$ curl http://127.0.0.2:3001/api/whoami
    {"you":"127.0.0.1","me":"pc","listen":"0.0.0.0:3001"}
# 从同一局域网的手机
phone$ curl http://192.168.1.10:3000/api/whoami
    curl: (7) Failed to connect to 192.168.1.10 port 3000 after 0 ms
phone$ curl http://192.168.1.10:3001/api/whoami
    {"you":"192.168.1.20","me":"pc","listen":"0.0.0.0:3001"}
# 在 3001 号上再启动一个
    Error: listen EADDRINUSE: address already in use 0.0.0.0:3001
# 是谁在用 3001 号
pc$ ss -ltnp 'sport = :3001'
    0.0.0.0:3001   users:(("node",pid=748,fd=21))

在 127.0.0.1 上等待，只在内侧的口等，所以同一局域网的手机被拒绝（就算是电脑自己，发往局域网地址 192.168.1.10 也会被拒）。0.0.0.0 是“所有的口都等”这种等待方式的标记，手机能访问，API 看到的是手机的地址 192.168.1.20。

想用手机确认页面时，卡住的就是这里。开发服务器 Vite 平时只在 localhost 上等，加上 --host 才向局域网开放。

# 加上 --host 就会向局域网公开（出现 Network 行。节选）
pc$ npx vite --host --port 5174
    ➜  Local:   http://localhost:5174/
    ➜  Network: http://192.168.1.10:5174/
    ➜  Network: http://172.17.0.1:5174/
    ➜  Network: http://172.18.0.1:5174/
phone$ curl http://192.168.1.10:5174/   → 200
phone$ curl http://192.168.1.10:5173/   → curl: (7) Failed to connect

Network 行里列出了电脑拥有的所有口，包括 docker0（172.17.0.1）等。手机能访问的，只有同一局域网的 192.168.1.10。

把 API 放进容器，用 -p 8080:3000 启动。从里面和外面看看周围。

# 在容器里运行 API，把电脑的 8080 号接到容器的 3000 号
pc$ docker run -d --name nw11-api -p 8080:3000 … node api11.mjs
# 从容器内部看到的自己
api$ ip -4 addr; ip route
    inet 127.0.0.1/8 scope host lo
    inet 172.17.0.2/16 … eth0
    default via 172.17.0.1 dev eth0
# 电脑一侧：名为 docker0 的网桥，和改写地址的规则
pc$ ip -4 addr show docker0
    inet 172.17.0.1/16 … docker0
pc$ iptables -t nat -S DOCKER
    -A DOCKER ! -i docker0 -p tcp --dport 8080
       -j DNAT --to-destination 172.17.0.2:3000
pc$ ss -ltnp 'sport = :8080'
    0.0.0.0:8080   users:(("docker-proxy",…))
# 从电脑 / 从手机
pc$ curl http://localhost:8080/api/whoami
    {"you":"172.17.0.1","me":"api","listen":"0.0.0.0:3000"}
phone$ curl http://192.168.1.10:8080/api/whoami
    {"you":"192.168.1.20","me":"api","listen":"0.0.0.0:3000"}

容器里有自己的 eth0（172.17.0.2）和自己的 lo（127.0.0.1）。出去的路是 172.17.0.1，也就是 Docker 在电脑上建的、名为 docker0 的网桥（第 3 讲交换机的同类）。容器就是放在电脑里的另一台小电脑。

那么 -p 8080:3000 做了什么？电脑的规则里多了一行：“发到 8080 号的，把目标改写成 172.17.0.2 的 3000 号”（DNAT）。这和第 5 讲家用路由器的 NAT 是同一个机制，这次由电脑来当路由器。

手机的请求，在电脑入口处是发往 192.168.1.10 的 8080 号，在容器跟前变成发往 172.17.0.2 的 3000 号。发送方仍是手机，所以 API 回答“来自 192.168.1.20”。另一方面，从电脑自己发往 localhost:8080，回答是“来自 172.17.0.1”。这是因为由 Docker 的中继 docker-proxy 接收，再替你重新连接。

既然容器是“另一台电脑”，容器里的 localhost 就是那个容器自己。下面重现三个常见的坑。

# ① 容器里的应用在 127.0.0.1 上等待（-p 8081:3000）
pc$ curl http://localhost:8081/api/whoami
    curl: (56) Recv failure: Connection reset by peer
phone$ curl http://192.168.1.10:8081/api/whoami
    curl: (7) Failed to connect to 192.168.1.10 port 8081 after 0 ms
# ② 只在电脑内部公开（-p 127.0.0.1:8082:3000）
pc$ curl http://localhost:8082/api/whoami
    {"you":"172.17.0.1","me":"local","listen":"0.0.0.0:3000"}
phone$ curl http://192.168.1.10:8082/api/whoami
    curl: (7) Failed to connect to 192.168.1.10 port 8082 after 0 ms
# ③ 从容器访问电脑上运行的开发服务器（3000＝127.0.0.1，3001＝0.0.0.0）
pc$ docker run --add-host=host.docker.internal:host-gateway …
    localhost:3001             → 127.0.0.1    ECONNREFUSED
    host.docker.internal:3001  → 172.17.0.1   连上了
    host.docker.internal:3000  → 172.17.0.1   ECONNREFUSED

① 容器里的应用在 127.0.0.1 上等待时，经 DNAT 到达 eth0 的请求收不到，从电脑访问是“Connection reset by peer”，从手机访问是“连不上”。容器里的应用要在 0.0.0.0 上等待。② 只想在电脑内部公开时，像 -p 127.0.0.1:8082:3000 这样写上口。什么都不写，Docker 就在所有的口（0.0.0.0）上公开。Docker 的文档也提醒，默认情况下外面也能看到。③ 从容器调用电脑上的开发服务器时，localhost 是容器自己，所以访问不到。用 host.docker.internal（这里是 172.17.0.1）来叫电脑，电脑一侧在 0.0.0.0 上等待。

用 Docker Compose 把 API 和数据库摆在一起，又会碰到另一个经典问题：“用 localhost 连不上数据库”。

# compose.yaml：api（Node.js）和 db（PostgreSQL）。db 不对外公开
pc$ docker compose ps
    api   0.0.0.0:8080->3000/tcp
    db    5432/tcp
# api 内部的“电话簿”
api$ cat /etc/resolv.conf
    nameserver 127.0.0.11
# 从 api 内部连接数据库
api$ node ck11.mjs localhost:5432 db:5432 nothere:5432
    localhost:5432  → 127.0.0.1    ECONNREFUSED
    db:5432         → 172.18.0.2   连上了 (2.60 ms)
    nothere:5432    查不到名字 ENOTFOUND
# 普通 docker run 启动的容器之间，不能用名字互相访问
    nw11-bad:3000   查不到名字 ENOTFOUND

Compose 会建一个专用网络（172.18.0.0/16），让容器之间能用服务名互相访问。回答名字的，是每个容器里位于 127.0.0.11 的 Docker 的 DNS。从 api 来看，数据库不是 localhost:5432，而是 db:5432。而没有定名字的普通 docker run 之间（一开始就有的名为 bridge 的网络），不能用名字访问。

在公司里，公司内的电脑常常不能直接出去，要通过代理。练习用的“公司”里，公司内的电脑（10.0.0.10）也只认识代理（10.0.0.8 的 3128 号，tinyproxy）。

# 公司内部的电脑查不到外面的名字，也没有出去的路
corp$ curl https://expenses.example:3443/api/me
    curl: (6) Could not resolve host: expenses.example
# 用环境变量告诉它使用代理
corp$ export HTTPS_PROXY=http://10.0.0.8:3128
corp$ curl -v https://expenses.example:3443/api/me
    * Uses proxy env variable HTTPS_PROXY == 'http://10.0.0.8:3128'
    > CONNECT expenses.example:3443 HTTP/1.1
    < HTTP/1.0 200 Connection established
    * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519
    * ALPN: server accepted h2
    < HTTP/2 401
    {"error":"login required"}   (0.054 s)
# 不加密的 HTTP 会把整个 URL 交给代理
corp$ http_proxy=http://10.0.0.8:3128 curl -v http://expenses.example:3000/api/expenses
    > GET http://expenses.example:3000/api/expenses HTTP/1.1
    < HTTP/1.1 200 OK
    < Via: 1.1 proxy.corp.example (tinyproxy/1.11.1)

没有代理，连外面的名字都查不到。设置 HTTPS_PROXY 后，curl 向代理请求 CONNECT expenses.example:3443，收到“Connection established”之后，在这条隧道里开始和第 8 讲一样的 TLS 握手。HTTPS 时，代理知道的只有目的地的名字和端口。不加密的 HTTP 则用 GET http://… 把整个 URL 交出去，回复里还带上了代理的 Via 头部。

代理的设置，一般用环境变量告诉工具。可是，每个工具的读法都有些不同。

# ① 连自己电脑的 localhost 都交给了代理
corp$ http_proxy=http://10.0.0.8:3128 curl http://localhost:3000/api/whoami
    500 Unable to connect
    Tinyproxy was unable to connect to the remote web server.
# 用 NO_PROXY 告诉它“这里直连”
corp$ http_proxy=… NO_PROXY=localhost,127.0.0.1 curl http://localhost:3000/api/whoami
    {"you":"127.0.0.1","me":"corp-pc","listen":"127.0.0.1:3000"}
# ② curl 不会把大写的 HTTP_PROXY 用于 http://
corp$ HTTP_PROXY=http://10.0.0.8:3128 curl http://expenses.example:3000/api/expenses
    curl: (6) Could not resolve host: expenses.example
# ③ Node.js 的 fetch 默认不看环境变量
corp$ HTTPS_PROXY=http://10.0.0.8:3128 node -e "fetch('https://expenses.example:3443/api/me')"
    error EAI_AGAIN
# Node.js 22 里，设置 NODE_USE_ENV_PROXY=1 后才会看（带有“实验性”提示）
corp$ HTTPS_PROXY=… NODE_USE_ENV_PROXY=1 node -e "fetch(…)"
    Warning: EnvHttpProxyAgent is experimental, …
    ok {"error":"login required"}

① 设着代理去访问自己的 localhost，curl 也把它交给代理，代理去找代理自己的 localhost，结果是“Unable to connect”（500）。用 NO_PROXY=localhost,127.0.0.1 告诉它“这里直连”，就能访问了。② curl 用于 http:// 的 http_proxy 只读小写（文档里也这么写）。只设大写的 HTTP_PROXY，curl 不用代理、直接出去，于是失败。③ Node.js 的 fetch 默认不看环境变量。加上 Node.js 22.21 引入的 NODE_USE_ENV_PROXY=1，在带着“实验性”提示的情况下通过了代理。

在开发中的电脑上重现第 10 讲的 CORS。页面是 Vite 的开发服务器（localhost:5173），API 在 127.0.0.1:3000，API 不返回 CORS 许可。用 Chromium 打开页面，用两种方式发送申请。

# 启动开发服务器（Vite）
pc$ npx vite
    VITE v7.3.7  ready in 217 ms
    ➜  Local:   http://localhost:5173/
    ➜  Network: use --host to expose
# 从页面（5173 号）直接向 API（3000 号）POST（Chromium 的控制台）
    Access to fetch at 'http://localhost:3000/api/expenses'
    from origin 'http://localhost:5173' has been blocked by CORS policy:
    Response to preflight request doesn't pass access control check:
    No 'Access-Control-Allow-Origin' header is present …
    → Failed to fetch
# 经开发服务器 POST（把 /api 转给 127.0.0.1:3000 的设置）
    POST http://localhost:5173/api/expenses
    → 201 {"id":"EXP-2026-0012","status":"submitted"}
# API 的记录：直接发送时只收到预检（OPTIONS），正式的 POST 没有来
    OPTIONS /api/expenses from 127.0.0.1   ← 直接
    POST /api/expenses from 127.0.0.1      ← 经由

同样是 localhost，端口不同就是不同的 Origin。直接发送时，浏览器只发了预检（OPTIONS），因为没有许可，就没发正式的 POST。API 的记录里也只留下了 OPTIONS。在开发服务器的配置里写上 proxy: { '/api': 'http://127.0.0.1:3000' }，页面发往 /api/expenses，在浏览器看来对象一直是 5173 号。开发服务器在背后转给 API，返回了 201。

觉得“连不上”时，先用一行写下来：从哪里、发往哪里的哪个口的几号。从电脑？从容器里？localhost 指的是谁？光是这样，问题就解决了一半。