我要抓一小段地圖資料。送出去之後，畫面就停在那裡。
等了十五秒，回來的只有一行字：504 Gateway Time-out。
我以為是連線斷了。順手打開那個服務自己的狀態頁看一眼，上面寫著 Rate limit: 2、2 slots available now，連它當下實際在用的那台機器叫什麼名字都公告出來。
它活得好好的。停下來的是我那個要求。
同一個 relation，兩條路
────────────────────────────────────
Overpass 主站 等 15 秒 → 504
它的 /api/status 活著，2 slots
kumi 鏡像 連不上
private.coffee 連不上
────────────────────────────────────
OSM 主 API /full 200
5 way、956 node
────────────────────────────────────
我以為發生了什麼
我以為是塞車。逾時看起來就是網路不穩的樣子：對面很忙，等一下再送一次就好。
所以我重送，隔一會兒再重送，接著去試兩個常見的鏡像站。整個過程我都沒有懷疑過自己的查詢，因為它小得不像會出事——只是要一個 relation 的 id 而已。
現在回頭看，我預設了一件從來沒有人保證過的事：服務還活著，等於我的查詢跑得完。
實際發生了什麼
2026-09-17 實測。送到 overpass-api.de 的查詢很小，只取一個 relation 的 id，等了 15 秒，回 504。
同一時間打它的 /api/status，服務是活的。回應裡明白寫著 Rate limit: 2、2 slots available now，還公告了它實際在用的後端節點名稱。它不是在拒絕我，它是接下了這個查詢，跑到一半放棄。
當天兩個常見鏡像 overpass.kumi.systems 與 overpass.private.coffee 完全連不上。三條路同時不通，很容易讓人把帳算到自己的網路上。
換一條路：打 OpenStreetMap 主 API 的 api.openstreetmap.org/api/0.6/relation/{id}/full，同一個 relation，回 200，拿到 5 個 way、956 個 node，沒有碰到任何速率限制。
官方文件寫了嗎
狀態頁本身就是官方的，而且它沒有說謊。它報的是配額，不是進度——現在還收不收得下新的請求，跟你送進去的東西做不做得完，本來就是兩個問題。它從頭到尾沒有承諾過後者。
沒有被寫在你看得到的那一頁上的，是這兩件事可以同時成立：有空位、照樣逾時，兩個都是真的。 工具沒做錯，是我把一個資源指標讀成了完成保證。
主 API 那條路的限制反而寫得很清楚：/full 是把整個 relation 全撈下來，不能依 bbox 或 tag 篩選，也沒有跨 relation 的彈性查詢可用。它拿掉了彈性，換來確定性。
你一定會踩的那個細節
逾時錯誤最容易被歸類成「等一下再說」，於是你會在同一條路上重打一整個下午。逾時不是叫你重試的訊號，是叫你換路的訊號。
分辨的方法很短，你今天就能自己跑一次：
分清楚「服務掛了」跟「查詢做不完」： 1. 先看服務活著沒 curl -s https://overpass-api.de/api/status → 看得到 slots available 就代表它活著 2. 把查詢縮到最小（只取一個 id）再送一次 → 還是 504，就不是你的查詢太大 3. 改打主 API 抓同一個 relation H=https://api.openstreetmap.org/api/0.6 curl -s "$H/relation/<id>/full" | head -c 200 → 回 200 就把這條收進備援路徑 第 1 步活著、第 2 步還是逾時，就別再重試了。
次序不能跳。先確認服務活著，再確認查詢做不完，最後才決定換來源。少了中間那一步，你分不出來自己是被限流還是被放棄，兩者的處置完全相反。
站內延伸
來源： Overpass API 主站與 /api/status、overpass.kumi.systems、overpass.private.coffee，以及 OpenStreetMap 主 API 的 /api/0.6/relation/{id}/full，皆為 2026-09-17 當日實測。
一個逾時長得像網路問題，其實是能力問題。狀態頁回答的是「還收不收得下」，不是「你這個做不做得完」——這兩個問題的答案可以一個是、一個否。在你決定重試之前，先弄清楚它剛剛回答的是哪一個。