NDI 端口与发现：排查缺失源和视频

NDI 源可能不在列表中、可见但无法连接，或已连接却没有可用画面或声音。请从看到的症状开始：

• 源缺失：检查发送端、接口和发现方法。
• 源已列出但无法连接：检查媒体传输、端口和路由。
• 已连接但没有画面或音频：检查接收媒体和解码器。

整个检查过程使用同一发送端和接收端。记录其源名称、NDI 版本、网络接口和每次测试的时间，以便比较结果。

NDI 源缺失时，先证明发现正常

确认发送端应用或设备正在运行且其 NDI 输出已启用。然后检查接收端是否查看预期接口，以及两个端点是否属于预期 NDI 组。若一个应用中缺失、却在 NDI 诊断工具中可见，问题可能是应用、运行时或配置问题，并非整个网络的发现故障。

默认情况下，NDI 使用 mDNS 实现零配置发现。它使用 IPv4 多播地址 224.0.0.251 和 UDP 端口 5353，发现范围仅限于一个物理或逻辑 LAN。在 Windows 上，公共网络配置文件可能阻止 NDI 所需的 mDNS 响应；在受管域网络中，管理员必须允许发现流量。请参阅官方 NDI mDNS 参考。

对于隔离、路由或云环境，应选择已有文档的发现设计，而非假定多播会穿越网络。手动主机条目可通过 TCP 5960 查询远程计算机，但它只能帮助接收端找到该计算机上的源，不能建立媒体连接或创造网络容量。

在发送端和接收端配置 Discovery Server

NDI Discovery Server 是集中式注册表，适用于不希望或无法使用 mDNS 的部署。其默认监听端口为 TCP 5959，服务可绑定到选定地址或配置其他端口。客户端必须使用部署指定的相同服务器地址和端口。

关键在于角色差异。配置了 Discovery Server 的发送端不会通过 mDNS 宣告；该发送端对配置为使用该服务器的查找器和接收端可见。查找器和接收端也可以使用 mDNS 发现未配置 Discovery Server 的本地计算机。应将其视为设计选择，而不是只在一台主机上打开后就忘记的开关。

NDI 5 为受支持客户端记录了以逗号分隔的 Discovery Server 地址。在服务器失效的情况下测试确切的发送端、接收端和 NDI 版本：较新的接收端监听器实现可能要求客户端逻辑检测服务器故障并重新连接。Discovery Server 概览及其配置参考是已安装版本的权威依据。

使用与 NDI 模式匹配的端口规则

下表按功能列出，并不表示可以在每台主机之间放行不受限制的端口范围。请按已部署的发送端和接收端所用方向、区域和连接数量应用规则。在制定最小权限规则前，确认已安装的 NDI 版本和选定接收模式。

当前 NDI 文档说明，4.6 及更高版本不再使用临时端口。任何防火墙变更都应结合完整的NDI 端口参考进行。

检查子网和网络接口

mDNS 有 LAN 边界；路由、多播中继和 VPN 行为不会把它变成通用的路由发现服务。源和接收端位于不同的受控网络时，请使用 Discovery Server 或参与产品已有文档的手动寻址方法。

在多网卡主机上，记录哪个接口负责发现、哪个接口承载媒体。管理适配器、Wi-Fi 连接或 VPN 可能让源从错误网络出现，或使回复经由接收端无法使用的路由离开。为媒体接口分配稳定地址，避免重复机器名称，并在活动前确定接口优先级。

源已列出，但没有画面或声音

源已列出仅表示接收端取得了源宣告或注册表条目。它不能证明所选传输能够打开、返回路径被允许，或接收端可以解码视频。检查活动源 URL 和端口、连接状态、接收模式、视频存在、音频存在和渲染输出。

当前 NDI Discovery 工具可显示已注册发送端、源地址/端口，以及包括连接状态、接收模式和视频或音频存在的接收端监测数据。用这些证据选择下一项检查。对端口 5959 的 TCP 探测只证明可到达 Discovery Server；不能证明 NDI 媒体会话。

检查 mDNS 是否到达此 Linux 接口

sudo tcpdump -ni <media-interface> udp port 5353

预期结果：该接口上发现活动时出现 mDNS 数据包。这些数据包确认此接口存在发现流量，并不确认可访问所选媒体端口。仅在获得生产网络所需授权时运行数据包捕获和防火墙诊断。

从 Windows 检查 Discovery Server 可达性

Test-NetConnection <discovery-server> -Port 5959

预期结果：成功连接到已配置服务器地址和端口的 TCP。它确认 TCP 监听器可达。请在 NDI 应用中检查注册、组成员资格和媒体传送。

在 Callaba 中检查已发现源

Callaba Cloud NDI为操作员提供配置发现、接口和适配器的位置，其已发现设备工作流程可显示当前清单。这有助于区分已保存设备条目和当前由选定实例发现的源。除了清单，也要在最终接收端检查所选源。

当源已是最新状态且媒体路径已验证后，再配置生产实际需要的 NDI 适配器或下游作业。在目标接收端单独检查其输出；发现结果只是该决策的输入，并非验收测试。

记录可工作的配置

1. 源缺失：证明发送端输出、组、所选 NIC 以及 mDNS 或 Discovery Server 配置。
2. 源已列出、无会话：记录源地址、传输模式和活动媒体规则；检查两个方向的端点防火墙和路由。
3. 有会话、无可用帧：检查接收模式、码率、视频/音频存在、解码兼容性和实际渲染输出。
4. 验收前：在生产接口上重复成功路径，并为运行手册记录配置、源名称和证据。

后续步骤

使用 Cloud NDI 配置预期的发现和接口路径；当工作流程需要清单检查时，阅读已发现设备参考。将生产验收测试放在最终接收端：连续画面、预期音频和选定的输出路径。