在Chrome浏览器里鼓捣WebRTC应用时，如果遇到媒体流获取失败、连接报错，或者冒出“Permission denied”、“NotReadableError”这类提示，别急着怀疑人生。大多数情况下，问题都出在权限、扩展、配置这几个环节上。

简单来说，你需要依次排查和设置这样几件事：

• 确认摄像头和麦克风权限已经放开
• 把可能捣乱的浏览器插件暂时关掉
• 给本地开发环境配置一下非安全上下文支持
• 关闭那个可能导致连接失败的IP保护机制
• 最后再通过几行测试代码验证一下——看看浏览器是不是真的已经具备WebRTC的通信能力了

如果你在Chrome里运行点对点视频通话之类的WebRTC应用，却发现媒体流死活拿不到、连接建立不起来，那多半就是上面这些环节出了问题。下面咱们就来一步步拆解，看看怎么把这些障碍清掉。

一、确认并启用摄像头与麦克风权限

WebRTC的核心就是实时调用本地的音视频设备。说白了，你得让浏览器知道，你允许这个网站用你的摄像头和麦克风，否则MediaStream API根本没法干活。

• 在地址栏直接输入 chrome://settings/content/camera 并回车，进入摄像头权限管理页面。
• 确保“询问前允许网站访问您的摄像头”这个总开关是打开的。然后检查下面的“不允许使用摄像头的网站”列表，如果目标网站不幸在里面，把它移掉。
• 用同样的方法，访问 chrome://settings/content/microphone，把麦克风权限也检查一遍。
• 回到你的目标网页，如果地址栏左边出现了摄像头图标，点一下，选择“始终允许”这个网站使用摄像头和麦克风。

二、禁用可能干扰WebRTC的扩展程序

很多广告拦截器或隐私保护类插件，像uBlock Origin、Privacy Badger这些，常常会“好心办坏事”——它们会主动屏蔽WebRTC的ICE候选收集、STUN请求，甚至直接拦截getUserMedia调用。结果就是信令失败，或者画面黑屏、没有流。

• 点击浏览器右上角三个点，进入“更多工具” -> “扩展程序”。
• 先别管哪个是哪个，把所有扩展的开关都关掉。特别注意那些名字里带“ad”、“block”、“privacy”、“rtc”、“webrtc”的，嫌疑很大。
• 重新加载你的WebRTC网页，看看问题是否消失。如果本地视频流能正常获取，连接也建立起来了，那就说明问题出在扩展上。
• 好了，现在可以逐个打开扩展来排查了。哪个一开就出问题，哪个就是罪魁祸首。要么把它加入白名单，要么直接卸了。

三、启用WebRTC非安全上下文支持（仅限本地开发）

Chrome出于安全考虑，默认只允许在HTTPS或localhost环境下调用WebRTC的API。如果你是在本地HTTP服务器上测试（比如 http://127.0.0.1:8080），那就需要手动给这个环境“开个绿灯”。这一步主要是给做本地开发的同学们准备的。

• 地址栏输入 chrome://flags/#unsafely-treat-insecure-origin-as-secure 并回车。
• 找到“Unsafely treat insecure origins as secure”这个实验性选项，把它从“Default”改成“Enabled”。
• 在下面出现的输入框里，填上你的本地测试地址，比如 http://127.0.0.1:8080 或 http://localhost。
• 点击页面右下角的“Relaunch”按钮，重启浏览器让设置生效。

四、关闭WebRTC IP地址泄漏防护（可选）

Chrome默认开启了一个叫“阻止网站获取您的真实IP地址”的功能，原理是通过mDNS来匿名化本地IP。这个功能的本意是保护隐私，但有时候也会误伤——它可能导致一些TURN/STUN服务无法正确识别你的NAT类型，从而影响P2P连接的成功率。

• 访问 chrome://settings/privacy，拉到最下面，在“安全性”区域点击“管理安全性设置”。
• 找到“防止网站获取您的真实IP地址”这个选项，把它关掉。
• 嫌上面步骤麻烦？也可以直接访问 chrome://flags/#enable-webrtc-hide-local-ips-with-mdns，把那个标志位设成“Disabled”，然后重启浏览器。

五、验证WebRTC基础能力是否就绪

前面几项设置都搞定之后，千万别以为就万事大吉了。一定要动手验证一下，确保浏览器是真的具备了可用的WebRTC通信链路，而不是光界面没报错。

• 打开一个新标签页，按F12打开开发者工具，切换到“Console”面板。
• 粘贴并执行下面这段测试代码：
  na vigator.mediaDevices.getUserMedia({video:true,audio:true}).then(s=>console.log(" 媒体流获取成功",s)).catch(e=>console.error(" 媒体流失败",e));
• 如果控制台里出现了“ 媒体流获取成功”，那说明设备权限和基础API都已经准备就绪。如果报错，就根据错误信息倒回去检查前面的环节，看是哪个没到位。
• 这还没完，再测一下核心连接对象。执行 new RTCPeerConnection({iceServers:[]})，只要不报错，就说明RTCPeerConnection可以正常创建，WebRTC的核心能力是完备的。

《夸克》非常好用的免费AI浏览器

下载APP查看