TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
ip-info-api 免費 IP 查詢 API 清單，55 個端點先分級再挑
ip-info-api 是 GitHub 上收了 55 個免鑰匙免費 IP 查詢端點的清單，2024 年建立至今仍持續標記失效端點。實測發現清單裡混著兩種可靠性等級：服務商免費額度適合放進正式專案，中國網路公司的內部端點 12 個已死 4 個只適合拋棄式腳本；同一個 IP 被不同資料庫查出四個不同城市，城市欄位要交叉兩個來源再採信。
用 AI 摘要這篇文章：
GitHub 上有一份跑了兩年半還在更新的清單：ihmily 的 ip-info-api，收了 55 個免費 IP 查詢端點，全部用 GET、全部不用註冊 key，貼上網址就能拿到 JSON 或純文字位址。我在 2026 年 10 月 25 日把清單裡的端點抽樣實測了一輪，結論先講：這份清單標記的死活大致誠實，標失效的確實死了，標可用的抽測端點當天全部有回應。但「可用」要分成兩種等級，混著用會出事。一種是 API 服務商正式提供的免費額度，另一種是中國網路公司內部系統順手開著的端點。前者可以放進會長期跑的程式，後者只適合拋棄式腳本。
這條分界線怎麼來、怎麼用，下面用實測來說明。
55 個端點分五類，但真正的分界線只有一條
清單主體是 55 個查詢端點：21 個能查本機 IP 也能用 IP 反查、27 個只能查本機、7 個只能用 IP 反查；另外單獨收了一個用地名或經緯度反查位置的服務（OpenStreetMap 的 Nominatim），結尾再附 21 條 curl 就能呼叫的純 IP 回聲服務。每個條目都標了請求方式、參數、CORS 支援與範例回應，拿到手就能對照著寫程式。倉庫本身用 Apache-2.0 授權，1,500 多顆星，2024 年 2 月建庫，本身沒有任何程式碼，就是一份持續維護的文件。
但對要挑端點的人來說，真正重要的分類不在這五節，而在端點背後是誰。
一種是專門提供 IP 查詢的服務商免費額度：ipify、ipinfo.io 的示範端點、ip-api.com、freeipapi.com、db-ip.com、geojs、ipapi.co、ipwhois.app 這類。它們有正式文件、有速率與額度政策，通常也有付費方案接著，臨時要拉高用量有路可走。另一種是中國網路公司的內部端點：QQ 新聞的 ip2city、B 站直播網的 getIpInfo、攜程的 cdid、騰訊影片的 checktime、百度開放資料、愛奇藝、樂視、CSDN、美圖，QQ 新聞與百度各有兩個位址，太平洋電腦網也計入，一共 12 個。這些不是人家開給你用的 API，是別人產品內部呼叫的位址，被清單整理出來而已。沒有文件、沒有承諾，對方改版、換路徑或加驗證，你都不會收到通知。
| 服務商免費額度 | 大廠內部端點 | |
|---|---|---|
| 文件與範例 | 有，條列速率限制 | 無，靠社群逆向整理 |
| 存在保證 | 商業模式支撐，有 SLA 可買 | 主產品活著才活著 |
| 用量超標時 | 回明確錯誤或引導升級 | 靜默擋掉或直接消失 |
| 適合的用途 | 長期專案、正式服務 | 拋棄式腳本、備援、玩票 |
判斷很簡單：要放進正式專案的，只從服務商免費額度裡挑；寫個跑一次就丟的腳本，或想找備援時，內部端點可以用，但要預設它哪天會死。這個預設不是杞人憂天，下面有數字。
15 座墓碑反而讓這份清單更可信
55 個端點裡有 15 個被標了「已失效」，超過四分之一。我把這 15 個抽了 5 個出來實測，結果四個真的死透了，一個已經轉址：
| 端點 | 清單標記 | 實測結果 |
|---|---|---|
| qifu-api.baidubce.com（百度） | 已失效 | 404，回 Resource not found |
| searchplugin.csdn.net（CSDN） | 已失效 | 403 被拒 |
| ip.useragentinfo.com | 已失效 | 連線直接失敗 |
| api.myip.com | 已失效 | 逾時無回應 |
| www.ip.cn | 已失效 | 回 302 轉址，API 不在了 |
失效標記可信，代表這份清單的存活資訊可以拿來先刪掉一半候選。更難得的是維護者把「標失效」當成持續的工作在做：commit 紀錄裡 2026 年 5 月還有一筆「Update README to indicate invalid API link」，9 月底仍有更新，2024 年 2 月建庫至今 32 筆提交，其中 25 筆來自同一位維護者，另外 7 筆是社群貢獻的新端點。社群送來的端點會標上 PR 編號，看得出這份清單的活躍有一部分是大家一起養的。
不過抽測也測到一個標記沒跟上的案例，比死掉的更值得記下來：db-ip.com 的 demo 端點沒被標失效，我也確實拿到了 HTTP 200，但它回的內容已經不是查詢結果。第一個請求回了一份委內瑞拉卡拉卡斯的位置資料，跟我查的 IP 完全無關；接著再查 8.8.8.8 和 1.1.1.1，兩次都回「over query limit, please try again later」。對照清單快照裡留下的範例，這個端點曾經會回真實的查詢結果，現在退化成示範資料加限流訊息。
這帶出一個比「哪些死了」更實用的教訓：判斷一個端點能不能用，要驗的是回傳內容對不對，不是有沒有回應。HTTP 200 只證明伺服器還開著，內容早就可以是罐頭。驗收自己接的 API 時，拿一個已知答案的 IP 去對，比看狀態碼可靠得多。404 是路徑沒了，403 是被政策擋了，連線失敗是網域或憑證出了狀況，逾時是服務掛了或防火牆不讓你過，這幾種死法的後續處理並不相同，值得在報錯訊息裡多看一眼。
標著可用的大廠端點，是借來的
12 個大廠內部端點裡，4 個已經進了上面的墓碑名單：美圖、CSDN、百度 qifu、愛奇藝。剩下 8 個我實測當天全部應答，而且資料不差。QQ 新聞的 ip2city 回國家、省分、城市與行政區代碼；B 站直播網的 getIpInfo 連緯度經度和 ISP 都給；攜程的 cdid 一個請求就回純文字的 IP；百度開放資料回的位置欄位精確到城市與電信業者這種等級，只是欄位一律簡體中文。
它們能活，原因並非服務商好心。這些是騰訊、百度、B 站自己的網頁與 App 每天要呼叫的位址，主產品還活著，端點就跟著活。反過來說，這也是它們唯一的存在保證。哪天對方改版、加簽章驗證，或單純換路徑，第一個知道的方式就是你的程式壞了。前面那 4 個死掉的，就是這條路上的先例。
還有一層代價容易漏算：隱私。每呼叫一次 IP 查詢，等於把「你的來源 IP 加上查詢對象」送進對方系統留一筆紀錄。對正式服務商來說，這受條款約束，怎麼用資料至少寫在文件裡；對內部端點來說，你的請求進的是別人家產品與資料管線，清單裡那個 ipv4.gdt.qq.com 的網域，從命名看就掛在騰訊廣告體系（GDT 廣點通）之下。查自己的 IP 玩一玩無妨，若想放進會處理訪客資料的服務裡，這條路就不對勁了。
順帶一提，這類「整理別人內部端點」的策展在 GitHub 上自成一路，像本站先前介紹過的 bilibili-api-collect 就是把 B 站文件外的介面整理成庫的例子。這類資料庫的價值與風險是同一件事：它們記錄了官方不會告訴你的入口，但入口隨時會換鎖。
同一個 IP，四個城市
挑端點之前還得先接受一件事：免費 IP 地理資料對同一個位址會給出不一致的答案，這是結構性的，不是哪家特別差。
我拿清單範例用的 121.8.215.106（中國電信廣東的位址）同時查了幾個服務。ip-api.com 回廣州，緯度 23.12，這是對的。ip.sb 也回城市 Guangzhou，但緯度給了 34.77，那個座標已經落到河南一帶，與它自己標的城市兜不攏。同一分鐘、同一個 IP、兩份互相矛盾的答案，而且都包在成功的 JSON 裡，沒有任何欄位提醒你哪個可疑。
換個角度看更熱鬧。我用一台透過 Cloudflare WARP 連線的機器去查「本機 IP」，freeipapi.com 說我在加拿大多倫多；B 站與 ipip.net 說我在台北市；ipquery.io 說桃園；ipwtf.com 直接把我放到德國波昂。同一台機器、前後幾秒的請求，四個城市、三個國家的答案。甚至不同端點看到的來源 IP 都不一樣，因為 WARP 的出口本來就會輪換，這對「拿查詢結果比對黑名單」之類的用法是實實在在的干擾。
背後的原因不神秘。每家服務商背的資料庫不同，MaxMind、IP2Location 或自建庫，更新的時間差各異；IP 段的註冊資料（誰被分配到哪個網段）與實際使用地點本來就有落差；遇到代理、VPN 或骨幹網段，各家的猜法更是各自表述。整理成可信度排序大致是：國家級判定各家高度一致，出了事也容易察覺；ISP 與 ASN 欄位相對可靠，因為這來自註冊資料而非推測；城市與經緯度是機率性的答案，是四個城市那種笑話的主要來源。
所以實務上的用法是：把任何一家單獨的城市答案都當成參考值，固定的做法是同時查兩個來源，一致就採信，不一致就以國家級欄位為準，城市降級成「大概的區域」。要偵測訪客是不是掛著代理，ipquery.io 這類直接回傳 VPN 標記的端點會比人肉比對座標省事。消費端也有同樣的困擾，之前介紹過的 ip111 就是用一頁同時對照多個觀測點的思路在解這件事。
真的要挑的時候，按需求縮小候選
55 個端點不用都試，按用途收斂很快。
只需要拿到本機對外 IP 的，用最單純的回聲服務就夠：ifconfig.me、checkip.amazonaws.com、api.ipify.org 都是一行 curl 回一個位址，亞馬遜那個大概是全部裡最長命的。這裡有個小坑：ifconfig.me 會看 User-Agent 決定回什麼，用瀏覽器 UA 去打會收到整頁 HTML，用 curl 才回純文字。寫進程式前記得用呼叫環境實際跑一次，別拿瀏覽器測試的結果當依據。
要在網頁前端直接呼叫的，先看清單的 CORS 欄位：55 個條目裡 28 個標支援、27 個標不支援。CORS 是瀏覽器的跨來源政策，標不支援的端點，瀏覽器會直接把回應擋下來，你的 JavaScript 拿不到資料，但同一個網址用後端或 curl 呼叫又完全正常，這種「curl 通、瀏覽器不通」的症狀，十之八九是踩到這裡。
會長期跑的程式，就往有文件的那一側挑。這裡有個一定要先知道的限制：ip-api.com 的免費層只走明文 HTTP，我實測用 HTTPS 去打，回 403 與「SSL unavailable for this endpoint」的訊息，要走 HTTPS 得向他們買 key。清單目錄裡另有三個條目同樣以 http 開頭。放在 HTTPS 網站上時，瀏覽器會把這種明文請求當混合內容擋掉，這在正式環境幾乎必然踩到。ip-api.com 支援 lang 參數把欄位換成中文，免費服務裡少見。
要中文地區資料的，百度開放資料與 ip9.com.cn 都回中文欄位，但一律簡體，台灣的場景拿去顯示前得自己轉換，或乾脆用英文欄位組合。太平洋電腦網的 ipJson 回的是 GBK 編碼，直接當 UTF-8 解會拿到亂碼，程式裡要明確指定編碼。
另外兩個環境敏感的案例也記一下。OpenStreetMap 的 Nominatim 會擋簡短的 User-Agent，帶完整瀏覽器 UA 才放行；ipwhois.app 用路徑式查法會回 403，要用它文件裡的查詢參數式。這兩個都活著，但換個呼叫方式就會以為它死了。反過來說，你在別的教學裡看到某端點不能用時，也先檢查自己的呼叫方式再下判斷。
單發實測能證明什麼，不能證明什麼
這篇文章的實測是 2026 年 10 月 25 日做的單發請求，它能證明端點當下的死活與回傳內容，不能證明速率額度、長期可用率，或下個月還在不在。免費 IP 查詢服務普遍有每分鐘請求數限制與商用條款，正式用途請回各服務商的文件確認，清單本身不會替你讀條款。
兩件事容易誤解。其一，這個倉庫採 Apache-2.0 授權，但授權涵蓋的是清單文件本身，你呼叫各端點的權利由每個服務方自己的條款決定，兩者無關。其二，清單由單一維護者主力維護，取捨難免主觀，收錄標準就是「免費、免 key、GET」，沒有品質篩選，更新節奏也是爆量式的，有時隔月補一筆，有時一次加好幾個。它 2026 年 8 月還一次收進三個新端點，9 月底仍有清單更新，但單人策展的清單，永遠要有哪天停更的心理準備。
誰該把這份清單收進書籤：常寫小工具、爬蟲腳本，或需要在多個環境查 IP 位置的人，它是現成的備援池，配上失效標記可以省大量試錯。誰不用特意收藏：產品需要穩定地理位置服務的，直接評估付費方案與 SLA，免費端點的答案品質前面已經看到了。平常只想快速檢查連線與對外 IP 的讀者，zhale 這類網路診斷工具會比拼 API 更順手。
免費的東西不是不能碰，而是要知道自己拿到的是哪一種免費。這份清單把兩種並排在一起，剩下的判斷，就是你的工作了。
