网络代理组件链路

网络代理系统由多个组件协同完成。每个组件都有明确边界：客户端界面不负责转发，订阅配置不负责连通性，入口网关不负责理解所有代理协议，远端代理服务不负责决定本机哪些应用该走代理。

组件总览

组件	做什么	怎么用	原理
客户端界面	管理订阅、节点、规则模式和系统开关	Clash Verge、其他 GUI	调用代理内核 API，读写配置并展示状态
客户端内核	接收本机流量、执行规则、连接节点	Mihomo、sing-box、v2ray-core 等	在本机开放入站端口，或通过 TUN 接管系统流量
订阅配置	描述节点、代理组、规则和 DNS	URL 导入或本地 YAML	把分散的节点和规则标准化为客户端配置
代理协议	定义认证、加密和远端通信方式	Shadowsocks、Trojan、VMess、VLESS 等	客户端和服务端按同一协议封装并还原流量
传输承载	决定代理连接在网络上长什么样	TCP、TLS、WebSocket、gRPC、QUIC	在底层网络上承载加密后的代理数据
入口网关	统一公网入口、证书和转发策略	Nginx、Caddy、HAProxy、负载均衡	按端口、域名、路径或协议把连接转给后端
远端代理服务	解密、认证、转发到目标服务	官方镜像、发行版包、systemd 服务	作为出口节点代表客户端访问目标
DNS 组件	决定域名在哪里解析和如何参与规则	fake-ip、redir-host、DoH/DoT	解析结果会影响规则命中和最终连接目标
运维组件	启动、日志、升级、备份、监控	Docker Compose、systemd、日志轮转	保证服务长期运行并可恢复

控制面和数据面

控制面负责配置，数据面负责流量。两者可以部署在同一台机器，也可以完全分开。

flowchart LR
    subgraph Control["控制面"]
        Source[节点来源]
        Sub[订阅配置]
        Group[代理组与规则]
        Source --> Sub --> Group
    end

    subgraph Data["数据面"]
        App[应用]
        Core[客户端内核]
        Remote[远端代理服务]
        Target[目标服务]
        App --> Core --> Remote --> Target
    end

    Group --> Core

控制面可用，只能说明客户端拿到了配置；数据面可用，才说明真实连接能从客户端到远端、再到目标服务。很多排障误判来自把这两条线混在一起。

客户端界面和内核

以 Clash Verge 为例，界面和内核是分离的。

• Clash Verge：负责按钮、订阅列表、代理组选择、连接列表、设置页面。
• Mihomo：负责监听端口、解析配置、匹配规则、连接远端节点。

界面异常不一定代表代理内核异常；内核日志报错也不一定会直接体现在界面上。排查时要同时看 GUI 状态和内核日志。

订阅配置

订阅配置是客户端的“作战地图”。它通常包含：

proxies:
  - name: proxy-node-a
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-256-gcm
    password: "******"

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - proxy-node-a
      - DIRECT

rules:
  - DOMAIN-SUFFIX,api.example.org,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

节点描述“怎么连远端”，代理组描述“怎么选择节点”，规则描述“什么流量用哪个组”。这三者缺一不可。

订阅内容通常包含敏感凭据，不应该公开到代码仓库、截图、日志、公共对象存储或没有鉴权的接口里。

协议和传输承载

代理协议和传输承载是两层概念。

层	关注点	例子
代理协议	认证、加密、数据封装	Shadowsocks、Trojan、VMess、VLESS
传输承载	代理连接如何跑在网络上	TCP、TLS、WebSocket、gRPC、QUIC

两者可以组合。例如一个节点可能是“某种代理协议 + TLS + WebSocket”。客户端和服务端必须在协议、认证信息、传输参数上完全一致，否则连接会失败。

入口网关

入口网关不是所有代理链路都必须有。它主要用于这些场景：

• 多个服务共用一个域名或 443 端口。
• 统一 TLS 证书和访问日志。
• 把 WebSocket、HTTP/2、gRPC 等 HTTP 形态流量转给内部服务。
• 在代理服务前增加限流、访问控制或负载均衡。

如果代理协议本身直接监听公网端口，入口网关可以省略。若使用 Nginx/Caddy 这类 HTTP 网关，要确认代理流量确实是 HTTP 形态；纯 TCP 协议需要四层转发或 stream 配置。

远端代理服务

远端服务是出口节点。它接收客户端连接，完成认证和解密，再代表客户端访问目标服务。

部署远端服务时，至少要明确：

1. 监听端口和绑定地址。
2. 认证信息和加密方式。
3. 是否支持 UDP。
4. 是否需要 TLS、WebSocket、gRPC 或 QUIC。
5. 日志位置和启动方式。

远端服务的出口能力取决于服务器网络本身。客户端能连上远端，不代表远端一定能访问目标服务。

DNS 组件

DNS 决定域名到 IP 的映射，也影响规则判断。常见策略有：

• 系统 DNS：交给操作系统解析，简单但规则可控性弱。
• 客户端 DNS：由代理内核接管解析，便于按域名分流。
• fake-ip：给域名分配虚拟 IP，客户端内部保存域名映射。
• DoH/DoT：通过加密 DNS 查询，减少明文 DNS 暴露。

DNS 配置错误会造成规则不命中、目标错连、连接超时或局部服务不可达。涉及企业内网、开发环境、局域网设备时，要特别维护 DIRECT 和 NO_PROXY 范围。

运维组件

运维组件让代理系统长期稳定运行：

• Docker Compose：适合多组件部署、统一目录、迁移方便。
• systemd：适合宿主机服务、日志进入 journal、自启动明确。
• 日志轮转：防止访问日志、错误日志、容器日志打满磁盘。
• 监控脚本：定期验证订阅、节点、出口和关键目标可达。
• 备份：保存配置模板、匿名化示例和回滚版本。

工程上不要只关心“进程活着”。更可靠的检查是：订阅能拉取、节点能连接、代表性目标能访问、日志没有持续错误。

总结

网络代理组件之间是分工协作关系。客户端界面负责管理，内核负责执行，订阅负责配置分发，协议负责认证加密，入口网关负责公网入口，远端服务负责出口访问，DNS 和运维决定长期稳定性。