在GCP部署Kurento-media-server无法向浏览器传视频流问题咨询

一、KMS核心配置排查（90%云环境部署问题出在这部分） #

• 登录GCP实例执行netstat -tulpn | grep kurento确认KMS正常监听8888端口，先把自定义OpenCV滤镜从pipeline中摘除，跑官方原生的点对点流转发测试，如果原生流都无法正常传输，先不用排查滤镜相关问题。
• 打开KMS配置文件/etc/kurento/kurento.conf.json找到webRtcEndpoint配置段，必须显式将publicIp配置为GCP实例的公网IP。本地localhost环境运行时KMS可以自动识别127.0.0.1地址，云环境下KMS默认会读取网卡上的内网IP（10.x.x.x段）作为ICE候选发给浏览器，浏览器拿到内网地址根本无法建立连接，这是云环境部署Kurento最常见的配置疏漏。
• 查看KMS运行日志，默认存储路径为/var/log/kurento-media-server/，重点检索滤镜加载失败、pipeline初始化报错、帧处理中断类报错。本地能正常运行不代表Docker镜像内依赖完整，很多打包场景会漏装OpenCV依赖的动态链接库、H264/VP8编解码库，会导致pipeline看似启动成功，实际媒体流走到滤镜环节就中断，根本不会向WebRTC端点送帧。

二、Docker网络配置校验 #

• 如果将KMS打包在Docker镜像中运行，启动容器时直接加--net=host参数使用宿主机网络，别用默认的bridge模式。WebRTC需要占用49152-65535的大段UDP端口，bridge模式下端口映射很容易遗漏，还会出现NAT转换导致的候选地址错误。
• 进入运行中的KMS容器执行ip a查看网卡地址，确认KMS识别到的出口IP是宿主机公网IP，不是Docker虚拟网卡的172.17.0.x段地址，如果拿到虚拟网卡IP，生成的ICE候选全是无效内网地址。
• 容器内执行curl ifconfig.me查看出口公网IP，确认和实例绑定的公网IP一致，排除容器NAT出口异常问题。

三、Coturn与ICE链路排查 #

• 先验证coturn本身是否正常工作，在实例本地执行turnutils_uclient -u 配置的turn用户名 -w 配置的turn密码 实例公网IP，如果该测试连通失败，优先调整coturn配置：
  • listening-ip填写实例内网IP，external-ip填写实例公网IP，不要直接填公网IP做监听，会导致绑定失败。
  • 确认coturn配置的认证用户名密码、域值和Springboot后端写入的TURN配置完全一致，任意字段错配都会导致中继失败。
• 检查Springboot中的Kurento客户端配置，发给浏览器的ICE候选列表不要携带实例内网IP段，只保留公网主机候选和TURN中继候选。
• 浏览器打开应用后按F12调出开发者工具，切到WebRTC内部调试页面查看ICE连接状态：
  • 如果状态一直卡在checking，逐层检查防火墙：不要只配置GCP侧防火墙规则，Ubuntu本地如果开启了ufw，也要放行3478（TURN端口）、49152-65535（KMS媒体端口）的UDP流量；另外进入GCP实例的网卡配置页，关闭「源和目标检查」选项，GCP默认会丢弃源目IP和实例不匹配的流量，TURN中继流量很容易被该规则拦截。
  • 如果ICE状态显示connected但是没有画面，直接排查自定义OpenCV滤镜的运行日志，基本都是滤镜处理帧时崩溃导致，比如云服务器无GPU触发CUDA逻辑报错、输入帧格式和本地测试环境不一致导致处理中断。

四、快速定位问题的验证步骤 #

• 摘掉自定义滤镜跑原生流转发，如果能正常出流，说明问题完全出在自行构建的Docker镜像的滤镜依赖上，重点检查容器内OpenCV相关动态链接库、KMS滤镜模块的文件权限。
• 临时关闭实例侧ufw、GCP侧先全开所有TCP/UDP端口测试，如果能通再逐步收窄端口规则，排除漏放端口的问题。
• 如果实例绑定的是临时公网IP，重启后IP变化要同步修改KMS和coturn中的publicIp配置，否则会持续发送旧IP的无效候选。

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