I wonder if it is tied to my NIC at all or if the OS or driver intercepts and immediately returns data sent to the loopback address?

Does the signal actually travel to my NIC then the NIC returns it?

  • 6
    More trivia the entire 127 /8 is dedicated to loop back
    – Jacob
    Feb 11, 2011 at 11:33
  • 3
    It would be interesting to see some real-world throughput and/or latency figures for the loopback if anyone has them.
    – NPE
    Feb 11, 2011 at 12:25
  • 3
    Even if the electrons travel there, the NIC probably wouldn't return the same electrons :) Oct 6, 2011 at 20:31
  • :) yeah i should say signal..
    – user55029
    Nov 25, 2011 at 0:49
  • 1
    there's no place like
    – user130370
    Dec 5, 2012 at 21:08

9 Answers 9


You don't mention a particular OS but for most all that happens is that the data travels down the stack until it gets to IP at which point it's pretty much sent back. That's a massive oversimplification but means that the entire process is usually CPU bound so its performance is therefore directly linked to CPU speed plus stack efficiency. In practical terms modern CPUs and OSs should be able to 'bounce' loopback traffic considerably faster than 40Gbps - which is the fastest NIC I think I'm capable of buying today. Hope this helps.


All 127.xx.xx.xx traffic never hits the physical network, it gets processed by a loop back adapter in the kernel.

  • so that means super fast right :)
    – user55029
    Feb 11, 2011 at 4:45
  • @Mrk Mnl yes you bet. For my ping 00ms using XAMP 1.7.4
    – Benny
    Feb 11, 2011 at 11:17
  • 16
    any local address never hits the physical network. just one of them
    – alvosu
    Feb 11, 2011 at 11:27
  • 2
    "hitting the physical network" is a bit ambiguous as it could get to your NIC without being sent and not hit the physical network, anyway if it is returned by the kernel, i.e. the OS, obviously it doesnt get to the NIC.
    – user55029
    Feb 21, 2011 at 7:46

You may be interested in the "Loopback Fast Path" feature Microsoft added in Windows 8 and Windows Server 2012. See:


It also provides an illustration of the path taken by the loopback with and without the optimization.

8 is no faster any other local ip. The local ip fast, because it doesn't use physical device and 2-layers.( It never hits your NIC)

iperf -c 109.191.109.xxx 1111 -t 5
iperf: ignoring extra argument -- 1111
Client connecting to, TCP port 5001
TCP window size: 49.7 KByte (default)
[  3] local 109.191.109.xxx port 32840 connected with 109.191.109.xxx port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  4.72 GBytes  8.12 Gbits/sec

$ iperf -c 1111 -t 5
iperf: ignoring extra argument -- 1111
Client connecting to, TCP port 5001
TCP window size: 49.7 KByte (default)
[  3] local port 56482 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  4.62 GBytes  7.94 Gbits/sec
  • 5
    There's an awful lot wrong with this answer. It is faster. If you aturate the collision window then the limiting factor will be driven by context switching.
    – symcbean
    Feb 11, 2011 at 13:02
  • awesome, just what I was looking for. I wanted to see my upper limit when running client to server locally...thanks for the answer!!!! Apr 19, 2016 at 14:59
  • @symcbean: can you elaborate on the "wrongness" of this answer, please?
    – Sam Axe
    Jan 3, 2019 at 10:01
  • @SamAxe I think symcbean interpreted "local IP" as "an IP on the LAN", but alvosu meant "an IP starting with 127.", which is local to the machine. So the answer isn't wrong, just a bit unclear.
    – acl
    Jan 25, 2021 at 15:42

It depends on what OS you're running, but Windows 2000 had a bug in it where requests on the loopback adaptor would be slow. There's some useless trivia for you!

Please see this kb article for more information.


As stated above, on Linux machine at least, both localhost and any other local address bypasses the NIC drivers - it is directly served by the kernel IP stack (sidenote: many ethernet hardware MAC are simply not capable of reading back an outgoing packet).

What speed can be achieved over a loopback interface? I run some test via iperf3 -s & iperf3 -c localhost on the following machines:

  • an old Intel i7-860@2.8 GHz achieves 23 Gb/s
  • a more recent Intel Pentium G3260@3.3 GHz achieves 26 Gb/s
  • a Ryzen 7 1700@3.0 GHz achieves 29.4 Gb/s

All three machines above had a CPU utilization of about 150% (ie: 1.5 cores were used). A faster processor (with higher single-thread speed) will obviously give greater performance. Anyway, at these speed memory copy operations are a significant bottleneck: re-running the same test on the Ryzen machine using a "zero-copy transfer" (iperf3 -Z -c localhost) resulted in >38 Gb/s

  • What do you mean by "many ethernet hardware MAC are simply not capable of reading back an outgoing packet"?Could you please explain that in more details?
    – John
    Jun 16, 2021 at 11:59
  • How did I have to scroll this far to find the one person who actually tested it? Thank you!
    – nbura
    Aug 12, 2022 at 23:42

I'd rather say that you find your answer in it's name itself. The name says: "Local Loopback Address", which in itself means that the network never intervenes in the process and the request is in itself looped back locally.

  • I was about to post the same when I noticed you beat me to it. Indeed 'loopback address' should give a hint :) Feb 11, 2011 at 12:35
  • the question was how fast, i know what it does
    – user55029
    Feb 12, 2011 at 8:22
  • The name doesn't actually tell you anything. For example, a physical RS-232 loop back will be just as slow as your serial port, whereas if you were to implement one at the driver level it would be faster. Of course localhost will be handled in software, but you can't tell that just from the name "loopback". In case you're too young to know of these things, I give you google.com/search?q=rs232+loopback&tbm=isch
    – aij
    Nov 18, 2015 at 4:00

If you are on Linux...

type in "ifconfig -a" as root...

Notice the "interrupt" line on all NICs...notice there is no "interrupt" line on "lo"...that means it does not even have an interrupt assigned to it, so pretty darn fast ;-)

  • that makes no sense. This makes little sense for a virtual device and says nothing about its performance. Apr 16, 2018 at 1:07

Localhost "local loopback" runs as fast as your CPU, RAM, and chipset (SATA, IDE, etc.), and other local physical limits of the computer. Localhost off a USB 2.0 Hard drive will yield maybe 480 Mbps or less because of the bus of the local hard drive that you are using to run the local webserver via localhost. On the other hand, if you are using SSD or something yielding 100 Gigabytes per second per direction data rate and system bus capable of handling that with other activities on the computer, then it will be fast. There is no actual hard set limit. There is a little overhead on the CPU to process the TCP packet stuff but even an i9-10900K cpu maybe limited to data running at some speed less than 45.8 Gigabytes per second. SATA gives you limits of like 6 Gbps. PCIe x16 based SSD could go to speeds of over 60 GBytes per second per direction!! PCIe 6.0 specs takes the cake to over 120 Gigabytes per direction !!!!

No one can specifically state a singular number as to how fast localhost will be. Several factors will impact the actual measured speed and that is dependent on your computer and the impact of OS and other software and hardware on the system. These numbers given above are theoretical limits not necessarily actual performance measured. The bottleneck is the weakest link in your computer. Usually the speed of data coming to and from your hard drive on the computer and sometimes, you can cache in RAM for some speed improvement but that isn't always an easy thing or an easily/available option for every OS.

You will likely yield less than 10GBase-T performance if you are using a SATA based drive. If you are using an M.2 drive, you might beat that performance. SSDs running on a PCIe x16 bus speed will yield performance above 40gigabits per second but your CPU and memory bus will impose its own limits as well as the overall system bus. The slowest bus that is involved with the operation of localhost loopback process is your most limiting factor other than the CPU itself which maybe loaded down with stuff which can effect data rate. An i5 will be more limiting than the an i9-10900K cpu.

  • 1
    loopback works even if no hard disk interface is present at all - how could the bandwidth of the disk interface possibly matter?
    – anx
    Nov 25, 2020 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.