Reverse-Proxy Hijacking

What reverse-proxy hijacking is

A reverse proxy is an intermediary server that takes an incoming request, fetches the page from another server, and returns it to the visitor as though it had served the page itself. The technology is ordinary and overwhelmingly legitimate - every content delivery network is a reverse proxy, and so is most load balancing and edge caching. What turns it into an attack is the origin being proxied: someone points a domain they control at your website and relays your pages under their own hostname, without your permission.

The result is not a copy. It is a second, complete, live website. Publish a correction on your site and it appears on theirs within seconds, because there is nothing stored on their side that could go stale. Every page, every image, every price, the whole template. From a search engine's position there are now two near-identical sites and one canonical decision to make.

Three attacks on this site end with "a copy of my site is on somebody else's domain," and the difference is where the copy lives. In content scraping the attacker holds a stored copy on their own server, taken by a bot that walked your URLs, and it begins going out of date immediately. In canonical hijacking the weapon is the rel="canonical" element on a copy, and freshness is beside the point. Here the attacker stores nothing at all, your own server is doing the serving, and consequently the fix is a configuration change on your infrastructure rather than a takedown notice to theirs.

The two conditions that make it possible

These are different problems with different defenses, and conflating them is why so much published advice on this is wrong.

1. The permissive origin. Web servers decide which site to serve using the HTTP Host header - the hostname the browser asked for. Both major servers document what they do with a hostname they do not recognize. nginx routes a request whose Host matches no configured server name, or which carries no such header at all, to the default server for that port (nginx, request processing). Apache falls back to the first virtual host listed for the matching address and port. On a default installation the default virtual host is your site - so a server pointed at by any hostname on earth will answer to it. That is not a vulnerability in the software; it is documented, intended behavior, and it is the condition most incidents of this kind rest on.

2. The rewriting proxy. A more capable operator does not need your server to be permissive at all. Their proxy requests your page with the correct Host header, like any ordinary visitor, then rewrites your response before serving it - substituting their domain for yours in canonical elements, internal links, sitemaps and structured data. Against this, host-header validation does nothing whatever, because the header being sent is legitimate. Any guidance that presents Host filtering as a complete fix is wrong about the harder half of these cases, and I would rather say so than sell you a checkbox.

A documented case, and what it does and does not show

On 20 February 2026 I published an analysis of a case that had been reported publicly by a site owner on Reddit's r/TechSEO, in which a spam domain was serving a live reverse-proxied copy of a legitimate application's website (my write-up, 20 February 2026). I want to be exact about what that is: I documented and analyzed somebody else's publicly reported case. I did not discover this attack, and it is not my case. The piece has since been cited back to me as the Bill Hartzer reverse-proxy attack, which it is not. A site owner found it and described it; I explained the mechanism and assessed the defenses.

The reported facts are the useful part. Organic traffic to the legitimate site fell sharply. Google Search Console showed the cloned domain as the Google-selected canonical, meaning Google had chosen the clone to represent the duplicate cluster. And content changes made on the real site appeared on the clone immediately, which is the observation that separates a live proxy from a static scrape.

Now the caveats, because they matter more than the headline. Those figures are the site owner's own account, reported in a public forum and not independently tested. I was not able to fetch the originating thread when I checked it for this page, so everything about the case reaches you through my article rather than from the source. No resolution is recorded anywhere. Nobody has said whether Google reassigned the canonical, whether the clone came down, or whether the traffic returned. Treat it as a well-attested pattern with an unknown ending, not as a case study with a result.

One detail from it changes how you should respond, though: the proxying domain was a scam operation. The commonest real-world use of a live mirror is fraud - phishing, fake storefronts, credential capture - because proxying is the cheapest possible way to build a convincing fake. Damage to your rankings is frequently a side effect rather than the goal.

Does it work?

Sometimes, under conditions you largely control, which is what a situational verdict means.

Google's canonicalization documentation, last updated 20 August 2026, says that indicating a canonical preference is a hint rather than a rule, and that Google selects the page its indexing signals suggest is the most complete and useful for users (Google Search Central, canonicalization). Read that against the attack and it cuts both ways, which is the crux of the assessment: Google can override the clone's preference exactly as easily as yours, and against an established origin it usually does, because the origin wins on age, links, internal linking and crawl history. The mirror takes the cluster only where it can win a contest of signals.

It can win where the target is new or low-authority; where the origin answers to any hostname; where the origin's canonical elements are relative or missing, so the proxied copy self-references cleanly and declares nothing pointing home; where the proxy sits on a faster or better-crawled host; or where the origin is slow, intermittently available or blocking crawlers, so the mirror genuinely looks more useful. A brand-confusable domain compounds the loss, because it captures direct and branded traffic that never touched a search result at all.

What changed is the cost, not Google's behavior. Nothing in canonical selection was altered to make this newly dangerous. Free automatic certificates and one-click edge-proxy platforms mean a convincing live mirror of any website, on its own secure hostname, now takes minutes and no infrastructure. The technique is old; the effort required collapsed. That is the defensible version of "this is a rising threat," and it is also why the verdict is not myth: the misconfiguration it exploits ships by default.

Note the evidentiary floor as well. There is no controlled experiment showing a live proxy taking a canonical from an established site, and no Google documentation addresses proxied copies specifically. Anyone telling you Google has a position on this is inventing one.

Confirming it, before you touch anything

The one test that separates this from every other copying attack: change something visible on your live site - a heading, a price, a sentence - and reload the suspect domain. If the change is there within seconds, you are looking at a live proxy and no stored copy exists to take down. If it still shows yesterday's text, you are dealing with a scrape.

Then the evidence, and the awkward part is that most sites are not logging what they need:

• Log the Host header. The proxy's fetches arrive at your origin like any other traffic, so the record exists - but the identifying field is not in the default log format and is thrown away. Add it ($host on nginx, %{Host}i on Apache) before you block anything. Requests carrying a hostname you do not own are the entire case.
• Look for a narrow source with a wide spread of visitors. A proxy relays real user traffic, so you see many varied requests, with ordinary browser user agents, from a small set of addresses or a single hosting network - the opposite of a scraper's fingerprint, and the reason blocking by user agent fails here.
• Check for forwarding headers the proxy adds on its way through, such as X-Forwarded-For, X-Forwarded-Host and Via, arriving from an address that is not your own delivery network. Those are a proxy announcing itself.
• Look at the hostname dimension in your analytics. A pass-through proxy relays your analytics tag too, so sessions recorded against a hostname you do not own land in your own reports. I offer that as a technique rather than a documented finding - it follows from how proxying works, no source states it, and it costs nothing to check.
• Read the Google-selected canonical in Search Console's URL Inspection. In this attack it has a particular signature: the field names a domain you have never heard of, and the clone is current rather than stale. If it still names your own URL, your rankings are moving for another reason. The general reading of that field is on the page about a copy outranking your original.

Rule out the innocent explanations first, because they are more common than the attack: your own delivery network, a staging or preview domain left indexable, a platform-assigned hostname, a partner deployment your organization authorized, or an old domain still proxying after a migration. Ask internally before you conclude sabotage.

Host-header validation, done properly

This is the root-cause fix for the common case, it is a configuration change rather than a purchase, and it is the single most useful thing on this page.

The goal is that your site is never the fallback for a hostname nobody configured. Define an explicit default server that matches unrecognized hostnames and refuses them, and make your real site reachable only under the names you own.

• On nginx, add a server block that catches the unmatched names - conventionally with an empty server_name - and closes the connection without a response, using the non-standard status 444 that nginx documents for that purpose. Your real server block then matches only your own hostnames.
• On Apache, remember that the fallback is the first-listed virtual host for the address and port. Make that first entry a deliberate catch-all that returns 403, rather than leaving it as your live site, and give the real site explicit ServerName and ServerAlias values.
• Behind a delivery network or a hosting platform, set the equivalent list of permitted hostnames there, and confirm the origin itself is not still reachable directly by IP address.

And here is the limit, stated plainly, because you will not get it from a vendor: this defeats the naive case, where a domain has simply been pointed at your IP address and your server obligingly answers. It does nothing against a proxy that sends the correct Host header and rewrites your response afterward. How often each case occurs is not measured anywhere, and I am not going to attach a percentage to it. Do it regardless - it is free, it is correct, and it converts an attack that requires nothing into one that requires deliberate effort.

The rest of the response, in order

1. Preserve the evidence before you change anything. Logs with the Host field, dated screenshots of the mirror, registration and name-server records for the attacking domain, and the Google-selected canonical for affected URLs. If this becomes a legal matter, the record you make in the first hour is the case, and blocking first destroys it.
2. Confirm Google actually chose the clone. If it did not, the mirror has cost you nothing in search and you can skip to the last step.
3. Validate the Host header at the origin, as above.
4. Make every ownership signal absolute and self-referencing: fully qualified canonical elements rather than relative ones, absolute internal links, absolute URLs in the sitemap, organization and website structured data naming your domain, a consistent og:url. Against a pass-through proxy this is decisive, because the mirror ends up publicly declaring your URL as canonical and handing you the cluster. Against a rewriting proxy it does not win on its own, but it costs nothing and it strengthens your side either way.
5. Rate-limit or filter the fetch source at the edge, once you have logged it. Expect rotation; this is pressure, not a cure, and it must never broaden into blocking real users or search crawlers.
6. Escalate off-platform, in parallel: a spam report to Google citing the scraping section of its policies, a copyright removal request for the mirror's URLs, and - usually more effective than either - abuse reports to the operator's host, delivery network and registrar, who can switch the whole thing off. Where the mirror is a fraud operation, browser safe-browsing reporting is often fastest of all.
7. Monitor the Google-selected canonical over time. Recovery shows there before it shows in your traffic.
8. Consider doing nothing about search. If your pages still rank and Google still names your URL as canonical, the mirror has done nothing to your visibility, and mirrors of successful sites are constant background noise. If it is defrauding your customers that is serious - but it is a fraud and brand problem for the registrar, the host and counsel, and no disavow file will touch it.

Legal footing, and where it is weaker than people assume

Copyright is the strongest lever. The mirror reproduces your copyrighted pages, so a removal request against its URLs - filed with Google, and separately with the operator's host and registrar - is the only route that removes the competing URLs rather than arguing about signals. Note the symmetry with the reverse abuse: filing a notice you know to be false is a knowing material misrepresentation under 17 U.S.C. §512(f), which is an attack in its own right.

Trademark fits better here than in most negative SEO. A mirror on a confusable domain, presenting your brand as its own to your customers, is straightforward source confusion rather than a strained analogy - a matter for counsel under the Lanham Act, and a candidate for the domain dispute process where the name is confusingly similar to a registered mark and was registered in bad faith. This is the point at which a mirror stops being a search issue and becomes a brand problem, and the brand problem is usually the larger one.

Computer-crime theories are a weak fit and I would not build on them. The proxy requests public pages from a public server, which is not obviously access without authorization, and the Supreme Court narrowed the federal statute further in Van Buren v. United States, decided 3 June 2021, holding that exceeding authorized access means reaching material that is off-limits on a system you may otherwise use - not using authorized access for an improper purpose. If your origin refuses unknown hostnames and the operator engineers around that refusal, the analysis looks different, which is one more reason to configure it.

And I could not locate any decided litigation on reverse-proxy site cloning as negative SEO. Suits over cloned websites exist generally; a case on this fact pattern does not, as far as I can find, and nobody should cite one to you.

Common mistakes

• Blocking the proxy before logging it, destroying the only evidence that identifies the operator.
• Never logging the Host header at all, so the attack stays invisible in the logs that would have proved it.
• Treating host-header validation as a complete fix. It is a necessary configuration, not a guarantee.
• Blocking by user agent. A proxy relays the real visitor's user agent, so the rule catches your customers and misses the operator.
• Panicked blocking in robots.txt, which can stop Google seeing your canonical declarations at all and makes the contest you are trying to win strictly worse. This is the most damaging overreaction available.
• Relying on a JavaScript hostname redirect. My own assessment is that these are of limited use: they do not stop Googlebot reaching the proxied copy, and a rewriting proxy can strip the script before it ever runs.
• Rewriting the affected content to differentiate it. A live proxy copies the rewrite instantly, and you have thrown away rankings the original still held.
• Assuming sabotage before ruling out your own delivery network, staging hostname or a partner deployment.
• Treating a fraud problem as a search problem. If the mirror is taking customer payments, the registrar, the host, safe-browsing reporting and counsel matter far more than any canonical element.

Frequently asked questions