核心用法
proxq是一个基于Go语言和Redis的异步HTTP代理队列服务，构建于asynq任务队列框架之上。其核心工作模式是将任何HTTP请求（任意方法、路径、请求体）转化为后台异步任务，让客户端实现"fire-and-forget"的调用体验。
使用流程极为简洁：客户端向proxq提交HTTP请求，立即获得202 Accepted响应和任务ID；后台worker异步转发请求至配置的上游服务；客户端通过轮询GET /__jobs/{id}查询任务状态（queued/running/completed/failed）；任务完成后通过GET /__jobs/{id}/content获取完整的上游响应（状态码、响应头、响应体）。
该服务支持多上游路由（最长前缀匹配）、每上游独立配置超时与重试策略、路径过滤、以及可选的响应缓存（内存或Redis LRU）。对于WebSocket、分块传输或大体积请求，系统会自动切换为直连代理模式，绕过队列机制。
显著优点
解耦客户端与上游延迟：最核心的价值在于将同步等待转为异步轮询，特别适合处理耗时数秒至数分钟的慢请求，避免客户端连接超时或占用资源等待。
内置容错与重试机制：基于asynq的Redis队列提供持久化、任务调度、自动重试与指数退避，上游临时故障不会导致请求丢失。
灵活的架构适配：支持多上游路由配置，可为不同后端设置差异化的超时、重试策略和路径过滤规则；缓存层可减少重复请求对上游的压力。
无状态设计：proxq本身无持久状态，完全依赖Redis，易于水平扩展和容器化部署。
潜在缺点与局限性
非实时响应模型：submit-then-poll的轮询模式天然引入延迟，不适合需要实时流式响应或低延迟场景；且无内置的回调/webhook机制通知调用方任务完成。
SSRF攻击面：设计上允许提交任意HTTP请求至配置的上游，若上游指向内网敏感服务或配置不当，将构成服务器端请求伪造风险。
零内置认证：服务本身不提供API密钥、JWT、IP白名单等任何认证机制，完全依赖外部反向代理层实现访问控制。
任务ID无所有权绑定：任何知晓任务ID的调用者均可查询状态、获取结果、甚至取消任务，UUIDv4的不可预测性仅提供弱防护。
缓存语义风险：响应缓存对幂等和非幂等请求一视同仁，重复提交可能返回历史响应而非最新上游状态，需谨慎配置。
适合的目标群体
- 微服务架构团队：需要将耗时操作（报表生成、批量处理、视频转码）从API网关解耦，避免长连接占用。
- Webhook接收方：希望异步处理第三方回调，避免因处理延迟导致发送方超时重发。
- CDN/短超时网关后端：上游处理时间超过CDN或反向代理的超时阈值，需通过异步队列兜底。
- 内部工具开发者：构建需要"提交后稍后查看结果"形态的数据处理、导出、迁移工具。
使用风险
SSRF风险：proxq会忠实转发任意请求至配置的上游，包括自定义Header、请求体和HTTP方法。必须确保upstreams[].url指向可信、可控的服务，严禁配置指向内部管理接口、元数据服务（如AWS 169.254.169.254）或未授权的第三方API。
网络暴露风险：若无外部认证层（如API Gateway、OAuth代理、Basic Auth反向代理），暴露至公网的proxq实例将成为开放代理，允许任何人提交任务、轮询任意任务ID、取消他人任务。
资源耗尽风险：Redis队列无上限保护时，恶意或错误的大量请求提交可能导致队列积压、内存耗尽；大体积请求体（文件上传）若未触发directProxyMode，将占用Redis内存存储任务负载。
依赖可用性：服务强依赖Redis，Redis故障将导致队列不可用、任务状态查询失败；需配置Redis哨兵或集群模式保障高可用。
缓存失效风险：内存缓存非分布式，多实例部署时可能出现缓存不一致；Redis缓存依赖LRU驱逐，热点数据可能被意外清理。