部署在Heroku的Django Channels 3.0.4 WebSocket连接失败求助

代码部分检查 #

先确认以下代码细节是否存在隐性问题：

• 检查routing.py中的路径参数：确保实际代码中是<username>而非转义后的<username>（你提供的代码示例是HTML转义后的显示，实际代码若写错会直接导致路由不匹配）。
• 调整consumers.py的连接逻辑顺序：建议先调用self.accept()建立连接，再执行群组添加操作（虽然之前运行正常，但顺序问题可能在特定环境下触发异常），调整后代码如下：

class MyQuizConsumer(WebsocketConsumer):
    def connect(self):
        log_and_print('QUIZ HOST TEST connecting...')
        self.accept()  # 优先完成WebSocket握手
        async_to_sync(self.channel_layer.group_add)(
            'id-1',
            self.channel_name
        )

• 确认asgi.py的完整配置：确保已正确注册WebSocket路由，示例配置如下：

import os
from django.core.asgi import get_asgi_application
from channels.routing import ProtocolTypeRouter, URLRouter
from channels.auth import AuthMiddlewareStack
import taskmanager.routing

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')

application = ProtocolTypeRouter({
    "http": get_asgi_application(),
    "websocket": AuthMiddlewareStack(
        URLRouter(
            taskmanager.routing.ws_urlpatterns
        )
    ),
})

Heroku配置排查重点 #

因为测试版应用运行正常，优先排查生产版Heroku的环境差异：

• Procfile配置：确认生产版的Procfile使用Daphne服务器而非Django自带的runserver，正确格式应为：

  web: daphne myproject.asgi:application --port $PORT --bind 0.0.0.0
  

  若误写为web: python manage.py runserver会直接导致WebSocket无法工作。
• Dyno状态：执行heroku ps查看web dyno是否正常运行，有无崩溃、重启记录；尝试手动重启dyno：heroku restart。
• Redis服务状态：Channels依赖Redis作为channel layer，检查生产版的REDIS_URL环境变量是否有效，Redis实例是否过期或连接异常。可通过heroku redis:info查看Redis状态，对比测试版配置。
• 实时日志排查：执行heroku logs --tail查看WebSocket连接请求的日志：
  • 若未看到QUIZ HOST TEST connecting...的日志输出，说明请求未到达消费者，需检查路由、Daphne配置或Heroku的请求路由规则；
  • 若看到日志但连接失败，检查channel_layer的Redis连接是否正常，或是否有未捕获的异常导致连接中断。
• SSL与HTTPS配置：确认生产版是否强制HTTPS，检查Heroku的SSL证书是否有效；你的JS代码已做wss://协议适配，此点可快速排除。
• 依赖版本锁定：检查requirements.txt中是否固定了Django、Channels及相关依赖的版本，避免Heroku自动升级依赖导致兼容性问题（测试版用相同代码库，此点概率低，但需确认）。
• Heroku路由规则：检查是否设置了影响WebSocket的应用级路由规则或防火墙限制，比如是否有自定义HTTP路由规则拦截了WebSocket请求。

内容的提问来源于stack exchange，提问作者Mark__C