试用我们的虚拟代理 - 它可以帮助你快速识别和修复常见的 Active Directory 复制问题。

本文旨在帮助排查 TCP/IP 通信问题。

ping 命令可用于测试基本连接。 但是，不应依赖它来证明整体连接性。 Telnet 和 PsPing 更有用，原因如下：

捕获详细说明受影响区域路径中的设备的网络关系图。 具体而言，请注意以下设备：

此关系图可帮助你可视化和确定查找问题原因的位置。

网络跟踪可用于了解问题发生时网络级别发生的情况。

尝试 ping 计算机的本地 IP 地址。

如果节点无法 ping 其本地 IP，则本地堆栈不起作用。 请注意显示的任何错误消息。

如果收到 “常规失败” 错误，则表示没有用于处理请求的有效接口。 此问题可能是由硬件问题或堆栈问题引起的。

检查系统托盘中的 “网络连接 ”图标上是否显示红色“X”字符或黄色感叹号。 红色 X 表示 Windows 未检测到网络连接。 黄色感叹号指示 NSCI (网络连接状态指示器) 探测检查失败。

若要排查此问题，请验证网络适配器是否报告了连接。 确保网络适配器已接通电源，并且节点连接的交换机端口未处于错误状态。 可以更改电缆、交换机端口和网络适配器，以缩小出现此问题的位置。 但是，问题最终出在 OS 之外。 若要进一步调查，请联系硬件供应商。

网络驱动程序和 Windows 之间也可能出现问题。 此问题通常是由于堆栈中的损坏。 使用以下故障排除步骤：

确保节点上的最新位 (TCP/IP、NDIS、AFD、Winsock 等) 。

通过运行以下命令重置 IP 和 Winsock。 备份所有网络配置。

重启节点。

重启后还原网络设置。 仅当接口名称未更改或脚本更新为使用新名称时，此操作才有效。

根据需要卸载或重新安装网络适配器驱动程序。

检查并删除第三方筛选器驱动程序 (，例如防病毒) 。

尝试使用网络在安全模式下启动计算机。 如果网络安全模式有效，请通过禁用 MSConfig 中的所有第三方应用和服务来运行“干净启动”过程，然后逐个重新启用它们，直到问题再次出现。 然后，可以联系供应商获取支持。

如果 NSCI 探测失败检查 (黄色感叹号) ，则不一定表示存在连接问题。 请确保正常通信正在正常进行。

如果节点可以 ping 或 telnet 连接到同一子网或网段上的节点，这将确认外部连接正常工作。 仍需要进一步测试才能了解是否存在基本连接问题。

如果节点无法 ping/telnet 到同一子网/网段上的节点。 请注意显示的任何错误消息。

目标主机无法访问 错误意味着节点发送的 ARP 请求未收到响应。

从要测试的节点中收集双面跟踪。 确保源节点发送的 ARP 请求到达目标节点，并且目标节点相应地答复。 此回复应显示在源跟踪中。 如果此过程失败，则问题可能是配置错误或其他影响基础结构的问题。

可能的原因可能是：

“请求超时”错误意味着 ARP 请求收到响应，但节点发送的 ICMP 回显请求未获得 ICMP 回显响应。 仅此一项并不表示存在问题。 节点上的网络或防火墙软件可能会阻止 ICMP 流量。 关闭 Windows) (防火墙配置文件，或者通过防火墙供应商支持的 ICMP 测试方法禁用这些配置文件可能会很有帮助。

当节点可以 ping 其默认网关时，可以从源节点 (外部连接) 等外部连接。 仍需要进一步的测试来了解是否存在基本连接问题。 如果节点无法 ping 或 Telnet 连接到其默认网关，这意味着 ICMP 回复在路由器上处于禁用状态。

如果源节点可以 ping、Telnet 或 PsPing 到目标子网上的其他节点，则基础结构内的基本连接和路由正常工作。 此结果指向影响特定目标节点的问题。

尝试将 Telnet 或 PsPing 连接到应用程序正在侦听的特定端口 (例如 TCP 端口 445 for SMB) 。 如果连接成功，则可以确认基本的应用程序级连接。 在这种情况下，必须联系应用程序供应商，以帮助调查应用程序不连接的原因。

注意

例如，如果问题在于无法连接到共享，则应用程序供应商可能是 Microsoft。 在这些情况下，采用双面 netsh netconnection 方案跟踪来收集其他信息并帮助你验证网络堆栈中是否存在问题会很有用。

如果与特定端口的连接不成功：

如果节点无法 ping、Telnet 或 PsPing 到目标子网上的其他节点，则问题可能与基础结构相关。 同样，ICMP 可能会在环境中被阻止。 因此，请使用 Telnet 或 PsPing 连接到已知侦听端口来验证连接性。 此时，需要一个双面网络跟踪来显示网络上发生数据包丢失的位置。 在尝试连接测试之前，请确保这两个跟踪都在运行，以便捕获问题。

出现此问题的原因是，数据在 TCP 和 UDP 队列中被阻止，或者存在网络或用户级软件延迟问题。

若要解决此问题，请使用 netstat -a 命令显示本地计算机上的 TCP 和 UDP 端口上所有活动的状态。 在发送和接收队列中具有 0 (0) 个字节时，会建立良好的 TCP 连接状态。 如果数据在任一队列中被阻止，或者状态不规则，则连接可能存在错误。 否则，可能会遇到网络或用户级软件延迟。

出现此问题是因为按顺序分析 Lmhosts 文件以查找没有 #PRE 选项的条目。

若要解决此问题，请将常用条目放在文件顶部附近，将 #PRE 条目放在底部附近。 如果将条目添加到大型 Lmhosts 文件的末尾，请使用 #PRE 选项将 Lmhosts 中的条目标记为预加载的条目。 然后，运行 nbtstat -R 命令以立即更新本地名称缓存。

如果使用 命令，如果特定计算机名称的名称解析失败， net use 则返回系统错误 53。

如果计算机位于本地子网上，请验证名称拼写是否正确，以及目标计算机是否也在运行 TCP/IP。 如果计算机不在本地子网上，请确保其名称和 IP 地址映射在 Lmhosts 文件或 WINS 数据库中可用。 如果所有 TCP/IP 元素似乎都安装正确，请将 ping 命令与远程计算机一起使用，验证其 TCP/IP 软件是否正常工作。

出现此问题的原因是 NetBIOS 名称解析未解析名称或正在解决错误的 IP 地址。

若要解决此问题，请在服务器上使用 nbtstat -n 命令来确定在网络上注册的服务器的名称。 要连接到的计算机的计算机名称应位于显示的列表上。 如果未列出该名称，请尝试显示 nbtstat的其他唯一计算机名称之一。 如果远程计算机使用的名称与命令显示 nbtstat -n 的名称相同，请确保远程计算机在 WINS 服务器或其 Lmhosts 文件中具有服务器名称条目。

出现此问题的原因是默认网关的 IP 地址与 IP 地址不在同一个 IP 网络 ID 上。

若要解决此问题，请通过将默认网关的 IP 地址与计算机任何网络适配器的网络 ID 进行比较，确定默认网关是否位于计算机网络适配器所在的同一逻辑网络上。

例如，计算机具有一个网络适配器，该适配器配置的 IP 地址为 192.168.0.33，子网掩码为 255.255.0.0。 这要求默认网关的格式为“192.168”。.“，因为 IP 接口的网络 ID 部分是 192.168.0.0。

在联系 Microsoft 支持人员之前，可以收集有关你的问题的信息。

注意

如果当前 PowerShell 执行策略不允许运行 TSS，请执行下列操作：

在所有节点上下载 TSS 并将其解压缩到 C：\tss 文件夹中。

从提升的 PowerShell 命令提示符打开 C：\tss 文件夹。

使用以下 cmdlet 在源和目标服务器上启动跟踪：

如果跟踪首次在源或目标服务器上运行，请接受 EULA。

允许录制 (PSR 或视频) 。

在输入 Y 之前重现问题。

注意

如果在客户端和服务器上收集日志，请在两个节点上等待此消息，然后再重现问题。

在重现问题后，输入 Y 以完成日志收集。

跟踪将存储在 C：\MS_DATA 文件夹中的 zip 文件中，该文件可上传到工作区进行分析。