Navicat On-Premises同步大文件超时的根本原因是HTTP上传链路中客户端、Web服务（如Tomcat/IIS）及服务端处理三端超时参数未协同调整，需同步修改客户端upload_timeout、Tomcat的connectionTimeout/maxHttpHeaderSize及启用本地路径直挂替代方案。
Navicat On-Premises 同步大文件时超时，根本原因不是“同步慢”，而是它默认用 HTTP 协议上传/下载，且底层依赖的 Web 服务（如内置 Tomcat 或 IIS）对单次请求有硬性超时限制——常见是 30 秒或 2 分钟，一旦文件体积大、网络抖动或磁盘写入慢，就直接中断并报 Connection timed out 或 Upload failed: request timeout。
为什么默认 HTTP 上传会卡在 30–120 秒？
Navicat On-Premises 的文件同步走的是 Web API 接口（比如 /api/v1/files/upload），不是 rsync 或分块直传。整个文件被读入内存再 POST 发送，服务端收到后才开始解压/校验/入库。这个链路里任意一环卡住都会触发超时：
- 客户端上传阶段：Navicat 客户端未启用分块上传，大文件（>50MB）容易因网络波动导致单次 HTTP 请求停滞
- 服务端接收阶段：Tomcat 的
connectionTimeout默认是 20000ms（20 秒），IIS 的executionTimeout默认 110 秒，都远低于大文件传输所需时间 - 服务端处理阶段：上传完还要解压、校验、生成预览缩略图，这些操作阻塞主线程，进一步延长响应时间
怎么改 Tomcat 的 timeout 配置？
如果你部署的是 Windows + Tomcat 模式（最常见），必须手动改 conf/server.xml 里的 Connector：
- 找到
<Connector port="8080" ...>这一行 - 添加或修改两个属性：
connectionTimeout="1800000"（30 分钟）和maxKeepAliveRequests="100" - 重启 Tomcat 服务（不是 Navicat 服务，是 Tomcat 进程）
- 注意：不能只调大
connectionTimeout，还要确保maxHttpHeaderSize≥ 65536，否则大文件带长 header 会直接 400
有没有更稳的替代方案？
绕过 Web 上传是最有效的办法。Navicat On-Premises 支持“本地路径直挂”模式，只要数据库服务器和 On-Premises 服务在同一个内网，可以：
- 把备份文件（.sql / .ndb / .bak）提前拷到服务端某个目录，比如
C:\navicat-data\imports\ - 在 Navicat 客户端选择“从服务器路径导入”，填入相对路径
imports/my_big_dump.sql - 服务端会跳过 HTTP 上传，直接 fopen + fread 流式读取，不走超时控制
- 该方式要求服务端磁盘有足够空间，且路径需在
application.properties中的navicat.import.path.whitelist白名单里显式声明
客户端也得调：Navicat 自身的上传超时
客户端不是完全被动的。Windows/macOS 客户端都有隐藏参数可覆盖默认行为：
- 启动 Navicat 时加命令行参数：
--upload-timeout=1800（单位秒） - 或者修改用户配置文件
%APPDATA%\PremiumSoft\Navicat\onprem\config.json，加入"upload_timeout": 1800 - macOS 路径是
~/Library/Application Support/PremiumSoft/Navicat/onprem/config.json - 改完必须完全退出 Navicat（托盘进程也要杀掉），再重进才生效
maxHttpHeaderSize，结果还是 400。大文件同步本质是两端协同，漏掉任意一端的 timeout 都会失败。 
