SRS WebRTC部署踩坑实录：WHIP 404报错？可能是你的证书和端口配置错了

SRS WebRTC部署实战WHIP 404报错深度排查指南引言当你满怀期待地按照官方文档部署SRS WebRTC服务却在关键时刻遭遇WHIP接口404报错时那种挫败感我深有体会。作为一名经历过多次类似问题的开发者我理解这种看似简单却令人抓狂的困境。WebRTC技术栈本身就足够复杂而SRS作为开源媒体服务器虽然功能强大但在实际部署中总会遇到各种坑。本文将带你深入分析WHIP 404错误的根源从证书配置到端口选择再到Nginx反向代理的妙用为你提供一套完整的排查思路和解决方案。1. 问题现象与初步诊断WebRTC推流时遇到WHIP接口404错误通常表现为推流窗口一闪而过浏览器控制台显示404状态码。这种问题看似简单实则可能涉及多个层面的配置错误。让我们先还原典型的问题场景环境配置CentOS 7.9系统SRS 5.0源码编译安装启动命令CANDIDATE192.168.6.240 ./objs/srs -c conf/https.rtc.conf 8000/udp错误日志[ERROR] serve error code4042(HttpsHandshake)(Failed to do handshake for HTTPS)关键诊断步骤端口连通性测试nc -vuz 192.168.6.240 8088如果返回Connection refused说明端口未正常监听证书验证检查证书文件路径是否正确验证证书是否自签名且被浏览器信任确保证书CN(Common Name)与访问域名/IP匹配日志分析重点HTTPS握手失败(4042错误码)证书验证相关警告端口绑定成功与否的提示2. HTTPS证书的陷阱与解决方案自签名证书是部署测试环境时的常见选择但也是WHIP 404错误的罪魁祸首之一。让我们深入分析证书相关的问题2.1 证书生成的关键细节典型的证书生成命令如下openssl genrsa -out server.key 2048 \ subj/CCN/STBeijing/LBeijing/OMe/OUMe/CN192.168.6.240 \ openssl req -new -x509 -signkey server.key -out server.crt -days 3650 -subj $subj常见问题点问题类型影响解决方案CN不匹配浏览器警告确保证书CN与访问地址完全一致证书路径错误服务启动失败检查配置文件中的证书路径权限问题读取失败确保SRS进程有证书文件读取权限2.2 浏览器信任问题处理即使生成了正确的证书浏览器仍可能拒绝信任Chrome特殊处理地址栏输入chrome://flags/#allow-insecure-localhost启用Allow invalid certificates for resources loaded from localhost系统级证书导入# CentOS系统证书导入示例 sudo cp server.crt /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust开发环境变通方案临时使用HTTP而非HTTPS不推荐生产环境使用Lets Encrypt等受信任的CA签发证书3. 端口配置的玄机8088 vs 1990SRS的配置文件中有多个HTTP/HTTPS端口设置理解它们的区别至关重要http_server { enabled on; listen 8080; https { enabled on; listen 8088; key ./cert/server.key; cert ./cert/server.crt; } } http_api { enabled on; listen 1985; https { enabled on; listen 1990; key ./cert/server.key; cert ./cert/server.crt; } }端口功能对比表端口用途适用协议典型问题8088WebRTC信令(WHIP/WHEP)HTTPS证书问题导致4041990HTTP API接口HTTPS跨域访问问题8000RTC媒体传输UDPNAT穿透问题端口选择建议WHIP/WHEP优先使用1990端口这是SRS专门为API设计的端口避免与Web服务器功能冲突推流地址格式https://[IP]:1990/rtc/v1/whip/?applivestreamlivestream https://[IP]:1990/rtc/v1/whep/?applivestreamlivestream防火墙配置检查sudo firewall-cmd --list-ports sudo firewall-cmd --add-port1990/tcp --permanent sudo firewall-cmd --reload4. Nginx反向代理优雅的解决方案当直接使用SRS的HTTPS端口遇到问题时Nginx反向代理是一个可靠的备选方案。4.1 基本代理配置server { listen 443 ssl; server_name your_domain.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location /rtc/ { proxy_pass https://localhost:1990; proxy_ssl_verify off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }配置要点将外部443端口代理到内部1990端口统一管理SSL证书解决浏览器对自签名证书的限制4.2 高级调优建议WebSocket支持proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade;负载均衡配置upstream srs_cluster { server 192.168.1.100:1990; server 192.168.1.101:1990; }访问控制location /rtc/ { allow 192.168.1.0/24; deny all; # 其他代理配置... }5. 系统级问题排查当上述方案都不能解决问题时可能需要深入系统层面排查系统资源检查# 查看端口占用情况 ss -tulnp | grep -E 8088|1990 # 检查SRS进程是否正常运行 ps aux | grep srs # 查看系统资源限制 ulimit -aSRS日志分析技巧启用详细日志srs_log_tank file; srs_log_file ./objs/srs.log; srs_log_level trace;关键日志模式HttpsHandshake错误证书问题bind失败端口冲突ICE超时网络/NAT问题网络诊断工具# 检查端口可达性 telnet 192.168.6.240 1990 # 测试HTTPS连接 curl -vk https://192.168.6.240:1990/rtc/v1/whip/ # 抓包分析 tcpdump -i any port 1990 -w srs.pcap