Logto项目在Nginx反向代理环境下的配置问题分析与解决方案

问题背景

在自托管Logto身份认证系统时，许多开发者会选择使用Nginx作为反向代理来提高安全性和可用性。然而，当Logto部署在Nginx Proxy Manager这样的反向代理后面时，可能会遇到"Internal server error"的内部服务器错误问题，特别是在设置了ADMIN_ENDPOINT环境变量的情况下。

问题现象

当配置了ADMIN_ENDPOINT环境变量后，用户能够成功登录管理控制台，但在访问仪表板或其他功能时会出现"Internal server error"错误。通过开发者工具检查网络请求，可以发现对auth.localhost的API调用失败。

根本原因分析

这个问题源于Logto内部服务间通信机制与反向代理环境的兼容性问题：

1. 内部请求路由问题：Logto后端会使用ENDPOINT和ADMIN_ENDPOINT中配置的URL进行内部服务间通信。当这些URL解析为localhost时，请求不会经过Nginx代理，而是直接尝试连接容器内部的127.0.0.1:443端口。

2. 端口不匹配：Logto容器内部实际上只监听3001和3002端口，而内部请求却尝试连接443端口，导致ECONNREFUSED连接拒绝错误。

3. TLS证书验证：即使请求能够路由到正确位置，Logto容器内部可能无法验证Nginx配置的自签名证书。

解决方案

方案一：配置网络别名

通过修改docker-compose.yml，为nginx-proxy-manager服务添加网络别名，强制Logto的内部请求通过Nginx代理：

services:
  proxy:
    networks:
      default:
        aliases:
          - auth.localhost
          - test.localhost

方案二：禁用TLS验证

在Logto服务环境中添加以下变量，临时禁用TLS证书验证（仅限开发环境）：

environment:
  - NODE_TLS_REJECT_UNAUTHORIZED=0

方案三：调整端口映射

确保Nginx代理配置中的端口映射与Logto实际监听的端口一致：

services:
  logto:
    ports:
      - "3001:3001"  # 核心服务端口
      - "3002:3002"  # 管理控制台端口

最佳实践建议

1. 生产环境配置：在生产环境中，建议使用有效的SSL证书而非自签名证书，并保持TLS验证开启。

2. 域名规划：为Logto服务使用独立的子域名，避免使用localhost这类可能引起解析混乱的域名。

3. 日志监控：定期检查容器日志，及时发现和解决类似的服务间通信问题。

4. 环境隔离：开发、测试和生产环境应使用不同的配置，避免开发环境的临时解决方案被误用于生产。

总结

Logto在反向代理环境下的配置问题主要源于服务内部通信机制与代理环境的兼容性。通过合理的网络配置和端口映射，可以确保Logto在Nginx等反向代理后正常工作。理解这些配置原理不仅有助于解决当前问题，也为未来在复杂环境中部署Logto提供了宝贵经验。