IP spoofing
Sending packets with someone else's source address. The reply goes to that address rather than to the sender, so a spoofed connection cannot be held open.
Updated 20 September 2026 · 8 primary sources
IP spoofing means sending packets whose source address is not the sender's own. Nothing in the protocol prevents it, because the source address is a claim rather than a proof. The reply, however, goes to the address written in the packet.
That one fact decides what spoofing can and cannot do. Anything two-way collapses at the first reply, because the answer travels to the address in the header and not to whoever sent the request. What is left is traffic that never needs an answer, which is why spoofing lives on in floods and reflection attacks rather than in browsing.
Why a spoofed connection cannot be held open
A TCP connection begins with three packets. The client sends a request to open, the server answers, and the client confirms with a number taken from the server's answer. With a forged source address, that answer goes somewhere else, so the third packet cannot be written.
Guessing the number was the old way around that. Morris described the trick in 1985, and its use was widely publicised about ten years later. The answer came in 1996: choose the starting numbers so that an outsider cannot predict them, an approach the IETF restated in February 2012. Spoofing therefore buys nothing for a conversation, which is exactly why proxies exist. Something has to receive the replies and pass them back to you.
Filtering at the edge
The defence at the network level is older still. In May 2000 the IETF published ingress filtering as a best current practice. A network should drop outgoing packets whose source address it could not legitimately have sent. A follow-up of March 2004 extended the advice to networks with several providers.
Adoption is still incomplete a quarter of a century later. The Spoofer project collects volunteer tests. Its results keep two columns: networks where spoofed packets left, and networks where they were blocked. Both columns hold plenty of entries.
The header layer, where forging does work
One address can be forged without touching a packet. Sites often read a request header such as X-Forwarded-For, which proxies use to name the visitor they forwarded. Anyone can write that header by hand. Whether it is believed depends entirely on the site's own trust order.
We measured what happens with our own endpoint on 20 September 2026. A forged X-Forwarded-For arrived and took first place in the chain, while the edge's own header still carried the true address. A forged X-Real-IP was replaced by our web server, and a forged CF-Connecting-IP had the request rejected at the edge before it reached us.
| What we sent | What our origin saw |
|---|---|
| Nothing forged | Every header carried the server's real address |
| Forged X-Forwarded-For | The forged address first in the chain, real address behind it |
| Forged X-Real-IP | Replaced by our web server with the real address |
| Forged CF-Connecting-IP | Request refused at the edge, error 1000 |
Spoofing and proxies
A proxy is not spoofing. The proxy holds the connection with its own address, receives the replies, and passes them back over the connection you hold with it. Two honest conversations replace one forged packet, which is the only arrangement that works.
The header layer is where the two ideas meet. A transparent proxy writes your address into X-Forwarded-For, which is the leak our proxy checker grades. A site that reads that header without care can also be told anything. An address from it deserves less trust than the one the connection came from.
How HProxy handles it
Our proxy checker reads X-Forwarded-For deliberately, because that header is where a transparent proxy leaks the visitor's address. For anything that has to be right, our services use the address the connection came from, not a header a caller can write.
Frequently asked questions
What is IP spoofing?
Sending packets with a source address that belongs to someone else. The protocol allows it, since the address is only a claim, but the replies then travel to that address instead of to the sender.
Can I browse the web with a spoofed IP address?
No. Loading a page needs the answers, and the answers go to the address in your packets. That is why people use proxies, which hold the connection with their own address and pass the replies back.
Is using a proxy the same as IP spoofing?
No. A proxy uses its own address honestly and receives the replies. Spoofing writes an address the sender does not hold and gets no replies at all.
What stops IP spoofing?
Ingress filtering, published as a best current practice in May 2000: a network drops outgoing packets whose source address could not have come from it. Measurements show it is widely deployed but still not everywhere.
Can the X-Forwarded-For header be spoofed?
Yes, and that is a different thing from spoofing a packet. Anyone can send the header; whether a site believes it is the site's choice. In our own test the forged value arrived first in the chain while the edge's own header kept the true address.
Can someone spoof my address to get me blamed?
They can send one-way traffic that appears to come from you, which is how reflection attacks work. They cannot hold a conversation as you, because every reply would come to your machine and not to them.
Why do the replies matter so much?
Because almost everything online is two-way. A request that gets no answer cannot load a page, log in, or keep a session. Spoofing removes the answer, so it removes the use.
Sources
- RFC 2827 (BCP 38): Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, IETF, P. Ferguson, D. Senie, 2000-05.
- RFC 3704 (BCP 84): Ingress Filtering for Multihomed Networks, IETF, F. Baker, P. Savola, 2004-03.
- A Weakness in the 4.2BSD Unix TCP/IP Software (Computing Science Technical Report 117), R. T. Morris, AT&T Bell Laboratories, 1985.
- RFC 1948: Defending Against Sequence Number Attacks, IETF, S. Bellovin, 1996-05.
- RFC 6528: Defending against Sequence Number Attacks, IETF, F. Gont, S. Bellovin, 2012-02.
- RFC 5358 (BCP 140): Preventing Use of Recursive Nameservers in Reflector Attacks, IETF, J. Damas, F. Neves, 2008-10.
- State of IP Spoofing (the Spoofer project), CAIDA, 2026-09-19.
- Four requests to our own echo endpoint, with and without forged headers, HProxy measurement, 2026-09-20.
Back to the full glossary.