Swoole官方不提供SwooleProxyServer类，new该类必报错；官方仅支持两种反向代理方式：基于SwooleHttpServer手动实现转发逻辑，或使用SwooleCoroutineHttpClient协程转发。
不存在 SwooleProxyServer 类
直接写 new SwooleProxyServer() 会报错：Class 'SwooleProxyServer' not found。这不是版本低或没装扩展的问题，而是这个类压根没进过 Swoole 官方主干代码。你看到的所谓 “SwooleProxyServer” 示例，基本来自以下三类情况：
– 某些旧版 Gitee / GitHub 上第三方自己写的 Proxy 封装（比如 x2460087/swoole-src）
– 教程作者照着 SwooleHttpServer 名字瞎仿的命名
– Composer 包（如 swoole-proxy）里的独立实现，内部仍是基于 SwooleHttpServer + SwooleCoroutineHttpClient
官方支持的两种反向代理路径
Swoole 官方只认两种可落地的反向代理方式，区别在于控制粒度和运行模型：
– SwooleHttpServer + on('request') 手动转发：完全可控，能改 Header、加鉴权、做路由判断，适合需要定制逻辑的网关场景
– SwooleCoroutineHttpClient 协程转发：轻量、高并发，但必须在协程上下文中调用，不能在 onStart 或非协程回调里用
两者都不自带“自动重试”“健康检查”“负载策略”，这些得自己补。比如用 set(['timeout' => 5.0]) 控制超时，用 gethostbyname() 做简单 DNS 缓存，否则每次请求都解析域名会拖慢性能
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
为什么不用 Swoole 做最外层反向代理？
把 Swoole 当 Nginx 用（即监听 80/443 端口直面公网做反代）是常见误区，问题集中在：
– 静态文件处理能力弱，没内置 gzip、ETag、range 请求支持
– SSL 终止性能差，openssl 握手开销大，容易成瓶颈
– 缺少连接队列管理，突发流量下 accept() 阻塞风险高
– 日志格式、访问控制、限流等基础设施要全手写
真实生产环境，99% 的案例都是 Nginx 做最外层反向代理（proxy_pass http://swoole_servers），Swoole 只专注业务逻辑。Nginx 负责 TLS、静态资源、黑白名单；Swoole 负责 PHP 协程处理、数据库连接池、实时推送
自己写 HTTP 反向代理的关键陷阱
若真要基于 SwooleHttpServer 写透明代理，这几个点不注意就返回乱码或超时：
– 必须透传原始 $request->header，但要删掉 connection、keep-alive、transfer-encoding 这类 hop-by-hop 字段，否则后端服务可能拒收
– $response->end() 前必须手动设置 Content-Length 或用 chunked 编码，不能依赖后端自动带过来的头
– 如果后端返回 302，Location 是相对路径，需拼上原始 $request->server['request_uri'] 基础 URL，否则跳转失效
– 协程客户端默认不跟随重定向，set(['follow_redirect' => true]) 仅对 3xx 有效，但不会自动处理 Cookie 透传，要手动取 Set-Cookie 并塞进下次请求
