KwToPA

> > emmm之前我也有一次抓取不到，我没有注意当时的报错情况是不是400，登录推特看是每日浏览帖子的数量达到上限了，需要开会员 > > 但是我网页版和app版推特都是能正常使用的 试试网页版退出登录，把x的抓取频率设置成4小时一次，等半小时后重新登录再次获取新的cookie，然后恢复rss的抓取频率，并用新cookies拉rss

@freakojc 不是你设置路由的抓取频率导致的。 应该是X的服务器问题，他们服务器挂了或者维护都会到这本机的RSS故障，例如token失效或者别的报错 只能靠手动重新登录刷新cookie来更新路由

token is not valid必须刷新，其他报错可以等等，有机会恢复

这边的问题是，X的服务器修复了，网页端的x账号不会被踢出登录或者有别的异常，只有rsshub的路由等了 明明token都不变。

@AiraNadih 你的意思是x修复了服务器问题，RSSHUB会在自己的token锁定期 24h后（ https://github.com/DIYgod/RSSHub/issues/17580 ） 正常工作？ 就会用chrome浏览器自动恢复一样？还是说要手动重新启动rsshub 如果把这个锁定期改成30分钟，是不是也能生效？ 根据你这边的测试应该可以实现 https://github.com/DIYgod/RSSHub/issues/17580#issuecomment-2482423072 我是手动刷新token 我用docker装得rsshub https://github.com/DIYgod/RSSHub/blob/091ed089301b942b916807f081e2316a9d04c125/lib/routes/twitter/api/web-api/utils.ts#L206 这行能不能手动改？ 还是必须等官方的image？

@AiraNadih 我的脚本是 ``` cd /1 docker pull diygod/rsshub:latest; docker run -d --name rsshub ... diygod/rsshub:latest ``` 则可以通过添加新的运行参数来覆盖文件：```-v /1/utils.ts:/app/lib/routes/twitter/web-api/utils.ts``` AI说 /app/lib/routes/twitter/web-api/utils.ts：这是容器内部的绝对路径。 当容器启动时，Docker 会将宿主机上的 ./utils.ts 文件“映射”或“挂载”到容器内的这个指定路径。 是的，如果容器镜像的这个路径下原本有一个 utils.ts 文件，那么宿主机上的这个文件将会覆盖（或者更准确地说，是“遮蔽”或“隐藏”）容器镜像中原有的文件。 容器内的应用程序在访问 /app/lib/routes/twitter/web-api/utils.ts 时，实际读取和使用的是你本地的...

好像有效，我用这个命令之后，用docker exec -it rsshub /bin/sh 进去查看 cat /app/lib/routes/twitter/web-api/utils.ts | grep await 确实用1800覆盖86400了 等碰到故障我在测试

经测试有效， 需要一个监控脚本 让AI写了一个，等待测试 ``` #!/bin/bash # ========================================================================= # = 日志看门狗脚本 (结合1秒锁 + 预重启延时10秒的最终方案) = # ========================================================================= # --- 配置区域 --- # 1. 要监控的Docker容器的名字 CONTAINER_NAME="rsshub" # 2. 触发重启的关键错误关键词 (使用 | 作为“或”逻辑分隔)...

有效果，把86400改成1，1秒钟。然后用上面的监控脚本监控，参数ERROR_THRESHOLD 根据本地状况自己决定，把监控脚本放到开机启动中，crontab 每周一次echo > /var/log/rsshub_watchdog.log

@AiraNadih 感谢老哥，我改成100秒锁定再搭配 这个脚本 发现1秒锁定导致内存溢出了