直播推流连不上？协议端口与防火墙放行清单（企业/医院内网适用）
在办公室网络里怎么试都正常，一到会场、医院专网、企业内网就推不出去——这类问题九成不是平台故障，而是网络没有放行。本文给出五类推流协议的端口对照表、可以直接转发给 IT 部门的放行清单、四步定位法，以及常见拦截设备的绕行方案。
为什么内网里推不出去
直播推流和日常上网看起来一样，都是"把数据发出去"，但网络设备对两者的态度完全不同。普通网页浏览走的是 80/443 端口，几乎在所有网络里都是放行的；而推流常用的 RTMP 协议默认走 1935 端口，这个端口在企业防火墙、医院专网、酒店会场网络里经常被默认阻断。
更麻烦的是，阻断的方式有两种，表现却很不一样。一种是直接拒绝，推流软件会立刻报连接失败，这种反而好办——你知道问题在网络；另一种是静默丢包，连接显示成功，但数据发不出去或者断断续续，表现为画面卡住、码率掉到零、或者推了几分钟自动断开，这种最容易被误判成平台问题。
所以在排查之前，先建立一个基本认识：推流能否成功，取决于从你的推流机到平台接入点之间这条路是否通、端口是否放行、上行带宽是否够。三者缺一不可，而前两个是网络管理员能解决的。
五类推流协议的端口对照
不同协议用不同端口、走不同传输方式，被拦的概率也完全不同。下面这张表是选型和排查的基础。
| 协议 | 默认端口 | 传输层 | 典型延迟 | 说明与适用场景 |
|---|---|---|---|---|
| RTMP | 1935 （或 80/443 变体） | TCP | 2–5 秒 | 推流端最主流协议，兼容性最好。缺点是 1935 端口在企业网络常被拦；多数平台同时提供 80/443 的 RTMP 变体作为备选。 |
| HTTP-FLV | 80 / 443 | TCP | 1–3 秒 | 走标准 HTTP 端口，几乎不会被拦，是内网环境的首选拉流协议。延迟比 HLS 低，适合对实时性有要求但不能开特殊端口的场景。 |
| HLS | 80 / 443 | TCP | 5–20 秒 | 兼容性最强，任何浏览器和手机都能播，穿透性最好。代价是延迟高，互动场景体验差。适合以观看为主、不强互动的大规模直播。 |
| WebRTC | 443（UDP 动态端口） | UDP 为主 | <1 秒 | 延迟最低，适合连麦、互动问答、远程会诊。难点是需要开放 UDP，且部分严格的企业网络会限制 UDP，需要 TURN 服务器中转兜底。 |
| SRT | 自定义 UDP （常用 10000+） | UDP | 1–3 秒 | 抗丢包能力强，在跨运营商、跨国、弱网环境下表现明显优于 RTMP。适合分会场回传主会场、海外连线这类链路质量不可控的场景。 |
这张表最实用的一句话总结是：如果网络严格，优先用走 80/443 的协议；如果链路质量差，优先用 SRT；如果要低延迟互动，才上 WebRTC。很多"推流连不上"的问题，其实换个协议就解决了，根本不用去求 IT 开端口。
可以直接转发给 IT 的放行清单
下面这份清单按"最小开放"原则整理，可以直接发给网络部门。注意这里列的是推流端需要放行的目标，不是观众端——观众端走的是 CDN 分发，通常只需要能正常上网即可。
| 用途 | 目标端口 | 方向 | 备注 |
|---|---|---|---|
| 推流（首选） | TCP 443 | 出站 | 优先使用平台提供的 RTMPS 或 443 端口推流地址，穿透性最好，一般无需额外申请。 |
| 推流（备选） | TCP 1935 | 出站 | 标准 RTMP。若 443 方案可用，不建议使用此端口。 |
| 拉流 / 观看 | TCP 80、443 | 出站 | HLS 与 HTTP-FLV 均走此端口，通常已默认放行。 |
| 低延迟互动 | UDP 动态端口段 | 出站 + 入站 | WebRTC 所需。企业网络常限制 UDP，需确认策略；无法开放时应启用 TURN 中转。 |
| SRT 回传 | UDP 自定义端口 | 出站 | 多会场回传时使用，需双方约定端口并在防火墙放行。 |
| 控制信令 / API | TCP 443 | 出站 | 平台控制台、场次创建、录制回调等接口调用。 |
除了端口，还有一类容易被忽略的拦截：域名白名单。部分单位的网络采用白名单机制，只放行已知域名。这种情况下需要在白名单中加入平台的推流域名、API 域名和 CDN 域名。这些域名要提前向平台索取，不要等到现场才发现。
另外提醒一点：不要只测"能不能打开网页"。很多酒店的认证网络允许浏览网页，但会限制长时间大流量的上行连接，表现为推流几分钟后自动断开。这种网络必须要求对方提供专线或独立的有线网络。
四步定位法：快速确定问题在哪一层
现场时间有限，不建议逐个试参数。按下面四步走，通常十分钟内能定位到问题层级。
第一步：用手机热点做对照
把推流机切到手机 4G/5G 热点，再推一次。如果热点能推、内网不能推，问题百分之百在网络环境，不用再查设备和软件。这一步是整篇里性价比最高的动作。
第二步：用命令行测端口通不通
不要只看"能不能上网"。在 Windows 上用 Test-NetConnection 推流域名 -Port 1935，在 macOS 或 Linux 上用 nc -vz 推流域名 1935，直接测目标端口是否可达。端口不通，就是防火墙或白名单的问题。
第三步：测上行带宽，而不是下载带宽
很多人测速只盯着下载速度，但推流吃的是上行。一场 1080P 直播需要稳定 4–6 Mbps 的上行，且要求持续稳定而非瞬时峰值。如果测出来上行只有 2 Mbps，或者波动很大，那即使端口全通也推不稳，需要先降配置或换网络。
第四步：换协议再试一次
如果 1935 不通，改用平台提供的 443 端口推流地址；如果 UDP 被限制，改用 RTMP 或 HTTP-FLV 而不是 WebRTC。换协议往往比开端口更快，尤其在现场临时遇到问题时。
五类常见网络环境的处理方式
| 网络环境 | 常见拦截方式 | 应对建议 |
|---|---|---|
| 企业办公内网 | 默认封锁非 80/443 端口；部分启用上网行为管理设备做流量识别 | 走 443 端口推流；如需 UDP 提前报备；重要场次申请临时会议网络或独立专线 |
| 医院专网 / 内网隔离区 | 内网与外网物理或逻辑隔离，手术室、示教室常在外网受限区 | 提前两周提交网络申请，明确推流域名与端口；无法开通时改用 4G/5G 直播背包或聚合路由器 |
| 酒店会议厅网络 | 网页认证、带宽共享、长时间大流量连接被切断 | 要求提供独享有线网络并做压力测试；自备 4G/5G 作为热备；不要依赖无线网络做主链路 |
| 校园 / 政务网络 | 实名认证、白名单域名、出口带宽紧张 | 提前提交域名白名单；避开网络高峰时段；确认出口上行余量 |
| 海外 / 跨境连线 | 跨境链路丢包高、抖动大 | 优先选 SRT 等抗丢包协议；或在国内设中转节点，海外先推到中转再转推平台 |
备用链路：开播前必须准备的第二条路
把所有希望压在单一网络上，是直播事故最常见的原因。任何一场不能出错的直播，都应该在开播前准备好备用链路，并且预先配置好切换动作。
- 主备双链路：有线网络为主，4G/5G 聚合设备为备。要求两条链路来自不同运营商，避免同时故障。
- 预置双推流配置：在推流软件里保存两套场景配置（主链路地址、备用链路地址），出问题时一键切换，不要现场手填地址。
- 降级档位：预先准备一套低码率配置（例如 720P / 1.5 Mbps）。网络退化和正常推流失败是两回事，降级能保住画面不中断。
- 断流自动重连：开启推流软件的自动重连，并把重试次数设高一些。短暂的抖动不应导致整场中断。
- 本地录制兜底：即使断流，本地也在录。至少保证事后有完整素材可以补发回放，这一点在学术会议和手术示教场景尤其重要。
需要强调的是：这些预案必须在彩排时真实演练一遍。只在文档里写了"有备用方案"而没演练过，等于没有。
开播前网络检查清单
| 序号 | 检查项 | 通过标准 |
|---|---|---|
| 1 | 目标推流端口可达性测试 | 命令行测试 TCP 连接成功 |
| 2 | 上行带宽实测 | 持续上行 ≥ 推流码率的 1.5 倍 |
| 3 | 连续推流压测 | 连续推 30 分钟无断流、无丢帧 |
| 4 | 备用链路可用性 | 切换后能在 30 秒内恢复推流 |
| 5 | 平台域名白名单 | 推流、API、CDN 域名均已放行 |
| 6 | 本地录制已开启 | 确认录制指示灯或状态正常 |
| 7 | 降级配置已保存 | 推流软件中存在低码率预设档 |
| 8 | 现场网络负责人联系方式 | 已确认，且开播期间可联系到 |
网络这摊事，可以不在你身上
上面这些检查项单看都不复杂，但每一场、每一个新场地都要重做一遍，而且必须在开播前做完。对于一年只办几次重要直播的团队，专门为此培养一名同事并不划算。
我们的企业直播服务把网络联调作为标准交付环节：会前与场地 IT 对接端口与带宽、出具放行清单、现场压测、准备主备双链路与降级档位，开播期间有人值守。你只需要告诉我们场地地址和时间。