Django Allauth 生产环境登录和注册出现 SMTP 535 错误，如何排查？

2026-11-04数据阿明

结论：先检查生产进程使用的 SMTP 凭据

Traceback 显示，邮件发送已进入 self.connection.login(self.username, self.password)，SMTP 服务器在认证阶段返回了 535。应先检查生产环境实际读取的用户名和密码、SMTP 主机是否对应当前邮箱，以及邮箱是否允许 SMTP 登录。

现有信息无法确定哪项配置有误，也无法将问题归因于 Django 6 或 Python 3.14 的兼容性。

ACCOUNT_EMAIL_VERIFICATION = "mandatory" 让登录或注册流程依赖验证邮件，因此邮件异常会影响当前请求。改成 "optional" 后能够登录，说明流程行为发生了变化，但不能证明 SMTP 已恢复正常；可选验证也不等于关闭邮件发送。

1. 核对邮箱账号和 SMTP 服务器

在 cPanel 的邮箱客户端配置页面，核对以下信息：

SMTP 主机名是否为 mail.agrotekpluss.com。
SMTP 用户名是否要求填写完整邮箱地址，例如 atpsus@agrotekpluss.com。
使用的是邮箱密码，还是服务商要求的应用密码或专用 SMTP 凭据。
邮箱是否启用，是否存在 SMTP 登录限制或认证锁定。
服务商要求使用的端口和加密方式。

除非服务商明确说明可以这样使用，否则不要把 cPanel 管理账号的密码当作邮箱密码。如果域名邮件服务已经迁移，原来的 mail. 地址也可能不再对应当前邮箱服务。

DEFAULT_FROM_EMAIL 是默认发件地址，EMAIL_HOST_USER 是这里用于 SMTP 登录的账号。修改发件地址通常无法解决 login() 阶段的认证失败。认证成功后，还要检查是否允许使用该发件地址。

2. 检查 Passenger 进程实际读取的配置

本地正常、生产失败时，先比较两边实际生效的配置。生产环境可能存在变量未注入、旧值覆盖新值、配置文件路径不同，或应用进程仍保留旧配置等情况。

可以先在生产部署使用的 Python 环境和项目目录中运行：

python manage.py shell

然后检查非敏感配置和凭据是否存在：

from django.conf import settings

print({
    "backend": settings.EMAIL_BACKEND,
    "host": settings.EMAIL_HOST,
    "port": settings.EMAIL_PORT,
    "use_tls": settings.EMAIL_USE_TLS,
    "use_ssl": settings.EMAIL_USE_SSL,
    "username_configured": bool(settings.EMAIL_HOST_USER),
    "password_configured": bool(settings.EMAIL_HOST_PASSWORD),
})

变量非空只能证明读取到了某个值，不能证明凭据正确。还需在受控环境中核对用户名和密码是否与邮箱配置一致，留意复制时带入的空格、换行，以及配置工具对引号和特殊字符的处理。如果密码本身包含特殊字符，应按配置工具的规则保存，不要随意删除字符或调用 .strip()。

原配置没有说明 config() 来自哪个库，因此无法判断其读取优先级和解析规则。

命令行 shell 与 Passenger Web 进程可能使用不同的环境变量。命令行检查通过后，仍需确认 Web 进程的配置来源。更新环境变量后，通过部署平台支持的方式重启应用，让新进程重新读取配置。不要把密码、完整环境变量或包含凭据的日志贴到公开渠道。

3. 脱离 Allauth，单独测试邮件发送

使用同一套 Django 配置直接发送测试邮件，可以判断故障是否独立于 Allauth 存在：

from django.conf import settings
from django.core.mail import send_mail

sent = send_mail(
    subject="SMTP diagnostic test",
    message="Test email from the production Django environment.",
    from_email=settings.DEFAULT_FROM_EMAIL,
    recipient_list=["atpsus@agrotekpluss.com"],
    fail_silently=False,
)

print("Messages accepted by the mail backend:", sent)

收件地址应使用你有权接收测试邮件的邮箱。如果仍然出现相同的 535，可以先排查 SMTP 配置和服务端认证，无需先修改 Allauth 的登录逻辑。

如果测试发送成功，而网页请求仍失败，应比较测试进程与 Passenger 进程的配置、Python 环境和重启状态。发送函数成功返回也不代表邮件一定进入收件箱，还需确认最终投递情况。

4. 按服务商要求确认 TLS 配置

当前配置：

EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_USE_SSL = False

这组配置表示使用 STARTTLS。如果邮件服务商明确要求端口 587 配合 STARTTLS，配置意图是一致的，但这不能证明服务器地址和凭据正确，也不能证明服务器允许当前账号认证。

如果服务商明确提供的是端口 465 的隐式 TLS，应将三项配置一起调整为：

EMAIL_PORT = 465
EMAIL_USE_TLS = False
EMAIL_USE_SSL = True

不要同时开启 EMAIL_USE_TLS 和 EMAIL_USE_SSL，也不要仅为尝试消除 535 而关闭加密。

这次异常发生在 SMTP 认证阶段，应优先检查账号、密码和服务端认证策略。如果出现证书错误、连接超时或 STARTTLS 不受支持，再按对应的新异常排查。

5. 凭据确认无误后，查看邮件服务器日志

如果生产进程读取的凭据与服务商配置完全一致，仍然返回 535，需要查看对应时间的服务端日志。使用托管邮箱时，可以联系服务商，提供失败时间、SMTP 主机、认证账号和生产服务器出口 IP，请其检查认证被拒绝的原因；不要提供密码。

需要确认邮箱是否被锁定、是否允许 SMTP AUTH、生产服务器 IP 是否受限，以及账号是否要求其他认证凭据。这些方向都需要核实，现有错误消息无法区分它们。

6. 什么时候考虑版本兼容性

目前没有证据能把问题归因于 Django 6.0.3 或 Python 3.14.3。输入中的 django-allauth: latest 也无法表明实际安装版本，可以记录版本供后续对比：

python -m pip show Django django-allauth
python --version

如果相同主机、端口、加密方式和凭据在其他客户端成功，而生产 Python 环境持续失败，再比较认证方式、运行环境及对应版本的问题记录。完成这些对照前，直接降级的依据不足。

修复 SMTP 后，应恢复业务要求的邮件验证策略，并使用未验证邮箱的账号重新测试注册、验证邮件发送、验证链接和登录流程。不要通过忽略发送异常或长期改为可选验证来代替修复。