如何在Windows VPS上透明转发所有入站请求至另一台服务器

核心要实现的是无感知透明反向代理，全程不返回3xx重定向响应，客户端完全感知不到后端服务地址切换，所有请求、响应原封不动透传到服务器2，旧版硬编码地址的App不需要任何改动就能正常运行，完全规避res.redirect导致的业务异常。
以下按推荐优先级排序方案： #

方案1：Caddy反向代理（首推，运维成本最低、稳定性最高） #

这个方案不需要修改任何现有业务代码，资源占用极低，自动处理HTTPS证书续期，是长期跑转发的最优选择。

• 前置操作：先停掉服务器1上当前PM2托管的Node业务服务，释放80、443公网端口，避免端口冲突。
• 部署步骤：
  1. 下载Caddy的Windows amd64版本压缩包，解压到服务器本地目录例如C:\caddy。
  2. 在解压目录新建名为Caddyfile的无后缀配置文件，写入以下配置：

  www.pharmart.sy {
      reverse_proxy www.pharmartco.com {
          header_up Host {upstream_hostport}
          header_up X-Real-IP {remote_host}
          header_up X-Forwarded-For {remote_host}
          header_up X-Forwarded-Proto {scheme}
      }
  }
  

  3. 以管理员权限打开PowerShell，进入Caddy所在目录，执行.\caddy.exe install将Caddy注册为Windows系统服务，配置开机自启、崩溃自动恢复，再执行.\caddy.exe start启动服务即可。
• 实际效果：所有发往www.pharmart.sy的请求，不管是普通接口请求、文件上传、Websocket连接，都会被原封不动转发到www.pharmartco.com，上游返回的响应也会直接透传给客户端，和客户端直接访问服务器2的表现完全一致，旧版App不会出现任何兼容性问题。Caddy会自动申请、续期www.pharmart.sy的SSL证书，不需要手动维护证书有效期。

方案2：Node层透明代理（适合不想额外安装服务的场景） #

如果你不想在服务器上部署额外的服务程序，可以直接把服务器1上的Node业务服务替换为代理服务，不需要做跳转响应，直接做请求流转发。

• 部署步骤：
  1. 新建一个极简Node项目，安装依赖：npm i express http-proxy-middleware
  2. 编写入口文件app.js：

  const express = require('express');
  const { createProxyMiddleware } = require('http-proxy-middleware');
  const https = require('https');
  const fs = require('fs');
  const app = express();
  
  // 全路径透明转发
  app.use('/', createProxyMiddleware({
    target: 'https://www.pharmartco.com',
    changeOrigin: true,
    ws: true, // 兼容业务用到的Websocket连接
    secure: true // 校验上游服务证书，避免安全风险
  }));
  
  // 启动HTTP服务，可选配置HTTPS服务加载本地SSL证书
  app.listen(80, () => console.log('Proxy service running on port 80'));
  // 如需启动HTTPS，取消以下注释，替换证书路径即可
  // const httpsOptions = {
  //   key: fs.readFileSync('./ssl/privkey.pem'),
  //   cert: fs.readFileSync('./ssl/fullchain.pem')
  // };
  // https.createServer(httpsOptions, app).listen(443, () => console.log('HTTPS proxy running on 443'));
  

  3. 删除PM2中托管的旧业务服务，将这个代理服务加入PM2托管即可。
• 缺点：需要自己手动维护SSL证书申请、续期，高并发、大文件上传场景下性能远低于专用反向代理程序，稳定性一般，只适合短期临时转发用。

不推荐踩坑的方案 #

• 不要用Windows自带IIS的ARR反向代理：配置流程繁琐，坑点多，资源占用高，出问题排查成本极高。
• 不要用四层端口转发（比如netsh portproxy）：无法处理HTTPS的SNI证书匹配，会导致App端报SSL证书错误，完全无法正常使用。
• 不要用任何形式的3xx跳转、DNS层面的URL转发：这类方案都会被客户端感知到地址变化，直接导致旧版App运行异常。

运维提示：转发服务稳定运行后，可以持续观察服务器1的访问日志，等连续1-2个月几乎没有请求进来，说明旧版App用户基本已经完成升级，再关停服务器1即可。转发服务本身资源占用极低，1核1G配置的VPS完全可以承载日常业务流量，不会有性能瓶颈。

内容的提问来源于stack exchange，提问作者Bakri Alkhateeb