1. 项目概述最近在折腾一个基于WebRTC的实时音视频项目踩了不少坑尤其是信令服务器这块。项目里用到了signalmaster这个轻量级的信令服务器但在实际部署时发现一个关键问题现代浏览器对于WebRTC的安全要求越来越严格尤其是在非HTTPS环境下很多功能比如获取摄像头、麦克风权限会被直接禁止。这就意味着如果你想让你的WebRTC应用在公网上能被正常访问给信令服务器配置SSL证书、启用HTTPS/WSS连接几乎成了必选项。然而网上关于signalmaster的教程大多集中在基础使用对于如何给它“穿上”SSL证书这件安全外衣讲得要么语焉不详要么步骤零散。今天我就把自己从申请证书到最终让signalmaster跑在HTTPS下的完整过程以及中间遇到的各种“坑”和解决方案详细拆解一遍。无论你是刚接触WebRTC的新手还是正在为信令安全头疼的开发者这篇实战记录应该都能给你提供一条清晰的路径。2. 核心需求与方案选型2.1 为什么信令服务器必须上HTTPS很多人刚开始接触WebRTC时会觉得信令服务器只是用来交换一下SDP和Candidate用个简单的HTTP/WS服务跑在本地或者内网好像也没问题。但一旦你需要真刀真枪地部署到公网让用户通过浏览器访问情况就完全不同了。首先是浏览器的安全策略。以Chrome、Firefox为代表的现代浏览器明确要求获取用户媒体getUserMedia的页面必须运行在安全上下文Secure Context中。简单说就是你的网页必须通过HTTPS或localhost加载。如果你的信令服务器还是HTTP那么页面即使通过HTTPS加载但与信令服务器的WebSocket连接WS也是不安全的混合内容浏览器会阻止媒体设备的访问你的视频通话也就无从谈起。必须升级到WSSWebSocket Secure。其次是数据安全。信令过程中交换的SDP会话描述协议信息虽然本身是文本但其中可能包含候选地址Candidate等网络信息。在公网环境下明文传输存在被窃听或篡改的风险。启用HTTPS/WSS后整个信令通道都是加密的能有效防止中间人攻击。最后是生产环境的基本要求。任何面向公众的Web服务使用HTTPS已经是行业标准和用户信任的基础。搜索引擎如Google也会对HTTPS站点给予排名优待。所以给signalmaster配置SSL证书不是“锦上添花”而是“雪中送炭”是WebRTC应用能够正式上线运行的前提。2.2 SignalMaster与SSL证书部署的几种方案Signalmaster本身是一个基于Node.js和Socket.io的服务器。要让其支持HTTPS/WSS核心是为Node.js的HTTP/HTTPS服务器模块提供SSL证书。通常有以下几种部署方案Signalmaster内置HTTPS服务器直接服务这是最直接的方式。修改signalmaster的服务器启动代码使用Node.js的https模块创建服务器并加载你的证书和私钥。这种方式简单但通常需要你直接修改signalmaster的源码或配置。使用反向代理如Nginx这是更推荐、更灵活的生产环境方案。让Nginx监听443端口HTTPS处理SSL/TLS握手、证书验证等繁重工作然后将解密后的普通HTTP请求反向代理到后端运行在某个端口如8080的signalmasterHTTP服务。Signalmaster本身无需感知HTTPS只需处理HTTP即可。Nginx作为专业Web服务器在SSL性能优化、负载均衡、静态文件服务等方面有巨大优势。使用PM2等进程管理器结合方案1如果你选择方案1并且需要进程守护、日志管理、集群等功能可以配合PM2来管理你的signalmaster HTTPS进程。我为什么选择“Nginx反向代理”方案职责分离Nginx专精于高效处理网络I/O和SSLNode.jssignalmaster专注于业务逻辑信令交换。各司其职性能更优。配置灵活在Nginx中管理SSL证书、域名、重定向HTTP到HTTPS非常方便。未来如果需要添加多个WebRTC相关服务如TURN服务器前端、状态页也易于扩展。便于维护证书续期、更换等操作只在Nginx层面进行不影响后端信令服务器的运行。社区实践这是部署Node.js应用最普遍、最受认可的模式。因此本实战将围绕“Nginx反向代理 SignalMaster”这个架构展开。我们的目标是用户通过https://your-domain.com访问WebRTC应用页面页面通过wss://your-domain.com/socket.io/...与信令服务器安全通信。3. 实战准备环境与证书3.1 基础环境说明我使用的环境是阿里云的一台CentOS 7.x服务器。假设你已经具备以下条件一台拥有公网IP的云服务器Ubuntu/CentOS等均可步骤大同小异。一个已经解析到该服务器公网IP的域名例如webrtc.yourdomain.com。这是申请SSL证书所必需的。服务器上已安装Node.jsv12和npm。Signalmaster的运行依赖。服务器上已安装Nginx。基本的Linux命令行操作能力。如果你还没有安装Node.js和Nginx可以通过包管理器快速安装# CentOS/RHEL sudo yum install -y epel-release sudo yum install -y nodejs npm nginx # Ubuntu/Debian sudo apt update sudo apt install -y nodejs npm nginx安装后可以通过node -v,npm -v,nginx -v验证安装。3.2 获取SSL证书以Let‘s Encrypt为例SSL证书有付费的如DigiCert, GeoTrust和免费的如Let‘s Encrypt。对于个人项目、测试或中小型应用Let‘s Encrypt提供的免费、自动化的证书是完全够用的并且被广泛信任。我们将使用certbot工具来自动化获取和安装证书。这是EFF电子前沿基金会维护的官方客户端。安装Certbot和Nginx插件# CentOS 7 (需要先启用EPEL) sudo yum install -y epel-release sudo yum install -y certbot python2-certbot-nginx # Ubuntu/Debian sudo apt update sudo apt install -y certbot python3-certbot-nginx安装Nginx插件是为了让certbot能自动修改Nginx配置实现自动续期。获取并安装证书 执行以下命令certbot会自动检测Nginx的配置并引导你完成域名选择和验证。sudo certbot --nginx过程中你会被要求输入你的邮箱用于接收证书到期提醒和紧急通知。同意服务条款。选择你要为哪个域名申请证书它会列出Nginx配置中找到的所有server_name。是否将HTTP流量重定向到HTTPS强烈建议选择“2: Redirect”。如果一切顺利certbot会自动完成以下工作向Let‘s Encrypt申请证书。通过HTTP-01挑战验证你对域名的控制权它会临时在你的网站根目录下创建一个文件供CA访问验证。下载证书和私钥通常存放在/etc/letsencrypt/live/your-domain.com/目录下。自动修改你的Nginx站点配置文件添加SSL相关配置并设置HTTP到HTTPS的重定向。验证证书文件 申请成功后关键的文件是/etc/letsencrypt/live/your-domain.com/fullchain.pem证书链文件包含你的证书和中间CA证书。/etc/letsencrypt/live/your-domain.com/privkey.pem私钥文件。还有cert.pem和chain.pem但Nginx配置通常使用fullchain.pem重要提示/etc/letsencrypt/live/目录下的文件是符号链接指向/etc/letsencrypt/archive/your-domain.com/目录下的实际文件。在Nginx配置中请始终引用live目录下的路径因为续期后链接会自动更新。自动续期 Let‘s Encrypt证书有效期是90天。Certbot安装时会创建一个定时任务cron job或systemd timer来自动续期。你可以手动测试续期流程sudo certbot renew --dry-run如果测试成功就无需担心证书过期问题。实操心得证书申请避坑防火墙申请证书时确保服务器的80端口HTTP和443端口HTTPS在防火墙中是开放的因为Let‘s Encrypt的验证和后续服务都需要访问这些端口。# 如果使用firewalld (CentOS 7) sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps sudo firewall-cmd --reload # 如果使用ufw (Ubuntu) sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw reload域名解析务必确保你的域名已正确解析到服务器的公网IP并且生效可通过ping your-domain.com或nslookup your-domain.com检查。解析未生效会导致验证失败。Nginx配置在运行certbot --nginx前最好先有一个基本的Nginx配置监听80端口并且server_name设置正确。Certbot依赖这个配置来识别域名。4. SignalMaster的安装与基础配置4.1 获取与运行SignalmasterSignalmaster是AppRTC项目的一部分但我们可以单独使用它。最简单的方式是通过npm全局安装其独立版本或者克隆仓库。方法一使用npm推荐方便# 全局安装signalmaster sudo npm install -g signalmaster # 安装后可以直接通过命令启动一个基础的HTTP信令服务器 # signalmaster --port 8888 # 但我们需要配置它所以更常用的是使用自定义配置文件启动不过全局安装的版本可能不方便自定义。我更倾向于克隆源码这样可以灵活修改。方法二克隆源码# 创建一个项目目录 mkdir ~/webrtc-signal cd ~/webrtc-signal # 克隆signalmaster仓库注意原始的webrtc/apprtc仓库中的signalmaster可能不是最新独立版本 # 我们可以使用一个维护较好的fork或者直接使用socket.io的示例。这里以某个常见版本为例 git clone https://github.com/simplewebrtc/signalmaster.git cd signalmaster npm install克隆后目录下关键文件是server.js和config.json或config.json.example。4.2 理解Signalmaster的配置Signalmaster的核心配置通常通过一个JSON文件或环境变量进行。我们创建一个自定义的配置文件config/production.json假设项目结构支持config目录。{ isDev: false, server: { port: 8080, // Signalmaster监听的端口我们将通过Nginx代理到这个端口 host: 0.0.0.0, // 监听所有网络接口 secure: false // 关键因为我们用Nginx处理HTTPS所以这里设为falseSignalmaster自身以HTTP运行。 }, rooms: { maxClients: 0 // 0表示无限制 }, stunservers: [ {urls: stun:stun.l.google.com:19302} ], turnservers: [ // 如果你有自己的TURN服务器在这里配置 // { // urls: [turn:your-turn-server.com:3478], // username: username, // credential: password, // auth: secret // } ], redis: { // 如果你需要多进程/多服务器部署可以用Redis做适配器存储单机可忽略 // host: 127.0.0.1, // port: 6379 } }配置要点解析server.port: 这是Signalmaster内部服务监听的端口我们将在Nginx配置中把请求代理到这个端口。server.secure:必须设置为false。因为我们采用Nginx反向代理方案SSL终止SSL Termination发生在Nginx层。Nginx与Signalmaster之间的通信是在内网或本地回环地址上使用HTTP是安全且高效的。如果这里设为trueSignalmaster会尝试以HTTPS服务器启动需要你提供证书这就复杂了且没必要。host: “0.0.0.0”: 确保服务监听在所有网络接口上方便Nginx从本地连接。4.3 启动SignalmasterHTTP模式使用你的配置文件启动Signalmaster。假设你的配置文件在~/webrtc-signal/signalmaster/config/production.json。cd ~/webrtc-signal/signalmaster # 通过环境变量指定配置文件或者修改server.js硬编码加载你的配置 # 这里假设signalmaster支持CONFIG环境变量 CONFIG./config/production.json node server.js或者你可以直接修改server.js将加载配置的路径指向你的production.json。启动后你应该能看到类似以下的日志表明Signalmaster正在8080端口以HTTP模式运行[INFO] SignalMaster server running at http://0.0.0.0:8080此时你可以用curl在服务器上测试一下curl http://localhost:8080/socket.io/?EIO4transportpolling如果返回一串包含sid的JSON数据说明信令服务器基础功能正常。注意事项进程管理直接通过node server.js启动进程会在前台运行关闭终端就会停止。对于生产环境我们需要一个进程守护工具。推荐使用pm2。# 全局安装pm2 sudo npm install -g pm2 # 使用pm2启动signalmaster并设置为开机自启 cd ~/webrtc-signal/signalmaster pm2 start server.js --name signalmaster --interpreter node -- -c ./config/production.json # 或者通过 ecosystem.config.js 文件配置更灵活 pm2 save pm2 startup # 根据提示执行命令设置系统服务这样Signalmaster就会在后台稳定运行即使服务器重启也会自动启动。5. Nginx反向代理配置详解这是将HTTP的Signalmaster安全地暴露给HTTPS/WSS外网的关键步骤。5.1 基本的HTTPS代理配置Certbot在申请证书时可能已经为你修改了Nginx配置。我们需要在其基础上添加对Signalmaster WebSocket路径的反向代理。找到你的Nginx站点配置文件通常位于/etc/nginx/conf.d/your-domain.com.conf或/etc/nginx/sites-available/your-domain.comUbuntu。我们打开并编辑它。在原有的server块监听443端口内部我们需要添加一个特定的location块来处理信令服务器的WebSocket连接。Socket.io的默认路径通常是/socket.io/。server { listen 443 ssl http2; # 监听443启用SSL和HTTP/2 server_name webrtc.yourdomain.com; # 你的域名 # SSL证书配置这部分通常是certbot自动添加的 ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # 静态文件服务如果你的WebRTC前端页面也由此Nginx服务 root /var/www/webrtc-app; # 你的前端文件目录 index index.html; location / { try_files $uri $uri/ 404; } # 关键配置反向代理到Signalmaster的WebSocket连接 location /socket.io/ { proxy_pass http://127.0.0.1:8080; # 指向Signalmaster运行的地址和端口 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 86400s; # WebSocket连接可能保持很长时间需要设置较长的超时 proxy_send_timeout 86400s; } # 可能还需要代理其他API路径如果你的信令服务器有其他HTTP端点 # location /api/ { # proxy_pass http://127.0.0.1:8080; # proxy_set_header Host $host; # proxy_set_header X-Real-IP $remote_addr; # ... 其他代理头 # } }配置解析proxy_pass http://127.0.0.1:8080;: 将所有到达/socket.io/的请求转发到本机8080端口运行的Signalmaster。proxy_http_version 1.1;: 使用HTTP/1.1协议这是WebSocket升级所必需的。proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection “upgrade”;: 这两个头部是WebSocket代理的核心。它们告诉Nginx将客户端发起的HTTP连接“升级”为WebSocket协议并保持长连接。proxy_set_header Host $host;等将一些原始请求头信息传递给后端服务器这对于日志记录、IP识别等很有用。proxy_read_timeout 86400s;: WebSocket连接是持久连接可能维持数小时甚至数天。将代理的超时时间设置得非常长这里设为24小时避免Nginx因为长时间没有数据传输而主动断开连接。5.2 处理CORS跨域资源共享如果你的WebRTC前端页面HTML/JS与信令服务器通过Nginx代理后不在同一个域名/端口下浏览器会因同源策略阻止WebSocket连接。虽然我们通过Nginx代理后域名通常是相同的但如果你有特殊架构可能需要处理CORS。Signalmaster的Socket.io服务器端通常已经内置了CORS处理。但在Nginx层面也可以添加响应头来确保万无一失。可以在上面的location /socket.io/块中添加add_header Access-Control-Allow-Origin https://your-frontend-domain.com always; add_header Access-Control-Allow-Credentials true always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS always; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range always;如果前端和后端在同一域名下则不需要这些。5.3 配置测试与重载配置完成后务必检查Nginx配置文件的语法是否正确sudo nginx -t如果输出syntax is ok和test is successful就可以安全地重载Nginx使配置生效sudo nginx -s reload # 或者 systemctl reload nginx (systemd系统)6. 客户端前端配置调整现在服务器端的HTTPS和WSS已经就绪。你需要修改你的WebRTC前端JavaScript代码将连接信令服务器的地址从http://或ws://改为wss://。假设你之前使用类似socket.io-client库这样连接// 旧的、不安全的连接本地开发或HTTP环境 // const socket io(http://localhost:8080); // 或 const socket io(ws://your-server-ip:8080); // 新的、安全的连接生产HTTPS环境 const socket io(https://webrtc.yourdomain.com, { path: /socket.io/, // 如果Nginx配置的location是 /socket.io/ transports: [websocket, polling], // 优先WebSocket降级为轮询 secure: true, // 使用安全连接 rejectUnauthorized: false // 仅在开发或使用自签名证书时可能需要生产环境使用可信证书应设为true或省略 });关键参数第一个参数是服务器地址现在必须是https://开头的域名。path: 必须与Nginx配置中的location路径匹配这里是/socket.io/。secure: true: 明确指示使用安全连接。rejectUnauthorized: 如果使用的是Let‘s Encrypt等受信任CA颁发的证书浏览器和Node.js客户端都会自动验证不需要设置这个。如果你在Node.js后端环境中测试连接且使用自签名证书可能需要将其设为false来跳过证书验证但生产环境绝对不要这样用。前端部署将你的HTML、JS、CSS等前端文件放置到Nginx配置中root指令指定的目录例如/var/www/webrtc-app。确保通过https://webrtc.yourdomain.com能正常访问到你的首页。7. 完整链路测试与验证所有组件配置完成后我们需要进行端到端的测试确保HTTPS/WSS信令链路完全畅通。7.1 分步验证验证HTTPS站点访问直接在浏览器中打开https://webrtc.yourdomain.com。浏览器地址栏应该显示锁形标志点击可以查看证书详情确保证书有效且由Let‘s Encrypt签发。验证Nginx代理是否工作在服务器上使用curl测试Nginx是否将/socket.io/路径的请求正确转发到了Signalmaster。# 从服务器本地测试代理 curl -k https://localhost/socket.io/?EIO4transportpolling # 或者使用域名但需要解析 curl -k https://webrtc.yourdomain.com/socket.io/?EIO4transportpolling加上-k参数是暂时忽略证书验证因为我们向自己发请求。你应该看到和之前直接访问http://localhost:8080/...时类似的Socket.io握手响应。验证Signalmaster进程检查pm2或你的进程管理器确保signalmaster正在运行。pm2 list pm2 logs signalmaster --lines 50 # 查看最近日志日志中不应有频繁的错误连接信息。前端连接测试打开你的WebRTC应用页面HTTPS打开浏览器的开发者工具F12切换到“网络”Network标签页过滤“WS”或“WebSocket”。刷新页面你应该能看到一个到wss://webrtc.yourdomain.com/socket.io/...的WebSocket连接状态码应该是101Switching Protocols表示连接成功升级为WebSocket。信令交互测试打开两个不同的浏览器标签页或两台设备都访问你的应用页面。在一个页面发起“加入房间”或“呼叫”操作观察另一个页面的控制台和网络面板应该能看到Socket.io的信令消息如“join”“offer”“answer”“candidate”在安全地传输。7.2 常见问题与排查技巧实录即使按照步骤操作也可能会遇到一些问题。以下是我在部署过程中遇到的一些典型问题及解决方法问题1前端连接失败控制台报错WebSocket connection to ‘wss://...‘ failed或ERR_SSL_PROTOCOL_ERROR。排查思路检查证书确保证书路径正确且Nginx有读取权限。sudo nginx -t检查配置时也会验证证书路径。检查Nginx配置确认listen 443 ssl;指令存在且ssl_certificate和ssl_certificate_key路径正确。确认server_name与访问的域名完全一致。检查防火墙确认服务器的443端口对公网开放。sudo firewall-cmd --list-all或sudo ufw status。检查代理配置确认location /socket.io/块中的proxy_pass地址和端口与Signalmaster实际运行的地址端口一致。可以用netstat -tlnp | grep :8080查看端口监听情况。检查Signalmaster是否运行pm2 list或ps aux | grep node。问题2WebSocket连接可以建立但很快断开状态码101后变成200或0或者信令消息发不出去。排查思路检查Nginx超时设置这是最常见的原因。确保在location /socket.io/块中设置了足够长的proxy_read_timeout和proxy_send_timeout例如86400s。检查Signalmaster日志查看Signalmaster的PM2日志或控制台输出看是否有错误信息。可能是房间逻辑错误或客户端传入了非法数据。检查CORS如果前端控制台出现CORS错误检查Nginx配置或Signalmaster配置中的CORS设置。确保Access-Control-Allow-Origin头包含你的前端域名。检查Socket.io版本兼容性确保客户端前端使用的socket.io-client版本与服务器端Signalmaster使用的socket.io版本兼容。版本差异过大可能导致协议解析错误。尽量保持主版本号一致。问题3使用自签名证书进行本地测试时前端拒绝连接。解决方案前端浏览器对于本地开发可以直接访问https://localhost或https://127.0.0.1浏览器会显示不安全警告手动点击“高级”-“继续前往”即可。这不是生产环境的做法。更佳实践为本地开发环境也生成一个受信任的本地证书。可以使用mkcert工具它能创建被本地操作系统和浏览器信任的证书。# 安装mkcert (以Linux为例) # 请参考 https://github.com/FiloSottile/mkcert mkcert -install mkcert localhost 127.0.0.1 ::1 # 会生成 localhost2.pem 和 localhost2-key.pem # 在Nginx配置中使用这两个文件Node.js后端测试客户端如果有一个Node.js脚本需要连接WSS信令服务器做测试且服务器使用自签名证书需要在代码中设置rejectUnauthorized: false仅限测试。const socket require(socket.io-client)(https://your-test-server.com, { transports: [websocket], secure: true, rejectUnauthorized: false // 仅用于测试自签名证书 });问题4证书续期后Nginx配置没有自动更新。解决方案Certbot的续期钩子--deploy-hook可以解决。编辑Certbot的续期配置文件如/etc/letsencrypt/renewal/your-domain.com.conf确保其中有类似如下配置或者在续期命令后手动重载Nginx。# 手动测试续期并重载Nginx sudo certbot renew --force-renewal --deploy-hook systemctl reload nginx更标准的做法是使用Certbot的--post-hook或--deploy-hook参数在证书成功续期后自动执行重载命令。通常通过systemd timer或cron运行的certbot renew命令已经包含了这些钩子。8. 性能优化与安全加固部署完成后还可以从性能和安全性角度进行一些优化。8.1 Nginx性能优化调整Worker进程和连接数根据服务器CPU核心数在nginx.conf的events块中调整worker_connections在顶层调整worker_processes。启用Gzip压缩虽然WebSocket数据本身可能不压缩但你的前端静态资源JS CSS可以压缩。gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript;调整缓冲区大小对于高并发的WebSocket连接可以适当增加代理缓冲区。location /socket.io/ { ... proxy_buffers 8 32k; proxy_buffer_size 64k; ... }8.2 安全加固禁用不必要的HTTP方法在Nginx的server块中可以限制只允许GET POST OPTIONS。if ($request_method !~ ^(GET|POST|OPTIONS)$) { return 405; }隐藏Nginx版本号在http块或server块中添加server_tokens off;。使用安全的SSL协议和加密套件就像我们配置中使用的TLSv1.2 TLSv1.3和较安全的加密套件。可以使用在线工具如SSL Labs的SSL Test扫描你的域名获取安全配置建议。限制请求频率对于公开的信令服务器可以考虑对连接请求进行限速防止滥用。limit_req_zone $binary_remote_addr zonewslimit:10m rate10r/s; location /socket.io/ { limit_req zonewslimit burst20 nodelay; ... }Signalmaster配置安全确保生产环境配置中isDev设置为false。如果启用了Redis确保Redis服务本身有密码保护且只监听在本地。8.3 监控与日志Nginx访问日志与错误日志定期检查/var/log/nginx/access.log和error.log监控异常连接和错误。Signalmaster日志通过PM2日志或输出到文件监控信令交互情况便于调试。系统资源监控使用htopnload等工具监控服务器CPU、内存、网络流量确保在高并发下运行平稳。整个配置过程从申请证书到最终验证虽然步骤不少但每一步都有其明确的目的。采用Nginx反向代理的方案将SSL的复杂性交给了更擅长的Nginx让Signalmaster专注于信令逻辑架构清晰也便于后续扩展和维护。当你看到浏览器中小锁标志亮起并且两个标签页之间通过WSS成功建立音视频通话时这套部署的价值就完全体现出来了。
1. 项目概述最近在折腾一个基于WebRTC的实时音视频项目踩了不少坑尤其是信令服务器这块。项目里用到了signalmaster这个轻量级的信令服务器但在实际部署时发现一个关键问题现代浏览器对于WebRTC的安全要求越来越严格尤其是在非HTTPS环境下很多功能比如获取摄像头、麦克风权限会被直接禁止。这就意味着如果你想让你的WebRTC应用在公网上能被正常访问给信令服务器配置SSL证书、启用HTTPS/WSS连接几乎成了必选项。然而网上关于signalmaster的教程大多集中在基础使用对于如何给它“穿上”SSL证书这件安全外衣讲得要么语焉不详要么步骤零散。今天我就把自己从申请证书到最终让signalmaster跑在HTTPS下的完整过程以及中间遇到的各种“坑”和解决方案详细拆解一遍。无论你是刚接触WebRTC的新手还是正在为信令安全头疼的开发者这篇实战记录应该都能给你提供一条清晰的路径。2. 核心需求与方案选型2.1 为什么信令服务器必须上HTTPS很多人刚开始接触WebRTC时会觉得信令服务器只是用来交换一下SDP和Candidate用个简单的HTTP/WS服务跑在本地或者内网好像也没问题。但一旦你需要真刀真枪地部署到公网让用户通过浏览器访问情况就完全不同了。首先是浏览器的安全策略。以Chrome、Firefox为代表的现代浏览器明确要求获取用户媒体getUserMedia的页面必须运行在安全上下文Secure Context中。简单说就是你的网页必须通过HTTPS或localhost加载。如果你的信令服务器还是HTTP那么页面即使通过HTTPS加载但与信令服务器的WebSocket连接WS也是不安全的混合内容浏览器会阻止媒体设备的访问你的视频通话也就无从谈起。必须升级到WSSWebSocket Secure。其次是数据安全。信令过程中交换的SDP会话描述协议信息虽然本身是文本但其中可能包含候选地址Candidate等网络信息。在公网环境下明文传输存在被窃听或篡改的风险。启用HTTPS/WSS后整个信令通道都是加密的能有效防止中间人攻击。最后是生产环境的基本要求。任何面向公众的Web服务使用HTTPS已经是行业标准和用户信任的基础。搜索引擎如Google也会对HTTPS站点给予排名优待。所以给signalmaster配置SSL证书不是“锦上添花”而是“雪中送炭”是WebRTC应用能够正式上线运行的前提。2.2 SignalMaster与SSL证书部署的几种方案Signalmaster本身是一个基于Node.js和Socket.io的服务器。要让其支持HTTPS/WSS核心是为Node.js的HTTP/HTTPS服务器模块提供SSL证书。通常有以下几种部署方案Signalmaster内置HTTPS服务器直接服务这是最直接的方式。修改signalmaster的服务器启动代码使用Node.js的https模块创建服务器并加载你的证书和私钥。这种方式简单但通常需要你直接修改signalmaster的源码或配置。使用反向代理如Nginx这是更推荐、更灵活的生产环境方案。让Nginx监听443端口HTTPS处理SSL/TLS握手、证书验证等繁重工作然后将解密后的普通HTTP请求反向代理到后端运行在某个端口如8080的signalmasterHTTP服务。Signalmaster本身无需感知HTTPS只需处理HTTP即可。Nginx作为专业Web服务器在SSL性能优化、负载均衡、静态文件服务等方面有巨大优势。使用PM2等进程管理器结合方案1如果你选择方案1并且需要进程守护、日志管理、集群等功能可以配合PM2来管理你的signalmaster HTTPS进程。我为什么选择“Nginx反向代理”方案职责分离Nginx专精于高效处理网络I/O和SSLNode.jssignalmaster专注于业务逻辑信令交换。各司其职性能更优。配置灵活在Nginx中管理SSL证书、域名、重定向HTTP到HTTPS非常方便。未来如果需要添加多个WebRTC相关服务如TURN服务器前端、状态页也易于扩展。便于维护证书续期、更换等操作只在Nginx层面进行不影响后端信令服务器的运行。社区实践这是部署Node.js应用最普遍、最受认可的模式。因此本实战将围绕“Nginx反向代理 SignalMaster”这个架构展开。我们的目标是用户通过https://your-domain.com访问WebRTC应用页面页面通过wss://your-domain.com/socket.io/...与信令服务器安全通信。3. 实战准备环境与证书3.1 基础环境说明我使用的环境是阿里云的一台CentOS 7.x服务器。假设你已经具备以下条件一台拥有公网IP的云服务器Ubuntu/CentOS等均可步骤大同小异。一个已经解析到该服务器公网IP的域名例如webrtc.yourdomain.com。这是申请SSL证书所必需的。服务器上已安装Node.jsv12和npm。Signalmaster的运行依赖。服务器上已安装Nginx。基本的Linux命令行操作能力。如果你还没有安装Node.js和Nginx可以通过包管理器快速安装# CentOS/RHEL sudo yum install -y epel-release sudo yum install -y nodejs npm nginx # Ubuntu/Debian sudo apt update sudo apt install -y nodejs npm nginx安装后可以通过node -v,npm -v,nginx -v验证安装。3.2 获取SSL证书以Let‘s Encrypt为例SSL证书有付费的如DigiCert, GeoTrust和免费的如Let‘s Encrypt。对于个人项目、测试或中小型应用Let‘s Encrypt提供的免费、自动化的证书是完全够用的并且被广泛信任。我们将使用certbot工具来自动化获取和安装证书。这是EFF电子前沿基金会维护的官方客户端。安装Certbot和Nginx插件# CentOS 7 (需要先启用EPEL) sudo yum install -y epel-release sudo yum install -y certbot python2-certbot-nginx # Ubuntu/Debian sudo apt update sudo apt install -y certbot python3-certbot-nginx安装Nginx插件是为了让certbot能自动修改Nginx配置实现自动续期。获取并安装证书 执行以下命令certbot会自动检测Nginx的配置并引导你完成域名选择和验证。sudo certbot --nginx过程中你会被要求输入你的邮箱用于接收证书到期提醒和紧急通知。同意服务条款。选择你要为哪个域名申请证书它会列出Nginx配置中找到的所有server_name。是否将HTTP流量重定向到HTTPS强烈建议选择“2: Redirect”。如果一切顺利certbot会自动完成以下工作向Let‘s Encrypt申请证书。通过HTTP-01挑战验证你对域名的控制权它会临时在你的网站根目录下创建一个文件供CA访问验证。下载证书和私钥通常存放在/etc/letsencrypt/live/your-domain.com/目录下。自动修改你的Nginx站点配置文件添加SSL相关配置并设置HTTP到HTTPS的重定向。验证证书文件 申请成功后关键的文件是/etc/letsencrypt/live/your-domain.com/fullchain.pem证书链文件包含你的证书和中间CA证书。/etc/letsencrypt/live/your-domain.com/privkey.pem私钥文件。还有cert.pem和chain.pem但Nginx配置通常使用fullchain.pem重要提示/etc/letsencrypt/live/目录下的文件是符号链接指向/etc/letsencrypt/archive/your-domain.com/目录下的实际文件。在Nginx配置中请始终引用live目录下的路径因为续期后链接会自动更新。自动续期 Let‘s Encrypt证书有效期是90天。Certbot安装时会创建一个定时任务cron job或systemd timer来自动续期。你可以手动测试续期流程sudo certbot renew --dry-run如果测试成功就无需担心证书过期问题。实操心得证书申请避坑防火墙申请证书时确保服务器的80端口HTTP和443端口HTTPS在防火墙中是开放的因为Let‘s Encrypt的验证和后续服务都需要访问这些端口。# 如果使用firewalld (CentOS 7) sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps sudo firewall-cmd --reload # 如果使用ufw (Ubuntu) sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw reload域名解析务必确保你的域名已正确解析到服务器的公网IP并且生效可通过ping your-domain.com或nslookup your-domain.com检查。解析未生效会导致验证失败。Nginx配置在运行certbot --nginx前最好先有一个基本的Nginx配置监听80端口并且server_name设置正确。Certbot依赖这个配置来识别域名。4. SignalMaster的安装与基础配置4.1 获取与运行SignalmasterSignalmaster是AppRTC项目的一部分但我们可以单独使用它。最简单的方式是通过npm全局安装其独立版本或者克隆仓库。方法一使用npm推荐方便# 全局安装signalmaster sudo npm install -g signalmaster # 安装后可以直接通过命令启动一个基础的HTTP信令服务器 # signalmaster --port 8888 # 但我们需要配置它所以更常用的是使用自定义配置文件启动不过全局安装的版本可能不方便自定义。我更倾向于克隆源码这样可以灵活修改。方法二克隆源码# 创建一个项目目录 mkdir ~/webrtc-signal cd ~/webrtc-signal # 克隆signalmaster仓库注意原始的webrtc/apprtc仓库中的signalmaster可能不是最新独立版本 # 我们可以使用一个维护较好的fork或者直接使用socket.io的示例。这里以某个常见版本为例 git clone https://github.com/simplewebrtc/signalmaster.git cd signalmaster npm install克隆后目录下关键文件是server.js和config.json或config.json.example。4.2 理解Signalmaster的配置Signalmaster的核心配置通常通过一个JSON文件或环境变量进行。我们创建一个自定义的配置文件config/production.json假设项目结构支持config目录。{ isDev: false, server: { port: 8080, // Signalmaster监听的端口我们将通过Nginx代理到这个端口 host: 0.0.0.0, // 监听所有网络接口 secure: false // 关键因为我们用Nginx处理HTTPS所以这里设为falseSignalmaster自身以HTTP运行。 }, rooms: { maxClients: 0 // 0表示无限制 }, stunservers: [ {urls: stun:stun.l.google.com:19302} ], turnservers: [ // 如果你有自己的TURN服务器在这里配置 // { // urls: [turn:your-turn-server.com:3478], // username: username, // credential: password, // auth: secret // } ], redis: { // 如果你需要多进程/多服务器部署可以用Redis做适配器存储单机可忽略 // host: 127.0.0.1, // port: 6379 } }配置要点解析server.port: 这是Signalmaster内部服务监听的端口我们将在Nginx配置中把请求代理到这个端口。server.secure:必须设置为false。因为我们采用Nginx反向代理方案SSL终止SSL Termination发生在Nginx层。Nginx与Signalmaster之间的通信是在内网或本地回环地址上使用HTTP是安全且高效的。如果这里设为trueSignalmaster会尝试以HTTPS服务器启动需要你提供证书这就复杂了且没必要。host: “0.0.0.0”: 确保服务监听在所有网络接口上方便Nginx从本地连接。4.3 启动SignalmasterHTTP模式使用你的配置文件启动Signalmaster。假设你的配置文件在~/webrtc-signal/signalmaster/config/production.json。cd ~/webrtc-signal/signalmaster # 通过环境变量指定配置文件或者修改server.js硬编码加载你的配置 # 这里假设signalmaster支持CONFIG环境变量 CONFIG./config/production.json node server.js或者你可以直接修改server.js将加载配置的路径指向你的production.json。启动后你应该能看到类似以下的日志表明Signalmaster正在8080端口以HTTP模式运行[INFO] SignalMaster server running at http://0.0.0.0:8080此时你可以用curl在服务器上测试一下curl http://localhost:8080/socket.io/?EIO4transportpolling如果返回一串包含sid的JSON数据说明信令服务器基础功能正常。注意事项进程管理直接通过node server.js启动进程会在前台运行关闭终端就会停止。对于生产环境我们需要一个进程守护工具。推荐使用pm2。# 全局安装pm2 sudo npm install -g pm2 # 使用pm2启动signalmaster并设置为开机自启 cd ~/webrtc-signal/signalmaster pm2 start server.js --name signalmaster --interpreter node -- -c ./config/production.json # 或者通过 ecosystem.config.js 文件配置更灵活 pm2 save pm2 startup # 根据提示执行命令设置系统服务这样Signalmaster就会在后台稳定运行即使服务器重启也会自动启动。5. Nginx反向代理配置详解这是将HTTP的Signalmaster安全地暴露给HTTPS/WSS外网的关键步骤。5.1 基本的HTTPS代理配置Certbot在申请证书时可能已经为你修改了Nginx配置。我们需要在其基础上添加对Signalmaster WebSocket路径的反向代理。找到你的Nginx站点配置文件通常位于/etc/nginx/conf.d/your-domain.com.conf或/etc/nginx/sites-available/your-domain.comUbuntu。我们打开并编辑它。在原有的server块监听443端口内部我们需要添加一个特定的location块来处理信令服务器的WebSocket连接。Socket.io的默认路径通常是/socket.io/。server { listen 443 ssl http2; # 监听443启用SSL和HTTP/2 server_name webrtc.yourdomain.com; # 你的域名 # SSL证书配置这部分通常是certbot自动添加的 ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # 静态文件服务如果你的WebRTC前端页面也由此Nginx服务 root /var/www/webrtc-app; # 你的前端文件目录 index index.html; location / { try_files $uri $uri/ 404; } # 关键配置反向代理到Signalmaster的WebSocket连接 location /socket.io/ { proxy_pass http://127.0.0.1:8080; # 指向Signalmaster运行的地址和端口 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 86400s; # WebSocket连接可能保持很长时间需要设置较长的超时 proxy_send_timeout 86400s; } # 可能还需要代理其他API路径如果你的信令服务器有其他HTTP端点 # location /api/ { # proxy_pass http://127.0.0.1:8080; # proxy_set_header Host $host; # proxy_set_header X-Real-IP $remote_addr; # ... 其他代理头 # } }配置解析proxy_pass http://127.0.0.1:8080;: 将所有到达/socket.io/的请求转发到本机8080端口运行的Signalmaster。proxy_http_version 1.1;: 使用HTTP/1.1协议这是WebSocket升级所必需的。proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection “upgrade”;: 这两个头部是WebSocket代理的核心。它们告诉Nginx将客户端发起的HTTP连接“升级”为WebSocket协议并保持长连接。proxy_set_header Host $host;等将一些原始请求头信息传递给后端服务器这对于日志记录、IP识别等很有用。proxy_read_timeout 86400s;: WebSocket连接是持久连接可能维持数小时甚至数天。将代理的超时时间设置得非常长这里设为24小时避免Nginx因为长时间没有数据传输而主动断开连接。5.2 处理CORS跨域资源共享如果你的WebRTC前端页面HTML/JS与信令服务器通过Nginx代理后不在同一个域名/端口下浏览器会因同源策略阻止WebSocket连接。虽然我们通过Nginx代理后域名通常是相同的但如果你有特殊架构可能需要处理CORS。Signalmaster的Socket.io服务器端通常已经内置了CORS处理。但在Nginx层面也可以添加响应头来确保万无一失。可以在上面的location /socket.io/块中添加add_header Access-Control-Allow-Origin https://your-frontend-domain.com always; add_header Access-Control-Allow-Credentials true always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS always; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range always;如果前端和后端在同一域名下则不需要这些。5.3 配置测试与重载配置完成后务必检查Nginx配置文件的语法是否正确sudo nginx -t如果输出syntax is ok和test is successful就可以安全地重载Nginx使配置生效sudo nginx -s reload # 或者 systemctl reload nginx (systemd系统)6. 客户端前端配置调整现在服务器端的HTTPS和WSS已经就绪。你需要修改你的WebRTC前端JavaScript代码将连接信令服务器的地址从http://或ws://改为wss://。假设你之前使用类似socket.io-client库这样连接// 旧的、不安全的连接本地开发或HTTP环境 // const socket io(http://localhost:8080); // 或 const socket io(ws://your-server-ip:8080); // 新的、安全的连接生产HTTPS环境 const socket io(https://webrtc.yourdomain.com, { path: /socket.io/, // 如果Nginx配置的location是 /socket.io/ transports: [websocket, polling], // 优先WebSocket降级为轮询 secure: true, // 使用安全连接 rejectUnauthorized: false // 仅在开发或使用自签名证书时可能需要生产环境使用可信证书应设为true或省略 });关键参数第一个参数是服务器地址现在必须是https://开头的域名。path: 必须与Nginx配置中的location路径匹配这里是/socket.io/。secure: true: 明确指示使用安全连接。rejectUnauthorized: 如果使用的是Let‘s Encrypt等受信任CA颁发的证书浏览器和Node.js客户端都会自动验证不需要设置这个。如果你在Node.js后端环境中测试连接且使用自签名证书可能需要将其设为false来跳过证书验证但生产环境绝对不要这样用。前端部署将你的HTML、JS、CSS等前端文件放置到Nginx配置中root指令指定的目录例如/var/www/webrtc-app。确保通过https://webrtc.yourdomain.com能正常访问到你的首页。7. 完整链路测试与验证所有组件配置完成后我们需要进行端到端的测试确保HTTPS/WSS信令链路完全畅通。7.1 分步验证验证HTTPS站点访问直接在浏览器中打开https://webrtc.yourdomain.com。浏览器地址栏应该显示锁形标志点击可以查看证书详情确保证书有效且由Let‘s Encrypt签发。验证Nginx代理是否工作在服务器上使用curl测试Nginx是否将/socket.io/路径的请求正确转发到了Signalmaster。# 从服务器本地测试代理 curl -k https://localhost/socket.io/?EIO4transportpolling # 或者使用域名但需要解析 curl -k https://webrtc.yourdomain.com/socket.io/?EIO4transportpolling加上-k参数是暂时忽略证书验证因为我们向自己发请求。你应该看到和之前直接访问http://localhost:8080/...时类似的Socket.io握手响应。验证Signalmaster进程检查pm2或你的进程管理器确保signalmaster正在运行。pm2 list pm2 logs signalmaster --lines 50 # 查看最近日志日志中不应有频繁的错误连接信息。前端连接测试打开你的WebRTC应用页面HTTPS打开浏览器的开发者工具F12切换到“网络”Network标签页过滤“WS”或“WebSocket”。刷新页面你应该能看到一个到wss://webrtc.yourdomain.com/socket.io/...的WebSocket连接状态码应该是101Switching Protocols表示连接成功升级为WebSocket。信令交互测试打开两个不同的浏览器标签页或两台设备都访问你的应用页面。在一个页面发起“加入房间”或“呼叫”操作观察另一个页面的控制台和网络面板应该能看到Socket.io的信令消息如“join”“offer”“answer”“candidate”在安全地传输。7.2 常见问题与排查技巧实录即使按照步骤操作也可能会遇到一些问题。以下是我在部署过程中遇到的一些典型问题及解决方法问题1前端连接失败控制台报错WebSocket connection to ‘wss://...‘ failed或ERR_SSL_PROTOCOL_ERROR。排查思路检查证书确保证书路径正确且Nginx有读取权限。sudo nginx -t检查配置时也会验证证书路径。检查Nginx配置确认listen 443 ssl;指令存在且ssl_certificate和ssl_certificate_key路径正确。确认server_name与访问的域名完全一致。检查防火墙确认服务器的443端口对公网开放。sudo firewall-cmd --list-all或sudo ufw status。检查代理配置确认location /socket.io/块中的proxy_pass地址和端口与Signalmaster实际运行的地址端口一致。可以用netstat -tlnp | grep :8080查看端口监听情况。检查Signalmaster是否运行pm2 list或ps aux | grep node。问题2WebSocket连接可以建立但很快断开状态码101后变成200或0或者信令消息发不出去。排查思路检查Nginx超时设置这是最常见的原因。确保在location /socket.io/块中设置了足够长的proxy_read_timeout和proxy_send_timeout例如86400s。检查Signalmaster日志查看Signalmaster的PM2日志或控制台输出看是否有错误信息。可能是房间逻辑错误或客户端传入了非法数据。检查CORS如果前端控制台出现CORS错误检查Nginx配置或Signalmaster配置中的CORS设置。确保Access-Control-Allow-Origin头包含你的前端域名。检查Socket.io版本兼容性确保客户端前端使用的socket.io-client版本与服务器端Signalmaster使用的socket.io版本兼容。版本差异过大可能导致协议解析错误。尽量保持主版本号一致。问题3使用自签名证书进行本地测试时前端拒绝连接。解决方案前端浏览器对于本地开发可以直接访问https://localhost或https://127.0.0.1浏览器会显示不安全警告手动点击“高级”-“继续前往”即可。这不是生产环境的做法。更佳实践为本地开发环境也生成一个受信任的本地证书。可以使用mkcert工具它能创建被本地操作系统和浏览器信任的证书。# 安装mkcert (以Linux为例) # 请参考 https://github.com/FiloSottile/mkcert mkcert -install mkcert localhost 127.0.0.1 ::1 # 会生成 localhost2.pem 和 localhost2-key.pem # 在Nginx配置中使用这两个文件Node.js后端测试客户端如果有一个Node.js脚本需要连接WSS信令服务器做测试且服务器使用自签名证书需要在代码中设置rejectUnauthorized: false仅限测试。const socket require(socket.io-client)(https://your-test-server.com, { transports: [websocket], secure: true, rejectUnauthorized: false // 仅用于测试自签名证书 });问题4证书续期后Nginx配置没有自动更新。解决方案Certbot的续期钩子--deploy-hook可以解决。编辑Certbot的续期配置文件如/etc/letsencrypt/renewal/your-domain.com.conf确保其中有类似如下配置或者在续期命令后手动重载Nginx。# 手动测试续期并重载Nginx sudo certbot renew --force-renewal --deploy-hook systemctl reload nginx更标准的做法是使用Certbot的--post-hook或--deploy-hook参数在证书成功续期后自动执行重载命令。通常通过systemd timer或cron运行的certbot renew命令已经包含了这些钩子。8. 性能优化与安全加固部署完成后还可以从性能和安全性角度进行一些优化。8.1 Nginx性能优化调整Worker进程和连接数根据服务器CPU核心数在nginx.conf的events块中调整worker_connections在顶层调整worker_processes。启用Gzip压缩虽然WebSocket数据本身可能不压缩但你的前端静态资源JS CSS可以压缩。gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript;调整缓冲区大小对于高并发的WebSocket连接可以适当增加代理缓冲区。location /socket.io/ { ... proxy_buffers 8 32k; proxy_buffer_size 64k; ... }8.2 安全加固禁用不必要的HTTP方法在Nginx的server块中可以限制只允许GET POST OPTIONS。if ($request_method !~ ^(GET|POST|OPTIONS)$) { return 405; }隐藏Nginx版本号在http块或server块中添加server_tokens off;。使用安全的SSL协议和加密套件就像我们配置中使用的TLSv1.2 TLSv1.3和较安全的加密套件。可以使用在线工具如SSL Labs的SSL Test扫描你的域名获取安全配置建议。限制请求频率对于公开的信令服务器可以考虑对连接请求进行限速防止滥用。limit_req_zone $binary_remote_addr zonewslimit:10m rate10r/s; location /socket.io/ { limit_req zonewslimit burst20 nodelay; ... }Signalmaster配置安全确保生产环境配置中isDev设置为false。如果启用了Redis确保Redis服务本身有密码保护且只监听在本地。8.3 监控与日志Nginx访问日志与错误日志定期检查/var/log/nginx/access.log和error.log监控异常连接和错误。Signalmaster日志通过PM2日志或输出到文件监控信令交互情况便于调试。系统资源监控使用htopnload等工具监控服务器CPU、内存、网络流量确保在高并发下运行平稳。整个配置过程从申请证书到最终验证虽然步骤不少但每一步都有其明确的目的。采用Nginx反向代理的方案将SSL的复杂性交给了更擅长的Nginx让Signalmaster专注于信令逻辑架构清晰也便于后续扩展和维护。当你看到浏览器中小锁标志亮起并且两个标签页之间通过WSS成功建立音视频通话时这套部署的价值就完全体现出来了。
