Cloudflare Tunnel链接错误排查

一大早Cloudflare Tunnel忽然坏掉了。 修复结论:除了检查QUIC协议是否被屏蔽之外,也查一下本机时间同步。

T00:33:53Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.18.0.134 
2026-01-06T00:33:54Z WRN If this log occurs persistently, and cloudflared is unable to connect to Cloudflare Network with `quic` protocol, then most likely your machine/network is getting its egress UDP to port 7844 (or others) blocked or dropped. Make sure to allow egress connectivity as per https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/ports-and-ips/ If you are using private routing to this Tunnel, then ICMP, UDP (and Private DNS Resolution) will not work unless your cloudflared can connect with Cloudflare Network with `quic`. connIndex=0 event=0 ip=198.18.0.134 
2026-01-06T00:33:54Z INF Switching to fallback protocol http2 connIndex=0 event=0 ip=198.18.0.134 
2026-01-06T00:35:52Z ERR Serve tunnel error error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.0.134 2026-01-06T00:35:52Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.18.0.134 2026-01-06T00:36:17Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.4.32 2026-01-06T00:36:17Z ERR Serve tunnel error error="TLS handshake with edge error: EOF" 
connIndex=0 event=0 ip=198.18.4.32 2026-01-06T00:36:17Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.18.4.32

最先想到的是服务商突然屏蔽了QUIC 协议(基于 UDP 端口 7844),准备开始查资料看能否代理。 后来检查中,发现windows时间同步是三天前,手工同步time.windows.com一直失败。 再后来,发现是之前一次代理规则调整不当,造成了时间同步失败。之后本地时间不准确,造成TLS handshake失败。

查看日志处理Synology Drive Client文章同步失败

同步客户端里,有文件一直是preparing,准备中的状态。但是在窗口里看不到这个文件的具体路径。

第一步:找到这些文件的具体路径

既然文件名很普通,无法通过全盘搜索定位,需要通过 Synology Drive Client 的日志查找

  1. 按下 Win + R 键,打开运行窗口。
  2. 输入 %localappdata%\SynologyDrive\log 并回车。
  3. 你会看到一堆日志文件。找到 daemon.log (或者 service.log,通常是 daemon.log 记录同步核心进程)。
  4. 用记事本或 VS Code 打开它。
  5. 使用查找功能(Ctrl+F),搜索你在界面上看到的那个文件名
  6. 你应该能搜到类似 [ERROR] worker.cpp... /Volume/Path/To/File.jpg 这样的记录,这里面就会包含完整的绝对路径。

继续阅读查看日志处理Synology Drive Client文章同步失败

修复React2Shell漏洞导致服务器权限泄露 之二

参考这篇分析报告,重新做一轮检查修复 https://www.huntress.com/blog/peerblight-linux-backdoor-exploits-react2shell

核心相似点:

  1. 伪装系统文件: 文章提到恶意软件会将自己伪装成看似合法的系统进程。你遇到的 /bin/systemd-daemon 正是这种典型手段(真正的 systemd 不在这个位置,也不叫这个名字)。
  2. 持久化机制: 利用 Systemd 服务(Service)进行驻留,确保杀不死、重启自愈。
  3. 行为模式: 作为“加载器(Dropper)”,定期从 C2 服务器(你的案例中是 185.196.9.41)下载并执行新的恶意脚本(um2)。

既然暂时不能重装系统,我们需要制定一个“外科手术式” 的深度清理方案。请务必按照以下步骤,一次性、连贯地执行,不要中断,以防病毒利用时间差复活。

继续阅读修复React2Shell漏洞导致服务器权限泄露 之二

OpenClash 深入解析:架构与原理 – 系列之一

本系列介绍clash,特别是在openwrt中安装的openclash程序的内在结构。在实际使用过程中,软件里有大量选项,需要了解他们的实际功能。

要真正理解 OpenClash 里的那些繁杂选项,我们确实不能只看表面,而必须深入到它的架构设计数据流向中去。

简而言之,OpenClash 本质上是一个运行在 OpenWrt 上的“管家”(由 Lua 脚本和 Shell 脚本组成),它指挥着一个核心引擎——Clash(由 Go 语言编写的二进制文件)。你在界面上看到的每一个复选框,最终都会转化成 Clash 核心的一行配置,或者是 OpenWrt 防火墙(iptables/nftables)的一条规则。 继续阅读OpenClash 深入解析:架构与原理 – 系列之一