{"id":54,"date":"2026-10-10T16:40:00","date_gmt":"2026-10-10T16:40:00","guid":{"rendered":"https:\/\/www.myipinquire.com\/blog\/?p=54"},"modified":"2026-10-08T03:03:22","modified_gmt":"2026-10-08T03:03:22","slug":"cdn-and-proxy-edges-change-what-a-lookup-sees","status":"publish","type":"post","link":"https:\/\/www.myipinquire.com\/blog\/cdn-and-proxy-edges-change-what-a-lookup-sees\/","title":{"rendered":"CDN and Proxy Edges Change What a Lookup Sees"},"content":{"rendered":"

TL;DR:<\/strong> A website’s address is often a door belonging to a content network or a proxy, not a single machine in a back room. Your lookup of that domain can show an edge city far from the company. Your own public IP is a separate fact. When a tool “sees the wrong IP,” decide whether you queried yourself or the site. Look up the address or domain on Ipsaya<\/a> and write down which question you asked.<\/p>\n

The shop that appeared to live in another country<\/h2>\n

A potter took payments through a small storefront platform. A customer claimed the site was “hosted in a country the potter had never visited” and sent a screenshot of a lookup. The screenshot was a real address, and the location database placed it with a large content network on another continent. The potter’s laptop, her photos, and her bank were still in her town. The storefront’s name pointed at an edge that caches pages close to buyers. The customer’s lookup answered “where did this name send me?” The customer heard “where does this person live?” Those questions share a text box and nothing else.<\/p>\n

Edges, proxies, and the address you get<\/h2>\n

Content networks announce many addresses for one name. Two lookups an hour apart can differ because the DNS answer changed, and both can be correct. A reverse proxy in front of a company’s origin shows the proxy, because that is the machine that accepted the connection. An origin hidden behind the proxy is doing what the proxy was hired to do. You will not discover the potter’s kitchen by querying the shop’s domain.<\/p>\n

    \n
  • Your visit to a lookup site:<\/strong> reports the exit you are using right now.<\/li>\n
  • A domain you typed:<\/strong> reports where that name resolved, often an edge.<\/li>\n
  • An IP you pasted from an email header:<\/strong> reports who owns that block, which may be a mail gateway.<\/li>\n
  • A mismatch between them:<\/strong> expected, not a bug in the page.<\/li>\n<\/ul>\n

    When your own tools disagree about you<\/h2>\n

    A status widget inside a web app might display the address it saw at the edge that terminated your TLS session. If the app sits behind a network that rewrites connections, the widget can show an internal proxy address that you will never see on a public lookup. Support then says “we see 10.x” while you correctly report a public address. Both are describing their side of a proxy. Ask which side they logged. Sending them screenshots of your router will not change what their edge recorded, and their internal 10.x address will not help you configure your router.<\/p>\n

    The reverse also happens. You query your own address and get a cloud provider because a privacy relay or a VPN is on. The website you are debugging is not “behind a CDN” in that moment. You are. Turn the relay off, reload, and only then compare notes with the agent.<\/p>\n

    Mail headers and the first untrusted hop<\/h3>\n

    Received lines in an email list every server that touched the message. The top lines are often the recipient’s own mail provider. The address you care about may be further down, and it may be a marketing platform’s sender, not a human’s home connection. Pasting the first IPv4 you see into a lookup is a hobby that produces confident nonsense. Read upward from the earliest untrusted hop, then look that one up.<\/p>\n

    Use the edge result for the right errand<\/h2>\n

    Edge addresses are useful when you are checking whether a domain still points at the host you intended, whether a migration cut over, or whether a blocklist hit a shared CDN range and collateral-damaged a neighbor. They are useless as a home address for a small business. If you are writing a complaint, a contract, or a parent newsletter, do not paste a CDN city as the place the organization “is.” Name the company. Let the anycast map stay in the debugging notes.<\/p>\n

    If two people query the same domain and get different addresses in different cities, compare the timestamps and the record type. Anycast is allowed to do that. A single origin moving overnight is also allowed to do that. The lookup is a photograph of DNS at one moment.<\/p>\n

    Anycast is a choir, not a typo<\/h3>\n

    When many cities answer for one name, a lookup is a snapshot of the door you happened to reach. A second snapshot from a phone on cellular can name another city and still be the same shop, the same origin hidden behind the choir. The potter’s customer took one snapshot and promoted it to a biography. If you are checking a migration, query twice from two networks and expect disagreement. If both still show the old provider, then you have a real cutover problem. One odd city is not that problem.<\/p>\n

    Label the photograph<\/h2>\n

    Before you forward a result, write “my exit” or “their domain” at the top of the note. The potter needed one sentence of that labeling to answer the customer. The content network was doing its job. The lookup was doing its job. The confusion was a caption that never got written.<\/p>\n","protected":false},"excerpt":{"rendered":"

    A domain lookup often shows a content-network door, not the town where a small business keeps its laptop.<\/p>\n","protected":false},"author":1,"featured_media":33,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[4],"tags":[],"class_list":["post-54","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-use-cases"],"_links":{"self":[{"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/posts\/54","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/comments?post=54"}],"version-history":[{"count":1,"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/posts\/54\/revisions"}],"predecessor-version":[{"id":55,"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/posts\/54\/revisions\/55"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/media\/33"}],"wp:attachment":[{"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/media?parent=54"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/categories?post=54"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.myipinquire.com\/blog\/wp-json\/wp\/v2\/tags?post=54"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}