第三十七期
2026-10-24
一.Zeabur死了
作者:YD
還記得我們在第三十四期才剛拆解過 Zeabur 的資安事故嗎？沒想到短短不到兩個月，這個台灣開發者幾乎人人聽過的一鍵部署平台，就在 10 月 14 日再度遭到入侵，而且這次的規模比八月還要大上許多。10 月 17 日，創辦人林沅霖寄出一封信給所有使用者，宣布 Zeabur 將逐步結束營運，所有服務最晚在 12 月 31 日全面關閉。是的，Zeabur 死了。這篇週刊就來看看第二次入侵到底發生了什麼、攻擊者是怎麼一路走進平台資料庫的，以及程式貓在這段時間做了哪些搬家決定。
圖：取自 Zeabur 官方部落格
停運時程：年底前一定要搬走
先講最實際的，如果你手上還有服務跑在 Zeabur，請把這幾個日期記下來：
- 即日起（10 月 17 日）：停止新的專用伺服器與網域購買，開始受理帳戶餘額退款，網域可以在 Dashboard 自助轉出。
- 12 月 1 日起：專用伺服器停止續費，依各自到期日在 12 月內陸續關閉；共享叢集則會暫停所有運行中的服務，需要備份的話可以手動恢復運行。
- 12 月 31 日：所有專用伺服器與共享叢集停止服務。
至於資料刪除日、最晚匯出期限，以及客服 Zeabur Support 停止服務的日期，官方都說會另行公告。林沅霖在信中特別提醒：「不要等到資料刪除期限公布才開始準備。」餘額退款和資安事件賠償要分開申請，都是透過 Zeabur Support 辦理；台北市消保官也表態，退費原則上應以消費者原本支付的貨幣返還。
至於停運的原因，林沅霖坦言在八月事件之後，團隊「討論、糾結了很久」，第二次事件發生後重新評估，最後才做出這個決定。除了資安事故，他也提到另一個更根本的問題：AI 為雲端部署帶來前所未有的需求，但同時也快速降低了部署本身的門檻——當 Coding Agent 已經能幫你寫好 Dockerfile、設定好伺服器，「一鍵部署」的價值自然就被稀釋了，平台成長也開始遇到瓶頸。再加上系統從快速開發起步，歷經多次架構調整，複雜度與維護難度不斷累積。
「短時間內再次發生資安事件，辜負了大家對我們的信任。」、「謝謝過去三年多曾經支持，或現在仍在使用 Zeabur 的你。」這是公告裡的兩句話，讀起來還是有點不捨。
攻擊規模：32 萬個帳號、321 萬筆環境變數
圖：取自 Zeabur 官方部落格
根據 Zeabur 10 月 19 日公布的初步調查報告，這次入侵的規模大概是這樣：
- 共享叢集：9 個區域全數受影響，攻擊者在 865 個資料庫服務的容器內執行了讀取指令
- 平台資料庫：3,218,965 筆環境變數、321,810 筆帳號資料（電子郵件、使用者名稱、手機號碼等）遭讀取
- GCP 專用伺服器：101 台遭攻擊者以 root 身分登入，影響 92 位使用者，其中 50 台被植入攻擊者的 SSH 金鑰，另有 16 份客戶磁碟被複製到攻擊者控制的虛擬機
- 其他：566 把 zSend 金鑰（明文保存，已撤銷）、GitHub App 私鑰、Hetzner 與 DigitalOcean 的雲端管理權杖
如果說八月的事件是「AI 金鑰被盜刷」，這次就是「整個平台被翻過一遍」。官方也觀察到，攻擊者似乎主要在找可以直接拿來用的第三方金鑰，特別是 AI 服務的 API Key。更讓人頭痛的是 n8n 的使用者：n8n 的加密金鑰和加密資料都存放在環境變數裡，等於鑰匙和保險箱放在一起，官方統計有 602 個這樣的情況，實質上就跟明文沒兩樣。
攻擊路徑：一把兩年沒換的鑰匙
這次的攻擊鏈比八月複雜，可以分成兩條路，最後在平台資料庫會合。
路徑 A：共享叢集與 AWS
- 攻擊者取得一組 AWS 金鑰，以及一把共享叢集管理權杖。這把權杖是 2024 年 1 月建立的，沒有設定到期日，今年 1 月還被以明文寫進了設定儲存庫。
- 因為叢集的管理介面直接對公網開放，攻擊者從外部就能用這把權杖進入 9 個區域的共享叢集。
- 讀取共享叢集上所有服務的設定與機密，包含使用者的環境變數，並進入 865 個資料庫容器執行讀取指令。
- 再利用一把權限過大的儲存空間金鑰讀取舊叢集的備份，從中拿到 Zeabur 內部機密管理服務的存取金鑰，進一步讀出約 53 筆正式環境機密——包括內網管理憑證、平台資料庫帳號與 GitHub App 私鑰。
路徑 B：GCP 專用伺服器
- 利用一把舊的 GCP 金鑰，讀到伺服器初始化設定中明文保存的 root 密碼。
- 以 root 身分登入 101 台 GCP 專用伺服器，修改設定、植入 SSH 金鑰，並再取得一把正式環境的 GCP 金鑰。
兩條路會合：攻擊者在被入侵的 GCP 伺服器上，拿路徑 A 偷到的內網憑證把自己的節點加入 Zeabur 內網，最後用一個「唯讀」但可以讀取所有資料的內部資料庫帳號，把平台資料庫讀了一遍。
整起攻擊從 10 月 14 日凌晨開始，持續了超過 16 個小時都沒有觸發任何告警，團隊是隔天收到使用者回報才開始調查。
最讓人遺憾的是，這把管理權杖和 AWS 金鑰其實都沒有被納入八月事件後的輪替範圍。官方在報告中也主動更正，八月時「已停用或輪替所有內部管理金鑰」的說法並不完整；而 GCP 初始化設定保存 root 密碼的問題，早在 9 月 3 日就已經被發現，卻沒有在事發前修正。至於攻擊者最初是怎麼拿到這些憑證的，官方推測與八月事件有關，但目前還沒有直接證據。
換句話說，這次的問題不是某個高深的零時差漏洞，而是一連串資安基本功的缺口：無期限的權杖、明文保存的密碼、對外開放的管理介面、權限過大的帳號、內部服務與使用者服務部署在同一個叢集，以及失靈的監控。任何一個環節做好，攻擊者都可能走不到最後。
無獨有偶，Railway 也炸了
就在 Zeabur 宣布停運的同一週，同樣是熱門部署平台的 Railway 在 10 月 21 日也發布資安公告，表示偵測到儲存使用者環境變數的系統出現異常活動，攻擊者可能存取了加密的環境變數，而且部分已經取得解密後的內容。Railway 隨即暫停全平台的部署，並要求所有使用者輪替環境變數與私有 Registry 憑證。
最值得注意的是 Railway 公告中的一句話：這起事件屬於「近期一系列針對平台公司、以入侵 AI 推論服務供應商為目標的攻擊」之一。如果再往前推，Vercel 在今年 4 月也因為第三方 AI 工具的 OAuth 應用程式遭入侵而外洩部分環境變數。把這些事件放在一起看，攻擊者的目標已經很清楚了：部署平台上滿滿的 AI API Key，就是現在最值錢的獵物。
程式貓搬家了：從 Zeabur 到自建 Dokploy
程式貓的 AI 服務原本就運行在 Zeabur 上，八月事件時我們已經輪替過所有金鑰。這次 Zeabur 決定停運，我們也正式完成了遷移，把服務搬到自建的 Dokploy。
Dokploy 是一套開源、可自架的 PaaS，核心採用 Apache 2.0 授權，用起來的感覺跟 Zeabur、Vercel 很像：支援 Dockerfile、Nixpacks、Docker Compose，內建 PostgreSQL、MySQL、Redis 等資料庫與排程備份，透過 Traefik 自動處理路由與 Let's Encrypt 憑證，還有監控和通知功能。差別在於，它跑在我們自己的伺服器上。
選擇自建當然不是沒有代價，伺服器的維運、更新與資安都要自己扛起來。但經過這兩次事件，我們更確定一件事：把所有機密集中交給一個多租戶平台，等於把自己的安全上限綁在別人的資安水準上。自建至少讓我們能掌握憑證放在哪裡、誰能存取、出事時能多快反應。
本週觀察：該追究責任，也該保留一點溫度
身為受影響的客戶，程式貓認為 Zeabur 應該為這次事件負起責任。兩個月內兩度遭駭，而且第二次的根本原因，大多是第一次就該修好的問題，這不是運氣不好可以解釋的。我們也期待官方把後續的調查、賠償與資料刪除都好好走完，讓使用者能安心地離開。
但另一方面，選擇新創的服務，本來就要承擔新創的風險。Zeabur 是一個從畢業專題起家、由一群年輕人一路做到十萬用戶的台灣團隊，他們在兩次事件中都公開了相當透明的調查報告，連自己先前說錯的地方都主動更正，這在資安事故中其實並不常見。比起在社群上部分人一面倒地譴責，筆者更希望大家能用鼓勵代替譴責——責任要追究，但台灣願意挑戰基礎設施的團隊已經不多了，我們不希望這次事件讓下一個想嘗試的人卻步。
Agent 時代，資安該換個想法了嗎？
回頭看這個月，資安新聞幾乎沒停過：Zeabur、Railway 接連出事；10 月 21 日，影響全球約七成網站的 PHP 被揭露兩個可遠端執行程式碼的嚴重漏洞 PHP2Shell（CVE-2026-109618、CVE-2026-109619），幾乎過去十年所有 PHP 版本都受影響，而且 AWS 的蜜罐在公開揭露前四天就已經觀察到利用嘗試；同一天，AI 開發者常用的 LiteLLM 也被攻擊者入侵發布流程，在 PyPI 和 Docker 上推出了惡意版本。
值得一提的是，PHP2Shell 是 Wiz 的研究團隊借助 AI 模型找到的——這些漏洞藏了十年，過去要把它們串成可用的攻擊非常困難，AI 卻大幅降低了這個門檻。AI 能幫防守方找漏洞，當然也能幫攻擊方；而 AI API Key 本身，又成了攻擊者最想拿到的東西。
當 Agent 能幫我們部署、幫我們寫程式、甚至幫我們管理伺服器時，我們手上的金鑰只會越來越多、權限只會越來越大。也許是時候重新檢視一些過去覺得「麻煩」的習慣了：金鑰一定要設到期日、權限能小就小、機密不要明文落地、定期輪替而不是出事才換，以及——不要把所有雞蛋放在同一個籃子裡。
如果你也是 Zeabur 的使用者，記得在 12 月前完成備份與遷移，並且把所有環境變數裡的憑證再換一次，包括八月之後已經換過的。你會選擇搬到哪個平台，還是乾脆像程式貓一樣自己架呢？
資料來源
Zeabur 官方 — 2026 年十月資安事件（初步報告）
iThome — Zeabur再遭駭後公布調查結果，攻擊者讀取逾321萬筆環境變數
數位時代 — Zeabur兩度遭駭後宣布停運！12月31日全面關站，備份、退款時程一次看
INSIDE — Zeabur 宣布停止營運！12 月 31 日前全面關閉，專用伺服器 12 月 1 日起停止續費
蕃新聞 — Zeabur宣布將停止營運 消保官：退費原則應以原支付貨幣返還
BleepingComputer — Zeabur shutting down after second security breach in two months
GitGuardian — New Railway Incident: Treat Every Env Variable as Exposed
OfficeChai — Cloud Platform Railway Discloses Security Breach, Pauses All Deployments
Vercel — April 2026 Security Incident
Wiz — PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
The Register — Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure
DEV Community — October 2026 Security Incidents: Supply Chain, CAs, and Cloud Breaches
Dokploy — The Self-Hosted PaaS Built for Developers
二.遊戲角色怎麼知道我推多大力？從電壓變化到數位數值，認識類比數位轉換器「ADC」
作者:昀
在第三十五期中，我們聊到了超商自動門如何透過「中斷機制」來偵測人體。那種紅外線感測器就像是一個數位開關，只有「有人 (1)」跟「沒人 (0)」兩種狀態。但在現實生活中，大部分的物理現象並不是非黑即白的，而是連續的漸變。
真實世界是「連續」的，但微控制器只懂「0 與 1」
當你在玩射擊遊戲或賽車時，輕輕推搖桿跟把搖桿推到底，角色的移動速度和視角轉動幅度是完全不同的。這種「推多大力」的連續變化，在硬體底層其實大多是透過轉動「可變電阻 (Potentiometer)」來感測。
當你推動搖桿，它會產生 0V 到 5V 之間連續的電壓變化（例如 2.3V、4.1V）。然而，微控制器（MCU）的大腦裡只有數位邏輯的 0 與 1，它聽不懂什麼叫做「2.3V 的電壓」。
圖 1：類比與數位訊號的差異
左側的可變電阻會產生一條連續上升的斜線訊號 (Continuous) ；但要轉換為數位訊號時，必須將其切割成階梯狀 (Stepped) 的離散數值[cite: 7]。
這時候，我們就需要一位翻譯官來幫忙將連續的斜線，轉換成 MCU 聽得懂的階梯。
軟硬體之間的翻譯官：類比數位轉換器 (ADC) 的底層原理
這位翻譯官就是 ADC（Analog-to-Digital Converter，類比數位轉換器）。它的工作是把連續的電壓變化，切分成無數個微小的「數位階梯」。
為了深入理解 ADC 是如何運作的，我們可以先看一個最基礎的「2 位元 (2-bit) ADC」內部電路：
圖 2：2 位元類比數位轉換器電路
這是一個 2 位元 ADC 內部電路。透過串聯的電阻 (R) 產生不同的參考電壓 (1V, 2V, 3V)，再利用運算放大器構成的比較器 (U1, U2, U3) 來判斷輸入電壓 (VIN) 的高低，最後經過優先編碼器 (Priority Encoder) 輸出數位訊號[cite: 9]。
圖 3：2 位元 ADC 轉換器輸出真值表
(當輸入電壓介於 0-1V 時，比較器全為 0，數位輸出為 00；當電壓上升至 2-3V 時，比較器 D1 與 D2 會被觸發為 1，編碼器則會輸出對應的數位邏輯 10 [cite: 10]。)
透過上面的電路與真值表可以發現，ADC 其實是利用硬體電路的「比較器」來達成翻譯工作[cite: 9, 10]。
在我們常用的微控制器（例如 Arduino Uno）中，內建的是更精密的 10 位元（10-bit）ADC。它可以把 0V 到 5V 的電壓，精準地切割成 210=1024 個階距（範圍從 0 到 1023）。
所以，當你把搖桿推到正中間（大約 2.5V），ADC 就會把它翻譯成數字「512」；推到底（5V），數字就是「1023」。MCU 拿到這個明確的整數後，就能瞬間明白：「喔！原來玩家現在推了 50% 的力道」。
概念驗證：打造包含「實體反饋」的動力儀表板
為了具體呈現這個過程，我在 Tinkercad 中實作了一個進階的概念驗證。我不只將「可變電阻」作為類比輸入（模擬搖桿），還同時加入了「伺服馬達」與「三色 LED 陣列」作為輸出端。
圖 4：Tinkercad 概念驗證：ADC 動力儀表板完整電路設計
透過程式邏輯，我把 ADC 讀取到的數值（0-1023），等比例映射（Mapping）到伺服馬達的旋轉角度（0-180度）。同時，我撰寫了多重條件判斷式（if-else）：當推力小於 30% 時亮綠燈、到達 50% 時加亮黃燈、推到底時紅燈齊亮。
圖 5：實體狀態反饋：類比數值等比例映射至馬達角度與 LED 燈號
實作結果非常直觀：當我在畫面上轉動旋鈕，馬達的指針分毫不差地同步轉動，旁邊的 LED 燈也像賽車儀表板一樣隨之蓄力亮起。這跨出了傳統的「開關思維」，正是所有工業機械手臂、無人機姿態控制，甚至是汽車電子油門踏板背後的底層控制邏輯——「比例控制 (Proportional Control)」。
跨越虛實邊界的橋樑 從 GPIO 的數位開關，到 ADC 的連續讀取，我們在系統控制上又向真實世界邁進了一大步。
很多人覺得寫程式就是在電腦螢幕裡創造虛擬世界，但對我們來說，最迷人的瞬間，是看到自己寫出的程式碼，精準地捕捉了現實世界的物理微小變化，並轉化為肉眼可見的實體動作。ADC，正是這座跨越虛擬與現實最不可或缺的橋樑。
參考資料：
Electronics Tutorials: Analogue to Digital Converter Basics
(註：本文內容與 Tinkercad 模擬皆為本人親自實作撰寫，僅以 AI 輔助語句潤飾。)
三.一個 IP 位址，能找到一個人嗎？實測網路定位的界線
作者:游錐
網路上有許多網站宣稱，只要輸入一個 IP 位址，就能查出對方所在的國家、城市，甚至經緯度。但地圖上的那個點，真的代表一個人所在的位置嗎？我們從公開 IP 位址出發，嘗試用不同工具追查它的來源，看看這些數字究竟能揭露多少資訊。
地圖上的一個點
在網路上，只需要一串數字，就能查詢一個 IP 位址可能來自哪裡。
打開 IP 定位網站，輸入一個公開 IP，畫面很快就會顯示國家、城市，有些服務甚至會提供經緯度。看著地圖上的標記，很容易讓人以為，只要取得某人的 IP，就能在地圖上找到他。
但這個點究竟代表什麼？
它可能是網路服務商登記的區域、某個網路出口的位置，也可能只是資料庫根據既有資訊推估出的結果。它不一定是使用者當下所在的地方，更不一定是住址。
為了弄清楚 IP 定位究竟能做到什麼程度，我們決定從一個公開 IP 位址開始，分別查詢地理定位資料、網路註冊資訊與網路連線路徑，再比較不同來源能提供哪些線索。
這次調查的問題很簡單：如果我們只知道一個 IP 位址，究竟能查到多少關於它的位置資訊？
從一串數字開始
IP 位址是網路設備交換資料時使用的位址。當我們開啟網站、觀看影片或傳送訊息時，網路需要知道資料應該送往哪個目的地，而 IP 位址就是這個過程中的重要資訊之一。
不過，IP 位址並不像身分證字號一樣，能直接對應到一個特定的人。
一個家庭裡可能有多台手機、電腦與智慧家電，卻共用同一個對外公開的 IP 位址；電信業者也可能讓大量使用者透過共同的網路出口連線。反過來說，同一個人也可能因為切換 Wi-Fi、使用行動網路或連上 VPN，而呈現不同的公開 IP。
因此，我們真正能調查的，是這個 IP 所屬的網路，以及它可能對應的地理位置，而不是直接從一串數字認出使用者。
為了避免把其他人的私人資訊當成實驗材料，我們先選擇公開提供的 8.8.8.8 作為測試目標。這是 Google 提供的公開 DNS 服務位址，適合用來示範如何查詢公開網路資訊。
它並不是某位使用者的私人 IP，也不能用來代表一般網路使用者的位置。
第一個線索：定位網站顯示了什麼？
我們首先使用 IP 地理定位服務查詢測試位址。
例如，MaxMind 提供的 GeoIP Demo，可以讓使用者輸入 IP 位址，查看資料庫對該位址的地理位置判定。
操作方式很簡單：開啟 GeoIP Demo，輸入 8.8.8.8，再記錄網站實際顯示的國家、城市與其他可用資訊。
但查詢結果需要被放回正確的脈絡中理解。
地理定位服務通常會利用 IP 位址分配資訊、網路資料及其他來源建立資料庫，再根據這些資料推估位置。它並不是直接讀取連線者的 GPS 座標。
換句話說，網站顯示的座標，是資料庫對這個 IP 的判定，不是它直接測量到使用者的位置。
如果不同服務顯示不同的城市，這可能代表它們採用了不同的資料來源或判定方式。如果結果一致，也不能立刻證明使用者真的位於該城市，因為不同服務可能引用相同或相近的資料。
第一個線索因此只能告訴我們：資料庫認為這個 IP 可能位於哪裡。
它還不能回答，實際使用這個 IP 的人在哪裡。
第二個線索：這個 IP 屬於誰？
接著，我們試著查詢 IP 位址的網路註冊資料。
在 macOS 或 Linux 的終端機中，可以執行：
whois 8.8.8.8
如果系統沒有提供 whois 指令，也可以使用公開的網路註冊資料庫，例如 RIPE Database
查詢結果可能包含網路名稱、位址範圍、管理組織與通報濫用事件的聯絡資訊。這些欄位能幫助我們理解 IP 位址由哪個組織管理，或屬於哪個網路範圍。
不過，註冊資料也有自己的限制。
管理一段 IP 位址的組織，不一定就是實際提供服務的公司；提供服務的公司，也不一定就是使用者所在的地點。大型網路業者可能在多個國家設置設備，伺服器也可能由其他企業代管。
因此，即使註冊資料顯示某個國家，也不能直接推論使用者就在那個國家。
如果第一個定位網站顯示某個城市，而註冊資料又出現另一個國家，我們不應急著判定其中一方錯誤。兩筆資料可能回答的是完全不同的問題：前者估算網路位置，後者記錄網路資源的管理資訊。
真正重要的，是釐清每一筆資料代表什麼，而不是從中挑出看起來最精確的答案。
第三個線索：沿著網路連線追查
如果地理定位與註冊資料都無法確認實際位置，是否可以沿著網路連線一路追查？
我們接著使用 traceroute，觀察資料從自己的裝置前往目標 IP 時，會經過哪些可以回應的網路節點。
在 macOS 或 Linux 上，可以輸入：
traceroute 8.8.8.8
Windows 則可以執行：
tracert 8.8.8.8
這類工具會利用封包的存活時間限制（TTL），逐步觀察沿途網路設備回傳的訊息，列出部分節點及其回應時間。
例如，結果可能包含多行 IP 位址與毫秒數。每一行通常代表一個觀察到的網路跳點，而不是地圖上的一個實體位置。
實際輸出會依使用者的網路環境、路由方式與目標而有所不同。有些節點可能不回應探測封包，因此出現星號不代表該節點一定不存在，也不代表連線必然遭到阻擋。
我們可以把實際結果記錄下來，觀察哪些節點能夠回應、延遲如何變化，再嘗試查詢部分節點的 IP 資訊。
然而，這裡存在一個重要的限制：網路路徑不等於地理路線。
封包經過的順序，是由網路路由機制決定的，不一定符合地理上的最短距離。即使某個節點的 IP 被定位到特定城市，也不能保證設備本身就在那裡。
Traceroute 可以協助我們理解資料如何在網路中傳遞，卻無法單靠路徑還原某個使用者的實際位置。
三種資料放在一起，能得到什麼結論？
經過前面的查詢，我們可以從三個角度觀察同一個 IP 位址。
| 調查方式 | 可以提供的線索 | 無法單獨證明的事 |
|---|---|---|
| IP 地理定位 | IP 可能對應的地理區域 | 使用者的精確位置 |
| 網路註冊資料 | IP 的管理組織與分配背景 | 當下使用者的身分 |
| 網路路徑分析 | 可觀察到的網路節點與延遲 | 每個節點的實際所在地 |
如果三種資料彼此一致，我們可以對這個 IP 所屬的網路建立較完整的認識；如果資料互相矛盾，則需要進一步釐清資料來源、更新時間與判定方式。
但這裡還有一個容易被忽略的問題：不同工具提供的資訊，不一定代表彼此獨立的證據。
例如，多個定位網站可能使用相同的商業資料庫。如果它們都顯示同一座城市，結果的一致性可能只是因為它們引用了相同來源，而不是多次獨立驗證了這個位置。
因此，調查時除了記錄結果，也應該記錄查詢時間、使用的服務與資料來源。只有先釐清證據的性質，才有辦法判斷它究竟支持什麼結論。 如果換一種網路環境，位置還會一樣嗎？ 前面的測試只能說明一個公開 IP 的資料可能如何被查詢。若要進一步了解 IP 定位的限制，我們還需要考慮不同網路環境。
例如，同一台手機在家中使用 Wi-Fi 時，網站看到的可能是家用網路的公開 IP；切換到行動網路後，網站看到的則可能是電信業者分配的另一個 IP。
如果使用者開啟 VPN，網站通常會看到 VPN 出口的 IP，而不是原本網路的公開 IP。
這些情境說明，IP 定位服務所查詢的對象，是網路連線使用的 IP，而不一定是使用者本人。
若要實際比較這些差異，可以在自己控制的裝置上，分別記錄 Wi-Fi、行動網路與 VPN 連線時對外呈現的公開 IP，再將這些 IP 輸入相同的定位服務。
測試時應維持查詢工具一致，並記錄每次查詢的時間與結果。若條件允許，也可以重複查詢，觀察資料是否會因時間或資料庫更新而改變。
這樣的測試能呈現不同網路環境下的定位差異，但仍不能直接證明某一種網路必然會定位到特定城市。實際結果取決於服務商的網路配置與定位資料。
IP 定位的界線，也是隱私的界線
IP 位址可以透露部分網路資訊，但它的價值不只在於地理定位。
在某些情境中，IP 位址可以協助網站判斷流量可能來自哪個國家或地區，用於風險控管、內容區域限制或異常連線分析。網路管理者也可以利用 IP 與其他紀錄，調查連線問題或濫用行為。
然而，當我們想從 IP 進一步推論一個人的身分、住址或行動軌跡時，問題就變得複雜許多。
IP 位址可能被多人共用，也可能隨著連線方式改變。要把某個連線事件對應到特定使用者，通常還需要其他資料，例如特定時間的服務紀錄、電信業者保存的分配紀錄，以及適當的法律程序。
即使取得更多資料，也必須考慮紀錄的完整性、時間是否一致，以及是否存在其他合理解釋。
這也是為什麼不應只憑 IP 定位結果，就公開指認某人住在哪裡，或認定某個人曾經從特定地點連線。
地圖上的標記看起來很精確，但畫面呈現的精確度，不等於證據本身的精確度。
結語：找到一個位置，不代表找到一個人
從一個公開 IP 位址開始，我們可以查詢地理定位資料、網路註冊紀錄，甚至觀察封包經過的網路節點。這些方法能讓我們對網路連線有更深入的認識，也能協助我們判斷某些資訊是否合理。
但每一種工具都有自己的限制。
地理定位提供的是估算，註冊資料描述的是網路資源的管理背景，網路路徑則呈現資料傳遞過程中的部分節點。三者可以互相補充，卻不能直接拼湊成某個人的精確位置。
IP 定位真正值得探討的，不是它能否在地圖上顯示一個點，而是那個點背後究竟有哪些資料、推論與不確定性。
當我們在網路上看到一個看似精確的定位結果時，最應該追問的或許不是「這個人在哪裡」，而是：「這項結果是怎麼得來的？它又能證明到什麼程度？」
因為在數位世界裡，找到一個位置，和找到一個人，始終是兩件不同的事。