Incidents and maintenance reported on status page for travellings https://status.travellings.cn/ https://d1lppblt9t2x15.cloudfront.net/logos/007b657011bf5a62e6038402c02a49ef.png https://status.travellings.cn/ en https://status.travellings.cn/incident/1006248 Tue, 27 Jan 2026 13:03:00 -0000 https://status.travellings.cn/incident/1006248#06eb4002287441a655310e03ded966b9d675336ed529f042edc4ad20e221ecf8 Incident 该事故已解决 https://status.travellings.cn/incident/1006248 Tue, 27 Jan 2026 12:53:00 -0000 https://status.travellings.cn/incident/1006248#3da5eab10e0ce3b02acb251a0da13e27092333ff12aa968f345f289f3d7886f3 Incident 近期，开往项目遭遇了一次大规模、持续性的恶意网络攻击。目前，根据蓝易云与 Cloudflare 的监控数据显示，本轮攻击已经结束，相关服务已恢复正常。攻击期间，项目后端服务在蓝易云的安全防护下保持稳定，核心接口未受影响；项目官网原部署于腾讯云 EdgeOne，因遭受高强度攻击被清退，迁移至 Vercel 后再次遭遇封禁，目前已重新部署至 Cloudflare Pages。 根据防护平台统计，本轮攻击规模巨大：蓝易云累计识别并拦截了近 1 万个恶意 IP 地址，腾讯云 EdgeOne 在攻击期间被刷取约 12TB 异常流量。更为严重的是，2026 年 1 月 27 日晚，攻击者公然在项目 GitHub 仓库发布威胁言论，试图以持续攻击为手段胁迫项目团队满足其无理要求。 在威胁出现的第一时间，我们已通过国家授时中心认证的可信时间戳对全部威胁证据进行了司法级电子存证，以确保其法律效力。事件发生后，我们迅速整理完整证据材料，并于次日（1 月 28 日）前往公安机关尝试报案，但目前材料尚未被接收。 我们对攻击者破坏开源公益项目、滥用公共网络资源、公然践踏法律底线的行为予以最强烈的谴责。我们坚信，任何通过违法手段达成目的的企图都不会得逞。感谢所有用户在此期间的理解与耐心，也感谢社区朋友们的持续关注与支持。维护一个干净、开放、友好的网络环境需要大家共同努力，我们将继续坚守初心，依法维护项目与社区的合法权益。 https://status.travellings.cn/incident/1006249 Mon, 18 Aug 2025 13:03:00 -0000 https://status.travellings.cn/incident/1006249#25c80b74a51a8c9513f23d770c8fb80de75bbc8cd598f51bcefdb4ffe48e0c2f Incident 该事故已解决 https://status.travellings.cn/incident/1006249 Mon, 18 Aug 2025 12:56:00 -0000 https://status.travellings.cn/incident/1006249#5f88d63041fb3fcf3cd2daa87a80a3f5ffccd166b558a6a02f92a7e82c92607b Incident 2025 年 8 月 14 日至 8 月 18 日，开往受到了 CC 攻击，开往的跳转功能几度不可用。本轮 CC 流量攻击规模大，EdgeOne 防护了 2.14 亿次 CC 攻击，Cloudflare 收到了七千五百多万次网络请求；攻击具有针对性，避开了有缓存的项目官网和成员列表，而攻击没有缓存且需要请求源服务器的后端接口；攻击来源广，国内和国外都有恶意流量。 在第一波攻击时，林林此前错误忘记关闭 EdgeOne 的「评估模式」，使攻击流量全部流入源服务器，后端接口服务崩溃。维护组原先认为这是一起来自外部的恶意攻击。之后，维护组查询了一些收集源站 IP 地址的数据库，比较了源服务器和 EdgeOne 的流量，确认源服务器的 IP 地址并未泄露。 此后，维护组将海外请求分流至 Cloudflare 进行防护，并对开往成员数据进行热备份。由于最开始的热备份采用 GitHub Actions 从后端接口拉取数据的方法，为了避免 GitHub Actions 被 Cloudflare 拦截，维护组关闭了 Cloudflare 的 「自动程序攻击模式」。当晚，海外攻击流量便因该模式被关闭而绕过了 Cloudflare 的防护，后端接口服务受到了第二波攻击，再次崩溃。 Xuanzhi 此前设计开发了一套容灾方案。即便开往的服务器宕掉，访客也可以通过请求此前备份的成员数据正常使用跳转，访问成员列表。对于开往成员和访客来说，流量攻击几乎没影响到功能的使用。后来发现，攻击流量总能绕过 EdgeOne 和 Cloudflare 致命打击源服务器使其宕机。在一波攻击结束后，维护组不再重启服务。 8 月 18 日，林林在个人邮箱中发现了名为 just intime 的用户于 8 月 16 日发送的邮件。发信人自称是开往项目的早期成员，站点曾通过审核，指控开往维护组某审核人员（发信人未指出）因个人问题错误移除了他的站点，澄清问题后站点未被恢复，反而被追加新理由。他在表达对项目赞赏的同时，声明因不满「被误会和不友好的沟通」而发起网络攻击（CC/DDoS）。8 月 19 日凌晨，just intime 发信承诺不会再发动新的攻击，并为开往加入申请的审核提出建议。 本次攻击暴露出了开往服务的脆弱，但在客观上提升了开往解决流量攻击问题的能力。 https://status.travellings.cn/incident/1006253 Sat, 19 Jul 2025 13:01:00 -0000 https://status.travellings.cn/incident/1006253#a80f8957815f0bb2462904b4ec5a76676eb5d29d270bf87ac3773bd346606916 Incident 该事故已解决 https://status.travellings.cn/incident/1006253 Sat, 19 Jul 2025 12:58:00 -0000 https://status.travellings.cn/incident/1006253#21c8f4b1d59ec97e40695e83a4ec226a7113000427712266a41c3b886c8a05f2 Incident 7月19日（星期六）北京时间晚9点49分许，维护组成员 Kegongteng 误删开往主仓库。结合示意图与相关信息，可见当事人当天较晚进行操作，注意力不集中，并未认真输入确认仓库名并查看系统提示（仓库路径仅所属不同，仓库名相同，路径较为类似），而通过复制进行验证。此外，开往在事故发生前并未做好仓库保护与权限划分。 在事故发生后第一时间，当事人通过维护组群聊告知其他成员，但受限于一些因素，维护组没有办法自助恢复仓库。随后，维护组向 GitHub 提交了关于恢复仓库的工单。在事故处理的过程中，考虑到恢复Repo可能需要订阅按席位进行计费的 GitHub Team（实际并没有用到），为减少可能支付的费用，我们将维护组里的大部分人员移除组织，在事故解决之后得以恢复。事故解决后，开往仓库限制所有成员删除仓库分支，开往组织规定只有组织 Owner 才有权删除或转移组织仓库。