这个问题的根源在于OSMNX的逻辑依赖于Overpass API的/api/status响应中包含的**"X slots available now"**字段来判断服务器是否有可用资源，但你的私有实例因为禁用了速率限制（Rate limit: 0），所以没有返回这个字段，导致OSMNX误以为没有可用插槽，进而陷入重试循环。

你有两种可行的解决路径，具体选择取决于你的需求：

一、在OSMNX端临时修复（无需修改Overpass服务器） #

你可以通过**猴子补丁（Monkey Patch）**修改OSMNX处理Overpass状态响应的逻辑，让它在检测到速率限制为0时，默认认为有可用插槽。

举个具体的实现示例（针对OSMNX v1.0+版本）：

import osmnx as ox
import re

def patched_get_overpass_status(url):
    """
    重写OSMNX的状态检查函数，适配rate limit为0的私有Overpass实例
    """
    response = ox.downloader._session.get(url, timeout=ox.settings.timeout)
    response.raise_for_status()
    status_text = response.text
    
    # 原逻辑：提取插槽数
    slots_match = re.search(r'(\d+) slots available now\.', status_text)
    if slots_match:
        return int(slots_match.group(1))
    
    # 新增逻辑：如果rate limit为0，默认返回2个可用插槽（可根据实际调整）
    if 'Rate limit: 0' in status_text:
        return 2
    
    # 其他情况按原逻辑处理
    return 0

# 替换原函数
ox.downloader._get_overpass_status = patched_get_overpass_status

# 之后正常使用OSMNX即可
G = ox.graph_from_place("Your Location", network_type="drive", overpass_url="http://your-private-overpass/api")

这种方法的优势是无需改动Overpass服务器，适合快速验证；缺点是如果OSMNX版本升级，可能需要重新调整补丁逻辑。

二、在Overpass端持久化修复（推荐长期使用） #

如果你希望一劳永逸解决问题，可以修改私有Overpass实例的配置，让它即使禁用速率限制时也返回插槽信息：

1. 登录到你的AWS Overpass实例
2. 找到Overpass的配置文件（通常位于/usr/local/etc/osm3s_config或类似路径，取决于AMI的配置）
3. 在配置文件中添加或调整以下参数：

   max_allowed_slots=2
   rate_limit=0
   

   这里的max_allowed_slots可以根据你的服务器资源设置合适的数值
4. 重启Overpass服务（例如执行systemctl restart overpass-api，具体命令取决于服务名）

修改后，你的私有实例/api/status响应会类似：

Connected as: 1190172919
Current time: 2020-12-30T03:02:05Z
Rate limit: 0
2 slots available now.
Currently running queries (pid, space limit, time limit, start time):

这样OSMNX就能正常识别可用插槽，不再陷入重试循环。

这种方法的优势是持久化解决，不受OSMNX版本更新影响；缺点是需要操作服务器配置，适合长期使用该私有实例的场景。

内容的提问来源于stack exchange，提问作者Jamie Burks