Paperless-ngx反向代理子路径下API浏览器路径解析问题分析

在Paperless-ngx文档管理系统的2.5.12版本中，当部署在反向代理后的子路径时，其内置的API浏览器存在一个关键的路由解析缺陷。这个缺陷会导致所有API请求都返回404错误，严重影响系统在特定部署场景下的可用性。

问题现象

当用户将Paperless-ngx部署在类似/paperless这样的子路径下，并通过设置PAPERLESS_FORCE_SCRIPT_NAME环境变量进行配置时，系统主体功能可以正常工作。然而，当访问/paperless/api/schema/view/这个API浏览器界面时，所有发起的API请求都会失败。

通过浏览器开发者工具观察发现，这些请求实际上被发送到了错误的路径——浏览器忽略了配置的子路径前缀，直接向/api/endpoint发起请求，而不是正确的/paperless/api/endpoint路径。

技术背景

这个问题涉及到Django框架在反向代理环境下的路径处理机制。在Web应用中，当部署在子路径时，需要正确处理两种路径：

1. 由Web服务器（如Nginx/Apache）重写后的路径
2. 应用内部生成的绝对路径

PAPERLESS_FORCE_SCRIPT_NAME环境变量正是用来解决这个问题的标准Django配置，它应该告知应用当前部署的基础路径。然而，在这个案例中，API浏览器的前端JavaScript代码没有正确继承这个配置。

影响范围

该问题影响所有满足以下条件的部署：

• 使用Paperless-ngx 2.5.12版本
• 通过反向代理部署在子路径下
• 需要使用API浏览器功能

值得注意的是，系统其他功能（如文档上传、查看等）不受此问题影响，因为它们正确地遵循了PAPERLESS_FORCE_SCRIPT_NAME的配置。

解决方案

开发团队迅速响应并修复了这个问题。修复的核心思路是确保API浏览器的前端代码能够：

1. 正确读取Django后端配置的子路径信息
2. 在所有动态生成的API请求URL前自动添加配置的子路径前缀

对于用户而言，解决方案很简单——升级到包含修复的版本即可。这个案例展示了开源社区高效的问题响应机制，从问题报告到修复仅用了很短的时间。

最佳实践建议

对于需要在子路径下部署Paperless-ngx的用户，建议：

1. 始终使用最新稳定版本
2. 确保反向代理和Paperless-ngx的路径配置一致
3. 测试所有功能，特别是API相关功能
4. 关注项目的更新日志，及时应用安全修复和功能改进

这个案例也提醒我们，在开发Web应用时，特别是在前后端分离的架构中，路径处理需要格外小心，确保所有组件都能正确处理部署基础路径。