AWS EC2实例上WebRTC应用ICE连接失败排查求助

问题背景 #

我正在开发一款WebRTC应用，其中一个对等端为后端服务器。本地环境运行正常，ICE连接可成功建立，但将包含信令服务和对等端的后端服务器部署到AWS EC2实例后，ICE连接始终无法完成。

已尝试操作 #

• 使用metered.ca提供的STUN和TURN服务器
• 在EC2实例上开放WebRTC所需的所有UDP和TCP端口
• 确认EC2实例可访问STUN和TURN服务器

观察结果 #

• 本地运行正常，说明基础实现无误，仅部署到EC2实例时出现问题

核心问题 #

EC2实例上ICE连接失败的原因可能是什么？有没有类似问题的解决经验？欢迎提供见解或建议！

客户端对等端（接收的消息） #

sdp {"sdp":"v=0\r\no=- 240022908004722204 989481823 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 ED:68:4A:BE:B4:57:06:52:12:32:76:C6:97:B4:E3:38:C3:D7:62:17:00:C4:82:6A:C6:91:E0:BC:C4:6F:1D:1B\r\na=group:BUNDLE 0 1\r\nm=audio 9 UDP/TLS/RTP/SAVPF
111 9 0 8\r\nc=IN IP4 0.0.0.0\r\na=setup:active\r\na=mid:0\r\na=ice-ufrag:jyRLMFbLqPUgRphu\r\na=ice-pwd:BvOTXnDoGRlLZWJjOvbPlupBRxTXNsXl\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtcp-fb:111
transport-cc\r\na=rtpmap:9 G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=ssrc:3651177996 cname:webrtc-rs\r\na=ssrc:3651177996 msid:webrtc-rs track-audio\r\na=ssrc:3651177996
mslabel:webrtc-rs\r\na=ssrc:3651177996 label:track-audio\r\na=msid:webrtc-rs track-audio\r\na=sendrecv\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 0.0.0.0\r\na=setup:active\r\na=mid:1\r\na=sendrecv\r\na=sctp-port:5000\r\na=ice-ufrag:jyRLMFbLqPUgRphu\r\na=ice-pwd:BvOTXnDoGRlLZWJjOvbPlupBRxTXNsXl\r\n","type":"answer"}

{"candidate":"udp host 172.31.15.252:49434","sdpMid":null,"sdpMLineIndex":null,"usernameFragment":null} {"candidate":"udp host 172.17.0.1:55449","sdpMid":null,"sdpMLineIndex":null,"usernameFragment":null} 
{"candidate":"udp relay 139.59.19.18:560210.0.0.0","sdpMid":null,"sdpMLineIndex":null,"usernameFragment":null}
{"candidate":"udp relay 139.59.19.18:359900.0.0.0","sdpMid":null,"sdpMLineIndex":null,"usernameFragment":null} {"candidate":"udp srflx 13.233.20.77:488520.0.0.0","sdpMid":null,"sdpMLineIndex":null,"usernameFragment":null}

13.233.20.77是我的EC2实例公网IP，可在上述发送给客户端对等端的最后一条候选信息中看到。

服务器对等端（接收的消息） #

sdp {"type":"offer","sdp":"v=0\r\no=- 3907482112097151524 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0 1\r\na=extmap-allow-mixed\r\na=msid-semantic: WMS 72d2cdcd-42e8-40aa-aea9-8b0a41952082\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110
126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:Ibni\r\na=ice-pwd:yV+xCsnzd9MPRffWcdfWJyfe\r\na=ice-options:trickle\r\na=fingerprint:sha-256 DB:DF:26:7B:55:84:BC:44:3D:C9:47:7C:C0:0D:DC:AD:57:A8:F2:83:58:D4:5A:B3:22:5B:D7:8D:5B:08:65:1F\r\na=setup:actpass\r\na=mid:0\r\na=extmap:1
urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=sendrecv\r\na=msid:72d2cdcd-42e8-40aa-aea9-8b0a41952082
b6416a9b-c811-4d15-9368-1772be9bfaad\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=rtcp-fb:111 transport-cc\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtpmap:63 red/48000/2\r\na=fmtp:63 111/111\r\na=rtpmap:9 G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8
PCMA/8000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:110 telephone-event/48000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:1848777914 cname:vYV3Pu/m38Hrw8ZW\r\na=ssrc:1848777914 msid:72d2cdcd-42e8-40aa-aea9-8b0a41952082 b6416a9b-c811-4d15-9368-1772be9bfaad\r\nm=application
9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:Ibni\r\na=ice-pwd:yV+xCsnzd9MPRffWcdfWJyfe\r\na=ice-options:trickle\r\na=fingerprint:sha-256 DB:DF:26:7B:55:84:BC:44:3D:C9:47:7C:C0:0D:DC:AD:57:A8:F2:83:58:D4:5A:B3:22:5B:D7:8D:5B:08:65:1F\r\na=setup:actpass\r\na=mid:1\r\na=sctp-port:5000\r\na=max-message-size:262144\r\n"}

{"type":"candidate","candidate":{"candidate":"candidate:3876928226 1 udp 2122260223 192.168.1.11 54334 typ host generation 0 ufrag Ibni network-id 1 network-cost 10","sdpMid":"0","sdpMLineIndex":0}} {"type":"candidate","candidate":{"candidate":"candidate:3876928226
1 udp 2122260223 192.168.1.11 59055 typ host generation 0 ufrag Ibni network-id 1 network-cost 10","sdpMid":"1","sdpMLineIndex":1}} {"type":"candidate","candidate":{"candidate":"candidate:2581256314 1 tcp 1518280447 192.168.1.11 9 typ host tcptype active
generation 0 ufrag Ibni network-id 1 network-cost 10","sdpMid":"0","sdpMLineIndex":0}} 
{"type":"candidate","candidate":{"candidate":"candidate:1928205250 1 udp 41885951 139.59.19.18 38534 typ relay raddr 106.222.202.29 rport 22875 generation 0 ufrag Ibni network-id 1 network-cost 10","sdpMid":"0","sdpMLineIndex":0}} {"type":"candidate","candidate":{"candidate":"candidate:1928205250 1 udp 41886463 139.59.19.18 57046 typ relay raddr 106.222.202.29 rport 31043 generation 0 ufrag Ibni network-id 1 network-cost
10","sdpMid":"0","sdpMLineIndex":0}} {"type":"candidate","candidate":{"candidate":"candidate:203551066 1 udp 25108991 139.59.19.18 56509 typ relay raddr 106.222.202.29 rport 4510 generation 0 ufrag Ibni network-id 1 network-cost 10","sdpMid":"0","sdpMLineIndex":0}}
{"type":"candidate","candidate":{"candidate":"candidate:4020057022 1 udp 8331263 139.59.19.18 60961 typ relay raddr 106.222.202.29 rport 25300 generation 0 ufrag Ibni network-id 1 network-cost 10","sdpMid":"0","sdpMLineIndex":0}} 
{"type":"candidate","candidate":{"candidate":"candidate:2817476683
1 udp 1686052607 106.222.202.29 12826 typ srflx raddr 192.168.1.11 rport 54334 generation 0 ufrag Ibni network-id 1 network-cost 10","sdpMid":"0","sdpMLineIndex":0}}

可能的原因及解决方案 #

1. ICE候选格式错误 #

观察客户端收到的服务器候选，存在明显格式问题：比如"udp relay 139.59.19.18:560210.0.0.0"，端口与后续IP拼接错误，且并非标准SDP候选格式。这种错误会导致客户端无法解析候选，直接阻断ICE连接。

• 解决方法：检查后端代码的候选发送逻辑，确保直接将PeerConnection生成的标准候选对象（包含完整candidate字段）通过信令转发，不要自行拼接自定义格式的字符串。

2. EC2实例的IP映射问题 #

EC2默认使用内网IP（172.31.15.252）绑定服务，后端WebRTC可能无法自动识别公网IP，导致生成的候选以内网IP为主，客户端无法访问。

• 解决方法：初始化PeerConnection时，在配置中强制指定优先使用公网IP生成候选；或者在后端代码中过滤掉内网候选，只对外发送公网和relay类型的候选。

3. 安全组与网络ACL的双向规则缺失 #

虽然开放了端口，但AWS网络ACL是无状态的，需要同时配置入站和出站的UDP/TCP规则，覆盖WebRTC使用的端口范围（默认49152-65535）。另外要确认EC2实例是否处于公有子网，若在私有子网需检查NAT网关的转发规则是否正常。

4. TURN服务器配置验证 #

EC2能访问TURN服务器不代表配置完全正确，需确认：

• PeerConnection的iceServers配置包含正确的用户名、凭证
• TURN服务器同时支持UDP和TCP传输（部分场景UDP会被运营商封锁）
• 使用工具测试TURN服务器是否能生成有效的relay候选，确保后端配置的TURN服务可用

5. 后端WebRTC库的环境适配问题 #

若后端使用第三方WebRTC库（如webrtc-rs），需确认：

• 库支持无图形界面的服务器环境，是否需要禁用音视频设备检测等依赖
• ICE收集逻辑是否适配EC2的网络环境，是否需手动设置iceTransportPolicy为"relay"强制走TURN通道

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