【求助】Pi-KVM 仅在 H.264 WebRTC 模式下黑屏 局域网正常

buzhidao

问题：

Pi-KVM 在局域网环境和使用 Tailscale 时均正常。

但是Tailscale使用不太方便要双方都装了客户端，想直接内网穿透就能用。

用FRP 和 Lucky 的 STUN 服务进行内网穿透后，H.264 WebRTC 模式黑屏，MJPEG正常。

按照官方文档（https://docs.pikvm.org/webrtc_config/）的说明，添加了多个不同的 STUN 服务器行测试，还是不行。

用了Lucky 的 STUN 内网穿透等于是nat之后的公网ip了吧？

搜了好久不知道还有什么可能了，各位MJJ大佬能指条明路或者给个关键词嘛

ROSROS

你都多余来这里问，这里MJJ 对于这种PI DIY技术 基本0 基础，要论抬杠扯犊子 都是一个比一个 是人才。

buzhidao

ROSROS 发表于 2025-2-17 07:07
你都多余来这里问，这里MJJ 对于这种PI DIY技术 基本0 基础，要论抬杠扯犊子 都是一个比一个 是人才。 ...

印象中mjj无所不知

乖.含住

好的，用户在使用Pi-KVM进行内网穿透时遇到了问题。他们在局域网和Tailscale下都正常，但用FRP和Lucky的STUN服务穿透后，H.264 WebRTC模式黑屏，而MJPEG正常。用户已经按照官方文档添加了多个STUN服务器，但问题依旧。现在他们想知道可能的原因和解决方案。

首先，我需要分析WebRTC的工作机制。WebRTC需要STUN/TURN服务器来处理NAT穿透。如果STUN配置不当，可能导致连接失败。虽然用户已经添加了多个STUN服务器，但可能还有遗漏，比如TURN服务器，因为某些情况下仅STUN不足以穿透对称型NAT。

接下来，考虑Lucky的STUN服务是否足够。用户提到使用Lucky的STUN服务，但可能这只是一个STUN服务器，而缺乏TURN中继功能。如果NAT类型是对称型的，可能需要TURN服务器来中转流量。这时候，建议用户检查NAT类型，并考虑配置或使用包含TURN的服务，比如Coturn。

然后，FRP的配置是否正确。FRP作为反向代理，需要正确转发UDP端口，因为WebRTC使用UDP传输媒体流。如果FRP只配置了TCP，那么UDP流量无法通过，导致黑屏。用户需要确认FRP是否配置了UDP端口转发，特别是与WebRTC相关的端口（如40000-65535范围）。

防火墙设置也是关键。无论是Pi-KVM主机还是中间节点的防火墙，都需要放行相关的UDP端口。用户需要检查iptables或ufw设置，确保这些端口未被阻止。

此外，Pi-KVM的配置可能需要调整。用户应该检查/etc/kvmd/nginx/ssl-overrides.conf中的STUN配置是否正确，并且没有语法错误。同时，可以尝试在WebRTC配置中强制使用TURN服务器，或者调整ICE传输策略，优先使用中继连接。

最后，用户提到的Lucky的STUN服务是否暴露了正确的公网IP和端口。可能需要通过在线工具检查STUN服务器是否返回正确的公网地址，并确保该地址和端口在FRP配置中被正确映射。

总结可能的问题点：缺少TURN服务器、FRP未配置UDP转发、防火墙阻止UDP流量、STUN配置错误或NAT类型不支持。用户需要逐一排查这些方面，可能需要结合日志和网络工具进行诊断。

针对你遇到的问题，这里有一个系统化的排查和解决方案：

关键问题分析
WebRTC协议特性

WebRTC依赖STUN/TURN服务器穿透NAT，但需要双向可达的UDP通道。

如果NAT类型为对称型（Symmetric NAT），仅STUN可能不够，必须依赖TURN中继。

Lucky/FRP穿透的局限性

Lucky的STUN服务可能仅提供NAT映射发现，但未提供中继功能（TURN）。

FRP默认转发TCP流量，而WebRTC的媒体流依赖UDP，需要特别配置。

Pi-KVM WebRTC配置

官方文档的STUN配置可能未覆盖所有网络场景，尤其是多层NAT或对称型NAT。

解决方案步骤
1. 确认NAT类型
使用工具（如 STUN Tester）检查网络NAT类型。

如果显示为Symmetric NAT，则必须部署TURN服务器。

2. 部署TURN中继服务器
安装Coturn服务器（推荐）：

bash
复制
sudo apt-get install coturn
配置/etc/turnserver.conf：

ini
复制
listening-ip=0.0.0.0
relay-ip=服务器公网IP
external-ip=服务器公网IP
realm=yourdomain.com
user=username:password
重启服务：

bash
复制
systemctl restart coturn
3. 配置Pi-KVM使用TURN
修改/etc/kvmd/nginx/ssl-overrides.conf，添加TURN服务器：

nginx
复制
add_header Alt-Svc 'webrtc="turn:turn.yourdomain.com:3478?transport=udp"';
add_header Alt-Svc 'webrtc="turn:turn.yourdomain.com:3478?transport=tcp"';
添加ICE服务器配置：

nginx
复制
add_header Link '</api/webrtc/ice>; rel="webrtc"';
创建/etc/kvmd/nginx/ice-servers.json：

json
复制
{
  "iceServers": [
    { "urls": "stun:stun.l.google.com:19302" },
    {
      "urls": "turn:turn.yourdomain.com:3478",
      "username": "username",
      "credential": "password"
    }
  ]
}
4. 配置FRP转发UDP
修改FRP服务端配置（frps.ini）：

ini
复制
[common]
bind_port = 7000
# 添加UDP绑定端口范围
udp_port = 40000-65535
修改FRP客户端配置（frpc.ini）：

ini
复制
[webrtc-udp]
type = udp
local_ip = 127.0.0.1
local_port = 80  # Pi-KVM实际UDP端口
remote_port = 40000  # 选择一个端口
5. 防火墙放行UDP
在Pi-KVM主机执行：

bash
复制
sudo ufw allow 3478/udp  # TURN端口
sudo ufw allow 40000:65535/udp  # FRP UDP范围
6. 强制WebRTC使用TURN
修改Pi-KVM的WebRTC初始化参数：

javascript
复制
// 在Web界面注入代码或修改前端配置
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: "turn:turn.yourdomain.com:3478", username: "user", credential: "pass" }
  ],
  iceTransportPolicy: "relay"  // 强制仅使用TURN
});
7. 验证穿透路径
访问 WebRTC Troubleshooter 检查连接状态。

在浏览器控制台查看RTCPeerConnection的ICE候选信息，确认有relay类型候选。

替代方案
如果仍无法解决，可尝试以下方法：

改用TCP中转模式：

nginx
复制
# 在Nginx配置中强制H.264 over TCP
add_header Alt-Svc 'webrtc="tcp://your-frp-domain.com:443"';
降级到MJPEG（临时方案）：

bash
复制
# 修改Pi-KVM配置使用MJPEG
ln -sf /etc/kvmd/override.d/mjpeg.ini /etc/kvmd/override.d/streamer.ini
systemctl restart kvmd
通过以上步骤，应能解决因NAT类型或UDP转发导致的WebRTC黑屏问题。重点在于确保TURN中继可用且FRP正确转发UDP流量。