网络代理生产实施

生产实施要先设计链路，再部署组件。直接从安装客户端开始，容易在后面遇到协议不匹配、入口路径不一致、DNS 策略错误、日志失控等问题。

1. 明确目标和边界

先回答这些问题：

问题	影响
谁在使用	决定账号、订阅、凭据轮换和日志策略
哪些流量需要代理	决定规则模式、DNS 和直连范围
是否需要 UDP	影响协议选择和服务端端口策略
是否多设备使用	影响订阅下发、并发连接和限流
是否有内网或公司 VPN	影响 DIRECT、NO_PROXY 和 TUN 兼容性
是否必须统一 443 入口	影响是否需要入口网关和 TLS

这一步的产物应该是一份链路设计，而不是一堆命令。

2. 选择协议和承载方式

协议选型不是比功能多少，而是看是否适合当前网络和运维能力。

方向	特点	适用
Shadowsocks	简洁、成熟、配置少	轻量代理、普通 TCP 访问
Trojan	常和 TLS 入口结合	需要 443 统一入口
VMess / VLESS	可组合多种传输	复杂路由、多形态接入
QUIC / Hysteria 类	弱网和 UDP 表现更强	移动网络、实时通信、长距离链路

承载方式要和协议分开看：

• TCP：最简单，网络兼容性好。
• TLS：提供证书校验和加密外壳。
• WebSocket：适合穿过 HTTP 入口网关。
• gRPC / HTTP/2：适合统一在 HTTP/2 基础设施上。
• QUIC：基于 UDP，适合部分弱网场景，但对网络环境要求不同。

3. 规划服务端目录和配置

生产目录应该可备份、可迁移、可恢复。一个通用结构可以是：

/opt/network-proxy/
  compose.yml
  config/
    server.yaml
    users.yaml
  subscriptions/
    template.yaml
  logs/
  backup/

真实凭据放在私有配置里，公开文档只保留模板。配置模板和真实配置分开，可以减少误提交风险。

4. 部署远端代理服务

远端服务部署时要固定：

1. 服务监听端口。
2. 认证信息。
3. 加密方式。
4. 传输参数。
5. 日志位置。
6. 重启和自启动方式。

使用 Docker Compose 时，关注镜像来源、卷挂载和日志限制：

services:
  proxy-server:
    image: example/proxy-server:stable
    restart: unless-stopped
    ports:
      - "127.0.0.1:10080:10080"
    volumes:
      - ./config:/etc/proxy:ro
      - ./logs:/var/log/proxy
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "5"

这里用 127.0.0.1 绑定端口，表示只允许本机入口网关访问后端服务。是否这样做取决于实际协议和网关方案；核心原则是不要把未鉴权或不该公开的端口直接暴露到公网。

5. 配置入口网关

入口网关适合统一域名、TLS 和 HTTP 形态流量。以 WebSocket 承载为例：

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl http2;
    server_name proxy.example.com;

    ssl_certificate     /etc/nginx/ssl/proxy.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/proxy.example.com.key;

    location /proxy-ws/ {
        proxy_pass http://127.0.0.1:10080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
    }
}

如果协议不是 HTTP/WebSocket 形态，就不要强行套 HTTP location。纯 TCP 入口应使用四层转发、Nginx stream 或让代理服务直接监听公网端口。

6. 生成订阅配置

订阅配置要把服务端参数转成客户端字段。最小结构包括节点、代理组、规则：

proxies:
  - name: proxy-node-a
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-256-gcm
    password: "******"
    udp: true
    plugin: v2ray-plugin
    plugin-opts:
      mode: websocket
      host: proxy.example.com
      path: /proxy-ws/
      tls: true

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

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

真实订阅要按所选内核和协议调整字段。客户端和服务端最容易不一致的是端口、密码、TLS、SNI、WebSocket path 和 UDP 开关。

7. 上线验证

上线验证分三层：

层级	验证内容	通过代表什么
控制面	订阅 URL 能拉取并解析	配置下发正常
节点连接	客户端延迟测试或连接测试成功	客户端能到远端服务
业务目标	访问代表性网站或 API 成功	规则、DNS、出口和目标链路正常

验证时先选手动代理组，不要一开始就用自动测速。自动策略会引入测速 URL、切换策略、健康检查间隔等额外变量。

8. 生产变更

生产变更要避免同时修改太多变量。建议顺序是：

1. 备份当前服务端配置和订阅模板。
2. 修改一类配置，例如只改规则或只改节点参数。
3. 做语法检查。
4. reload 或重启相关服务。
5. 从客户端重新拉订阅。
6. 验证代表性目标。
7. 观察日志和连接数。

如果新增用户或节点，要确认服务是否会热加载配置。不能热加载的服务，需要明确 reload 或 restart 的影响范围。

总结

生产实施的关键是让“服务端真实参数、入口网关、订阅配置、客户端内核”四者一致。任何一处不一致，都可能表现为订阅正常但节点失败、节点可连但目标不可达、局部应用不走代理。