在 Docker 中部署 mihomo，并让本机与局域网电脑接入

Tue, 19 May 2026 00:00:00 +0800

mihomo 是 Clash.Meta 的延续版本，常见用法是把它作为一个代理内核运行在一台长期在线的机器上，然后让本机、手机、Windows 电脑、Linux 电脑都通过这台机器访问代理服务。

这篇文章记录一个最实用的部署方式：在 Docker 里运行 mihomo，宿主机负责提供端口，局域网里的其他设备只需要把 HTTP / SOCKS 代理指向这台机器即可。

总览：先看整体链路

假设运行 Docker 的机器局域网 IP 是 192.168.1.10，mihomo 在这台机器上监听 7890 端口：

Windows / Linux / 手机
 |
 | HTTP / SOCKS 代理：192.168.1.10:7890
 v
Docker 宿主机：192.168.1.10
 |
 | mihomo 容器
 v
按规则直连或走代理节点

关键点只有三个：

mihomo 配置里开启 allow-lan: true。
mihomo 监听地址使用 bind-address: "*" 或宿主机局域网 IP。
Docker 把 7890 端口暴露给局域网。

第一步：准备目录

在准备用作代理网关的机器上创建目录：

mkdir -p ~/mihomo/config
cd ~/mihomo

后面所有文件都放在 ~/mihomo 目录里：

一次 HTTP 请求的完整旅程：从浏览器到 Nginx 再到后端服务

Wed, 29 Apr 2026 15:05:00 +0800

我们在浏览器里输入一个网址，比如：

https://www.example.com/api/users

看起来只是按下回车，页面就返回了。但在这几百毫秒甚至几十毫秒里，浏览器、操作系统、DNS、TCP、TLS、Nginx、后端应用、数据库和缓存可能都参与了一次协作。

这篇文章按时间顺序，把一次典型的 HTTPS 请求完整拆开：从浏览器发起请求，到 TCP 三次握手、TLS 密钥协商，再到 Nginx 接收连接、反向代理给后端服务，最后响应返回浏览器。

总览：请求链路长什么样

可以先看一个简化版流程图：

用户输入 URL
 │
 ▼
浏览器解析 URL
 │
 ▼
DNS 解析域名 -> 得到服务器 IP
 │
 ▼
TCP 三次握手 -> 建立可靠连接
 │
 ▼
TLS 握手/密钥协商 -> 建立加密通道
 │
 ▼
浏览器发送 HTTP 请求
 │
 ▼
Nginx 接收请求
 │
 ├─ 匹配 server_name
 ├─ 匹配 location
 ├─ 处理静态资源 / gzip / header / 日志
 │
 ▼
proxy_pass 反向代理到后端应用
 │
 ▼
后端应用处理业务逻辑
 │
 ▼
后端返回 HTTP 响应
 │
 ▼
Nginx 返回响应给浏览器
 │
 ▼
浏览器解析 HTML/CSS/JS 并渲染页面

实际生产环境里，中间还可能有 CDN、负载均衡、WAF、Service Mesh、网关、缓存、队列、数据库等组件。但核心路径大体就是上面这些层次。

网络 on 随手记

在 Docker 中部署 mihomo，并让本机与局域网电脑接入

总览：先看整体链路

第一步：准备目录

一次 HTTP 请求的完整旅程：从浏览器到 Nginx 再到后端服务

总览：请求链路长什么样