突然无法显示 X 博主的帖子信息

[3210448723]

路由地址

/twitter/user/:id/:routeParams?

完整路由地址

/twitter/user/liangxihuigui

相关文档

https://docs.rsshub.app/routes/social-media#user-timeline-5

预期是什么？

能够成功获取 Twitter 用户的帖子数据，并生成 RSS 订阅源。

实际发生了什么？

RSSHub 无法获取 Twitter 用户的帖子数据，只能显示用户名和用户自述。
我使用的是正确的，没有过期的TWITTER_AUTH_TOKEN，并且是最新docker版本的RSSHub，用了几天就出现了这样的问题（两台不同ip的服务器都出现了，重新登录推特刷新auth_token问题还是出现），同时在复现https://github.com/DIYgod/RSSHub/issues/16533issue时，报错：ConfigNotFoundError: Twitter cookie for token d4b24e28******************************** is not valid。

部署

自建

部署相关信息

docker image: sha256:c6a6a7e8c24bbf422ef536476f29bb0e09d645ae24f201757dfd4be63174bff2

额外信息

日志

> [email protected] start
> cross-env NODE_ENV=production node dist/index.js

�[32minfo�[39m: 🎉 RSSHub is running on port 1200! Cheers!
�[32minfo�[39m: 🔗 Local: 👉 http://localhost:1200
�[32minfo�[39m: 🔗 Network: 👉 http://172.20.0.4:1200
�[32minfo�[39m: 🔗 Network: 👉 http://[::]:1200
�[32minfo�[39m: Redis connected.
�[32minfo�[39m: <-- GET /twitter/user/formnoshape
�[32minfo�[39m: --> GET /twitter/user/formnoshape �[36m304�[0m 1s
�[32minfo�[39m: <-- GET /twitter/user/liangxihuigui
�[33mwarn�[39m: Request https://x.com with error 400 remaining retry attempts: 2
�[33mwarn�[39m: Request https://x.com with error 400 remaining retry attempts: 1
�[31merror�[39m: undefined


xml

<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
<channel>
<title>Twitter @凉兮大元帅（白虎）</title>
<link>https://x.com/liangxihuigui</link>
<atom:link href="http://ip:1200/twitter/user/liangxihuigui" rel="self" type="application/rss+xml"/>
<description>凉兮xxx - Powered by RSSHub</description>
<generator>RSSHub</generator>
<webMaster>[email protected] (RSSHub)</webMaster>
<language>en</language>
<image>
<url>https://pbs.twimg.com/profile_images/1908861280066420736/8nYRtT6q.jpg</url>
<title>Twitter @凉兮大元帅（白虎）</title>
<link>https://x.com/liangxihuigui</link>
</image>
<lastBuildDate>Tue, 27 May 2025 03:41:51 GMT</lastBuildDate>
<ttl>5</ttl>
</channel>
</rss>

这不是重复的 issue

• 我已经搜索了 现有 issue，以确保该错误尚未被报告。

[github-actions]

Searching for maintainers:

• /twitter/user/:id/:routeParams?: @DIYgod @yindaheng98 @Rongronggg9 @CaoMeiYouRen @pseudoyu

To maintainers: if you are not willing to be disturbed, list your username in scripts/workflow/test-issue/call-maintainer.js. In this way, your username will be wrapped in an inline code block when tagged so you will not be notified.

If all routes can not be found, the issue will be closed automatically. Please use NOROUTE for a route-irrelevant issue or leave a comment if it is a mistake.
如果所有路由都无法匹配，issue 将会被自动关闭。如果 issue 和路由无关，请使用 NOROUTE 关键词，或者留下评论。我们会重新审核。

[ivanwongtf]

I encountered the same issue, it happens since today.

[flameleaf]

The TWITTER_USERNAME, TWITTER_PASSWORD and TWITTER_PHONE_OR_EMAIL auth method works on my end.

[HikasaHana]

我也遇到了，之前还能通过重新拉取rsshub暂时解决，今天怎么也不起作用。我是用的TWITTER_AUTH_TOKEN。
刚测试了下用户名密码的方法，确实可以正常使用。

[3210448723]

我也遇到了，之前还能通过重新拉取rsshub暂时解决，今天怎么也不起作用。我是用的TWITTER_AUTH_TOKEN。 刚测试了下用户名密码的方法，确实可以正常使用。

我刚刚换成账号名和密码重新部署还是一样的不行，但是测试了几个之前没有调用过的推特rss账号时一切正常。然后我又换回了TWITTER_AUTH_TOKEN（没有重新登录推特），这时候又都正常了，很奇怪

[HikasaHana]

emmm之前我也有一次抓取不到，我没有注意当时的报错情况是不是400，登录推特看是每日浏览帖子的数量达到上限了，需要开会员

[3210448723]

emmm之前我也有一次抓取不到，我没有注意当时的报错情况是不是400，登录推特看是每日浏览帖子的数量达到上限了，需要开会员

但是我网页版和app版推特都是能正常使用的

[KwToPA]

emmm之前我也有一次抓取不到，我没有注意当时的报错情况是不是400，登录推特看是每日浏览帖子的数量达到上限了，需要开会员

但是我网页版和app版推特都是能正常使用的

试试网页版退出登录，把x的抓取频率设置成4小时一次，等半小时后重新登录再次获取新的cookie，然后恢复rss的抓取频率，并用新cookies拉rss

[freakojc]

emmm之前我也有一次抓取不到，我没有注意当时的报错情况是不是400，登录推特看是每日浏览帖子的数量达到上限了，需要开会员

但是我网页版和app版推特都是能正常使用的

试试网页版退出登录，把x的抓取频率设置成4小时一次，等半小时后重新登录再次获取新的cookie，然后恢复rss的抓取频率，并用新cookies拉rss

我也有这个问题
请问大佬，怎么设置抓取频率？用哪个参数？暂时只找到了缓存时间配置：

CACHE_EXPIRE: 路由缓存过期时间，单位为秒，默认 5 * 60
CACHE_CONTENT_EXPIRE: 内容缓存过期时间，每次访问会重新计算过期时间，单位为秒，默认 1 * 60 * 60

[KwToPA]

@freakojc

不是你设置路由的抓取频率导致的。 应该是X的服务器问题，他们服务器挂了或者维护都会到这本机的RSS故障，例如token失效或者别的报错

只能靠手动重新登录刷新cookie来更新路由

[KwToPA]

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

[KwToPA]

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

明明token都不变。

[AiraNadih]

@KwToPA 问题在于，RSSHub 当前遇到异常时会直接锁定 24 小时，导致路由在 1 天后才能恢复。
我之前在 #17580 中反馈过此问题，但似乎没有引起足够重视。

[KwToPA]

@AiraNadih 你的意思是x修复了服务器问题，RSSHUB会在自己的token锁定期 24h后（ #17580 ） 正常工作？ 就会用chrome浏览器自动恢复一样？还是说要手动重新启动rsshub

如果把这个锁定期改成30分钟，是不是也能生效？ 根据你这边的测试应该可以实现 #17580 (comment)

我是手动刷新token

我用docker装得rsshub

RSSHub/lib/routes/twitter/api/web-api/utils.ts

Line 206 in 091ed08

await cache.set(`${lockPrefix}${auth.token}`, '1', 86400);

这行能不能手动改？ 还是必须等官方的image？

[AiraNadih]

你的意思是x修复了服务器问题，RSSHUB会在自己的token锁定期 24h后（ #17580 ） 正常工作？ 就会用chrome浏览器自动恢复一样？还是说要手动重新启动rsshub

是的，意思是会自动恢复，但需要等待 token 解锁。

这行能不能手动改？ 还是必须等官方的image？

可以手动修改。如果你是通过 Docker Compose 部署的，可以通过配置 volumes 来覆盖文件：

volumes:
  - ./utils.ts:/app/lib/routes/twitter/web-api/utils.ts

如果使用 Docker，则可以通过添加新的运行参数来覆盖文件：-v ./utils.ts:/app/lib/routes/twitter/web-api/utils.ts

[KwToPA]

@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 时，实际读取和使用的是你本地的 ./utils.ts 文件。

查询对应镜像 https://hub.docker.com/layers/diygod/rsshub/latest/images/sha256-8f568d1b4e42af82623c6468ef7c4c647e80e13ceebab0f615e76049007f54bf

有个 WORKDIR /app，/app/lib/routes/twitter/web-api/utils.ts 这个路径应该没错

等下次x服务器挂了我测试下

[KwToPA]

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

等碰到故障我在测试

[KwToPA]

经测试有效， 需要一个监控脚本

让AI写了一个，等待测试

#!/bin/bash
# =========================================================================
# =          日志看门狗脚本 (结合1秒锁 + 预重启延时10秒的最终方案)          =
# =========================================================================

# --- 配置区域 ---

# 1. 要监控的Docker容器的名字
CONTAINER_NAME="rsshub"

# 2. 触发重启的关键错误关键词 (使用 | 作为“或”逻辑分隔)
#    - "is not valid": 捕获Token凭据配置错误。
#    - "403 Forbidden": 捕获认证失败或IP封锁。
#    - "503 Service Unavailable": 捕获持续的服务不可用错误。
#    - "No valid Twitter token found": 捕获Token池耗尽的最终错误。
ERROR_KEYWORDS_REGEX="is not valid|403 Forbidden|503 Service Unavailable|No valid Twitter token found"

# 3. 错误计数的阈值 (当检测到错误的次数达到此值时，触发重启)
ERROR_THRESHOLD=10

# 4. 你自己的重启脚本的路径 (强烈建议使用绝对路径)
#    ▼▼▼ 请将此路径修改为你 `rsup.sh` 脚本的实际存放位置 ▼▼▼
RESTART_SCRIPT="/path/to/your/rsup.sh"

# 5. 看门狗脚本自身的日志文件存放路径 (用于记录其行为)
#    ▼▼▼ 强烈建议使用绝对路径 ▼▼▼
WATCHDOG_LOG_FILE="/var/log/rsshub_watchdog.log"


# --- 脚本主逻辑 (从此以后无需修改) ---

# 使用 exec 命令将此脚本之后的所有输出(标准输出和标准错误)都追加到日志文件中
# 这样做的好处是，我们不再需要对每一个 echo 命令都进行 `>> logfile` 重定向
exec >> "$WATCHDOG_LOG_FILE" 2>&1

# 函数：用于记录带时间戳的日志，方便追溯
log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1"
}

log "✅ 日志看门狗脚本启动。"
log "   - 监控的容器名: $CONTAINER_NAME"
log "   - 触发重启的关键词 (正则表达式): '$ERROR_KEYWORDS_REGEX'"
log "   - 错误数量阈值: $ERROR_THRESHOLD 次"
log "   - 预重启延时: 10秒"

# 使用无限循环，确保脚本能持续不断地运行
while true; do
    # 在每一轮新的监控开始前，重置错误计数器
    error_count=0
    log "初始化新一轮监控，错误计数器已重置为 0。"

    # 检查目标容器是否正在运行，如果不在，则等待60秒后再次尝试
    if ! docker ps -q -f name="$CONTAINER_NAME" > /dev/null; then
        log "警告：容器 '$CONTAINER_NAME' 当前未运行。可能是正在重启或首次启动，将在60秒后重试..."
        sleep 60
        continue # 跳过本次循环的剩余部分，直接开始下一次循环
    fi

    log "已成功附加到容器 '$CONTAINER_NAME' 的日志流，开始监控..."
    # 核心管道逻辑：
    # 1. `docker logs -f` 持续不断地输出容器日志
    # 2. `grep -E` (扩展正则模式) 实时过滤出包含任何一个错误关键词的日志行
    # 3. `while read` 循环逐行读取这些被过滤出的错误日志，并进行处理
    docker logs -f --tail 50 "$CONTAINER_NAME" 2>&1 | grep -E --line-buffered "$ERROR_KEYWORDS_REGEX" | while IFS= read -r error_line; do
        # 每读取到一行错误日志，计数器就加1
        error_count=$((error_count + 1))
        
        log "检测到错误 #$error_count (阈值: $ERROR_THRESHOLD): $error_line"

        # 检查错误计数是否已经达到或超过了我们设定的阈值
        if [ "$error_count" -ge "$ERROR_THRESHOLD" ]; then
            log "‼️ 错误数量已达到阈值！准备执行重启操作。"
            
            # --- 这是你最新要求的修改点 ---
            log "根据要求，在执行重启前等待10秒钟..."
            sleep 10
            # --- 修改点结束 ---

            log "正在调用重启脚本 '$RESTART_SCRIPT' ..."
            bash "$RESTART_SCRIPT"
            
            log "重启脚本已执行。将暂停30秒，以便让容器有足够的时间完成重启..."
            sleep 30

            # 成功触发重启后，跳出当前的 `while read` 日志读取循环
            # 外层的 `while true` 会让脚本重新开始新一轮的监控
            break
        fi
    done
    
    # 如果 `docker logs` 命令中断 (通常是因为容器被停止或重启了)，程序会执行到这里
    log "日志流已断开。将在5秒后自动重新连接..."
    sleep 5
done

[KwToPA]

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

[AiraNadih]

@KwToPA 没有必要这么做。我已经创建了一个 PR，将它修改为 1 小时，而且已经合并了。

[KwToPA]

@AiraNadih 感谢老哥，我改成100秒锁定再搭配 这个脚本

发现1秒锁定导致内存溢出了