先说结论：你贴的这段配置方向是对的，Upgrade、Connection、proxy_http_version 1.1 三件套都齐了，所以 400/502 大概率不是缺这一对头，而是缺 Host 与真实 IP 头、长连接超时没放开，或者实际生效的配置与你看的不是同一份。按下面顺序排查，改一处、验证一处。1. Upgrade 和 Connection 必须成对出现WebSocket 握手是 HTTP 升级机制：客户端发 Upgrade: websocket，Nginx 必须原样把 Upgrade 转给后端，同时把 Connection 置为 upgrade，后端才回 101 Switching Protocols。只写 Upgrade 不写 Connection，后端会当成普通 HTTP 请求处理，多半直接 400；只写 Connection 不写 Upgrade，后端收不到升级意图，同样握手失败。更稳妥的写法是用 map，避免非 WebSocket 请求也被硬改 Connection：map $http_upgrade $connection_upgrade {    default upgrade;    '' close;}location 里写 proxy_set_header Connection $connection_upgrade; 这样普通请求走 close，握手请求走 upgrade，互不干扰。2. Host、X-Real-IP、X-Forwarded-For 缺失的影响这三行建议都补上：proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;Host 缺失最容易出 400：很多后端按 Host 做虚拟主机或 Origin 校验，收到的 Host 是 127.0.0.1:8080 就直接拒绝，而直连时 Host 正常，所以绕过 Nginx 反而能通。X-Real-IP 与 X-Forwarded-For 缺失一般只影响日志和限流统计，不会直接导致 400，但排查时没有真实 IP 会很难定位，仍建议补齐。3. proxy_http_version 1.1 是必须的Nginx 默认 proxy_http_version 是 1.0，而 HTTP/1.0 不支持 Upgrade 升级语义，握手会在“发了升级请求、后端却不认升级”这一步卡住，表现为 400 或连接直接断开。你已写了 1.1，这一点没问题，但要确认它的生效：执行 nginx -T 看最终合并后的配置，确认没有其他 location 或正则 location 覆盖了 /ws/，也确认改完是 reload 而不是只改了文件没生效。4. 400 与 502 分开查400 优先查请求头转发：用下面第 5 点的方法确认后端实际收到的 Upgrade、Connection、Host 是否齐全，同时看后端日志里拒绝原因是不是 Host、Origin 或 Sec-WebSocket-Protocol 不匹配（如果业务用了子协议，Nginx 还要透传 Sec-WebSocket-Protocol，不能丢）。502 优先查后端可达性与超时：先确认 127.0.0.1:8080 本机端口确实在监听、后端进程没挂；再看 Nginx error_log 里是 connection refused、timeout 还是 upstream prematurely closed。WebSocket 是长连接，默认的 proxy_read_timeout 60 秒很容易在空闲时断连，建议放开：proxy_read_timeout 3600s;proxy_send_timeout 3600s;另外注意 proxy_pass 的斜杠语义：proxy_pass http://127.0.0.1:8080;（无 URI 部分）会原样转发 /ws/ 路径，如果后端只认根路径不认 /ws/ 前缀，路径不对也可能被后端拒绝，核对一下后端实际监听的路径。5. 确认 Upgrade 头有没有被改写或丢掉的办法只看 Nginx error_log 不够，建议三处对照：（1）curl 复现握手，看状态码是不是 101：curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==" http://你的域名/ws/（2）在 Nginx 日志格式里加上 $http_upgrade、$http_connection、$upstream_status、$upstream_addr，复现一次就知道 Nginx 收到和转发的头分别是什么。（3）后端侧对照：看后端接入日志收到的 Upgrade、Connection、Host；还可以在本机抓包 tcpdump -i lo -A port 8080，看实际到达后端的请求头有没有被改写。建议的动手顺序：先 nginx -T 确认生效配置并 reload；再 curl 复现并区分 400/502；先补 Host 三行头，再放开两个超时；最后用日志加抓包确认后端收到的头与浏览器发出的头一致。改完每次先 nginx -t 再 reload，确认无报错再复测。

先说结论：你贴的这段配置方向是对的，Upgrade、Connection、proxy_http_version 1.1 三件套都齐了，所以 400/502 大概率不是缺这一对头，而是缺 Host 与真实 IP 头、长连接超时没放开，或者实际生效的配置与你看的不是同一份。按下面顺序排查，改一处、验证一处。 1. Upgrade 和 Connection 必须成对出现WebSocket 握手是 HTTP 升级机制：客户端发 Upgrade: websocket，Nginx 必须原样把 Upgrade 转给后端，同时把 Connection 置为 upgrade，后端才回 101 Switching Protocols。只写 Upgrade 不写 Connection，后端会当成普通 HTTP 请求处理，多半直接 400；只写 Connection 不写 Upgrade，后端收不到升级意图，同样握手失败。更稳妥的写法是用 map，避免非 WebSocket 请求也被硬改 Connection：map $http_upgrade $connection_upgrade {    default upgrade;    '' close;}location 里写 proxy_set_header Connection $connection_upgrade; 这样普通请求走 close，握手请求走 upgrade，互不干扰。 2. Host、X-Real-IP、X-Forwarded-For 缺失的影响这三行建议都补上：proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;Host 缺失最容易出 400：很多后端按 Host 做虚拟主机或 Origin 校验，收到的 Host 是 127.0.0.1:8080 就直接拒绝，而直连时 Host 正常，所以绕过 Nginx 反而能通。X-Real-IP 与 X-Forwarded-For 缺失一般只影响日志和限流统计，不会直接导致 400，但排障时没有真实 IP 会很难定位，仍建议补齐。 3. proxy_http_version 1.1 是必须的Nginx 默认 proxy_http_version 是 1.0，而 HTTP/1.0 不支持 Upgrade 升级语义，握手会在“发了升级请求、后端却不认升级”这一步卡住，表现为 400 或连接直接断开。你已写了 1.1，这一点没问题，但要确认它真的生效：执行 nginx -T 看最终合并后的配置，确认没有其他 location 或正则 location 覆盖了 /ws/，也确认改完是 reload 而不是只改了文件没生效。 4. 400 与 502 分开查400 优先查请求头转发：用下面第 5 点的方法确认后端实际收到的 Upgrade、Connection、Host 是否齐全，同时看后端日志里拒绝原因是不是 Host、Origin 或 Sec-WebSocket-Protocol 不匹配（如果业务用了子协议，Nginx 还要透传 Sec-WebSocket-Protocol，不能丢）。502 优先查后端可达性与超时：先确认 127.0.0.1:8080 本机端口确实在监听、后端进程没挂；再看 Nginx error_log 里是 connection refused、timeout 还是 upstream prematurely closed。WebSocket 是长连接，默认的 proxy_read_timeout 60 秒很容易在空闲时断连，建议放开：proxy_read_timeout 3600s;proxy_send_timeout 3600s;另外注意 proxy_pass 的斜杠语义：proxy_pass http://127.0.0.1:8080;（无 URI 部分）会原样转发 /ws/ 路径，如果后端只认根路径不认 /ws/ 前缀，路径不对也可能被后端拒绝，核对一下后端实际监听的路径。 5. 确认 Upgrade 头有没有被改写或丢掉的办法只看 Nginx error_log 不够，建议三处对照：（1）curl 复现握手，看状态码是不是 101：curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==" http://你的域名/ws/（2）在 Nginx 日志格式里加上 $http_upgrade、$http_connection、$upstream_status、$upstream_addr，复现一次就知道 Nginx 收到和转发的头分别是什么。（3）后端侧对照：看后端接入日志收到的 Upgrade、Connection、Host；还可以在本机抓包 tcpdump -i lo -A port 8080，看实际到达后端的请求头有没有被改写。建议的动手顺序：先 nginx -T 确认生效配置并 reload；再 curl 复现并区分 400/502；先补 Host 三行头，再放开两个超时；最后用日志加抓包确认后端收到的头与浏览器发出的头一致。改完每次先 nginx -t 再 reload，确认无报错再复测。

可以从三层来防误删： 1. 时间阈值留余量：别删“昨天”的，只删足够久以前的，比如 find /var/log -type f -mtime +7 ，正在写入的文件 mtime 会不断刷新，本身就很难落入 7 天前的范围；再加 -name 限定日志后缀，避免扫到别的类型。 2. 排除被进程打开的文件：删除前用 lsof 或 fuser 过一遍候选清单，比如 find 出来的文件逐个用 fuser -s 判断，被打开的跳过不删；也可以先 find -print 生成清单人工看一眼，确认无误再删。 3. 先演练、再删除：第一次别直接上 -delete 或 -exec rm，先用 -print 看会删哪些；文件名可能含空格，配合 -print0 和 xargs -0 处理。更稳妥的做法是先 mv 到一个暂存目录，观察几天确认业务无影响后再真正删除；生产环境建议直接用 logrotate 做轮转，比手写 find 更稳。

先说结论：60 秒这个数字本身定位不了哪一层，别先调大 --max-time。用一次分段计时就能把 DNS、TCP、TLS、首字节四个阶段拆开，再按卡住的那一段往下查。 一、先跑分段计时，定位卡在哪一段curl -o /dev/null -s -w 'namelookup:%{time_namelookup}\nconnect:%{time_connect}\nappconnect:%{time_appconnect}\npretransfer:%{time_pretransfer}\nstarttransfer:%{time_starttransfer}\ntotal:%{time_total}\n' https://api.example.com/v1/data看相邻两项的差值：time_namelookup 大是 DNS 慢；time_connect 减 time_namelookup 大是 TCP 建连慢（到服务器的路由、防火墙、安全组、端口没放行都落在这里）；time_appconnect 减 time_connect 大是 TLS 握手慢；time_starttransfer 减 time_pretransfer 大是服务端处理慢或响应被中间设备挂起。你已经看到 Trying，说明 DNS 已解析、正在建连，重点看后面三段的差值。 二、如果卡在 TLS（time_appconnect 很大）先用 openssl 做对照，排除 curl 自身的问题：openssl s_client -connect api.example.com:443 -servername api.example.com看三点：证书链最后是否 Verify return code: 0 (ok)；服务端选的 TLS 版本和密码套件；不加 -servername 再试一次，看 SNI 缺失会不会导致握手失败或返回默认证书。再结合 curl -v 看握手停在哪一步：ClientHello 发出后一直等不到 ServerHello，优先怀疑中间设备拦截、TLS 版本或密码套件不匹配、SNI 对不上；能拿到 ServerHello 但卡在证书交换，则优先查证书链完整性（中间证书缺失时浏览器可能因缓存补齐而正常，curl 会直接卡住或报错）。 三、如果前面都很快、只有 time_starttransfer 大基本可以判定请求已到达服务端或被中间设备挂起了，本地回环正常只能说明后端本身没问题，重点查反代、网关、负载均衡这一段：服务端 access 日志里有没有这条请求、处理耗时多少；上游日志（网关、反代、负载均衡）有没有超时或重试记录；后端连接池、慢查询、上游超时配置。必要时在服务器上抓包，看服务端到底有没有回首字节，区分是“服务端算得慢”还是“响应在中间被丢了”。 四、浏览器能打开、curl 超时的对照排除浏览器和 curl 默认条件不一样，别直接比较结论。逐项做对照，每次只变一个变量：curl --http1.1 排除 HTTP/2 协商问题；-A 加一个浏览器 User-Agent、-H 补 Accept 等请求头，排除服务端或 WAF 按请求头限流、挂起；--noproxy '*' 以及检查并临时清空 http_proxy/https_proxy 环境变量，排除代理分流（浏览器可能走了系统代理而 curl 走了直连，或者反过来）；curl --resolve 把域名固定到一个 IP，排除 DNS 解析结果不一致。哪一项对照后恢复了，问题就在哪一项。 按这个顺序走一遍：分段计时定段，再对该段做 openssl 或日志对照，最后用请求头、HTTP 版本、代理三项排除浏览器与 curl 的环境差异，一般就能定位到具体一层，而不是笼统地调大超时。

df -h 显示还有约 20% 空间，写文件却报 No space left on device，这种情况一般不是数据块真的满了，按下面顺序查，前面两项最常见：1. 先查 inode 是否用完df 默认看的是数据块用量，inode 耗尽时 df -h 照样显示有空闲，但任何新建文件都会报错。命令：df -i，看根分区那一行的 IUse% 是不是已经 100%。常见来源：缓存目录、日志碎文件、邮件队列、/tmp 里堆积的海量小文件。定位：逐层统计文件数，找到小文件最多的目录再清理或归档。2. 查已删除但仍被进程占用的文件日志文件被 rm 删掉、但写日志的进程还开着句柄时，空间不会释放，df 也看不出来。命令：lsof | grep deleted（或 lsof +L1），看 SIZE/OFF 很大的那几行。处理：重启或 reload 持有该文件的进程；不方便重启时，可以直接截断：: > /proc/进程PID/fd/句柄号，空间立即释放。3. 排除文件系统保留块ext 系列文件系统默认给 root 预留 5% 的块，普通用户写到预留线也会报这个错。命令：tune2fs -l 根分区设备 | grep -i reserved。不过你 df 还有约 20% 空闲，明显大于 5%，这一项基本可以排除，了解即可；真要调整用 tune2fs -m 调小比例，非必要不建议动。4. 确认报错路径实际所在的挂载点报错是写某个具体目录时出现的，不要只盯着根分区。命令：df -h 实际写入的路径，看它到底落在哪个分区或挂载点，那个分区满了同样报这个错；容器里还要留意 overlay 上层目录所在的分区。5. 以上都排除了，再查配额和异常只读quota -u 用户名 或 repquota -a，看是否触发用户或组配额；dmesg | tail 看文件系统是否因报错被重新挂载为只读；云硬盘场景再确认底层存储池是否已满。结合你的情况（根盘还剩约 20%），优先查第 1、2 项，十有八九是 inode 用完，或者 deleted 文件占着不放。

df -h 显示还有约 20% 空间，写文件却报 No space left on device，这种情况一般不是数据块真的满了，按下面顺序查，前面两项最常见：1. 先查 inode 是否用完df 默认看的是数据块用量，inode 耗尽时 df -h 照样显示有空闲，但任何新建文件都会报错。命令：df -i，看根分区那一行的 IUse% 是不是已经 100%。常见来源：缓存目录、日志碎文件、邮件队列、/tmp 里堆积的海量小文件。定位：逐层统计文件数，找到小文件最多的目录再清理或归档。2. 查已删除但仍被进程占用的文件日志文件被 rm 删掉、但写日志的进程还开着句柄时，空间不会释放，df 也看不出来。命令：lsof | grep deleted（或 lsof +L1），看 SIZE/OFF 很大的那几行。处理：重启或 reload 持有该文件的进程；不方便重启时，可以直接截断：: > /proc/进程PID/fd/句柄号，空间立即释放。3. 排除文件系统保留块ext 系列文件系统默认给 root 预留 5% 的块，普通用户写到预留线也会报这个错。命令：tune2fs -l 根分区设备 | grep -i reserved。不过你 df 还有约 20% 空闲，明显大于 5%，这一项基本可以排除，了解即可；真要调整用 tune2fs -m 调小比例，非必要不建议动。4. 确认报错路径实际所在的挂载点报错是写某个具体目录时出现的，不要只盯着根分区。命令：df -h 实际写入的路径，看它到底落在哪个分区或挂载点，那个分区满了同样报这个错；容器里还要留意 overlay 上层目录所在的分区。5. 以上都排除了，再查配额和异常只读quota -u 用户名 或 repquota -a，看是否触发用户或组配额；dmesg | tail 看文件系统是否因报错被重新挂载为只读；云硬盘场景再确认底层存储池是否已满。结合你的情况（根盘还剩约 20%），优先查第 1、2 项，十有八九是 inode 用完，或者 deleted 文件占着不放。

建议按“先定性、再看完整性、最后比对传输”这个顺序查，不要先反复换解压参数试。 1. 先用 file 看文件到底是什么，再用 gzip -t 测完整性：file backup.tar.gz；gzip -t backup.tar.gz。先 file 是因为它能告诉你拿到手的文件到底是不是 gzip 包；如果先跑 gzip -t，只会得到报错，无法区分是格式不对还是文件损坏。 如果 file 显示 gzip compressed data，再看 gzip -t 是否通过；如果显示 POSIX tar archive，说明它实际是普通 tar 包，不要加 -z，先用 tar -tf backup.tar.gz 验证，再用 tar -xf 直接解包。如果显示 ASCII text、HTML 或 empty，说明文件已被替换或混入了文本内容，要先核对来源和传输环节，而不是继续解压。 2. 核对打包与解压的 -z 是否对应。-z 表示 gzip 压缩：打包用 tar -czf，解压才用 tar -xzf；如果实际文件没有压缩却用了 -z，或者反过来，就最容易报这个错。你补充的打包命令是 tar -czf backup.tar.gz /data/www，所以如果到手的文件确实是这次打包的结果，理论上应该是 gzip 包；一旦 file 显示不是 gzip，就要先确认是否拿错文件、是否后来被覆盖，而不是认定参数本身写错了。 3. 对比源端和目标端的大小与校验值，判断传输中是否截断或损坏。分别在两端执行 ls -lh backup.tar.gz 和 md5sum backup.tar.gz。文件大小看起来正常不能证明内容没变，大小或 md5 不一致，就说明传输中出了问题；即使你用的是普通文件拷贝，也要排除中间环节对二进制内容的改写，例如用了文本模式传输或保存的情况。 如果确认文件确实损坏，不要对着目标端这个损坏文件反复解压，先从源端重新打包并重新传输，传完再比对一次大小和 md5，确认一致后再解压。

建议按下面顺序排查，先区分是 timer 没触发，还是触发后 service 没跑成。 一、timer 本身是否启用与激活systemctl status 对应 timersystemctl list-timerssystemctl is-enabled 对应 timersystemctl is-active 对应 timer注意：只启用 service 不等于启用 timer，timer 必须单独启用并处于激活等待状态；改过单元文件后，要先执行 systemctl daemon-reload。 二、看下次触发时间与上次触发结果systemctl list-timers --all看 NEXT、LEFT、LAST、PASSED，确认下次触发时间是否符合预期。journalctl -u 对应 timerjournalctl -u 对应 servicetimer 日志主要看是否触发，service 日志才看脚本是否真正执行、退出码和报错。 三、service 单元本身的问题检查 ExecStart 路径是否正确、脚本是否有可执行权限，WorkingDirectory 是否与脚本依赖的相对路径一致，User/Group 是否对脚本和备份目录有读、写、执行权限。还要检查环境变量与 PATH：systemd 环境比交互 shell 干净，脚本里用到的命令和变量在 service 里未必存在，优先用绝对路径，或在单元里用 Environment 声明。 四、时间语义问题核对 OnCalendar 表达式，可用 systemd-analyze calendar 校验；核对系统时区，可用 timedatectl。Persistent=true 的作用是系统在触发时刻关机或休眠、恢复后补跑一次，不是无条件保证执行。AccuracySec 会让实际触发时间在一定窗口内浮动，不应把它当作“没触发”的唯一证据；同时确认触发时刻系统是否关机、休眠或时间被大幅调整。 五、依赖与冲突检查 After/Wants 等依赖关系，确认 timer 触发时依赖单元是否就绪；检查 Condition* 条件是否导致单元被跳过；还要看 service 是否启动失败后被抑制或反复失败，相关记录同样用 systemctl status 和 journalctl -u 对应 service 查看。 六、验证方法先手动跑一次对应 service：systemctl start 对应 service再用 journalctl -xe 或 journalctl -u 对应 service 看报错。如果手动能跑、定时不能跑，重点回到第三、第四步对照环境与时间差异；如果手动也跑不成，先修 service/脚本本身，再回头查 timer。

建议按下面这个顺序查，先分清是 timer 没触发，还是触发后脚本没跑成，这样最省时间。 一、 timer 本身有没有真正排上 systemctl list-timers --all 找到对应的 timer，看 NEXT 一栏是不是你预期的下个凌晨 2 点，再用 systemctl status 看它是不是 active，同时确认是不是 enabled——只启动一次和开机自启是两回事，重启后没 enable 就会丢。再核 OnCalendar 的写法和机器时区：很多云主机默认是 UTC，写 02:00 很可能不是你以为的北京时间，用 timedatectl 看时区，再用 systemd-analyze calendar 校验一下表达式到底算到哪一天几点。另外 Persistent 有没有开：如果机器在 2 点那会儿关机或重启，没开这个选项，错过的时间点就不会补跑，开了才会在恢复后补一次。 二、 timer 到底触发了哪个 servicetimer 和 service 的名字要能对应上，确认触发的是不是你写的 backup.service，别出现名字差一个字母、却查了另一个单元的情况。 systemctl status 看这个 service 的状态，再用 journalctl -u 查它最近一次的记录：timer 的日志只说明有没有到点触发，真正跑没跑、退出了没有、报了什么错，要看 service 的日志。如果 service 根本没有执行记录，问题还在 timer 一侧；如果有执行记录但很快退出，就往脚本和环境上查。 三、再查脚本本身能不能独立跑通 /opt/backup/backup.sh 的路径没写错、文件有可执行权限、第一行 shebang 指向的解释器确实存在，然后在终端里手动直接跑一次。手动能跑通，只说明脚本逻辑大体没问题，不代 service 环境下也能跑通。脚本里凡是相对路径、自己在终端里配好的变量，在 systemd 里都可能不存在，尽量把路径、输出目录都写成绝对路径；确实需要变量时，在 service 里用 Environment 写清楚，或者在 ExecStart 里用绝对路径调用解释器加脚本。 四、最后查手 timer 的环境差异这是“手动能跑、定时跑不了”最常见的原因systemd 给 service 的环境很干净，PATH 很短，工作目录默认也不是脚本所在目录，运行用户也可能和你手动测试时不一样。重点核 service 里的 User、WorkingDirectory，再确认这个用户对脚本和备份目录有没有读、写、执行权限；同时把脚本的输出重定向到一个固定日志文件或 journal 里，别让它悄悄失败、查无对证。改完 unit 文件后，记得 daemon-reload 再重新 enable 并启动 timer 验证。 总结一下排查顺序： timer 状态，再看 service 日志，然后手动跑一遍脚本，最后对照环境差异。多数情况在前两步就能看出是没触发、还是触发后失败，不用一上来就改脚本。先看对。动和表先确认用再看看对用先看

这种情况基本是子账号权限没给够，不是 FunctionGraph 本身坏了。FunctionGraph 控制台打开时要先查函数列表，子账号缺 functiongraph 的查询权限，就会空白或者提示暂无资源查询权限。可以按下面顺序处理： 1. 用主账号（或有 IAM 管理权限的账号）登录 IAM，给这个子账号所在的用户组授权。最省事的是直接加系统策略「FunctionGraph Administrator」；如果想按最小权限给，至少要有函数查询类权限：functiongraph:function:listFunctions、functiongraph:function:getFunction 等只读权限，列表查不到，后面的操作都无从谈起。2. 如果子账号是直接授权而不是通过用户组，检查一下策略是不是绑定在对的项目/区域上。FunctionGraph 是区域级资源，在控制台右上角切换到函数所在的区域（比如华北-北京四），区域不对也会看起来“什么都没有”。3. 授权后让子账号退出重新登录再进控制台，权限生效和缓存刷新都需要重新登录，改完立刻刷页面经常还是旧状态。4. 如果后面还要让函数访问 OBS、触发器等其他服务，那是另一层：要在 FunctionGraph 里给函数配委托（agency），让函数以委托身份去调别的服务，和子账号本身的登录权限是两回事，别混在一起排查。 可以先按 1、2、3 试，一般加完 FunctionGraph 的策略、切对区域、重新登录，列表就能出来了。