搭建Reverse Proxy：目标服务器主动向代理发起请求的可行方案咨询

你的场景本质是主动拉取式的内网服务对外暴露，针对这个需求，既有现成工具可以快速落地，也可以根据需求轻量定制开发，分两种情况说明：

现成工具方案 #

不需要从零写代码，选这些工具就能满足需求：

• MQTT 消息中间件：在外网搭一个MQTT broker（比如Mosquitto、EMQX），内网教室的server作为订阅者，订阅指定主题；外部请求方把请求内容发布到对应主题，内网server收到后处理，再把结果发布到一个结果主题，外部请求方订阅该主题获取响应。这种方式比手动写GET轮询更高效，自带消息推送机制，不用自己处理轮询间隔、请求丢失等问题。
• 轻量脚本轮询：如果需求极简单，直接用shell/python脚本配合curl实现：内网server定时（比如每3秒）发起GET请求到外网server的接口，查询是否有待处理请求；外网server只需要做一个简单的请求存储（比如用文件、Redis存请求ID和内容），收到外部请求就存起来，收到内网查询就返回待处理项，再接收内网POST的响应并关联原请求。
• 部分内网穿透工具的变种用法：像frp这类工具，原本是正向穿透，但可以配置客户端（内网server）主动连接外网服务端，然后在外网服务端做请求转发，把外部请求转递给内网的主动连接，本质和你的同学提出的逻辑一致，只是工具已经封装好了轮询/连接维持的逻辑。

自行开发的场景 #

如果需要和你们的业务逻辑深度绑定（比如要做权限校验、请求日志、特定格式的响应处理），自己开发也很简单：

• 外网server核心逻辑：
  1. 提供接收外部请求的接口，给每个请求生成唯一ID，把请求内容和ID存在缓存/数据库里
  2. 提供给内网查询的GET接口，返回未处理的请求列表（带ID）
  3. 提供接收内网响应的POST接口，根据请求ID找到原外部请求，把响应返回给请求方（如果外部请求是长连接等待，直接推送；如果是短连接，就让外部请求方轮询结果接口）
• 内网server核心逻辑：
  1. 定时发起GET请求到外网的查询接口
  2. 拿到待处理请求后，调用本地服务处理
  3. 把处理结果和请求ID一起POST回外网的响应接口

总结 #

如果只是满足老师的基础需求，优先用现成工具（MQTT或轻量脚本），快速落地且不用维护复杂代码；如果有定制化业务需求，自行开发的成本也很低，核心就是处理请求的存储和ID关联。

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