Pangolin项目中的HTTP请求挂起问题分析与解决方案

问题现象

在Pangolin项目中，用户报告了某些特定服务（如Immich、Nextcloud、Audiobookshelf等）通过代理访问时出现HTTP请求挂起的问题。具体表现为：

1. 部分API调用或XHR请求在后台挂起
2. 有时整个服务无响应
3. 直接访问服务（绕过Pangolin）则工作正常
4. 问题在资源消耗较大的服务上更为明显

技术背景

Pangolin是一个基于WG的安全隧道解决方案，其核心组件包括：

• Gerbil：运行在VPS端的服务端组件
• Newt：运行在内网的客户端组件，负责建立隧道和代理请求

系统架构为：用户设备 → Pangolin(Gerbil) → Newt → 目标服务

问题诊断过程

开发团队最初怀疑是MTU（最大传输单元）设置问题。WG默认使用1420字节的MTU，可能导致数据包分片和丢失。为此团队：

1. 将MTU调整为1280进行测试
2. 添加了MSS（最大分段大小）钳制功能
3. 发布了测试版本供用户验证

然而测试结果表明MTU调整并未完全解决问题，说明存在更深层次的原因。

根本原因

经过深入分析，发现问题出在Newt组件的TCP代理实现上：

1. 代理管理器在处理某些长连接或大流量请求时存在缺陷
2. 连接状态管理不够完善
3. 缓冲区处理可能存在问题
4. 对特定HTTP行为模式（如频繁的API轮询）支持不足

解决方案

开发团队对Newt进行了重大重构：

1. 完全重写了代理管理器组件
2. 优化了连接状态跟踪机制
3. 改进了内部端口选择策略
4. 增强了错误处理和恢复能力

关键改进包括更高效的I/O处理、更好的连接池管理以及更可靠的超时机制。

验证结果

新版本发布后，多个用户验证了修复效果：

1. Paperless-ngx：完全解决挂起问题
2. Immich：API请求恢复正常
3. Audiobookshelf：稳定运行无中断
4. Plex：播放问题解决（登录重定向问题仍需优化）

技术启示

1. 隧道代理设计：在实现网络隧道代理时，需要特别注意TCP连接的完整生命周期管理
2. 性能考量：对于高频率API请求的服务，代理层需要更高的并发处理能力
3. 兼容性测试：不同应用协议的差异性需要充分测试
4. 调试方法：tcpdump等工具在网络问题诊断中非常有效

最佳实践建议

对于类似架构的项目，建议：

1. 实施全面的连接状态监控
2. 考虑添加自适应缓冲区机制
3. 针对不同协议特性进行优化
4. 建立完善的性能测试套件
5. 提供详细的日志和诊断接口

此问题的解决展示了Pangolin团队对技术问题的深入分析和快速响应能力，也为类似网络代理项目提供了宝贵的技术参考。