Web服务器请求重定向至应用服务器.Net Core Web API方案咨询

你设想的这套双API中转思路逻辑上是走得通的，能满足两端的网络访问限制，但实际用起来有个很容易踩的大坑：如果在Web服务器上部署的转发API带了重复的业务逻辑，后续迭代绝对会出问题——你在应用服务器的正式API里改了个校验规则、调了个返回字段，Web服务器上的转发API没跟着改，移动端直接拿到错误数据，排查起来都不知道是哪层出的问题。
如果一定要用这套方案，记得让Web服务器上的转发API完全做无业务逻辑的请求透传，不要内嵌任何数据校验、业务处理代码，只负责把原请求的路径、参数、请求头、认证信息完整转发给应用服务器的正式API，拿到响应后再原样返回给移动端，尽可能降低两边代码不一致的风险。

1. 基于现有Web服务器能力的纯反向代理方案（生产环境首选） #

完全不需要额外写代码、部署新的API应用，直接用Web服务器自带的反向代理功能就能搞定，比你单独写一套转发API省太多事了：

• 如果Web服务器是Windows环境跑IIS，可以直接安装URL Rewrite、Application Request Routing模块，配置规则把所有匹配API路径的请求，转发到应用服务器的内网IP对应端口上，整个过程对你已有的Web API代码零改动。
• 如果Web服务器是Linux环境跑Nginx/Caddy，只需要写几行配置块就能完成转发，几乎没有额外维护成本。
  这种方案的优势是：所有外部请求的入口完全集中在Web服务器上，完全符合IT团队要求的中转规则；应用服务器只需要给Web服务器的内网IP开放API端口即可，不需要对外暴露；所有业务逻辑还是只保留在应用服务器上的原有Web API里，从根本上避免多套代码并行维护的版本不一致问题。

2. 轻量API网关方案（适合后续服务扩容的场景） #

如果你们后续会陆续上线更多需要访问内网Oracle的API，可以直接在Web服务器上部署一套无业务逻辑的轻量API网关（比如基于.Net Core的YARP、Ocelot），所有移动端的请求统一先到网关，网关负责根据路径规则把请求路由到应用服务器上对应的正式API，同时统一处理鉴权、限流、请求日志记录等通用能力。
和你最初设想的双API方案相比，网关层没有任何业务代码，后续不管怎么调整应用服务器上的业务接口，只要路由规则不变，网关就完全不需要改动，长期维护成本远低于部署两套独立API的模式。

3. 内网主动隧道方案（仅适合临时测试，不推荐生产使用） #

如果Web服务器和应用服务器之间的入方向端口完全无法打通，可以在应用服务器上部署隧道客户端，由应用服务器主动向Web服务器的隧道端口建立长连接，把应用服务器上的API端口映射到Web服务器的本地端口，再由Web服务器把这个本地端口的请求对外暴露。
这个方案的问题是隧道链路的稳定性、安全性没有正规反向代理可控，很容易被企业安全策略判定为违规通道，只适合临时联调测试的时候用，不要长期在生产环境跑。

不管选哪种转发方案，落地时都要满足几个基本的安全要求：

• 防火墙做严格的来源限制，只允许Web服务器的内网IP访问应用服务器上的API端口，拒绝所有其他来源的访问请求，满足IT团队的审计要求
• 转发过程中完整透传原请求的认证信息（比如JWT令牌、用户身份头），不要把鉴权上下文丢了导致后端API校验失败
• 配置合理的请求超时、失败重试策略，避免后端应用服务器响应慢的时候把Web服务器的连接池占满
• Web服务器和应用服务器之间的通信尽量走HTTPS加密，哪怕是内网链路也不要明文传输数据

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