为什么访问tftp服务器没响应？绝大多数情况下，问题出在TFTP服务本身没有启动、系统防火墙拦截了UDP 69端口，或者TFTP根目录的读写权限没配好。 按照下面的顺序一步步排查，通常几分钟就能定位到原因。
先判断TFTP服务端到底“活没活”
很多人一遇到没响应,第一反应就是改防火墙、换客户端，其实第一步应该确认服务端进程是否真的在运行，TFTP是轻量级文件传输协议，很多Linux发行版默认不安装，或者装完不自动启动。
Linux下查看服务状态
以最常见的tftpd-hpa和tftp-server（xinetd方式）为例，登录服务器后分别执行：
systemctl status tftpd-hpa如果显示active (running)说明正常；如果显示inactive或failed，直接systemctl start tftpd-hpa并systemctl enable tftpd-hpa。ps -ef | grep tftp能看到/usr/sbin/in.tftpd进程才算真的起来了。
如果是用xinetd托管的TFTP，还需要检查/etc/xinetd.d/tftp里的disable参数是否为no，然后重启xinetd：
systemctl restart xinetd
Windows Server下的TFTP服务
Windows自带的TFTP服务在“服务器管理器”里添加“文件服务”角色后，还要在“服务”面板里找到“TFTP Server”，确认状态是“已启动”，很多人只装了角色，没启动服务，自然没响应。
tftp服务器搭建失败原因排查：防火墙和端口是第一嫌疑
TFTP默认使用UDP 69端口，这个端口很“脆弱”，只要防火墙没放行UDP 69，客户端访问时就会一直超时，表现为“没响应”，而且TFTP传输数据时还会使用随机高位端口，很多安全策略会把后续传输也挡掉。
放行UDP 69端口的实操步骤
Linux下如果用firewalld：
firewall-cmd --permanent --add-port=69/udp firewall-cmd --reload
如果用iptables：
iptables -A INPUT -p udp --dport 69 -j ACCEPT
Windows防火墙则去“高级设置”新建入站规则，选择“端口”，协议选UDP，端口填69，操作选“允许连接”，注意同时勾选“公用”“专用”网络类型。
不要忽略后续数据端口
行业共识认为,TFTP的后续数据传输使用客户端和服务器协商的临时端口，防火墙如果只放行69端口，传输大文件时依然会失败，最省事的做法是在防火墙规则中放行所有来自内网TFTP客户端的UDP流量，或者将TFTP服务绑定在可信网段。
检查TFTP根目录和文件权限：最常见的“隐形杀手”
服务通了、防火墙也放了，仍然没响应？那多半是TFTP根目录的权限不对，TFTP出于安全考虑，默认目录通常是/srv/tftp或/var/lib/tftpboot，运行TFTP的用户一般是nobody或tftp，如果目录属主是root且权限是755，客户端能列出文件但无法上传，甚至连接后立刻断开。
配置目录权限的推荐做法
- 查看当前根目录：
cat /etc/default/tftpd-hpa，注意TFTP_DIRECTORY这一行。 - 修改属主和权限：
chown -R tftp:tftp /srv/tftp chmod -R 777 /srv/tftp # 内网环境图省事可以这么干，不推荐在公网这么配
- 如果是上传场景,还要确保配置文件里启用了
--create选项，对于tftpd-hpa，在/etc/default/tftpd-hpa的TFTP_OPTIONS中加上--create，否则客户端上传时会得到“Permission denied”或直接无响应。
文件名大小写和路径别忽略
TFTP对文件名大小写敏感,且不允许使用绝对路径，客户端里写/home/user/file.txt是错的，应该只写相对于根目录的路径名，很多“没响应”其实是客户端命令格式错误，服务端直接忽略请求。
网络层与客户端自身的坑：为什么win7 tftp客户端连接超时怎么解决
服务端一切正常,那问题可能在客户端所在的网络环境，TFTP使用UDP，没有握手确认，客户端发出请求后如果收不到应答，就会反复重传直到超时，这时候需要从网络连通性和客户端参数两方面排查。
先ping一下服务器
执行ping 服务器IP，如果丢包或不通，先解决二层三层问题，如果ping通但仍然没响应，使用抓包工具（tcpdump -i any port 69
或Wireshark）看服务器是否收到了RRQ/WRQ请求。
- 能收到请求但不回包：看服务端防火墙、SELinux（执行
getenforce看是不是Enforcing）。 - 收不到请求：看客户端到服务器的UDP路由，以及中间交换机是否做了UDP限制。
常见客户端报错对照
| 问题现象 | 大概率原因 | 应对方法 |
|---|---|---|
| 连接超时 | 服务未启动或防火墙拦69端口 | 查服务状态、放行UDP 69 |
| 收到“Access violation” | 根目录权限或--secure限制 |
修改目录权限，检查配置文件 |
| 传输到一半断开 | 后续UDP端口被防火墙丢弃 | 放行内网UDP大范围端口 |
| 上传失败 | 缺少--create选项 |
在TFTP_OPTIONS中加上--create |
换个客户端试试
如果你用的是Windows ping命令里的TFTP组件，它不支持交互式操作，上传下载语法很别扭，更稳妥的方式是用tftp64.exe这类图形化工具，或者Linux下的curl -T file tftp://服务器IP/文件名，排除客户端软件自身的兼容性，能少走很多弯路。
tftp服务器和ftp服务器有什么区别：搞懂这两个概念就不会配错
不少人在配置TFTP时,总拿FTP的思维去套。TFTP和FTP之间的差异，恰恰是很多“没响应”问题的根源，TFTP基于UDP，不提供认证和目录列表功能，只适合在局域网内做设备固件升级、路由器配置备份等场景，而FTP基于TCP，有用户名密码机制，支持复杂目录操作，如果你需要权限控制，应该用FTP或SFTP，而不是纠结TFTP为什么总是不听话。
别把tftp服务跑在非69端口
有朋友为了避开防火墙,把TFTP端口改成比如8080，这时客户端必须手动指定端口，很多TFTP客户端默认只连69端口，配置里没改端口号，自然没响应，如果是思科或华为网络设备的copy命令，可以使用tftp://IP:端口号/文件名指定端口，但Windows自带客户端不支持，换第三方工具才可行。
终极排查顺序：三分钟内定位问题
按以下顺序操作,可以快速覆盖90%以上的“访问没响应”情况：
- 在服务器本机执行
tftp 127.0.0.1，然后get 一个存在的文件，如果本机都不通，问题肯定在服务端配置或服务状态。 - 检查
systemctl status tftpd-hpa（或xinetd状态）。 - 检查防火墙：
firewall-cmd --list-all或iptables -L -n，看UDP 69是否放行。 - 检查SELinux：
getenforce，如果是Enforcing，可以暂时setenforce 0测试。 - 检查根目录权限：
ls -ld /srv/tftp，确认为tftp用户可读写。 - 在客户端抓包看UDP是否收到服务器回应。
按这个顺序排查,绝大多数情况在第二步或第三步就能解决。
为什么访问tftp服务器没响应：常见问题问答
为什么tftp服务器能ping通，但客户端就是没响应？
能ping通说明网络层通,问题集中在UDP 69端口或TFTP服务进程，检查服务端是否监听UDP 69端口（执行netstat -lunp | grep 69），以及防火墙是否放行UDP流量，有些路由器或交换机默认开启了“UDP Flood防护”，也可能把TFTP请求包直接丢弃。
为什么tftp服务器在虚拟机里总是响应慢或超时？
虚拟机场景里,虚拟机网卡如果是NAT模式，宿主机防火墙会拦截TFTP这类UDP广播或特定端口流量，建议改用桥接模式，让虚拟机直接暴露在局域网，同时确认VMware或VirtualBox的“虚拟网络编辑器”中，UDP协议没有被过滤，轻量级的解决办法是把TFTP服务运行在宿主机上。
为什么tftp服务器已经启动，但多客户端同时访问时部分没响应？
TFTP的并发能力很弱,很多xinetd托管的TFTP默认单线程处理，当多个设备同时刷固件时，后续请求会被排队或丢弃，检查启动方式：tftpd-hpa默认使用-s安全模式，同时处理连接数有限，改用-c和-p参数，或者为每个设备分时执行，不要并发上传。
排查tftp没响应,核心思路永远是：服务端进程 → 防火墙端口 → 目录权限 → 客户端选项，按这条链路走下来，找不到原因的概率极低，只要把UDP 69放行、服务设为开机自启、根目录权限给对，TFTP就能老老实实跑起来。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/762358.html
