WebRTC服务器故障求助：重启后WebSocket握手返回502错误

咱们先把问题拆透：Chrome报的WebSocket握手502错误，本质是Nginx没法正常连接后端的uWSGI服务——Nginx日志里的connect() failed (111: Connection refused)已经把原因说得很明确了。结合是服务器重启后出现的问题，咱们按优先级一步步排查：

第一步：先确认uWSGI服务到底有没有跑起来 #

服务器重启后，uWSGI大概率没自动启动，或者启动过程中出了错。先执行这几个命令验证：

• 查看uWSGI进程状态：

  ps aux | grep uwsgi
  

  如果搜不到对应进程，说明服务根本没起来；如果能搜到，也得看进程是不是处于正常运行状态。
• 翻uWSGI的启动日志（一般在/var/log/uwsgi/或者你自己配置的日志路径），看看有没有启动报错——比如端口被占、配置文件语法错了、Python WebRTC模块的依赖没加载成功（重启后环境变量可能变了）。

第二步：核对Nginx和uWSGI的通信配置是否匹配 #

Nginx要连uWSGI，两者的通信地址必须完全对得上：

1. 打开你的Nginx站点配置文件（比如/etc/nginx/sites-available/your-domain.conf），找到WebSocket相关的location块，看proxy_pass或者uwsgi_pass的配置：

   location /rtc/ {
       proxy_pass http://127.0.0.1:8000;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       # 其他WebSocket配置项...
   }
   

2. 再打开uWSGI的配置文件，对比里面的监听设置：

   socket = 127.0.0.1:8000
   # 或者是 unix:///var/run/uwsgi/your-app.sock 这种套接字路径
   

   如果Nginx配置的是TCP端口，uWSGI却监听的是unix套接字，或者端口号不匹配，肯定会连不上。

第三步：检查端口/套接字的权限和可用性 #

• 如果用的是TCP端口，先确认端口没被其他进程抢了：

  netstat -tulpn | grep 8000 # 把8000换成你的实际端口
  

  要是有其他进程占用，要么杀掉那个进程，要么改uWSGI和Nginx的端口配置。
• 如果用的是unix套接字，得检查套接字文件的权限：

  ls -l /var/run/uwsgi/your-app.sock
  

  确保Nginx的运行用户（一般是www-data）有读写权限，必要时可以在uWSGI配置里加chmod-socket = 666，或者把Nginx用户加到uWSGI的用户组里。

第四步：验证WebRTC Python模块的初始化状态 #

就算uWSGI进程在跑，WebRTC的WebSocket服务也可能没正确启动：

• 查看Python应用的日志，看看有没有初始化报错——比如WebSocket服务的端口绑定失败、依赖库（比如aiortc这类WebRTC库）加载出错。
• 可以手动在服务器上测试uWSGI的连接：

  curl http://127.0.0.1:8000/rtc/
  

  如果返回连接拒绝，说明uWSGI虽然启动了，但Python应用本身没在处理请求，得去排查代码的启动逻辑。

临时修复小技巧 #

如果确认uWSGI没启动，先手动启动试试：

uwsgi --ini /path/to/your-uwsgi-config.ini

启动成功后刷新浏览器，要是WebSocket连接恢复了，记得给uWSGI配置开机自启（比如用systemd服务），避免下次重启又掉链子。

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