为什么访问tftp服务器没响应，tftp无响应怎么解决？

访问TFTP服务器没响应，多数情况不是服务器“坏了”，而是UDP 69端口没放行、服务没监听、客户端用错模式或网络回程不通。 按“先本机、再链路、后抓包”的顺序查,通常比反复重装服务更快定位。

先看清现场：tftp服务器没响应的典型表现

TFTP和常见网页服务不一样，它跑在UDP上，初始请求使用UDP 69端口，据IANA端口分配记录，这是TFTP的标准请求端口，客户端发出读请求或写请求后，如果服务端没回包，表现往往不是“连接被拒绝”，而是长时间卡住、提示传输超时,或者只显示一个模糊的错误码。

现场常见现象有几类：

• 命令行输入tftp 192.168.1.10 get test.txt后一直等待,最后提示超时。
• Windows客户端提示“传输超时”或“无法连接”，但ping服务器是通的。
• 服务器本机测试正常,换一台电脑就不行。
• 小文件偶尔能传,大文件传到一半失败。
• 抓包能看到请求包,却看不到服务器回包。

这些现象指向不同层。ping通只说明ICMP可达，不代表UDP 69可达，更不代表TFTP服务在监听，行业共识认为,TFTP排障的核心是确认UDP请求与回包是否双向可达。

tftp服务器没响应怎么排查：从本机到网络的五步法

先确认TFTP服务真的在运行

不要只看管理界面上的“已启动”,要到系统里看监听地址和端口。

Windows环境可以打开services.msc，找到TFTP服务相关项，确认状态为“正在运行”,再用管理员命令行执行：

netstat -ano | findstr :69

正常应看到UDP 0.0.0.0:69或指定网卡地址的UDP监听，如果只看到0.0.1:69,远程客户端访问必然没响应。

Linux环境按发行版不同，可能由systemd、xinetd或独立服务托管,可执行：

systemctl status tftp
ss -lunp | grep :69

重点看三件事：服务是否active、监听地址是否为0.0.0或业务网卡地址、进程有没有权限读取根目录，TFTP根目录权限不对时，服务可能活着，但回给客户端的是错误码，表现为“没响应”或“访问拒绝”。

在本机做一次闭环测试

先排除“客户端连错地址”和“文件名写错”，在服务器本机放一个测试文件，例如test.txt,然后执行：

tftp 127.0.0.1 get test.txt

Windows下可写：

tftp -i 127.0.0.1 GET test.txt

本机都不通，优先查服务配置、根目录路径、文件名大小写和权限，本机通、远程不通，问题基本落在防火墙、ACL、路由或客户端。

检查防火墙与安全软件

Windows防火墙需要放行入站UDP 69，第三方安全软件、终端防护软件也可能拦截TFTP，Linux常见的是firewalld、iptables和SELinux。

firewalld可先查看规则,再按需放行：

firewall-cmd --add-port=69/udp --permanent
firewall-cmd --reload

SELinux可用getenforce查看状态，临时setenforce 0只适合验证，确认是SELinux拦截后，再按策略放行,不要长期关闭。

这里有个容易踩的坑：TFTP不只使用69端口，数据传输阶段，服务器会使用临时UDP高端口回应客户端，防火墙或ACL如果只放行69，后续DATA包可能被丢掉，表现为请求有去,文件传不动。

查网络路径：ACL、路由和VLAN

跨网段访问时，先看交换机或防火墙ACL有没有放行UDP 69，以及回程流量是否允许，只放行客户端到服务器的方向不够，要确认双向放行。

再查服务器回程路由，服务器收到请求后，如果回包走错网卡或默认网关，客户端就会一直等，双网卡服务器尤其常见：请求从A网卡进来，回包从B网卡出去,客户端抓不到回应。

可用tracert或traceroute看路径，用tcpdump在服务器侧抓包：

tcpdump -i any udp port 69 -nn

抓包时重点看有没有RRQ请求、有没有DATA或ERROR回包，有请求没回包，查服务和防火墙；有回包但客户端收不到，查ACL、路由和NAT。

用Wireshark把结论落地

Windows客户端可安装Wireshark，过滤udp.port==69，正常流程应看到客户端发RRQ，服务器回DATA或ERROR，若只看到RRQ，说明请求到了但回应没回来；若看到ERROR code 2，通常是访问违规或权限问题；若看到DATA但客户端仍超时,查中间设备是否改写了源端口或丢弃了高端口UDP包。

局域网tftp服务器连接超时怎么办：三个高频场景

跨VLAN访问超时

办公室不同VLAN之间通常有ACL，TFTP使用UDP，部分ACL只放行TCP，或者只放行69单端口，处理时先确认VLAN间路由可达，再确认ACL放行UDP 69及会话回包，交换机开启端口隔离时,也要确认客户端和服务器不在隔离范围内。

Windows下tftp客户端上传下载失败

据微软官方文档，Windows的TFTP客户端需要在“启用或关闭Windows功能”中安装，命令格式也要注意：下载用GET，上传用PUT，二进制模式加-i。

tftp -i 192.168.1.10 GET test.txt
tftp -i 192.168.1.10 PUT local.txt

如果服务端根目录不允许写入，上传会失败，文件名大小写、路径写法、目标目录权限都要核对。

服务器多网卡选错回包

多网卡服务器要确认TFTP服务绑定在业务地址上，或者通过路由metric调整回程，测试时可在服务器上抓两个网卡的包，看请求从哪进、回包从哪出，回包源地址和客户端请求的目标地址不一致时,很多客户端会直接丢弃。

tftp和ftp访问无响应有什么区别：别把UDP问题当TCP查

telnet 服务器 21能通，只能说明FTP控制端口可达，不能证明TFTP正常，TFTP没有TCP握手，用telnet测69端口没有意义，判断TFTP是否响应，最直接的是用TFTP客户端发请求,同时在两端抓包。

容易被忽略的配置细节

• 根目录路径写错,服务启动但找不到文件。
• Linux下TFTP运行用户对文件没有读权限,上传目录没有写权限。
• 文件名大小写不一致,Windows客户端在Linux服务端下载失败。
• 安全设备把TFTP识别为高风险协议并阻断。
• NAT设备只映射了69,没有处理临时高端口回程。
• 客户端超时时间太短,跨广域网时容易误判。

这些细节不需要复杂工具，按“服务监听、本机测试、防火墙、ACL路由、抓包”的顺序逐项排除，结论通常很清楚。TFTP没响应不是玄学，关键是确认请求包和回包在哪一段断掉。

tftp服务器没响应常见问答

tftp服务器没响应但ping得通，问题在哪？

ping通只代表ICMP可达，TFTP走UDP 69，服务监听地址、防火墙UDP规则、ACL、回程路由任一环节都可能断，先在服务器执行ss -lunp | grep :69或netstat -ano | findstr :69确认监听,再抓包看RRQ有没有对应回包。

交换机只放行UDP 69为什么还是超时？

TFTP传输阶段会使用服务器临时UDP高端口，ACL只放行69，后续DATA包可能被丢弃，表现就是请求有去、文件传不动，需要放行会话双向，或使用设备的状态化检测能力,具体以设备型号和策略为准。

Windows下tftp客户端上传下载失败怎么判断服务器是否响应？

先在服务器本机执行tftp 127.0.0.1 GET test.txt，确认服务本身正常；再从客户端执行tftp -i 服务器IP GET test.txt，同时用Wireshark过滤udp.port==69，抓包中能看到RRQ并收到DATA或ERROR，说明服务器有响应；只看到RRQ没有回包，问题在服务、防火墙或网络策略。