A watershed analyst in Oregon runs QuickOSM’s “hospitals in the state boundary” query on a Monday morning and gets Download Failed: HTTP 406 Not Acceptable. The query worked on Friday. She re-runs it, gets the same error. Switches to QGIS’s native “Download OpenStreetMap data” tool — same error, slightly different wording. Twitter says other people are seeing it too. The r/QGIS thread has six comments and no consensus.
The 406 response from overpass-api.de is not a timeout, not a rate limit, not your query, and not a QGIS bug. It’s the Overpass server telling you something specific about your request that most documentation glosses over. The fix is a one-line configuration change, but only if you know which line.
What HTTP 406 actually means
From RFC 9110: “The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request.”
In plain terms: the client asked for a response format the server refused to produce. The negotiation happens through Accept, Accept-Language, Accept-Encoding, and Accept-Charset request headers. A 406 means one of those didn’t match what the server was willing to send.
For Overpass specifically, the cause has evolved. When QuickOSM and QGIS first started seeing 406s in 2024, the trigger was a tightened Accept-Language check on overpass-api.de — requests with unusual locale headers or missing User-Agent fields were being rejected by a new upstream filter. Through 2025 and into 2026, the cause shifted: the primary server at overpass-api.de has been increasingly overloaded by AI scraper traffic, and the operator has added request-shape filters that bounce requests that look programmatic rather than interactive. The 406 is a crude “you look like a bot” gate, and it catches plenty of legitimate GIS clients along with it.
The OSM Wiki status page updates this through the year. As of 8 April 2026, the DNS for z.overpass-api.de and lz4.overpass-api.de points at gall.openstreetmap.de and lambert.openstreetmap.de respectively — both are healthier servers than the primary but still intermittently rate-limited.
Why “just retry later” doesn’t work
Users on the OSM forum repeatedly report the 406 persisting for hours or days. This is different from the server’s normal 429 “rate limit” response, which clears after the cooldown. 406 is stateful from the server’s perspective: the server has categorised your client and is rejecting requests on that basis, not on current load. Retrying with identical headers from the same client gets you identical rejections.
The fix is not to retry. The fix is to change which server you talk to.
The working mirror list (as of April 2026)
Public Overpass instances that currently handle QGIS-shaped traffic without 406ing:
https://overpass.kumi.systems/api/— Run on strong hardware, keeps attic (historical) data, no registration. The most reliable mirror for GIS tool traffic in 2025-2026. Private.coffee now fronts this with a sibling endpoint athttps://overpass.private.coffee/api/.https://z.overpass-api.de/api/— DNS now points at gall.openstreetmap.de. Faster than the main endpoint for queries under 30s.https://lz4.overpass-api.de/api/— DNS now points at lambert.openstreetmap.de. The “large queries” endpoint, useful for country-scale extracts.https://maps.mail.ru/osm/tools/overpass/api/— Regional mirror in Russia; good latency from Europe, sometimes blocked from US traffic.https://overpass.osm.rambler.ru/cgi/— Russia-hosted mirror; note the/cgi/path, not/api/.
Avoid the main https://overpass-api.de/api/ as your default for tooling. Keep it as a fallback for the rare case a mirror is down.
Switching the endpoint in QuickOSM
QuickOSM ships with its own server list, hardcoded in definitions/overpass.py, and lets you override it per query or per project.
Per-query override (fast path)
The Query dialog has a Server dropdown below the query editor. Open any QuickOSM query, click the dropdown, pick overpass.kumi.systems/api/. Run it. If that query completes, the fix is confirmed.
Plugin-wide default
QuickOSM reads the server default from QGIS’s Settings → Options → QuickOSM → Default server. Change it there and every new query uses the new endpoint.
Adding a custom server
If you want to add a mirror not in the default list (or point at an internal cache), edit ~/.local/share/QGIS/QGIS3/profiles/default/python/plugins/QuickOSM/definitions/overpass.py (Linux/Mac) or %APPDATA%\QGIS\QGIS3\profiles\default\python\plugins\QuickOSM\definitions\overpass.py (Windows):
OVERPASS_SERVERS = [
'https://overpass.kumi.systems/api/',
'https://z.overpass-api.de/api/',
'https://overpass.private.coffee/api/',
'https://overpass-api.de/api/', # keep as last-resort
'https://your-internal-cache.example.com/api/',
]
The trailing /api/ matters. Requests hit {server}/interpreter under the hood, so the base must include the full API path. Omitting the trailing slash produces a 404 that looks like a 406 on casual inspection.
Switching the endpoint in QGIS’s native “Download OSM Data”
QGIS has its own Overpass downloader under Vector → OpenStreetMap → Download data, separate from QuickOSM. Its server setting lives in:
Settings → Options → Network → OpenStreetMap Overpass API URL
Paste https://overpass.kumi.systems/api/interpreter — note the /interpreter path at the end, which differs from QuickOSM’s /api/ base. This is a long-standing QGIS quirk: the native downloader asks for the full interpreter URL while QuickOSM asks for the API base URL. Both work, neither is documented well.
After changing, restart QGIS. The Overpass URL is cached in the session and doesn’t update on live setting changes for this particular downloader.
Detecting which mirror a tool is using
If you’re not sure which endpoint a plugin is calling, open the QGIS log panel (View → Panels → Log Messages Panel) and filter for Network or QuickOSM. Every Overpass request logs the full URL. A 406 on overpass-api.de and a 200 on overpass.kumi.systems will both appear there, clearly.
For Python scripts using requests or overpass-python, log the endpoint before every request:
import overpass
api = overpass.API(endpoint='https://overpass.kumi.systems/api/')
print(f"Using Overpass endpoint: {api.endpoint}")
result = api.get('node["amenity"="hospital"](44.0,-124.0,46.0,-116.0);', verbosity='body')
The request headers that trigger 406 on the primary endpoint
If you’re building your own Overpass client or debugging why a non-GIS tool gets 406s, these are the headers that matter:
User-Agent. Missing or genericpython-requests/2.xuser agents now get 406 on the primary. Send a descriptive agent with contact info:MyOrgGeoLoader/1.0 (contact@myorg.example).Accept. The primary wants*/*or an explicitapplication/osm3s+xml/application/json. Don’t send onlytext/html.Accept-Encoding.gzip, deflate, bris fine. Some clients send noAccept-Encoding, and the primary has started rejecting those.Accept-Language. Unusual locale tags can trip the filter. If you’re sending this at all, use a common one likeen-USor drop the header.
The mirrors don’t enforce these checks as aggressively. Part of why they work when the primary doesn’t is that they haven’t added the same AI-scraper defences.
When you’re downloading enough data that a mirror is the wrong answer
Overpass is designed for interactive queries — pick a small area, pull a tagged subset, iterate. Once you’re pulling country-scale or multi-country OSM data regularly, you’re past what any public Overpass instance is built for, and mirrors will 429 you even if they don’t 406.
The pattern that actually scales: pull the raw .osm.pbf extract directly from Geofabrik (download.geofabrik.de/) or BBBike for custom regions, then run Overpass-like queries locally with osmium or by loading into PostGIS with osm2pgsql. A 500 MB .pbf file imports to PostGIS in under 10 minutes on modern hardware, and every subsequent query runs in single-digit seconds with no network round trip.
For teams doing this regularly, the workflow usually looks like: weekly .pbf download → PostGIS import → QGIS connects to PostGIS → all exploratory queries hit the local database. QuickOSM stays in the toolbox for one-off small-area pulls.
What to do if the mirror pulls are feeding another tool
OSM extracts pulled through Overpass often end up in Rhino, AutoCAD, or SolidWorks for site modelling. The handoff from QGIS is where geometry quality becomes visible — holes in polygons, self-intersections, unclosed rings. QuickOSM’s OSM-to-vector conversion is fairly clean but not perfect, and the downstream CAD tool is usually less forgiving than QGIS about malformed geometry.
Run Vector → Geometry Tools → Check validity on the downloaded layer before exporting. If errors appear, run Fix geometries before the export step. This catches the QGIS-to-CAD issues covered in the QGIS to Rhino DXF export pitfalls post — the same validity issues that cause Save Features As to silently drop polygons also cause headaches when the data ends up in a CAD tool.
Overpass instances that look fine but aren’t
A few public Overpass endpoints appear in older tutorials and forum threads but shouldn’t be in your 2026 mirror list:
http://overpass.osm.ch/api/— Swiss academic mirror, was reliable but went read-only in 2023 and no longer accepts new queries.http://overpass.openstreetmap.fr/api/— French mirror, currently intermittent.- Anything over plain HTTP. Overpass’s original endpoints were HTTP-only; they’ve all migrated or been deprecated. If you see
http://in a tutorial, update tohttps://and check whether the host still serves the API at all.
The deeper reason public Overpass is unstable
The Overpass system was built on the assumption that one server could handle the world’s OSM queries if users were reasonable. The scaling issue is no longer traffic from humans — it’s traffic from AI pipelines, LLM grounding systems, and machine-learning training loops that query Overpass without rate-limiting themselves. This is the same pattern affecting every open GIS and CAD data source, and it’s why practitioners are increasingly building their own validation and extraction tools rather than depending on community infrastructure that wasn’t sized for this load.
For the foreseeable future, the right posture is: use mirrors as the default, keep the primary as fallback, and move to local .pbf + PostGIS the moment your usage is regular enough to justify it. That tier stack is how serious GIS shops stay productive while the public infrastructure continues to shake out.
The one-liner to remember
If you’re going to remember one thing from this post: when QGIS says “Download Failed: Not Acceptable” or “HTTP 406”, don’t retry and don’t change your query. Switch the server to https://overpass.kumi.systems/api/ and run it again. That fixes the problem for over 90% of cases, and the rest are usually cases where you should be using .pbf downloads anyway.
GeoConvert doesn’t interact with Overpass directly — it’s a format converter, not a data source — but we see the downstream of broken OSM extracts regularly. When GeoJSON or shapefiles arriving for conversion have malformed polygons, self-intersections, or mixed geometry types, it’s often traceable back to a QGIS session that failed a download, retried against a flaky mirror, and silently produced partial output. Pointing QGIS at a reliable mirror at the start of the workflow saves a lot of “why is my shapefile missing half the features” debugging two hours later.