2025 年 08 月第二次更新：网络流量攻击、维护组人员变动

网络流量攻击

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 发信承诺不会再发动新的攻击，并为开往加入申请的审核提出建议。

本次攻击暴露出了开往服务的脆弱，但在客观上提升了开往解决流量攻击问题的能力。

维护组人员变动

今年五月份，开往维护组遵循项目运维规定公开了招募计划。Lee 在林林的引导下加入了开往维护组，并按照新成员加入流程参与组内事务，目前参与内部工具的开发工作。