前两天我本地部署的 immich 发更新也提示说 redis 迁移到 valkey 了： https://github.com/immich-app/immich/releases/tag/v1.132.0

> We are now using Valkey's image for the Redis service in the default docker-compose.yml template. This is not a required change. If you wish to use it, you can download the docker-compose.yml file at the bottom of the release notes and replace the redis image with the new one.

当时看他们的描述还以为就是换了个 Redis 的 docker 提供商😂因为之前下载 Redis 的时候好像没有找到官方的二进制，所以以为只是换了个构建二进制的提供者。
然后今天就刷到这个了。看起来如果是 fork 出去准备单干的话，未来应该差异会越来越大吧，类似于 Blink 与 Webkit ？

@zhengmin451607 #6 截屏，切应用，扫码，选相册？

「不屏蔽首次请求，但首次请求之后会屏蔽一段时间的后续请求」
感觉和 GFW 刚开始屏蔽 Google 的行为很像。。。
检查了一下证书，貌似也不是某些可信的 CA 「误签发」了证书做测试。。
https://i.imgur.com/fiopSJD.png

@biglion666 #6 #8 TLP intentionally excludes some settings from the project, notably Fan speed control and Backlight.

写个脚本自动定时 commit --amend 并 push 。
一部分写完，就手动 commit 一次。
后续定时脚本 commit --amend 的时候就会追加到新的 commit 里去。
版本控制也有了，commit 历史也挺清楚。

建议 TRACE 一下规则，看看匹配的对不对

prerouting 链，匹配 TCP/UDP 的源地址是容器的网段，转发到旁路由

有确认单个复现用户的日志吗？
因为有些请求是客户端重复操作，后一个请求发起时主动中断了前一个请求，对实际用户来说可能没感知，对服务端来说就是一个请求在没来得及发响应的时候就中断了，报个异常日志。
如果是这个情况的话，那么现象通常是出现中断异常后同一个客户端会在几毫秒内再次发起请求，请求的资源相同，参数可能相同也可能近似（取决于服务类型），出现的次数一般同一个用户不会在一秒内连续出现多次。

回到楼主的问题，加上截图的日志，感觉像是客户端重复请求这个 Progress 接口，有点符合我说的这个特征？
排查的话，可能针对复现的单个用户，跟踪复现时间点前后一段时间的日志，看看特征。

@GuoJikun 其实不用删 fork ，只要迁一个新分支出来，reset 到原仓库的提交，然后把要 PR 的改动 cherry pick 过来就行。
不过最简单的还是在一开始就在新分支开发，原分支仅用于跟踪远程，还可以随时把原仓库的更新 merge 到自己的分支上。

@bclerdx #16 在手机内置 DNS 改不了的情况下，Wi-Fi 可以在路由器上直接拦截指定 IP 、重定向到其他 DNS 服务。
流量怎么劫持到路由器上？

@chairuosen #13 路由器只能劫持 Wi-Fi 的，流量就没办法了

看着貌似 5.180.253.215 的端口一直是 28000 不变，而 37.114.49.176 的端口一直在变。
sudo lsof -Pi | grep 28000
看看呢？看看本地是不是有这么个进程？

用户的网络情况可能是很复杂的，即便是在没有防火墙的国家，也可能会遇到比如连接了需要登录的 Wi-Fi 之类的情况，所有域名解析都会被拦截并跳转到 Wi-Fi 登录页面，所以 ping 、tcp ping 、普通 http 请求都是不可靠的。

所以 #12/#14 正解，但是服务器竞速比较常用的方法是提供一个 http 的 /generate_204 接口（/generate_204 属于事实上的标准，虽然没有定义标准，但大部分网站选择遵守），这个接口没有任何逻辑，仅返回 HTTP 状态码 204 ，且没有 body 。业务需要判断接口返回的状态码是 204 而非其他。
在 /generate_204 正常返回之前，都属于网络未连接的状态，应当以一定时间间隔（通常时间间隔越来越大）重试，直到最先返回的就是最快的。后续定期检查更新网络状态。