NAT环境下装Jitsi最大的坑往往不在安装本身而在你第一次呼叫时才发现“只见画面、听不到声音”或者“完全是黑屏”。上一篇文章我们聊了基础架构这篇直接进入实战把Jitsi服务器架在一台内网机器上通过端口映射对外提供服务。我会把网络规划、安装细节、NAT专项配置、验证方法全部过一遍把那些文档里不写、但实际部署时必踩的坑提前指出来。1. 为什么NAT环境是Jitsi部署的“特殊战场”1.1 NAT的两种典型形态NAT网络地址转换在Jitsi部署场景里通常表现为两种形态。第一种是家用或小型办公网络你有一条宽带路由器分配一个私网IP给服务器比如192.168.1.100公网侧只有一个动态或静态的公网IP。外部用户访问时数据包先到达路由器由路由器做DNAT目的地址转换把公网IP的某个端口映射到内网服务器的对应端口。第二种是云主机环境很多云厂商的虚拟机默认是私有IP比如10.0.0.4然后通过VPC网关或负载均衡把公网IP映射到这台机器。这种场景下服务器上看到的网卡IP是私网地址但对外通信时源地址会被替换成公网IP。不管哪种形态核心问题是一样的Jitsi的媒体组件JVB需要告诉客户端“去哪里找你”。如果JVB不知道自己的公网地址它会把内网IP告诉客户端外部用户拿到一个192.168.x.x的地址自然连不上。1.2 先搞懂Jitsi的通信模型在动手装之前必须清楚Jitsi的通信链路是什么样的。简单说有三条通道第一条是HTTPS信令通道。用户浏览器访问会议网址Nginx把请求转发给Prosody和Jicofo完成房间创建、用户鉴权、参会者列表同步。这条通道走TCP 80/443相对简单。第二条是BOSH/WebSocket通道。浏览器和Prosody之间维持实时信令主要通过/http-bindBOSH或/xmpp-websocket路径在Nginx里做反代即可。第三条是媒体流通道。这是NAT环境下最麻烦的一条。浏览器需要把音视频流发送给JVBJVB再转发给房间里的其他人。WebRTC默认使用UDP端口是10000Jitsi默认的UDP端口范围是10000-20000但容器部署时通常只用10000一个端口传统deb包安装则默认整个范围。问题在于浏览器怎么知道JVB的公网地址这是ICE Interactive Connectivity Establishment协议干的事。JVB会收集自己的候选地址candidate告诉浏览器浏览器也收集自己的候选地址双方尝试找到一条可用的路径。在NAT环境下JVB收集到的往往是内网地址这时候就需要我们手动告诉它“你的公网地址是xxx”。可能我说得有点快打个比方你请朋友来家里做客你告诉对方“我家在幸福小区3栋201”这是内网地址但如果朋友住在外地他根本找不到这个小区。你需要告诉对方“你在火车站出站口等我我举着牌子接你”这个“火车站出站口”就是公网映射后的地址。Jitsi的NAT配置做的就是这件事——给JVB发一个“站牌”。2. 部署前的网络规划一次画清楚所有映射关系2.1 Jitsi服务端组件与端口对照先列一张端口清单这是整个部署的地基。我建议你把这表格打印出来或者放在手边后面配置防火墙和路由器映射时逐项对照组件默认端口协议用途是否需要映射到公网Nginx80、443TCPWeb页面、信令入口必须Prosody5280BOSH、5281WebSocket、5222C2STCPXMPP信令后端内部不直接对外Jicofo5347TCP会议调度与房间管理后端内部不直接对外JVB10000-20000默认UDP音视频媒体流必须JVB4443TCP媒体流TCP回退TURN-like强烈建议映射prosody组件端口5280、5281TCP内部组件通信不需要这里有个重点80和443端口对外映射是共识但UDP 10000端口经常被漏掉。很多人配置完端口映射后页面能打开、房间能创建但进去后画面黑屏、只有对方名字却听不到声音十有八九就是UDP 10000没有映射或者被防火墙拦了。2.2 公网IP不够用时的替代方案如果你只有一个公网IP家庭宽带、小型VPS都是这种完全够用。因为Jitsi只需要三组对外端口TCP 80/443、UDP 10000或更大范围、TCP 4443可选。这三组端口全部映射到同一台内网服务器的相同端口即可。如果你的环境比较特殊比如公网IP不在你手上或者无法映射UDP端口那就要考虑TURN服务器方案。Jitsi可以在部署时同时配置coturnTURN服务让客户端在UDP不通时走TCP 443通道穿透。这个方案我会在后面常见问题里展开网络通畅时优先走UDP体验最好。2.3 域名解析与证书规划我强烈建议你给Jitsi配一个真实域名而不是直接用IP访问。原因有三个一是浏览器安全限制。摄像头和麦克风权限在非HTTPS环境下会被浏览器拦截除非你手动设置站点例外用http://IP访问时经常出现“无法使用麦克风”的问题。二是Let’s Encrypt证书签发需要域名和80端口验证。虽然Jitsi安装时也支持自签名证书但浏览器会报警告体验非常差。三是后续维护方便。你换公网IP时只要改DNS解析就行不需要改一堆配置。域名这里建议用二级域名比如meet.yourdomain.com专门给会议用不占用主站的HTTPS泛解析。3. 完整安装步骤从裸机到跑起来的每一步3.1 系统准备与初始配置我推荐用Debian 11或Ubuntu 22.04 LTS这两个系统在Jitsi社区里测试最充分。系统装好后第一件事是固定IP地址不要让服务器通过DHCP随机获取地址否则端口映射会失效。然后做系统更新sudo apt update sudo apt upgrade -y如果你在云环境或区域网络内访问软件源很慢可以顺手配置一下apt镜像源这个看个人网络情况。更新完成、确认服务器IP稳定后就可以装Jitsi了。3.2 安装Jitsi主程序Jitsi官方仓库的地址在prosody.im仓库或者download.jitsi.org。安装前先添加仓库密钥wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add - sudo sh -c echo deb https://download.jitsi.org stable/ /etc/apt/sources.list.d/jitsi-stable.list sudo apt update如果你用的系统比较新比如Debian 12apt-key会提示deprecated但这不影响功能。也可以换成挂keyring的方式限制更严格原理一样。接着安装sudo apt install jitsi-meet安装过程中脚本会问你几个问题Hostname填写你规划的会议域名比如meet.yourdomain.com。注意这不是服务器的hostname而是对外服务的域名。SSL证书方式选“I want to use my existing certificate”或“Generate a new self-signed certificate”。建议先选自签名装完后再切到Let’s Encrypt这样如果流程卡住至少还能用IP或临时域名访问。安装完成后Jitsi的各组件都会自动以服务方式启动。这时候桌面会多出一个小机器人图标吗不会Jitsi的一切都是通过web界面操作服务器端没有图形界面。3.3 网络层配置防火墙与端口映射到这一步先暂停一下因为网络配置必须在进入具体应用配置前搞定不然后面测试的时候排错范围很大。首先在内网服务器上放行端口。如果你用ufwsudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow 10000/udp sudo ufw allow 4443/tcp # 如果要用TCP媒体回退 sudo ufw allow 5347/tcp # Jicofo与Prosody通信 sudo ufw allow 5280/tcp # BOSH信令 sudo ufw allow 5281/tcp # WebSocket sudo ufw enable注意服务端口5222Prosody客户端直连端口在浏览器场景下不对外但如果你要用桌面端或移动端客户端如Jitsi Meet移动应用直接连可能需要。实际测试下来移动端通过443即可完成信令一般不需要额外开5222。接着做路由器或云安全组的端口映射。这一步放在路由器管理页面操作家用路由器或者在云控制台的安全组/防火墙规则里配置。映射规则非常简单就是把公网IP的指定端口一对一转发到服务器内网IP的相同端口公网端口映射目标内网IP:端口协议80192.168.1.100:80TCP443192.168.1.100:443TCP10000192.168.1.100:10000UDP4443192.168.1.100:4443TCP有些家用路由器在NAT设置里叫“虚拟服务器”或“端口转发”云安全组则是在“入方向规则”里添加。需要特别确认一件事你的路由器是否支持UDP端口映射。绝大部分支持但个别廉价路由器的“端口转发”功能只支持TCP这会导致媒体流完全不通。可以用tcping工具或者建个测试UDP端口来判断不过最快的方法是直接看路由器的参数页有没有明确标注支持UDP。3.4 HTTPS证书从自签名切换到Let’s Encrypt装好jitsi-meet后如果你选择的是自签名证书浏览器访问时会有安全警告。我习惯装完立刻切换为Let’s Encrypt证书操作很简单sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh脚本会让你填一个邮箱地址用于证书过期通知然后自动配置证书自动续期。这里有一个NAT环境的特殊点Let’s Encrypt的HTTP验证要求访问的公网80端口能到达服务器。如果端口映射还没配好证书签发会失败。所以顺序一定是先做端口映射再签证书。如果你的网络环境不方便暴露80端口比如运营商封了80那就只能用DNS验证方式签证书这需要在DNS服务商后台手动添加TXT记录操作复杂一些但可行。这个场景我不展开多数情况下80端口都是通的。3.5 核心难点JVB的NAT地址配置终于到本文的重头戏了。Jitsi安装完成后JVB默认只知道自己的内网IP它向外部客户端通告的candidate地址也是内网IP。这时候外部用户加入会议WebRTC协商出来的媒体地址是192.168.x.x数据包发不进来表现就是只能看到对方的文字消息但画面和声音全黑。解决办法是告诉JVB它的公网地址。编辑JVB的配置文件sudo nano /etc/jitsi/videobridge/sip-communicator.properties在文件末尾追加org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS192.168.1.100 org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS202.103.xx.xx这里LOCAL_ADDRESS填Jitsi服务器在内网的实际IPPUBLIC_ADDRESS填你映射出去的公网IP。填写完成后重启videobridge服务sudo systemctl restart jitsi-videobridge2如果用的是较新版本的Jitsi比如2023年后的版本也可以直接在/etc/jitsi/videobridge/config里设置环境变量JVB_NAT_HARVESTER_LOCAL_ADDRESS192.168.1.100 JVB_NAT_HARVESTER_PUBLIC_ADDRESS202.103.xx.xx两种方式等价看你手上的版本是哪种机制。改完config文件后同样需要重启服务。这一步做完外部用户加入会议时JVB会把公网IP放在ICE候选里媒体流就能正确回传了。注意如果你的公网IP是动态的比如家用宽带重启后IP变了就需要配合DDNS服务并及时更新NAT_HARVESTER_PUBLIC_ADDRESS。有一个办法是写个脚本定期检查公网IP变化并重写配置、重启服务但这属于进阶玩法这里先提个醒。3.6 配置Prosody与Jicofo的鉴权Jitsi默认允许匿名登录也就是说任何知道网址的人都能进你的会议。如果你希望给参会者设置密码可以在Prosody里启用mod_auth_token认证或者更轻量地在会议房间层面设置密码。但作为内部协作工具我一般建议用前置密码保护或者不做全局限制把重点放在是否允许创建房间上。如果你想限制只有管理员能创建房间、普通用户只能加入别人创建的会议可以按下面的方式配置。编辑/etc/prosody/conf.d/meet.yourdomain.com.cfg.luaVirtualHost meet.yourdomain.com authentication internal_hashed modules_enabled { roster; presence; message; muc; ping; bosh; websocket; }然后通过prosodyctl创建管理员账号sudo prosodyctl register admin meet.yourdomain.com your_strong_password但“管理员”要生效还需要让Jicofo认识这个用户。为了方便Jitsi安装脚本已经生成了两个内部账号focus和jvb用于组件之间的认证。如果你不做管理员区分保持默认即可它不会影响正常使用。3.7 Nginx反代配置检查Jitsi安装包会自动生成Nginx站点配置路径一般是/etc/nginx/sites-available/meet.yourdomain.com.conf。核心的反代规则已经写好了你只需要确认两个关键location块存在location /http-bind { proxy_pass http://127.0.0.1:5280/http-bind; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; } location /xmpp-websocket { proxy_pass http://127.0.0.1:5281/xmpp-websocket; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $http_host; }改完后测试并重载Nginxsudo nginx -t sudo systemctl reload nginx这步如果配置有误最常见的症状是会议页面一直转圈加载但网络请求里能看到部分API返回500。4. 验证与自检模拟内外网交互场景4.1 服务器端自检配置全部完成后先别急着找真实用户测试。在服务器上做一次快速自检检查各服务状态systemctl status prosody systemctl status jicofo systemctl status jitsi-videobridge2检查关键端口在监听ss -tulpn | grep -E 80|443|5280|5281|5347|10000如果TCP端口都在监听但UDP 10000没看到很可能是JVB还没启动完毕或者UDP绑定失败。再等几秒重新看一次。4.2 内网客户端验证用你办公环境里的电脑访问https://meet.yourdomain.com新建一个会议。这一步主要验证页面能否正常加载Nginx和证书摄像头能否打开HTTPS 浏览器权限进入房间后能否看到自己WebRTC本地流能否邀请另一台内网机器加入并互通音视频内网ICE路径内网测试通过不代表外网就通因为内网访问时浏览器和JVB可能都处于同一个NAT后面即使地址通告有误也可能误打误撞通了。所以这一步只能说完成了50%。4.3 外网客户端验证关键实验用手机流量关闭WiFi访问会议网址或者找一位外部网络环境的朋友加入同一个房间。观察几个现象能否加入房间并看到已有参会者加入后画面是否正常显示、声音是否清晰用另一个外网设备加入三方能否互通如果外网加入成功但画面黑屏、只有音频或只有视频多半是媒体服务转发的某个地址有问题。这时候打开浏览器控制台看WebRTC的ICE候选chrome://webrtc-internals重点看candidate列表里有没有公网IP。如果你发现candidate里只有内网地址那就是NAT_HARVESTER_PUBLIC_ADDRESS配置没生效或者videobridge服务没重启成功。如果candidate里有公网IP但通信还是失败则要检查UDP 10000端口映射是否真的通。可以做个UDP连通性测试或者临时开个nc -u监听观察一下。5. NAT环境下高频问题排查实录5.1 问题速查表这一节我把实际部署中遇到的问题按优先级整理成表方便你遇到类似情况时快速对照症状可能原因排查与解决页面能打开但加入会议后一直转圈Nginx反代BOSH/WebSocket失败Prosody未启动检查sudo nginx -t查看systemctl status prosody确认5280/5281端口是否被Firefox/Chrome的拦截策略影响加入会议后只有自己画面别人看到你黑屏麦克风/摄像头权限被浏览器拦截改用HTTPS访问检查地址栏左边权限设置刷新页面能听到声音但看不到画面或相反WebRTC只协商了音频或视频编解码器常见于带宽受限临时降低分辨率检查JVB日志看是否编码器协商失败跨网络呼叫时黑屏/无声音JVB NAT地址未配置或配置错误查看sip-communicator.properties打开webrtc-internals看有没有公网IP的candidate确认UDP端口映射内部正常、外网无法访问页面80/443端口映射未配置或防火墙拦截在路由器/云安全组检查443端口转发telnet测试外网443连通性会议进行中偶发卡顿、花屏公网带宽不足或UDP丢包严重降低最大码率在配置中设置bitrate限制检查路由器NAT会话表是否溢出移动端无法连接部分NAT路由器对WebSocket处理兼容性差在Nginx中启用WebSocket的proxy_read_timeout和proxy_send_timeout为7200s证书过期导致页面打不开Lets Encrypt续期失败检查续期任务systemctl status certbot.timer手动运行sudo certbot renew5.2 排查JVB NAT配置的最有效方法如果外网呼叫仍然失败我最先做的一件事是看JVB日志sudo journalctl -u jitsi-videobridge2 -n 100 -f日志里会显示ICE协商过程查找addIceCandidate或ICE failed相关关键字。如果看到MISSED或FAILED字样优先怀疑NAT配置或UDP端口不通。另一个实用的测试方法是在服务器上临时用一个公网可达的UDP端口做测试。比如你在路由器上临时加一条规则公网20000/udp映射到内网服务器的10000/udp然后在服务器上监听10000端口用外部机器发UDP包进去。如果服务器能收到包说明路由器和防火墙链路是通的如果收不到问题就出在网络链路上与Jitsi配置无关。5.3 我踩过的几个深度坑第一忘记配置JVB的单端口模式。默认情况下JVB在UDP端口10000-20000范围内监听路由器如果要映射整个UDP范围会很麻烦很多家用路由器不支持范围映射只支持单端口转发。我的解决方法是修改JVB配置让它只监听10000一个端口sudo nano /etc/jitsi/videobridge/sip-communicator.properties添加org.jitsi.videobridge.REUSE_SSRCtrue org.jitsi.videobridge.udp.port10000 org.jitsi.videobridge.udp.port.range1有些版本用org.ice4j.ice.udp.port10000、org.ice4j.ice.udp.port.range1。这个改动做完UDP映射只要一条规则就搞定。这个配置在不同版本的Jitsi中键名略有差异如果你用的版本找不到这两个键去/etc/jitsi/videobridge/config里找JVB_UDP_PORT设成10000、JVB_UDP_PORT_RANGE设成1效果一样。第二没有处理NAT回环hairpin问题。内网用户通过域名访问时数据包到达路由器后需要被“折返”回内网服务器这个行为叫NAT hairpin或NAT loopback。很多家用路由器默认不支持表现为内网访问meet.yourdomain.com打不开但手机流量访问正常。解决方法是换用支持hairpin的路由器或者在内网DNS里把域名解析到内网IP所谓split DNS。第三TURN服务在NAT网络里很有必要。上面常规的UDP 10000映射做好了对大多数网络环境够用但如果你经常有用户处于很严格的网络环境如公司防火墙只放行443就需要部署coturn。安装和配置其实不是太难sudo apt install coturn然后在/etc/turnserver.conf里把listening-ip设成内网IPrelay-ip设成内网IPexternal-ip设成公网IP最后在/etc/jitsi/videobridge/sip-communicator.properties里配置TURN凭证再让Jicofo把TURN信息传给客户端。Jitsi官网文档有专门的TURN配置章节跟着做一般不会错。但有TURN也意味着所有业务流量会经过服务器会占用出站带宽所以小规模部署时可以先不加遇到特定网络问题再加。5.4 性能相关的一个容易被忽视的点大多数家庭宽带的上行带宽有限比如只有30-50Mbps而Jitsi视频通话的质量与带宽直接相关。一个30分钟的四人会议每人720p可能需要1.5-2Mbps的码率四个人同时发言服务器上的转发流量会有多路叠加出站带宽可能瞬间吃满。如果发现会议卡顿除了调整客户端的config.js里constraints视频最大码率还可以在服务端Jicofo配置里限制单路视频码率。常见做法是编辑/etc/jitsi/jicofo/sip-communicator.properties加上org.jitsi.jicofo.MAX_BITRATE_720P1200 org.jitsi.jicofo.MAX_BITRATE_1080P2500具体数值根据你的带宽和会议规模来调。这个小改动在NAT环境下尤其重要因为很多NAT路由器对连接数限制较严带宽占用过高会导致NAT表溢出、连接被重置表现就是会议中途全部掉线。6. 部署完成后的收尾建议整个NAT环境下的Jitsi部署流程最核心的其实就三件事端口映射放行、JVB的公网地址通告、证书与反代配置。只要这三件事做对部署就成功了七成其余都是锦上添花。我个人在实际操作中体会最深的一点是排障时一定要分层。页面打不开先查80/443页面能开但信令不通就查Nginx反代和Prosody信令通了但媒体不行就查UDP端口和JVB候选地址。不要一上来就怀疑Jitsi软件有问题大多数问题都出在网络层。还有一个建议装好之后第一时间用手机流量从外网做一次完整测试因为内网测试和真实NAT穿透场景差别很大。这个测试成本很低却能提前发现百分之八九十的部署问题。如果你接下来想在团队里正式启用这套系统建议顺手把备份脚本加上——Prosody的数据库/var/lib/prosody和配置文件目录/etc/jitsi、/etc/prosody是必须备份的视频文件本身不落盘所以备份压力不大。后面如果有时间我再写一篇关于Jitsi高可用和容器化部署的实践把“多房间并发”和“单机性能瓶颈”这两块内容补上。