做了这么多年网络运维和开发调试，我始终觉得工具箱里不能没有 netcat。很多时候排查不通、验证服务、临时传文件，它就是最快的那把刀。今天我把这些年用 netcat 做网络测试的经验整理出来，从最基础的监听和连接讲起，到端口扫描、数据传输、反向交互，再到各种让人头疼的坑，尽量一次性讲透。这篇文章适合刚接触网络工具的新人，也适合已经会几条命令但想系统梳理一下的同行。
1. netcat 是什么，为什么被叫做网络瑞士军刀
1.1 它本质上就是一个双向管道
netcat 的官方描述特别简单：通过 TCP 或 UDP 协议，从网络的一端读写数据。它不关心你传的是什么，它只负责把数据从一端搬到另一端，就像一根双向水管。
想象一下：你在一台机器上执行nc -l 12345，它就开始监听 12345 端口；在另一台机器上执行nc 192.168.1.10 12345，它就去连接这个端口。连接一旦建立，两边就会进入一个半双工或者全双工的数据转发状态——你在键盘上敲什么，对方就能在屏幕上看到什么，反过来也是。这跟聊天软件的原理本质上是相同的，只不过 netcat 没有界面、没有加密、没有协议约束，它把最原始的通信能力交给你。
也正因为它什么协议都不实现，你反而可以用它模拟各种客户端和服务端。比如你想确认一台 Web 服务器 80 端口通不通，可以手写一个 HTTP 请求丢进去看响应。这种"裸"的能力，让 netcat 成为了网络测试中最通用的一块砖。
1.2 不同系统的安装方式
绝大多数 Linux 发行版都自带或者可以通过包管理器安装 netcat。最需要注意的一点是：不同发行版的 netcat 实现并不一样，常用的是 OpenBSD 版本和 GNU 版本。
在 Debian 和 Ubuntu 上，命令是：
apt install netcat-openbsd在 CentOS 和 RHEL 上，默认安装的是 nmap-ncat（也就是 Nmap 项目用 C 语言重写的版本），安装命令：
yum install nmap-ncatmacOS 自带的是 Bonnie 版本的 netcat，不过参数和 OpenBSD 版本基本兼容。Windows 用户现在可以直接用 PowerShell 的Test-NetConnection，但如果你更习惯 netcat 的用法，也可以下载 Nmap 套件里的 ncat.exe，老牌的 linux 发行版里还能找到nc.exe的经典版本。
我个人的建议是：服务器上优先安装 OpenBSD 版本，因为它的参数更稳定，行为更符合直觉。很多人在 CentOS 上用 ncat 时会遇到-p参数行为不一致的坑，后面我会专门讲。
2. 基础实战：从监听和连接开始
2.1 监听模式：把机器变成一台临时服务端
netcat 最基础的应用场景，就是在一台机器上监听某个端口。命令非常简单：
nc -l 12345-l是 listen（监听）的缩写，后面的 12345 是端口号。执行之后终端会停在原地，没有任何提示，这在第一次使用时会让人心里没底——其实它就是在等一个连接进来。
这里要说一个比较老的版本差异：在 GNU netcat 和早期的 ncat 里，指定监听端口必须带-p参数，例如nc -l -p 12345；而 OpenBSD 版本允许直接nc -l 12345。为了兼容，我写脚本时通常会用nc -l -p 12345这种老写法，或者根据发行版写判断条件。在 Ubuntu 的 netcat-openbsd 里，nc -l -p 12345其实也是可以用的。
监听端口时还有一个容易被忽略的点：默认情况下，netcat 只监听一个 TCP 连接请求，也就是说当第一个客户端连进来，并且连接关闭之后，进程就结束了。如果你想持续接受多个连接，需要加-k参数才能保持监听状态。很多新手想用 netcat 做一个简单的数据接收服务，却发现连接断了进程也没了，就是因为少了-k。
2.2 连接模式：去访问别人的端口
连接模式更像是一个临时客户端：
nc 192.168.1.10 80这条命令的意思是：尝试 TCP 连接 192.168.1.10 的 80 端口。如果连接成功，终端就进入双方交互状态；如果失败，会直接报错退出，比如出现Connection refused。
我在测试网络连通性时，习惯先用-v参数拿到更明确的反馈。没有-v的话，连接成功时屏幕上什么都没有，这对人的判断很不友好。
nc -v 192.168.1.10 80执行成功会显示类似Connection to 192.168.1.10 80 port [tcp/http] succeeded!的信息，一眼就能看出连没连上。
2.3 一个最简单的连通性演示
为了更直观地理解这两个模式，我经常做这样一个演示：
先在机器 A 上执行：
nc -l 12345然后在机器 B 上执行：
nc 192.168.1.100 12345这时候在任意一边输入字符，另一边就会显示出来。不过终端默认是"一行一送"的模式，按回车才会把数据发过去。如果想实现类似聊天室那种逐字符实时显示，可以用-u切换 UDP，或者配合stty raw -echo调整终端模式，但日常测试中按行发送已经完全够用了。
这个简单的"聊天"演示可以把 netcat 的工作模式解释得很清楚：它不做身份认证、不做加密、不需要配置，只要你指定一个 IP 和端口，网络连接就建立起来了。
3. 端口连通性测试：高频使用场景
3.1 TCP 端口测试的标配参数组合
做网络排查时，最常遇到的问题就是"这个端口到底通不通"。用 telnet 可以测 TCP 端口，但在很多系统上 telnet 客户端不一定装了，而且 telnet 在连接建立后还会尝试进行协议协商，反而干扰判断。netcat 处理这个场景更干净。
我的标配命令是：
nc -vz -w 3 192.168.1.10 22拆开来看：
-v：打印详细信息，连接成功或失败都要有反馈-z：只扫描端口，不发送任何数据，相当于只探测端口开着没-w 3：超时时间设置为 3 秒。如果不加超时，遇到防火墙丢弃数据包的情况（而非端口拒绝），netcat 会一直卡在那里不动
-z这个参数非常实用。它把 netcat 变成了一个纯粹的探针：TCP 三次握手完成就立即关闭连接，不发送任何应用层数据。这样既不会触发目标服务的协议解析，也不会因为服务端等待客户端发送数据而挂起。
3.2 UDP 端口测试是个大坑
UDP 跟 TCP 完全不同，很多人在 UDP 端口测试上栽过跟头。UDP 没有握手过程，你发一个数据包过去，服务端如果端口没监听，理论上应该回一个 ICMP 端口不可达消息，但现实里很多网络设备或防火墙会直接吞掉这个 ICMP，导致 netcat 一直等不到反馈。
我测试 UDP 端口时会这样处理：
nc -u -vz -w 3 192.168.1.10 53这条命令的结果是一个概率问题：如果连通，可能显示成功；如果没连通，可能没有任何输出，也可能显示Connection refused。所以在生产环境里，我基本不怎么依赖nc -u -z的反馈结果。
更好的做法是直接发送真实的应用层数据。比如测试 UDP 53 端口（DNS），就手动发一个 DNS 查询报文过去；测试 UDP 123 端口（NTP），就发一个 NTP 请求。只要能收到任何数据回包，就说明目标 UDP 端口确实有服务在监听。这个思路同样适用于验证其他 UDP 服务。
3.3 用 netcat 做简单的端口扫描
端口扫描只是 netcat 的附加功能，用它快速探测某个 IP 上开放了哪些 TCP 端口，排查问题够用：
nc -vz -w 1 192.168.1.10 20-80这条命令会扫描目标 20 到 80 端口区间。-w 1的作用是每个端口最多等 1 秒，避免在过滤策略下等太久。扫描结果会逐个打印出来，open 或 refused 一目了然。
但要强调一点：netcat 的扫描效率很低，因为它是逐个端口串行连接的，扫一段范围还可以，扫全端口（0-65535）会非常慢。专业端口扫描还是交给 Nmap，它做了并发和探测包优化，速度不是一个量级。netcat 的优势在于：系统默认就带、不需要装额外工具、命令简单到任何一台机器上都能立刻执行。
3.4 进阶思路：扫描一批服务器
如果你管理着一批服务器，想快速确认某端口在所有机器上的开放情况，可以写个一层循环脚本：
for ip in 192.168.1.{1..20}; do if nc -vz -w 2 $ip 22 >/dev/null 2>&1; then echo "$ip:22 open" else echo "$ip:22 closed" fi done这里把输出重定向到了/dev/null，脚本里只需要看退出码。netcat 的退出码 0 表示连接成功，非 0 表示失败。这个特性在脚本化运维中非常有用，不要只盯着屏幕输出。
4. 数据转发与文件传输
4.1 裸传文件：不加密但足够快
netcat 传文件也是经典场景。A 机器上有一个安装包，要传到同一内网段的 B 机器上，最省事的临时做法就是：
在接收方机器 B 上：
nc -l 9999 > package.tar.gz在发送方机器 A 上：
nc 192.168.1.101 9999 < package.tar.gz这个思路其实跟"管道重定向"完全一样：把文件内容喂给 netcat，它在网络上原封不动地搬运，接收方再把数据流落盘。整个过程没有端到端加密、没有断点续传、也没有校验机制，所以建议只在内网环境使用，传完后最好对比一下两侧文件的校验值。
关于传输结束的问题，这里有一个细节值得注意。在发送方向上，当文件读完、发送方 netcat 进程退出时，连接会关闭，正常情况下接收方的 netcat 也会跟着退出。但有些情况下接收方会一直挂着不退出，比如网络缓冲还没排空。这时候可以用-q参数，让发送方在 EOF 后再等待指定秒数然后关闭连接：
nc -q 1 192.168.1.101 9999 < package.tar.gz4.2 目录传输和镜像备份的土办法
传输整个目录可以先用 tar 打包，再配合 nc 推出去。发送方：
tar -czf - /data/backup | nc 192.168.1.101 9999接收方：
nc -l 9999 | tar -xzf -这里-代表标准输入输出，tar 在发送端把目录实时打包成流，接收端拿到流实时解包。这种管道链路的模式在临时迁移小规模数据时很实用，比搭一个 HTTP 或者 FTP 服务省事得多。
但要提醒一点：如果数据量很大（几十 GB 以上），或者网络质量不稳定，这种裸流传输模式没有断点续传，中断一次就要重来。正经的大文件迁移建议用 rsync over SSH，支持差量同步和断点续传。netcat 适合的是临时应急、一次性快速搬运。
4.3 用 netcat 充当 HTTP 客户端做接口验证
netcat 还能模拟 HTTP 请求，用来验证一个服务是否正常响应。比如测试某台机器的 Web 服务：
printf 'HEAD / HTTP/1.1\r\nHost: 192.168.1.10\r\nConnection: close\r\n\r\n' | nc 192.168.1.10 80如果 HTTP 服务正常，你会看到像HTTP/1.1 200 OK这样的响应头。这个方法比浏览器验证更底层，因为你可以完全控制请求内容，排查负载均衡、虚拟主机转发之类的问题时特别有用。
同样思路也适用于 Redis、MySQL 等有明文协议的中间件。比如连 Redis 后输入PING，如果服务器返回PONG，就说明服务在正常运行。这种验证方法不需要安装任何客户端工具，非常实用。
5. 进阶玩法：跟系统命令配合实现更强能力
5.1 远程反向管理：一条命令建立可交互通道
netcat 的经典进阶用法就是在一个端口"挂"一个 Shell，让另一端远程执行命令。这个能力在管理几十台内网服务器时非常方便。
比如我想让另一台机器能访问本机 Shell：
nc -l 12345 -e /bin/bash然后从另一台机器连过来：
nc 192.168.1.100 12345这样连接建立后，对方就能执行命令了。注意-e参数在很多 OpenBSD 版本的 netcat 里是被禁用的（出于安全考虑），但 ncat 和 GNU 版本支持。如果你用的 netcat 不支持-e，可以靠管道方式模拟：
mkfifo /tmp/fifo cat /tmp/fifo | /bin/bash -i 2>&1 | nc -l 12345 > /tmp/fifo这是利用命名管道做双向转发，实现的效果跟-e类似，不过稳定性略差，中断后需要清理管道和进程。
这里必须说明：-e这个能力没有加密和认证，一旦端口暴露给不可信网络，任何人都能连接执行命令。我只建议在内网管理网络段使用，并且用完后立刻关闭。生产环境更稳妥的选择是 SSH 或者加一层加密隧道，netcat 适合的是应急场景。
5.2 简易广播：给多台机器发消息
内网机器上想让一批机器都看到一条提示消息，可以使用 UDP 广播或者遍历 IP 段的方式。比如给子网内的每台机器发一行通知：
for ip in 192.168.1.{1..254}; do echo "即将进行网络维护，请保存工作" | nc -u -w 1 $ip 12345 & done; wait接收方机器上则可以通过监听端口看到这条消息：
nc -u -l 12345虽然这不是严谨的广播协议实现，但用来做一次性的内网通知比四处敲消息高效得多。
5.3 端口转发：利用 nc 做简单桥接
有时候我们需要在本机做一个端口转发，把流量导到另一台机器上。虽然生产环境应该有专业的负载均衡或网关，但临时调试时用 nc 的管道方式也能完成：
mkfifo /tmp/pipe nc -l 8080 < /tmp/pipe | nc 192.168.1.50 80 > /tmp/pipe这段命令把本机 8080 端口的输入流通过管道导给后端机器的 80 端口，再把后端返回的数据通过管道送回给客户端。注意这里同样用到了命名管道解决双向数据流动问题。这种方式效率不高，但作为临时跳板够用了。实际上我很少只用一层 nc 做转发，因为调试复杂流量时容易丢包，这种情况我更喜欢用 socat 配合 openssl，支持更完整的双向转发。
5.4 探测本机外部 IP 的思路
有时候你处在一个 NAT 后面，想知道自己的出口 IP 是什么。虽然标准做法是访问外部服务获取，但如果内网有一台已知的服务器，也可以借助 netcat 做简单探测。比如在服务器上监听端口，客户端连过去并发送一段自定义文本，服务器端就能看到发送方的 IP 和端口。这在排查网络连接来源时比较有用。
nc -l 5555客户端连接：
echo "hello" | nc 服务器IP 5555服务器端屏幕显示的连接来源信息里就包含客户端的 IP 和端口。这是个小技巧，但特别实用。
6. 常见问题与排查技巧实录
6.1 无法连接：先分清 refused、timeout 还是 unreachable
用 netcat 排查网络问题时，最常见的困惑是看到不同的报错，不知道到底什么原因。我把这些反馈整理成一个速查表：
| 现象 | 含义 | 排查方向 |
|---|---|---|
| Connection refused | 目标机器可达，但该端口没有进程监听，或者防火墙返回了 RST | 检查服务是否启动、端口是否绑定正确 |
| Operation timed out | 数据包发出后没有回应，通常是被防火墙静默丢弃 | 检查防火墙规则、安全组、中间设备 ACL |
| No route to host | 网络不可达，或者对方主机关机/路由配置有问题 | 检查 IP 配置、路由表、vlan 划分 |
尤其要记住：Connection refused是个好消息，它至少说明网络层是通的，问题只出在应用层端口是否监听上。真正难排查的是timed out，意味着你的包可能被防火墙直接丢掉了，需要逐段做链路检查。
6.2 防火墙顺手丢弃 ICMP 导致 UDP 测试误判
前面提过 UDP 测试的坑，这里再具体化一些。UDP 端口不可达的回馈机制依赖 ICMP 报文，但很多管理员为了"安全"会禁用 ICMP。此时即使 UDP 端口没监听，客户端也收不到任何反馈，表现就是发送数据后一直等不到响应，最后超时。
所以我的经验是：做 UDP 连通性测试，尽量不依赖nc -z，而是实际发送应用层数据并观察响应。如果抓包可以看到对方回包，那就是通的；如果只有请求没有响应，再检查对方服务和防火墙。
6.3-p参数在不同版本间的行为差异
这可能是 netcat 新手最常踩的坑。很多教程里写nc -l -p 12345，你在 Ubuntu 上跑没问题，换到 CentOS 的 ncat 上跑也能跑通，但换到某些老版本 GNU netcat 上，-l和-p的顺序会让你抓狂。
ncat 的语法是ncat -l -p 12345，而必填端口时-p才有意义。OpenBSD netcat 里-l后可以直接跟端口，-p反而不需要。为了解决这个问题，我通常在脚本里先判断发行版，或者干脆统一用-l加端口的形式，再在兼容层做特殊处理。
写自动化脚本时建议这样封装：
nc -l 12345如果发现执行报错，再改用：
nc -l -p 123456.4 连接挂起：永远是超时参数没给够
默认情况下 netcat 发起连接后，如果对端不回应，它会一直等下去。这在交互式调试时没问题，但在脚本和自动化测试里就是致命的：任务会卡住，流水线会一直卡在那里。
解决办法就是在所有自动化场景中加上-w参数：
nc -vz -w 2 192.168.1.10 3306-w的单位是秒。还有一种情况是连接已经建立成功，但数据交换完毕之后，进程不退出。这是因为连接对端没有关闭，netcat 不知道数据是否已经结束。这时候也要用-q参数来控制发送完数据后延迟几秒关闭连接。
6.5 端口明明开着，为什么还是连不上
有种情况很迷：你确认服务在监听某个端口，从本机都能连上，但用 netcat 从另一台机器连却显示超时。问题基本出在监听地址上。
服务进程可能只监听了 127.0.0.1 (localhost)，而没有监听0.0.0.0或具体的网卡 IP。在本机访问 127.0.0.1 没问题，但外部访问时这个端口根本不在对应网卡上监听。
排查命令：
ss -lntp看监听列表里的 Local Address。如果显示127.0.0.1:3306，说明只监听回环地址，就需要改服务配置绑定对外的 IP 或者0.0.0.0。
6.6 netcat 扫端口和 Nmap 扫端口的区别
虽然 netcat 可以做端口扫描，但两者定位完全不同。netcat 每次连接只能测一个（或一个连续区间）端口，不能做并发，速度非常慢。而 Nmap 支持 SYN 半开扫描、服务识别、操作系统指纹识别等高级功能。在内网小范围快速测试时，netcat 的优势是随装随用；做渗透测试或者全面扫描时，选 Nmap。
具体到场景：你在客户现场的一台最小化安装的 Linux 服务器上排查问题，没有权限装新软件，此时系统的 netcat 就是最好的朋友。而在自己的电脑上做完整扫描，直接 Nmap 就好。
7. 实用脚本与性能侧记
7.1 批量检测远端端口状态的脚本模板
很多运维脚本里都有"批量检测端口"的需求。我把自己常用的一个模板分享出来，它可以在多台主机上测试多个指定端口，并把结果以表格形式输出：
#!/bin/bash hosts=("192.168.1.10" "192.168.1.11" "192.168.1.12") ports=(22 80 443 3306) for h in "${hosts[@]}"; do for p in "${ports[@]}"; do timeout 2 bash -c "echo >/dev/tcp/$h/$p" 2>/dev/null && \ echo "$h:$p open" || echo "$h:$p closed" done done这里我用到了 bash 自带的/dev/tcp虚拟设备，不需要 netcat，逻辑更简洁。注意这个脚本假设本机支持 bash 的/dev/tcp，在大多数 Linux 发行版上都没问题。
7.2 netcat 的传输性能能达到多少
很多人在第一次用 netcat 传大文件时，会担心它性能不够。实际上 netcat 的性能瓶颈根本不在自身，它只是一层薄薄的数据搬运层，吞吐量上限更多取决于 TCP 缓冲区大小、网卡性能以及网络延迟。在千兆内网环境，用默认配置跑 netcat 传文件，实测速度大概能到 700 Mbps 左右；如果调大 socket 缓冲区，还可以进一步提升。
不过性能不是 netcat 的主要卖点。它的卖点是简单、直接、随处可见。真要在生产环境做高速可靠传输，应该用专门的传输工具与协议。
7.3 组合 socat 的场景建议
socat 常被看作是 netcat 的加强版。如果你发现 netcat 的功能不够用，比如需要 TLS 加密、需要双向独立通道、需要 Unix Socket 转发，就可以升级到 socat。但日常的端口探测、临时文件传输、简单 Shell 通道，netcat 完全够用，不必额外引入依赖。
一个典型场景是：用 netcat 测 TCP 通不通，再用 socat 做 TLS 包装后的数据转发。我曾经在一个客户现场做跨区域数据中转，由于不能改动防火墙策略，就是靠 socat 监听端口并把流量转发到另一台机器上，配合 netcat 检查链路状态完成的。工具没有高低之分，适合场景才是关键。
8. 写在最后：netcat 让我养成的动手习惯
用了这么多年 netcat，我最大的感受是：它让我养成了"遇事先探测"的习惯。网络不通、服务没反应、接口返回异常，我不会先去翻文档猜原因，而是先用 nc 把链路和端口状态摸清楚，再结合抓包定位问题。很多看似复杂的问题，在确认"端口通、协议不通"或者"端口本身就不通"之后，排查范围直接缩小了一大半。
netcat 本身不复杂，但它是网络排障的基础功。就像写字之前要先学会握笔一样，搞网络的人也都应该熟练掌握 netcat 的常用姿势。这篇文章里的所有命令都可以直接复制到终端里尝试，建议你找两台真机或者虚拟机搭个环境，把监听、连接、传送、探测这些场景都亲手过一遍。多踩几次坑，后面就能少加几个班。
