局域网里传文件这件事，说简单也简单，说折磨人也真折磨人。飞秋FeiQ这类基于飞鸽协议的内网通讯工具，界面朴素、部署零成本，很多办公环境、机房、车间、实验室的内网全靠它撑着日常的文件互传和消息通知。但一旦出现“只能接收无法发送文件”这种单向故障，问题就变得很微妙：对端发来的文件哗哗往下落，自己这边点发送却石沉大海，进度条不动、对端毫无反应、也没有任何报错提示。这篇内容就专门拆这一类故障，从协议走向、端口监听、防火墙入站规则、应用层配置一路讲到常见坑位，给出可以直接照着操作的排查顺序和处置方案。适合正在被这个问题卡住的运维、网管，也适合平时只是用飞秋传文件、但想搞明白它到底怎么工作的普通使用者。不管你是第一次遇到，还是试过重启重装都没用，下面这套分层思路都能用得上。
1. 先搞清楚飞秋收发文件到底走的是什么路子
排查单向故障，最忌讳上来就重装软件、重启系统。你得先明白数据是怎么从A机走到B机的，哪一段是“发送方主动”、哪一段是“接收方主动”，方向搞反了，后面所有动作都是瞎猜。飞秋这类工具虽然界面简单，但它的通信模型其实是“发现、协商、传输”三段式，每一段用的协议和端口都不一样。
1.1 从广播发现到数据拉取的三段通信模型
局域网内网工具的典型工作方式是：启动时向所在网段发送广播报文，宣告“我在这儿，我叫什么、我的端口是多少”，同时监听别人发来的同类广播，从而自动建立在线列表。这一段通常走UDP，默认端口2425，特点是“不保证送达、不建立连接”，所以你在列表里看到对方在线，本质上是收到过对方的广播，而不是建立过可靠连接。
真正的文件传输走的是另一条路。以经典飞鸽协议实现为例，发送方点击发送文件后，先发一条“文件发送请求”报文，把文件名、大小、校验信息以及自己准备接收数据连接的端口号一并告诉对方；对端接受后，由接收方主动发起TCP连接，向发送方索要文件数据。这个细节极其关键：在文件传输这个动作里，实际的“服务端”是发送方，接收方反而是客户端。不同版本和不同实现之间会有差异，但“发送方需要开一个可被连接的数据通道”这个特征在多数局域网传输工具里都存在。
提示：本节描述的是基于飞鸽协议常见实现方式的合理推断，具体版本的行为可能不同。判断依据不用死记，后面用命令行看监听状态，能直接验证你那台机器到底是“发不出去请求”还是“开了门但别人进不来”。
理解了这一点，“能收不能发”这个现象立刻就有了指向性。你能收文件，说明你作为客户端主动去连别人的数据通道是通的，你的出站方向、你的TCP客户端能力、你的文件写入权限都没问题。你发不出去，问题大概率出在“你作为服务端”这一侧：要么你开的门别人找不到，要么门开了被别人挡住了，要么门根本没开起来。
1.2 为什么“单向故障”反而比“完全不通”更好排查
完全不通是最难办的，因为故障点在整条链路的任意位置，可能性太多。而单向故障天然把范围砍掉了一半：既然同一个软件、同一个网段、同一批人，A方向通、B方向不通，那么网段路由、交换机隔离、网线质量这些“双向共用”的因素基本可以排除，剩下的必然是方向性差异导致的，比如入站规则、监听端口、服务端权限、路径写入等。
这也解释了一个特别常见的误区：很多人一发现发不出去，就跑去检查网线、换交换机口、重启路由，折腾一圈毫无效果，因为这些动作对“方向性故障”根本不敏感。真正该看的是本机的入站方向有没有被拦住、监听端口有没有真的起来、防火墙对“专用网络”和“公用网络”是不是用了两套不同策略。
1.3 把“发不出去”拆成四个可验证的环节
为了让排查有顺序、不遗漏，我习惯把这个动作拆成四个环节，每个环节配一个可观测的现象。这样做的价值在于：你不需要一次性想明白所有可能，只要按顺序排除，每一步都能拿到明确的“是/否”结论。
| 环节 | 具体动作 | 正常表现 | 异常表现 |
|---|---|---|---|
| 环节一：发现 | 广播报文互相可见 | 在线列表能看到对端 | 对端灰色、时有时无 |
| 环节二：协商 | 发送文件请求并收到接受 | 对端弹出接收确认框 | 对端毫无反应、无弹窗 |
| 环节三：通道 | 发送方开启数据端口，对端连接 | 进度条开始走动 | 卡在0%、长时间无进展 |
| 环节四：落盘 | 数据写入对端目标路径 | 传输完成、文件可打开 | 传到一半失败、提示写入错误 |
这个拆法的好处是：环节一的异常指向网络隔离，环节二指向报文被拦或软件被限制，环节三指向本机入站通道，环节四指向对端磁盘和权限。四个环节对应四类完全不同的处置手段，你不会再把时间浪费在无关的方向上。
2. 动手之前先把变量控制住
很多人排查效率低，不是因为技术不够，而是因为每次改动都同时改了好几个变量，改完不知道是哪一项起的作用。我自己踩过最蠢的一次坑，是同时关了防火墙、换了端口、重装了软件，结果好了，但根本不知道原因，两周后同样的问题再来一次，照样抓瞎。
2.1 建立最小可复现环境
最理想的验证环境是两台机器直连，或者接在同一台不配任何策略的普通交换机上。如果条件不允许，至少保证测试双方在同一网段、不跨VLAN、中间没有额外的安全设备。测试用的文件也别随便挑，选一个体积小、名字全英文、放在桌面这种读写无限制目录的文本文件，排除掉所有“文件本身”的干扰因素。
测试对象也有讲究：不要拿“那台一直传不进去的机器”当唯一测试对象，找一个之前能正常互传的同事机器做对照。对照实验的价值在于，它能把“我这台机器的问题”和“这两台机器之间的问题”区分开。如果换成另一台对端就能发，问题在对端或者两点之间的链路策略；如果换谁都发不出去，问题就锁死在本机。
2.2 三份必须记录的信息
动手前，把下面三样东西记下来，后面每一步排查都要用到，而且万一需要找人协助，这三样东西能省掉大量来回确认的时间。
第一份是版本信息。不同版本的飞秋在端口使用、加密方式、文件传输实现上差异不小，有些老版本对新系统兼容性差，有些修改版行为更怪异。把主程序的版本号、安装路径、是否为绿色免安装版都记清楚，特别是“绿色版”，它往往不写注册表、不申请防火墙规则，出问题的概率明显更高。
第二份是端口占用情况。默认端口是2425，但实际运行时可能还涉及相邻的几个端口，同时有UDP和TCP两类。用命令把当前进程占用的端口全部列出来，确认软件到底想用哪些端口、有没有被别的程序占了。
第三份是防火墙状态。注意不是“开还是关”这么简单，而是要看三套网络配置文件（域、专用、公用）分别是什么状态，以及有没有针对这个程序的显式规则、规则是允许还是阻止、方向是入站还是出站。这三套配置相互独立，经常出现“专用网络放行了、公用网络拦着”的情况，而系统有时会把一个陌生的办公网识别成“公用网络”，这就是隐蔽的坑。
# 查看当前进程占用的端口（管理员权限运行） netstat -ano | findstr ":2425" # 根据PID反查进程名 tasklist | findstr "对应PID" # 查看三套网络配置文件的防火墙状态 netsh advfirewall show allprofiles state # 查看已有的针对该程序的规则 netsh advfirewall firewall show rule name=all | findstr /i "飞秋"3. 逐层排查的完整实操流程
下面这套顺序是我自己用了很多次的，核心原则是“从便宜到贵、从外到内”：先做零成本的验证，再动配置，最后才考虑重装和换工具。每一步都有明确的判定标准，不要跳步，跳步的结果往往是改了一堆东西，问题还在。
3.1 第一层：确认对端是真的“在线”而不是“看起来在线”
在线列表这个东西有欺骗性。飞秋的在线状态依赖广播报文，而广播在很多网络环境里是被限制的：跨网段不转发、无线网络的客户端隔离会拦掉、交换机开了端口隔离也会拦掉。于是出现一种典型现象：对方明明在同一个办公区，列表里却时有时无，或者显示在线但发消息要等很久才到。
验证方法很朴素，直接用系统的连通性测试工具打对方的地址，看响应时间和丢包。如果连基础连通性都不稳定，那文件发不出去太正常了，先解决网络可达性，别在软件里绕圈。另外要特别注意多网卡的情况：一台机器同时接了有线内网和无线网络，或者装了虚拟网卡，广播可能从错误的网卡发出去，导致对方收到的“我的地址”是虚拟网卡的地址，回连自然失败。
注意：虚拟机软件、容器工具、远程办公工具都会创建虚拟网卡，这些网卡经常抢到广播的发送权。如果你的机器上装了这类软件，优先检查是不是广播走了虚拟网卡。
# 查看本机所有网卡与地址，确认没有虚拟网卡干扰 ipconfig /all # 测试到对端的连通性与丢包 ping -n 20 对端地址 # 查看本机ARP表，确认对端地址解析到的物理地址是否合理 arp -a判定标准很清楚：连续二十次测试全部有响应且延迟稳定在个位数毫秒，说明链路没问题，可以进入下一层；有丢包或者延迟忽高忽低，先解决网络层，后面的排查没有意义。
3.2 第二层：看本机的数据通道到底有没有开起来
这是整个排查流程里信息量最大的一步。按前面讲的模型，发送文件时本机需要开启一个可被连接的数据通道。用端口查看命令确认这个通道是否存在、监听在哪个地址上。
重点看两件事。一是监听地址：如果显示的是127.0.0.1（本地回环），那意味着只有本机能连，外面的人永远进不来，这是典型的配置异常或软件异常；正确的情况应该是0.0.0.0（所有网卡）或者本机的具体内网地址。二是监听协议：UDP用于发现和报文协商，TCP用于数据通道，两者都要有。
如果根本看不到监听，说明软件的数据通道压根没启动。这时候先看进程是不是以普通用户身份跑的，再考虑是不是被杀毒软件或安全软件拦了。有些安全软件会把“监听端口”这个行为判定为可疑，直接静默阻断，日志里还未必写，只在你手动查的时候才发现端口不见了。
# 查看所有监听端口及对应进程，重点关注2425及相邻端口 netstat -ano -p tcp | findstr "LISTENING" netstat -ano -p udp # 更直观的方式：按进程名过滤，确认程序确实在跑 Get-Process | Where-Object {$_.ProcessName -like "*fei*"} # 查看指定端口的占用进程，判断是否被别的程序抢占 Get-NetTCPConnection -LocalPort 2425 -ErrorAction SilentlyContinue如果端口被别的程序占用了，现象会非常隐蔽：软件能启动、能聊天、能收文件，就是发不出去，因为它想用的端口被别人拿着，只好退而求其次或者干脆失败。这种情况在老机器上特别常见，一堆常驻小工具抢端口，谁先启动谁占着。
3.3 第三层：入站规则才是“能收不能发”的头号嫌疑
如果前面两层都正常，端口也在监听，那基本可以锁定到入站方向被拦。这是单向故障里出现频率最高的原因，也是最容易被误判的——因为很多人只检查了“防火墙开没开”，却没检查“规则的方向和配置文件对不对”。
系统防火墙的规则是有方向的。出站规则管你能不能连别人，入站规则管别人能不能连你。你能收文件，说明出站方向没问题；你发不出去，说明别人连不进来，正是入站方向被拦。而系统默认策略一般是“出站允许、入站阻止”，除非有显式规则放行。软件第一次运行时通常会弹窗询问是否允许，很多人顺手点了“取消”或者直接关掉弹窗，于是规则就变成了一条“阻止”项，而且这条阻止规则优先级很高，后面再点允许也未必覆盖。
处置方式有两种，推荐第一种。第一种是手工建一条明确的入站允许规则，把程序路径和端口都绑上，这样规则可控、可复查、可批量复制到其他机器；第二种是直接临时关闭防火墙做验证，验证完立刻恢复。第二种只适合用来确认判断，不要当成长期方案。
# 方式一：按程序路径建入站放行规则（推荐，把路径换成实际安装路径） netsh advfirewall firewall add rule name="内网传输工具-程序入站" dir=in action=allow program="C:\程序目录\主程序.exe" enable=yes profile=any # 方式二：按端口建入站放行规则，UDP和TCP各一条 netsh advfirewall firewall add rule name="内网传输-UDP2425" dir=in action=allow protocol=UDP localport=2425 profile=any netsh advfirewall firewall add rule name="内网传输-TCP2425" dir=in action=allow protocol=TCP localport=2425 profile=any # 验证规则是否生效 netsh advfirewall firewall show rule name="内网传输-UDP2425"注意 profile 参数，写成 any 表示三套配置文件全部放行。如果是受管控的办公环境，可能只允许改“专用网络”这一套，那就把 any 换成 private，但要确保当前网络确实被识别为专用网络——这一点可以在网络和共享中心里看到，也可以用过命令行查询。我遇到过好几次“规则明明加了还是不行”，最后发现网络被识别成“公用”，规则只对“专用”生效，等于白加。
注意：除了系统自带防火墙，还要检查第三方安全软件的“网络防护”模块。这类模块通常有自己的规则体系，和系统防火墙互不干扰，系统里放行了不代表它放行。验证方法很简单：临时退出该软件再测一次，如果立刻能发，问题就锁定了。
3.4 第四层：文件本身和目标路径的隐性限制
有些“发不出去”其实不是发不出去，而是发出去之后对方落盘失败，表现上看起来像没发成功。尤其是传输大文件或者文件名含特殊字符的时候，前端表现是进度条卡住或者直接归零，很容易被误判成网络问题。
常见的文件侧问题有这么几类。文件名含特殊符号或超长路径，对端系统在拼接完整路径时超限，写入失败；文件被本机其他程序独占打开，读不出来，发送端在读取阶段就卡住；单个文件超过对端文件系统的限制，比如目标盘是某种不支持大文件的老格式；目标路径是只读的，或者对端当前登录用户没有写权限。还有一种特别隐蔽的：对端磁盘空间不足，但接收端没有任何提示，进度条走到最后直接失败。
处置思路是先做减法：换一个几KB的纯英文名文本文件，放到桌面这种绝对可写的目录，再发一次。能成功，说明问题在文件侧或路径侧，逐个回加变量（中文名、长路径、大体积、特殊目录）就能定位到具体是哪个因素。这个“二分回加”的方法比逐个猜快得多，尤其适合那种“有时候能发有时候不能发”的间歇性故障。
3.5 第五层：运行权限与会话环境
这一层容易被忽略，但在某些系统上确实是根因。软件如果以普通用户权限运行，某些系统目录、某些端口范围、某些网络操作会被限制。更麻烦的是多用户会话：一台机器上同时登录了多个账户，或者有远程桌面会话，此时同一个程序可能跑了多个实例，端口被其中一个实例占着，你在另一个会话里操作，自然发不出去。
还有一种典型情况：程序是以“管理员身份运行”启动的，但对端是普通权限，两边在处理文件路径时的权限上下文不一致，导致协商阶段正常、传输阶段失败。这类问题的特征是“所有环节看起来都对，就是不成功”，排查时容易被带到网络方向去。
处置办法就一条：两边都用同样的权限级别启动，最好都用普通用户身份，实在需要提权就两边一起提。同时确认任务管理器里只有一个实例在跑，多余的全部结束掉再重新启动。
4. 我踩过的几个典型坑与快速处置表
理论讲完，说点实际遇到的。下面这几个场景都是虚构代称，但现象和处置过程是我在实际工作中反复验证过的，遇到类似症状可以直接对号入座。
4.1 四个让人抓狂的真实感场景
第一个场景：某办公区的A同学，能收不能发，重装软件三次无效。最后发现是系统把当前网络识别成了“公用网络”，而之前加的那条放行规则只勾了“专用网络”。改规则为全部配置文件后立刻恢复。这个坑的迷惑性在于，网络类型是系统自动判定的，办公网有时候因为网关信息不完整被判成公用，你根本没动过任何设置，它自己就变了。
第二个场景：某机房的机器，发文件时进度条永远停在0%。端口查了、防火墙关了、软件也换了版本，还是不行。最后用端口查看命令发现，它想用的那个端口被一个常驻的打印服务占着。把打印服务改成手动启动，重启后一切正常。这类问题的价值在于提醒你：端口冲突的表现和防火墙拦截几乎一模一样，必须用命令去看实际监听状态，靠猜是猜不出来的。
第三个场景：某实验室的两台机器，互发都不行，但各自和其他机器都正常。这种“点对点不通、面面通”的情况，八成是这两台机器之间的链路策略问题，比如中间某台设备上配了针对这两个地址的访问控制，或者其中一台装了两个安全软件互相打架。处置方式是找一台中间机器做对照，分别测两个方向，很快就能定位到是哪一侧的策略在起作用。
第四个场景：能发小文件、发不了大文件。这种“按体积分层”的故障，通常指向两个方向：一是目标磁盘空间，二是传输过程中被某种流量检测机制中断。先查对端磁盘剩余空间，再查有没有安全设备对长时间连接做了限制。这个排查顺序很重要，因为磁盘空间是本地就能确认的，成本最低。
4.2 现象到处置的速查对照
下面这张表按“现象”列，方便你从自己的实际症状直接跳到对应处置，不用按章节顺序读。
| 现象 | 最可能的原因 | 一步验证 | 处置动作 |
|---|---|---|---|
| 对端无任何弹窗，自己这侧无提示 | 请求报文未送达或被拦 | 对端是否能收到文字消息 | 检查出站与报文端口，确认未被安全软件阻断 |
| 对端弹窗但接受后进度条不动 | 本机数据通道不可被连接 | 查看监听地址是否为0.0.0.0 | 修入站规则，检查端口占用 |
| 卡在0%且对端提示连接失败 | 端口被占用或通道未启动 | 查端口占用进程 | 结束占用进程，改端口或改启动顺序 |
| 传到一半中断、文件损坏 | 磁盘空间不足或连接被中断 | 查对端剩余空间 | 清理空间，排除流量检测干扰 |
| 小文件正常、大文件必失败 | 文件系统限制或超时策略 | 换不同体积文件对比 | 换目标盘，调整超时相关配置 |
| 换个对端就能发 | 点对点链路策略 | 用第三台机器做对照 | 排查两点之间的访问控制 |
| 时好时坏、重启后短暂恢复 | 端口抢占或网络类型漂移 | 重启前后各查一次网络类型 | 固定端口，显式指定网络类型 |
这张表建议存下来，下次遇到同类问题，先看现象再动手，能省掉大量试错时间。
5. 让这套东西长期稳定的几个加固动作
故障解决只是第一步，真正省心的是让它别再犯。下面这几个动作成本都不高，但收益明显，尤其适合需要长期维护一批机器的场景。
5.1 固定端口与规则模板化
端口随机化是很多局域网工具的设计特点，灵活性换来了排查难度。如果环境允许，把端口固定下来，并且把放行规则做成可复制的模板，新机器部署时直接导入，不要每台都手动点弹窗。规则命名也要规范，写上用途和端口，半年后回来看还能一眼认出是干什么的，别用“新建规则1”这种名字。
同时建议在部署文档里写清楚三件事：程序装在哪个路径、用了哪几个端口、规则是哪几条。这三条信息在出问题时能直接省掉半小时的摸索。我见过太多环境，机器是上一任同事配的，规则名一片空白，端口用了非默认值，接手的人只能从头猜。
5.2 备一条不用端口的兜底通道
再稳的配置也有失灵的时候，尤其是临时借用别人机器、或者跨到一个策略完全不同的网段时。这时候如果能有一条不依赖特定端口的兜底手段，会从容很多。系统自带的文件共享是最省事的，配一个共享目录，通过地址直接访问，走的是完全不同的协议栈，一条路不通另一条大概率通。
另一类兜底方式是临时起一个简单的本地文件服务，把文件放在目录里让对方用浏览器拉取。这种方式的好处是完全不依赖客户端软件、不依赖特定端口、对端什么系统都能用。缺点是单向的，而且用完要记得关掉，别长期开着。
| 方式 | 依赖条件 | 优点 | 适用场景 |
|---|---|---|---|
| 内网通讯工具直传 | 特定端口与入站放行 | 速度快、有确认、可批量 | 日常固定办公环境 |
| 系统共享目录 | 共享服务与账号权限 | 通用、无需额外软件 | 长期固定目录交换 |
| 临时本地文件服务 | 一个可用端口 | 跨平台、临时应急 | 借用机器、临时协作 |
| 移动存储介质 | 物理接触 | 完全离线、最可靠 | 网络策略严格或断网环境 |
选型上没有绝对优劣，关键是心里要有第二条路。我个人的习惯是：日常用内网工具，重要文件同时往共享目录放一份，遇到工具抽风直接切过去，不耽误事。
注意：兜底通道同样要注意访问范围控制。临时服务用完立刻关闭，共享目录设好读写权限，别为了方便把整个盘符开成所有人可写，那属于给自己埋雷。
6. 最后说几句实操体会
这套排查顺序我用了很多年，最大的感受是：单向故障看着玄乎，其实逻辑非常干净，因为它天然帮你排掉了一半可能性。真正拖时间的从来不是技术难度，而是没有顺序地乱试——关防火墙、重装、换软件、换网线，一通操作下来问题可能碰巧好了，但你不知道为什么好，下次照样抓瞎。
我现在遇到这类问题，固定动作是先记录三样信息（版本、端口、防火墙三套配置状态），然后按“发现、协商、通道、落盘”四个环节走一遍，每一步都要拿到明确的是或否，绝不允许自己“感觉应该没问题”就往下跳。这个习惯养成之后，同类故障的平均处置时间从半天压到二十分钟以内。
还有个小技巧值得单独说：改任何配置之前，先把当前状态导出一份。防火墙规则可以导出，端口列表可以存文本，网络配置可以截图。改完不行就还原，别在一堆已经改乱的状态上继续叠加改动。我见过太多环境，最后不是修好的，是重装系统重配一遍才好的，本质上就是改动叠太多，已经无法回溯了。留一份原始状态，是给自己留退路。
