OpenFreeMap在过去10个月中表现优异，架构稳定，Cloudflare赞助带宽，Hetzner服务器和Btrfs文件系统表现良好。然而，突然出现大量请求导致nginx日志显示“Too many open files”错误，Cloudflare数据显示24小时内处理了30亿请求，系统成功应对了每秒10万次请求的挑战。

OpenFreeMap成功应对每秒10万次请求的挑战

在过去的10个月里，OpenFreeMap的表现非常出色。其架构经受住了考验，Cloudflare同意赞助带宽，Hetzner服务器一如既往地稳定，使用Btrfs提供地图瓦片被证明是一个明智的选择，nginx表现优异，一切都很顺利。

然而，突然之间，我收到了一些报告，称某些地图瓦片无法加载。通常情况下，这可能是瓦片生成的问题，但这次并非如此。我查看了nginx日志，发现了以下内容：

2025/08/08 23:08:16 [crit] 1084275#1084275: *161914910 open() "/mnt/ofm/planet-20250730_001001_pt/tiles/8/138/83.pbf" failed (24: Too many open files) ...

这很奇怪，我从未见过这种情况。我检查了nload，发现流量异常巨大。登录Cloudflare后，我看到过去24小时的流量数据：

30亿次请求！ 这到底是怎么回事？而且，215 TB的流量来自仅70 kB的小文件？这样的流量在MapTiler上每月将花费超过600万美元，而在Mapbox上则要翻倍。

特别是在过去的5分钟内，流量激增，达到了3000万次请求。这相当于每秒10万次请求！

我的第一反应是：

• 哇。

• 哇，我惊讶的是，唯一的问题只是某些瓦片缺失。服务似乎仍在正常运行？这些空瓦片被Cloudflare缓存了，但除此之外，服务似乎还在工作？

查看Cloudflare仪表盘，我发现96%的请求是200 OK，只有3.6%的请求是206 Partial Content。因此，OpenFreeMap似乎成功应对了每秒10万次请求的挑战。

这一切的起因是Wplace.live，一个突然出现的协作绘图网站，它完全基于OpenFreeMap构建。互联网似乎对它疯狂追捧，带来了前所未有的流量。

我推测，这些图像是由一些脚本小子绘制的。网站限制每个人每30秒只能绘制一个像素，因此可能有人使用Puppeteer/Chromium脚本不断启动新浏览器、点击像素并关闭浏览器，甚至可能进行了IP地址轮换。

这是一个有趣的项目，但下次请提前联系我。Neal.fun在推出Internet Roadtrip之前就联系了我，询问流量是否可行，并决定赞助OpenFreeMap项目，覆盖了他们的带宽使用。

抱歉，Wplace.live，我不得不创建了第一个Cloudflare规则。作为一个用户，你让服务对所有人造成了影响。

我联系了Wplace.live的开发者，他们表示在几天内用户增长到了200万，因此他们完全没有预料到这种流量。我建议他们设置一个自托管的OpenFreeMap实例，这样既能为他们提供免费服务，也不会给公共实例带来负担。

此外，200万用户产生了30亿次请求，平均每个用户1500次请求。正常用户加载地图时可能只会发出10-20次请求，因此这些显然是脚本化的高频率使用。

我的建议是，移除那些迫使用户通过新浏览器会话绕过的规则，否则服务器将不断受到冲击。

我从这次事件中学到了两点：

1. 我需要通过referer实施带宽限制。我正在研究如何在Cloudflare上实现这一点。服务不会改变，仍然免费且无需注册，但每个referer将被限制在一个非常高的数字内，比如每天1亿次请求。对于原生应用，我可能会要求他们添加一个自定义头来标识应用。

2. 我需要改进服务器配置，以修复那些空瓦片。尽管我不期待未来会有这样的流量，但我认为我找到了导致瓦片缺失的配置问题。

如果你觉得OpenFreeMap有价值，请考虑在GitHub上赞助。目前，项目每月依靠500美元的捐赠运行，刚好覆盖所有基础设施成本。更多的支持意味着我可以投入更多时间进行开发，确保OpenFreeMap能够应对未来的挑战。

你可以在GitHub上赞助项目：https://github.com/sponsors/hyperknot

评论主要围绕OpenFreeMap（OFM）在面对高流量时的表现、技术问题和解决方案展开，观点多样且平衡。

1. 对OFM的认可与兴趣

   • colinbartlett表示对OFM的透明度和技术细节感兴趣，考虑将其用于StatusGator的中断地图服务。
     "Thank you for this breakdown and for this level of transparency."
     “感谢这份详细的解析和透明度。”
   • jspiner对OFM的缓存命中率表示赞赏，询问是否有特别优化。
     "The cache hit rate is amazing. Is there something you implemented specifically for this?"
     “缓存命中率令人惊叹。你们是否为此特别优化了什么？”

2. 对高流量原因的讨论

   • LoganDark认为高流量并非完全由脚本驱动，用户长时间探索地图也可能导致大量请求。
     "Users don’t just load a map, they look all around the place to search for and see a bunch of the art others have made."
     “用户不仅仅是加载地图，他们还会四处查看其他人创作的艺术作品。”
   • feverzsj将OFM的流量激增比作“另一个百万美元主页”，暗示其突然走红。
     "So, OFM was hit by another Million Dollar Homepage for kids."
     “所以，OFM遭遇了另一个‘百万美元主页’式的流量冲击。”

3. 技术问题的分析与建议

   • charcircuit指出，OFM的流量问题不应归咎于用户，而是系统本身的文件描述符限制不足。
     "Or you did by not having a high enough fd limit. Blaming sites when using it too much when you advertise there is no limit is not cool."
     “或者是因为你们的文件描述符限制不够高。在宣传无限制的情况下，责怪用户使用过多是不合理的。”
   • eggbrain建议通过IP速率限制或JA4/JA3指纹识别来阻止恶意流量。
     "can’t you just rate limit requests to 100 requests per minute per IP?"
     “你们不能将每个IP的请求速率限制为每分钟100次吗？”
   • ch33zer询问是否可以通过提高文件描述符限制来处理更多流量。
     "Since the limit you ran into was number of open files could you just raise that limit?"
     “既然你们遇到的是文件描述符限制，是否可以通过提高限制来处理更多流量？”

4. 对缓存和可用性的质疑

   • v5v3和rtaylorgarlock质疑Cloudflare缓存的作用以及wplace.live为何未实现缓存。
     "The article mentions Cloudflare, so how much of this was cached by them?"
     “文章提到了Cloudflare，那么有多少流量是由他们缓存的？”
     "Why wouldn’t they save openfreemap all the traffic when a caching server on their side presumably could serve tiles almost as fast or faster than openfreemap?"
     “为什么他们不在自己的服务器上实现缓存，从而减少OpenFreeMap的流量负担？”
   • willsmith72对96%的可用性是否算作“幸存”表示质疑，并指出可用性下降仅通过用户报告被发现的问题。
     "so 96% availability = 'survived' now?"
     “所以96%的可用性现在就算‘幸存’了吗？”

总结：评论者对OFM的技术细节和应对高流量的能力表现出兴趣，但也对其缓存策略、文件描述符限制和可用性提出了质疑。部分评论者认为高流量并非完全由脚本驱动，用户行为也可能是原因之一。同时，针对技术问题，评论者提出了多种改进建议。