Embykeeper

Appearance

常见问题 ​

Docker 镜像下载非常慢怎么办? ​

这一般在国内下载镜像时出现, 有两种策略:

  1. 使用 Docker 镜像: 教程
  2. 使 Docker Daemon 使用代理: 教程

我使用的平台是群晖等低内存平台, 可以使用吗? ​

Embykeeper 需要运行内存为 100-300 MB, 这是因为运行过程中, 部分 Bot 签到需要进行验证码识别. 如果您在运行过程中有内存不足的情况, 请适当调高您的虚拟内存.

如果依然无法使用, 请考虑使用 🪐 在线部署.

我使用 Docker 面板, 后台日志显示很混乱 / 有 ANSI 颜色字符 / 日志重复两遍, 怎么办? ​

请使用命令行参数 -CL 以启用简化日志+无颜色日志:

bash
docker run -v $(pwd)/embykeeper:/app --rm -it --net=host embykeeper/embykeeper -i -CL

如果您使用 docker-compose, 请使用:

yml
version: '3'
services:
  embykeeper:
    container_name: embykeeper
    image: embykeeper/embykeeper
    command: '-CL'
    restart: unless-stopped
    volumes:
      - ./embykeeper:/app
    network_mode: host

如果您使用源码构建请使用:

bash
embykeeper config.toml -CL

Emby 保活时, 经常出现 "无法获取视频长度", 重试乃至失败怎么办? ​

这说明该 Emby 站点很有可能是通过 Onedrive 直链等方法接入的, 大部分或所有视频都没有时长信息.

你可以开启 allow_stream 参数 (见教程) 以允许播放这类视频.

提示

出于安全考虑, 在 allow_multiple 时 (默认设置), 每个这类视频默认最多播放 8-12 分钟, 以防止设置超过视频实际时长的进度.

可不可以自定义... ​

大量的自定义内容均通过配置文件实现: 教程

例如:

  • 自定义启用的站点: 教程
  • 自定义 Emby 站点的 User-Agent: 教程
  • 自定义某些站点的自定义项: 教程

如果有其他您需要自定义的项目, 请通过交流群或高级用户群反馈, 您也可以通过爱发电购买私享定制服务.

运行时出现了错误, 怎么解决? ​

首先, 请检查您的错误是否与以下有关:

  1. 更新控制器错误.
  2. Connection reset by peer.
  3. ConnectionError.

以上均为网络波动或国际网络不通导致的问题, 请优化您的网络环境.

其他问题请反馈, 谢谢您的支持.

如何反馈? ​

首先, 请使用左上角的搜索, 搜索相关问题, 您可以参照右侧菜单寻找相关的解决方案, 这通常可以解答大部分的疑问, 且更加便捷.

若您的疑问没有得到解答, 您可以通过讨论群和高级用户讨论群进行反馈, 其中高级用户讨论群仅限高级用户加入, 且有开发者比较及时的响应.

如果您发现一个程序上的错误或问题, 您也可以通过 Github Issues 进行反馈.

在 Telegram 群组讨论, 是否有被认出的风险? ​

我们的相关讨论组(交流群或高级用户群)均实现了完全匿名.

匿名群组实际上是一个机器人, 发送的消息会被广播给所有其他用户, 从而实现群聊的效果. 同时在这个过程中您的所有个人信息 (包括 头像 / 用户名 / 手机号 / 输入状态 / 在线状态 等) 均会被隐藏, 您将以一个 emoji 作为面具作为身份代号. 所以在这种群组中聊天是绝对安全的.

但是, 您需要注意不要在截图/反馈信息中带有个人隐私 (包括手机号 / Telegram UID / 用户名) 等, 若您需要发送这些信息给开发者, 高级用户请直接发送到 PMBot, 其他用户请使用马赛克遮挡并发送到 Github Issues, 谢谢.

Telegram 被登出或封禁 ​

若您的账号存在安全风险时, 包括但不限于以下情况, 有小概率可能导致在使用时被登出, 或在所有设备被登出:

  1. 使用 +86 手机号
  2. 在多个地区的 IP 地址快速切换, 例如服务器部署位置的 IP 和手机使用代理访问的 IP 位置非常不同.
  3. 账号刚刚注册.
  4. 账号使用的是虚拟号码 (VoIP) 注册.

请注意, 满足这些条件也一般不会导致风控或封禁. 但是, 当您出现登出问题时, 从以上角度排查可能是一个好的方向.

同时, 如果您使用的是虚拟号码 (VoIP) 注册, 尤其是注册后无法再次访问号码的情况, 建议您参考 如何将 Telegram 绑定邮箱, 并开启两步验证, 避免一旦出现风控, 所有设备被登出, 无法再次登陆的情况.

我们发现对于风控的情况, 如果您被登出, 您可能在 0-48 小时内被限制登陆.

虽然目前为止没有收到任何使用该工具导致封禁的报告, 我们也已经对程序进行了非常合理的速率和风险控制, 我们依然无法保证不会导致封禁, 也不对这些问题负责.

Telegram 被登出其实与 Telegram 的非公开的 API 风控政策有关, 我们在常用的 Telegram 程序库 Telethon 和 Pyrogram 中都发现了相关的反馈. 在这里可以引用这两个伟大的工具库的作者的话:

Telethon:

首先，这不仅仅是本工具的问题。任何第三方库都可能导致帐户显示被封禁。 即使是官方应用程序在某些情况下也可能导致 Telegram 封禁帐户。像 Telethon 这样的第三方库使用起来非常简单，因此它们被滥用来发送垃圾信息，这的确可能导致 Telegram 识别某些模式并禁止可疑活动。但是，你也可能来自一个有限制的国家，或虚拟 (VoIP) 电话号码。在这种情况下，我们有一个坏消息要告诉你。Telegram 更有可能封禁这些号码，因为它们经常被用来对其他账户进行垃圾邮件攻击，且非常可能是通过类似这样的库。我们给你的最佳建议是，不要滥用 API，比如非常快速地发送大量请求。通常建议只在成熟的账户上使用这个库（而不是你刚创建的账户），并且不要执行可能被视为滥用的操作。Telegram 决定哪些操作属于此类操作，并且他们可以随时更改其运作方式。

Pyrogram:

我们的工具中，没有任何错误会导致您的帐户立即消失。人们应该明白，Telegram 有反垃圾邮件保护系统来防止滥用和垃圾信息，当然我们不知道它们究竟是如何工作的。我们知道的是，我们与 Telegram 分享的所有内容都可用于检测可能的垃圾邮件来源：虚拟/廉价电话号码、IP 地址（来自 Telegram 发现流量很大的国家/地区）以及泄露的第三方 API 密钥。

历史事件

2024 年 12 月左右, 出现了大量反馈登陆后立刻被登出的案例.

  1. 无法复现: 由于我们一直无法复现, 能正常使用. 我们注册了一个新账号, 也没有出现这种现象.

    因此, 我们先提醒用户自行排查注册的手机号是否为虚拟手机号等风险内容, 但是后续出现了看起来非常正常低风险的案例, 所以我们进一步对程序进行了排查.

  2. 初步判断: 由于我们没有改动任何关于登陆部分的代码, 我们首先怀疑程序某处有循环的请求.

    但是, 简单思考立刻排除了嫌疑:

    1. 请求超限情况下, Telegram 会返回 FloodWait, 程序会等待 (pyrogram 的自带功能), 而不会导致风控.
    2. 有用户还没有开始使用, 刚登陆就被登出, 说明并非程序其他部分的问题.
    3. 我们进行了若干次更新, 以极其保守的方式发送请求, 依然没有缓解.

  3. 进一步挖掘: 我们对我们使用的库 pyrogram 进行相关问题分析, 发现了大量反馈, 同时其他库 (telethon) 也有类似的反馈.

    相关问题记录在: Github Issue 中.

  4. 问题解决: 我们采用了两种方法双管齐下, 最终解决了这个问题.

    1. 有用户反馈, 使用一个特定的 system_version 作为请求参数登陆, 可以缓解这一现象, 且被大量认可.

      我们采纳了这个方法 (虽然该方法被认为原因和机制不明), 情况有所缓解.

    2. 有用户反馈, 使用 telethon 进行首次登陆, 并将 session_string 转换为 pyrogram 格式, 进行登陆, 可以解决这个问题.

      我们采纳了这个方法, 在首次登陆时候使用 telethon, 经多位用户反馈, 彻底解决了这个问题.

  5. 总结与思考: pyrogram 距离上一次更新已经一年多了, 在这段时间内 Telegram 的 API 可能发生了一定的变化, 导致 pyrogram 的请求相较于客户端特征更加明显, 从而被 Telegram 服务器认定为风险.

Emby 服务器的模拟登陆模式是什么? ​

登陆过程会传递几个关键信息: device, device_id, useragent, client, user_id.

默认情况下:

  • device: 设备名, 自 v2.6.0 后保持不变, 自 v7.0.0 后转为带缓存生成的形式, 同一站点保持不变.
  • device_id: 设备码, 在同一设备上恒定不变, 且不随程序重启/程序更新/容器重建变化.
  • useragent: 模拟 Fileball/Filebar 发送的 UA, 并从几个 Fileball/Filebar 版本中选取一个.
  • client: 模拟 Fileball/Filebar 发送的 Client 字段, 并从几个 Fileball/Filebar 版本中选取一个.
  • client_version: 模拟 Fileball/Filebar 发送的 Version 字段, 并从几个 Fileball/Filebar 版本中选取一个.
  • user_id (已不再支持自定义): Fileball/Filebar 在进行首次登陆时, 会发送一个随机的 UUID 作为 UserID 字段.

根据我们在自建的 Emby 服务器和 Jellyfin 服务器中的测试中, 多次保活不会导致后台设备显示数量, 或设备 UUID 数量的上涨.

使用默认配置, 很难从后台的 Playback 信息中分辨是否为自动化保活. 目前的保活请求顺序和逻辑是根据 Fileball/Filebar 调制的, 不推荐另行抓包填入其他客户端的数据.

你可以查看源代码以更清晰地了解逻辑.

部分需要 Cloudflare (CF) 验证码的站点为什么签到失败? ​

部分需要验证码的服务 (未响, Nebula 等) 签到失败的原因可能包括:

  1. 您不是 SUPER 等级用户, 因此无法解析 CF 验证码. (您应该可以在日志看到相关信息)

  2. 服务端解析错误, 可能是验证码解析暂不可用, 请联系开发者. (您应该可以在日志看到相关信息)

  3. 非以上问题, 但是依然出错, 可能是因为您的网络风控等级较高, 即使远端解析了验证码, 依然无法通过 CF 的 IP 检查.

    (日志显示: "验证码识别后接口返回异常信息")

    若为这种情况, 则请尝试在在运行时候增加 -d 命令行参数, 并根据输出的网址, 在运行 Embykeeper 的设备中的浏览器打开, 解验证码并重新运行.

为什么我们不能直接在服务器端发送签到的请求?

我们的服务目前仅支持解析验证码后返回令牌, 您运行 Embykeeper 的设备再利用这个令牌向站点服务器发送请求, 因此可能出现由于网络风控等级较高而无法通过 CF 的 IP 检查.

您可能会问, 如果在我们解析验证码的服务器端发送签到的请求, 是否可以解决这个问题?

可惜的是, 我们无法为您代发送请求.

一方面，该请求参数可能包含您账户的信息，发送至我们的服务器不符合我们的安全要求.

另一方面，如果这么做，站点管理员可以通过请求的IP找到我们的服务器，进行批量封禁.

调试日志中, 每次都会显示 "登出账号", 是否反复登出会导致风控? ​

不, 这里的登出账号意思为 "停止监听来自该账号的更新", 等同于关闭 Telegram 应用, 并非实际登出账号, 也不会发送和登出相关的任何指令给 Telegram.

保活时出现错误: Unexpected JSON output... ​

这可能有几种情况:

  1. Error processing request (403): 没有设置 Emby 密码, 在某些 Emby 版本中可能出现错误.
  2. 网页数据, 类似 <!doctype html> 等开头的内容: 请手动打开 https://example.com/System/Info/Public, 检查出现了什么问题.

保活是否有和播放器软件一致的行为? ​

目前软件默认模拟 Fileball/Filebar 软件进行播放:

Fileball/Filebar 软件首次登陆时的 Emby 日志:

Info Server: http/1.1 POST http://‌‍‍example.com‌/emby/Users/AuthenticateByName. Source Ip: ‌‍1.1.1.1, Accept=*/*, Host=‌‍‍example.com‌, User-Agent=Fileball/1.3.30, Accept-Encoding=gzip, br, Accept-Language=zh-CN,zh-Hans;q=0.9, Content-Type=application/json, Content-Length=52, Cdn-Loop=cloudflare; loops=1, Cf-Connecting-Ip=1.1.1.1, Cf-Ipcountry=MU, Cf-Ray=123456-HKG, Cf-Visitor={"scheme":"https"}, X-Emby-Authorization=MediaBrowser Token=,Emby UserId=(每次登陆都会变),Client=Fileball,Device=ABC%E2%80%99s%20iPhone,DeviceId=(随设备变化),Version=1.3.30, X-Forwarded-For=‌‍1.1.1.1, X-Forwarded-Host=‌‍‍example.com‌, X-Forwarded-Port=443, X-Forwarded-Proto=https, X-Forwarded-Server=123456, X-Real-Ip=‌‍1.1.1.1
Info UserManager: Authentication request for user1 has succeeded.

Info SessionManager: Reissuing access token: (每次登陆不会变)
Info Server: http/1.1 Response 200 to ‌‍1.1.1.1. Time: 5ms. POST http://‌‍‍example.com‌/emby/Users/AuthenticateByName
Info App: Sqlite: 284 - automatic index on LastWatchedEpisodes(SeriesPresentationUniqueKey)

再次登陆并访问一个视频 (第二次登陆直接使用了Token):

Server: http/1.1 GET http://‌‍‍example.com/emby/Videos/1234/AdditionalParts?Fields=PrimaryImageAspectRatio,UserData,CanDelete&IncludeItemTypes=Playlist,BoxSet&Recursive=true&SortBy=SortName. Source Ip: ‌‍‍1.1.1.1, Accept=*/*, Host=‌‍‍example.com, User-Agent=Fileball/1.3.30, Accept-Encoding=gzip, br, Accept-Language=zh-CN,zh-Hans;q=0.9, Cdn-Loop=cloudflare; loops=1, Cf-Connecting-Ip=1.1.1.1, Cf-Ipcountry=MU, Cf-Ray=123456-HKG, Cf-Visitor={"scheme":"https"}, X-Emby-Authorization=MediaBrowser Token=(发送的 token),Emby UserId=(登陆时的UserId),Client=Fileball,Device=ABC%E2%80%99s%20iPhone,DeviceId=(随设备变化),Version=1.3.30, X-Emby-Token=(发送的 token), X-Forwarded-For=‌‍‌1.1.1.1, X-Forwarded-Host=‌‍‍example.com, X-Forwarded-Port=443, X-Forwarded-Proto=https, X-Forwarded-Server=123456, X-Real-Ip=1.1.1.1

开始播放视频:

Server: http/1.1 POST http://‌‍example.com‌/emby/Items/1234/PlaybackInfo?AutoOpenLiveStream=false&IsPlayback=false&MaxStreamingBitrate=42000000&MediaSourceId=84466298f4e9d5135dee212204bbed3b&StartTimeTicks=0&UserId=35e7a33dbf1445958b0719747d1111fe. Source Ip: ‌‍1.1.1.1, UserAgent: Fileball/1.3.30
(发送若干条)

Server: http/1.1 GET http://‌‍example.com‌/emby/videos/1234/original.mp4?DeviceId=(随设备变化)&MediaSourceId=84466298f4e9d5135dee212204bbed3b&PlaySessionId=02981190f6c44a02b3015b7bbd372511&api_key=‌52c91904f5ef4bae8cb075394a114e66‌. Source Ip: ‌‍‍1.1.1.1‌, Accept=*/*, Host=‌‍example.com‌, User-Agent=VLC/3.0.21 LibVLC/3.0.21, Accept-Encoding=gzip, br, Accept-Language=en_US, Cdn-Loop=cloudflare; loops=1, Cf-Connecting-Ip=1.1.1.1, Cf-Ipcountry=MU, Cf-Ray=123456-HKG, Cf-Visitor={"scheme":"https"}, X-Forwarded-For=‌‍‍1.1.1.1‌, X-Forwarded-Host=‌‍example.com‌, X-Forwarded-Port=443, X-Forwarded-Proto=https, X-Forwarded-Server=123456, X-Real-Ip=‌‍‍1.1.1.1‌
(发送若干条)

Server: http/1.1 POST http://‌‍example.com‌/emby/Sessions/Playing. Source Ip: 1.1.1.1‌, UserAgent: Fileball/1.3.30

Server: http/1.1 POST http://‌‍example.com‌/emby/Sessions/Playing/Progress. Source Ip: 1.1.1.1‌, UserAgent: Fileball/1.3.30
(发送若干条)

Server: http/1.1 POST http://‌‍example.com‌/emby/Sessions/Playing/Stopped. Source Ip: 1.1.1.1‌, UserAgent: Fileball/1.3.30

Embykeeper 已尽可能实现了相同的模拟播放日志.

Released under the GPLv3 License.

Copyright © 2023-2025