網站搬到新主機、把 DNS 紀錄改好之後，隔了一整天打開瀏覽器，畫面卻還是連到舊主機的內容，甚至完全打不開。這時候盯著網址欄看不出任何線索，因為瀏覽器連線靠的從來不是那串英文字母，而是 DNS 解析出來的一組數字位址。
網址IP查詢，做的正是把一個網域名稱解析成它實際指向的 IP 位址，再往下追這個位址背後掛在哪家主機商、放在哪個地區。查得到位址不代表查得到真相，因為 CDN、代理服務、多組 DNS 紀錄都會讓答案變得複雜，光看一個查詢結果就下定論，很容易查錯方向。
搞懂這套查詢方法，能在搬家換主機後確認 DNS 是不是真的切過去，也能在收到可疑網站時找到該通報的窗口。網域名稱背後對應的是什麼，由 DNS 解析出的那組數字才是真正牽動連線的東西。
網域名稱背後，對應著一組 IP 位址
在瀏覽器輸入一個網址，按下 Enter 的那一刻，電腦做的第一件事不是連線，而是先向 DNS 系統查詢這個網域目前對應哪一組 IP 位址。拿到答案之後，瀏覽器才真的連上那組位址，把網頁內容抓回來顯示在畫面上。nslookup.io 在說明這套流程時，把這個過程拆成兩步：先解析出網域名稱對應的 IP 位址，再連到該位址把網頁內容抓下來。
這組位址在 DNS 裡分成兩種紀錄。A 記錄存放的是 IPv4 位址（例如 192.0.2.1 這種四段式數字），AAAA 記錄存放的是 IPv6 位址（一串用冒號分隔的十六進位數字）。dnschecker.org 的說明也呼應這一點，兩種紀錄各自對應不同版本的 IP 協定，查詢時要指定要哪一種，才不會拿到答案卻搞錯是 IPv4 還是 IPv6。
多數人以為一個網域只會對應一組固定的 IP，實際情況常常更複雜。同一個網域可以同時掛上好幾組 IP 位址，分散流量、互相備援，反過來，一組 IP 位址也可能被好幾個網域共用，尤其是共享主機或多租戶的雲端服務，一台伺服器上跑著幾十個網站，對外都是同一組位址。dnschecker.org 特別提醒，網域與 IP 之間不是唯一對應的關係，每個網域至少要有一組 IP 才能被存取，但不代表這組 IP 只屬於它一個。這個分歧點，也是後面查 CDN、查代管業者時最容易誤判的地方。
位址與網域不是唯一對應的關係，這件事決定了查詢的動機通常不只一種，同樣是查一個網址的 IP，搬家的人、抓詐騙線索的人、要評估雲端服務的人，各自要的答案都不一樣。
查網址 IP 位址的理由不只一種
大致可以分成四種情境。第一種最常見：把網站搬到新主機或換了主機商之後，要確認 DNS 是不是真的切到新主機的 IP，還是快取沒清乾淨、瀏覽器抓到的仍是舊位址。第二種是想知道一個網站是不是掛在 CDN 或雲端代理後面，理解它實際的連線路徑，這在評估一個站台的架構、或想確認對方基礎設施規格是否屬實時特別有用。
第三種是收到疑似詐騙或濫用的網站，想找出負責那段 IP 位址的代管業者，好把檢舉送到正確的窗口。第四種則牽涉合規判斷：評估合作對象或雲端服務把資料放在哪個地區，是初步判斷個資存放地是否符合法規要求的第一步，詳細的法規義務因產業與服務類型而異，這裡只談查詢層面能先掌握的線索。
這幾種情境有一個共通點，查到的 IP 位址只是起點，真正有用的是位址背後那個組織是誰的答案。至於一個網站打不開該怎麼排除故障，或是一個網站的全球流量排名怎麼判斷，是完全不同的另一組問題，跟查 IP 位址與代管業者是兩件事。
不管是哪一種動機，要查到答案都得從同一個起點出發，把網域翻譯成 IP 位址，而且這一步不必依賴任何第三方網站，作業系統本身就有內建工具。
命令列查出網域對應的 IP 位址
Windows、Mac 與 Linux 都內建能查 IP 位址的工具，不用開瀏覽器裝任何東西。差別在於介面與指令名稱不同，Windows 常用 nslookup，Mac 與 Linux 慣用 dig，兩者查到的都是同一件事，網域對應的 A 記錄（IPv4）或 AAAA 記錄（IPv6）。
nslookup.io 的教學把兩邊的指令都列出來：Windows 開啟命令提示字元後輸入nslookup -q=A example.com可以直接取得 IPv4 位址，結果會列在輸出的「Non-authoritative answer」區塊底下；要查 IPv6 時把參數裡的 A 換成 AAAA 即可。Mac 與 Linux 則開啟終端機，輸入dig example.com A取得 IPv4 位址，結果列在「ANSWER SECTION」裡，同樣把 A 換成 AAAA 就能查 IPv6。
Windows 用命令提示字元查 IP 位址
Windows 下的 nslookup 可以帶參數直接查一次就結束，也可以進入互動模式一次查好幾筆。國立成功大學的教學示範了互動模式的做法：在命令提示字元輸入nslookup後按下 Enter，畫面會停在等待輸入的狀態，這時候直接打入要查的網域名稱（例如www.ncku.edu.tw）並按 Enter，就會看到查詢結果，包含對應的 IP 位址，該教學示範查到的結果是140.116.241.66。
nslookup
www.ncku.edu.twCode language: Bash (bash)nslookup 預設查的是這台電腦目前設定的 DNS 伺服器，這件事常常被忽略，卻直接影響查到的結果。如果這台電腦接在家用網路分享器底下，nslookup 可能會先顯示一個 192.168 開頭的內網位址，那其實是分享器本身的位址，不是要查的網域。這時候可以在 nslookup 的互動環境輸入server 8.8.8.8切換成 Google Public DNS，或改用 Cloudflare 的 1.1.1.1，重新查詢一次就能拿到公開、一致的結果。
如果查不到結果，常見有兩種可能：這個網域根本不存在，或是目前指定的 DNS 伺服器沒有正確回應。換一個公開 DNS 伺服器（8.8.8.8、8.8.4.4 或 1.1.1.1）重新查一次，通常就能排除是 DNS 伺服器端的問題。
Mac 與 Linux 改用終端機執行 dig 指令
Mac 與 Linux 上，查詢 DNS 的慣用做法是用 dig 指令，語法比 nslookup 的互動模式更直接，一行就能查完，不需要先進入等待輸入的狀態。Mac 用「終端機」App、Linux 用系統內建的終端機，兩邊指令完全相同。
dig example.com ACode language: Bash (bash)執行後，查詢結果會列在輸出內容的「ANSWER SECTION」區塊底下，這一段就是 DNS 真正回覆的資料，包含網域名稱、紀錄類型與對應的 IP 位址。要查 IPv6 位址，把指令裡的A換成AAAA即可，其餘語法不變：
dig example.com AAAACode language: Bash (bash)跟 nslookup 一樣，dig 查到的內容也是照電腦目前設定的 DNS 伺服器去問；如果懷疑本機 DNS 設定有問題，可以在指令後面加上伺服器參數，指定要問哪一台 DNS 伺服器，例如dig example.com A @1.1.1.1就是直接問 Cloudflare 的公開 DNS。
免安裝的線上 IP 與 DNS 查詢工具
不想開終端機、或想一次看到更多背景資訊的人，做網址IP查詢時，線上工具做的其實是同一件事，只是多包了一層地理定位與代管業者資料庫的查詢。輸入一個網域，工具會先在背景做一次即時的 DNS 解析找出對應的 IP 位址，再拿這組位址去查地理定位與 ASN（自治系統編號）資料庫，藉此判斷這個位址掛在哪家主機商、哪個網路業者底下。nslookup.io 的 Website Hosting Checker 會一併檢查 DNS 紀錄、IP 位址、ASN 資訊與 CDN／代理跡象，一次查詢通常會同時回傳：代管業者、IP 位址、ASN 與網路業者、伺服器所在地區、DNS 服務商、名稱伺服器、有沒有掛 CDN 或代理、SSL 憑證與郵件伺服器紀錄，一次到齊，不用像命令列那樣一項一項分開查。
有些工具還能切換要問哪一組 DNS 伺服器，這在懷疑 DNS 紀錄還沒完全同步、或想確認不同地區使用者拿到的答案是否一致時很有用。以 dnschecker.org 為例，它的網域 IP 查詢工具可以在 Google、OpenDNS、Cloudflare、Quad9、Yandex 這 5 組公共 DNS 之間切換，查完的結果也能下載成 TXT 或 Markdown 檔案存起來備查；同站的 DNS 傳播檢查則是同時向全球多個地區的 DNS 伺服器發問，再把結果並排讓你比對。
要留意的是，線上工具的方便是建立在多查了幾個資料庫上，資料庫本身的準確度跟即時性不是工具能保證的，尤其是地理定位查到的位置能信到什麼程度，得另外看。
IP 地理定位查到的只是概略範圍
IP 地理定位查到的從來不是一個精確地址，而是這組位址大概落在哪個較大的地理範圍。MaxMind 在說明地理定位原理時把這一點講得很直白，地理定位資料庫存在的目的不是揭露某個人的實際居住地，設計上就不應該被拿來定位到個人或特定住戶；回傳的座標也不夠精確到指認某條街道或某個門牌。
正因為如此，查詢結果通常會附上一個準確度半徑，用來說明實際位置大概落在這個圓形範圍裡的哪裡。MaxMind 自己的說明文件裡舉的例子，座標會搭配一個約 100 公里的準確度半徑，提醒使用者這組座標本身只是一個機率中心點，不是絕對定位；不同 IP 的精細度落差很大，有些能精細到 5 公里內，有些則會拉大到數百公里。同一份查詢報告裡，兩個地址位置聽起來一樣具體，實際準確度可能天差地遠。
國家層級與城市層級的準確度落差
查得到國家跟查得到城市，兩者的準確度落差不小。MaxMind 的統計顯示，城市層級的典型準確度大約落在 20%到 75%之間，落差取決於這個地區的網路型態，人口密集、以住宅寬頻為主的大城市，準確度通常比較高；鄉下地區或以商用線路為主的網路，誤差往往拉得更大，查到的城市名稱可能只是那一整段 IP 的登記地址，不是使用者實際所在的城市。
實務上比較保險的用法，是把國家層級的判定當成可信度較高的參考，城市層級的判定當成方向性的線索，不當成最終依據。要評估雲端服務或合作對象宣稱的機房地區是否屬實，國家層級的查詢結果已經足以當初步判斷；要精確到某座城市，則得搭配其他佐證一起看，單靠一次地理定位查詢下結論並不穩妥。地理位置查得再準，也只是伺服器擺在哪裡的線索，還沒回答另一個常被搞混的問題，這個網站是誰在管。
網域註冊資訊和 IP 網段歸屬，查的不是同一件事
很多人以為，查一個網域的 WHOIS 就等於查到誰在代管這個網站，實際上這是兩套完全不同的查詢。查網域註冊資料回答的是這個網址是誰登記的，查 IP 網段歸屬回答的是這段位址被分配給哪個組織，也就是實際的主機商或雲端服務商。這兩個答案常常對不上同一家公司，網域可能是某個代理商幫忙註冊的，但網站實際跑在完全不同的一家雲端服務公司的機房裡。
把這個分野搞清楚，才不會查了半天 WHOIS，卻誤以為查到的註冊商就是網站背後的主機商。
網域 WHOIS 或 RDAP 只查得到註冊資訊
在一般頂級網域的領域，WHOIS 這個查詢協定已經走入歷史。根據 ICANN 在 2025 年 1 月的官方公告，gTLD 的 WHOIS 服務已於 2025 年 1 月 28 日正式退場，同一天起，RDAP（Registration Data Access Protocol，註冊資料存取協定）成為查詢一般頂級網域（gTLD）註冊資料的正式來源。RDAP 由網際網路工程任務組（IETF）制定，實際上從 2019 年起就已經由 ICANN 認證的註冊商與 gTLD 陸續提供，只是到 2025 年才正式取代 WHOIS，成為 gTLD 註冊資料的正式來源；跟舊版 WHOIS 自由格式的文字輸出不同，RDAP 回傳的是結構化資料，程式處理起來更容易。ICANN 也提供了官方的線上查詢工具，不用另外裝任何軟體就能直接查。
不管是舊的 WHOIS 還是新的 RDAP，查到的內容性質都一樣：這個網域是哪家註冊商登記的、註冊日期與到期日、目前指定的名稱伺服器。這些是網域本身的登記資料，不是主機所在地，也不是代管業者。
台灣的.tw 與.台灣網域則另外由 TWNIC（財團法人台灣網路資訊中心）維運查詢服務，可以查到 DNS 設定、IP、註冊人、註冊與到期日期等公開資訊。TWNIC 在 2023 年 6 月 1 日調整過 WHOIS 查詢結果的顯示內容，上一次調整是 2018 年，是為了因應歐盟 GDPR 上路，目前查得到的欄位以註冊必要資訊為主，個人聯絡細節已經有一定程度的遮蔽。
IP WHOIS 與 ASN 才查得到網路業者身分
要查誰在代管，得改查 IP 本身的 WHOIS 紀錄與 ASN，這裡查到的組織名稱才是實際的主機商、雲端服務商或網路業者，跟網站經營者、網域註冊人是不同層次的資訊。ARIN（負責北美地區位址分配的機構）官方文件說明，IP 的 WHOIS 查詢結果裡，Net（網段）紀錄包含 NetRange（IP 位址範圍）、CIDR、Name（該組織為這個網段取的名稱）等欄位；ASN 紀錄則包含 Number（自治系統編號）與 Name（該組織為這個 ASN 取的名稱）。
這些紀錄背後關聯的組織很關鍵——它通常就是實際持有、租用這段 IP 位址的主機商或網路業者，不是網站經營者本人，也不是網域註冊人。APNIC（負責亞太地區的機構）對自治系統的定義是，由一個或多個網路業者依同一套明確的路由政策營運、彼此相連的一組 IP 位址前綴；所以查 IP WHOIS 得到的組織資訊，答的是這段位址由哪個網路業者管，而不是這個網域是誰註冊的。
同一個網站可能在網域 WHOIS 查到的是一家台灣的網域代理商，在 IP WHOIS 查到的卻是一家完全不相關的國際雲端服務公司。兩個答案都對，只是回答的問題不一樣。知道兩套查詢問的是不同問題之後，實際要查一段 IP 的歸屬，得先判斷這個位址大概落在哪個區域，再到對應的區域機構查詢；如果查的是.tw 網域，還得另外查一次 TWNIC。
逐步查出 IP 網段和代管業者的歸屬
全球公開的 IP 位址空間，不是由單一機構統一管理，而是切成五個區域分別授權。NRO（Number Resource Organization，號碼資源組織）的官方說明指出，全球公共 IP 位址空間由五個區域網際網路註冊機構（RIR）依地區分工管理：ARIN 負責北美、RIPE NCC 負責歐洲與中亞、中東，APNIC 負責亞太地區，LACNIC 負責拉丁美洲與加勒比海，AFRINIC 負責非洲；IANA（網際網路號碼分配局）依各區域的實際需求，把位址空間分配給這五個機構，再由各區域機構往下分配給旗下的網路業者。
五大區域網際網路註冊機構的查詢入口
查到一組國外的 IP 位址時，要判斷它屬於哪個區域，才知道該去哪個機構的 WHOIS 查詢入口查。以亞太地區（含台灣多數的 IP 資源）來說，主要入口是 APNIC。APNIC 的官方指南說明，APNIC Whois 資料庫裡，inetnum（IPv4）與inet6num（IPv6）物件記載該網段被分配給哪個組織，查到的組織名稱就是實際持有那段位址的業者；另外還有一種irt物件，專門記載負責處理網路濫用申訴的聯絡窗口。
如果一時判斷不出這組位址屬於哪個區域，也不用逐一手動比對，大部分的線上查詢工具與命令列指令，輸入 IP 位址後都會自動導向正確的區域機構，不用自己先查一輪地理位置才能決定去哪查 WHOIS。
.tw 網域另外要查的 TWNIC 資訊
.tw 與.台灣結尾的網域，除了查 IP 本身的 WHOIS，還要另外查一次 TWNIC 才看得到網域本身的註冊管理資訊。TWNIC 目前是受數位發展部監督管理，負責維運.tw 與.台灣網域註冊系統的非營利機構，不是一般商業註冊商。TWNIC 官方提供線上 WHOIS 查詢服務，可以查到網域註冊人、註冊與到期日期、目前使用的名稱伺服器等公開資訊。
要留意的是，TWNIC 查到的是網域本身的登記資料，跟這個網站實際掛在哪家主機商的伺服器上，仍然是前面說的兩件事，一台掛著.tw 網域的網站，伺服器完全可能架在國外的雲端機房裡，查 TWNIC 查不出這件事，得另外查 IP WHOIS 或 ASN 才知道。
CDN 代管顯示的是邊緣節點，不是真正主機
前面幾節查到的位址、地理位置、代管業者組織名稱，都有一個常見的失真來源，網站如果掛在 CDN 或代理服務後面，查到的答案很可能都不是網站真正租用的那台主機，而是 CDN 業者自己的邊緣節點。
Cloudflare 官方文件說明，啟用代理（俗稱橙雲，proxied）的 DNS 紀錄，目的就是隱藏 origin 主機（真正跑網站程式的那台伺服器）的真實 IP 位址，同時提供 DDoS 防護；同一份文件也列出更進一步的做法，在 origin 主機端只放行 Cloudflare 的 IP 位址、擋掉其他來源的流量，否則有人一旦知道 origin 的 IP，請求仍可能繞過 CDN 直接打到真正的主機上。只要一個網站的 DNS 是 Cloudflare 的橙雲在運作，查到的組織名稱通常會變成 Cloudflare 本身，不是網站經營者租用的原始主機商。
Cloudflare 自己的文件也提醒了一個常見的破口，對一個啟用橙雲的網域做 dig 查詢，得到的會是 Cloudflare 的位址，origin 主機的真實 IP 不會公開曝露；但如果同一個帳號底下，同時存在一筆設定成僅限 DNS（DNS-only，俗稱灰雲）的紀錄指向同一台 origin 主機，例如一個沒設代理的子網域，或郵件伺服器用的紀錄，對那筆紀錄查詢，就會把 origin 的真實 IP 位址整個曝露出來。SPF、TXT 這類紀錄裡如果不小心留了 origin 的 IP，也是同樣的破口。
nslookup.io 的說明也點出同一個現象：有些網站把 origin 主機藏在 CDN、反向代理或資安服務後面，這時候公開查得到的 IP 位址，可能屬於 Cloudflare、Akamai、Fastly、AWS CloudFront 這類邊緣網路業者，而不是網站原本租用的主機商。要判斷查到的答案是不是 CDN 的邊緣節點，可以留意查到的 ASN 組織名稱是不是這幾家知名的 CDN 與雲端業者，如果是，代表查到的只是流量的第一站，不是網站真正落腳的地方。
代管資訊查到後能延伸出四項運用
查到 IP 位址、地理位置、代管業者之後，這些資訊真正的用處，是拿去核對、拿去通報，而不是查完就結束。以下四種情境，各自對應具體要做的下一步動作。
搬家或換主機之後，把新主機商提供的 IP 位址記下來，隔幾個小時用命令列或線上工具重新查一次網域對應的 A 記錄，兩者比對是否一致；如果查到的 IP 還是舊主機商的位址，通常是 DNS 紀錄的存活時間還沒過期，或是本機、瀏覽器的 DNS 快取沒清掉，換一台裝置或換一組公開 DNS 伺服器重查一次，就能排除是快取的問題還是紀錄真的沒切過去。
收到疑似詐騙或濫用的網站時，查出這段 IP 網段的 ASN 與代管業者名稱之後，下一步是直接向該業者提報，而不是找上網站表面看起來的經營單位。APNIC 等區域機構的 WHOIS 紀錄裡通常會有irt物件，列出負責審核濫用申訴的聯絡窗口，把截圖、發生時間、涉及的網址一併附上，遞交到這個窗口，比透過網站上的聯絡表單反映更容易被實際處理。
評估一項雲端服務或合作對象時，先查出對方伺服器實際落在哪個地理區域，再對照對方合約或說明文件上寫的機房地點是否一致；如果查到的地區跟對方宣稱的不同，這是值得直接提出來確認的落差，尤其牽涉到資料存放地是否符合特定法規要求時，這個查詢結果可以當成先問清楚的依據，而不是簽約後才發現問題。
核對合作對象或供應商的基礎設施規格時，把 ASN 查到的組織名稱、代管業者，拿去跟對方自我介紹裡提到的技術棧或雲端平台對照；查到的代管業者如果跟對方宣稱的雲端服務商不一致，通常代表對方實際外包給了另一家業者，或是資訊沒有更新，這時候直接拿查詢結果去問，會比單憑對方的說法更有依據。
一次查詢工具秀出來的位址、地區、代管業者，拆開來看都只是片段的線索，真正有用的判斷，來自把 DNS 解析、地理定位的準確度限制、網域註冊與 IP 網段歸屬這幾層線索兜在一起看，而不是只看其中一項就下結論。下次做網址IP查詢時，先把命令列或線上工具打開查一次，再回頭核對業者的說法，通常就能在對方回覆之前，自己先掌握大部分的答案。