The Realtek RTL8127 is the reason 10GbE stopped being a $100 decision. It is a single-port 10GBASE-T controller on a PCIe Gen4 x1 link, Realtek rates the chip at about 2 W, and the cards on Amazon sell for roughly $36 to $54. The catch is that it’s new silicon, so whether it works on Linux or Proxmox comes down almost entirely to which kernel you are running, and the answer is not the same for the copper and SFP+ versions.
This guide maps that out: the kernel each variant needs, which Debian, Ubuntu, RHEL and Proxmox VE releases ship it, when Realtek’s own r8127 driver is still worth the trouble, and why so many iperf3 results land between 6 and 8 Gbps. We verified every kernel and package version against kernel git, the Proxmox package repository and each distro’s package index in October 2026. We did not bench these cards ourselves, so every throughput figure links to whoever measured it.
Which kernel the RTL8127 needs
You need Linux 6.16 or newer for the RJ45 card, 6.18 (or a patched 6.17.y) to avoid a shutdown hang, and 7.0 or newer if you bought the SFP+ variant. All of it lands in the in-tree r8169 driver, so there is nothing extra to install once the kernel is new enough. These are the commits that matter:
| Change in r8169 | First kernel | What it means for you |
|---|---|---|
| Add RTL8127A support | 6.16 | The copper card is detected and links at 10G |
| Fix hang on suspend and shutdown | 6.18, backported to 6.17.y | Before this, the card could vanish from lspci until a full power cycle |
| Refuse fiber mode on RTL8127AF | 6.19 | SFP+ cards print a clear message instead of a silent no-link |
| Add RTL8127ATF (SFP+) support | 7.0 | SFP+ works, but at 10G only; 1G modules are not supported in-tree yet |
| RSS, up to 8 RX queues | Not merged | In-tree r8169 still runs the card on a single receive queue |
The firmware file is a softer requirement than people expect. The driver asks for rtl_nic/rtl8127a-1.fw, which first shipped in linux-firmware 20250613, but if the file is missing it logs a warning and carries on. Install it anyway, because the blob carries PHY fixes, and a missing file is the first thing anyone helping you on a forum will ask about.
Distro and Proxmox VE support at a glance
In practice this means anything on a 6.16 or newer kernel detects the card with no extra driver, and the long-term releases that froze on an older kernel need either a newer kernel series or the vendor driver. Here is how the common platforms line up today:
| Platform | Default kernel | RTL8127 RJ45 | RTL8127ATF SFP+ |
|---|---|---|---|
| Ubuntu 24.04 (original GA kernel) | 6.8 | No | No |
| Ubuntu 24.04.5 HWE | 7.0 | Yes | Yes, 10G |
| Ubuntu 26.04 LTS | 7.0 | Yes | Yes, 10G |
| Debian 13 (stock) | 6.12 | No | No |
| Debian 13 + trixie-backports | 7.2 | Yes | Yes, 10G |
| Fedora 45 | 7.2 | Yes | Yes, 10G |
| RHEL, Rocky, Alma 10.1 | 6.12 | No | No |
| RHEL, Rocky, Alma 10.2 | 6.12 with Red Hat’s backport | Yes | No |
| Proxmox VE 8.x and 9.0 | 6.8 / 6.14 | No | No |
| Proxmox VE 9.1 | 6.17 | Yes | No |
| Proxmox VE 9.2 | 7.0 | Yes | Yes, 10G |
Two rows catch people out. Debian 13 ships 6.12 with a firmware-realtek package that predates the RTL8127 blob, so a fresh trixie install will not see the card at all until you pull a newer kernel from backports, and the firmware with it. RHEL 10.2 does detect the copper card, but only because Red Hat backported the support into its 6.12 kernel, and the backport stops short of SFP+.
On Debian 13, enable backports and install the newer kernel and firmware together:
echo "deb http://deb.debian.org/debian trixie-backports main non-free-firmware" | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64 firmware-realtekUbuntu 24.04 machines still on the original 6.8 kernel only need the HWE kernel series, which now tracks 7.0:
sudo apt install --install-recommends linux-generic-hwe-24.04Reboot into the new kernel before you go looking for the interface.
Confirm the card is bound to r8169
Before touching any driver, we’d check what the kernel actually did with the card, because a missing interface has three different causes and each one has a different fix. Set the interface name once so the later commands work as written:
IFACE=enp1s0Ask lspci which driver claimed the Realtek device ID 10ec:8127:
lspci -nnk -d 10ec:8127A healthy card shows Kernel driver in use: r8169. If the device is listed with no driver line, the kernel is too old for it. If lspci does not list the device at all, it’s either not seated, sitting in a slot with no lanes wired, or it fell off the bus after a warm reboot on a kernel without the shutdown fix. Once it’s bound, confirm the driver and firmware version the interface reports:
ethtool -i $IFACEThen check the link speed and whether the cable actually negotiated 10G:
ethtool $IFACE | grep -E 'Speed|Duplex|Link detected|Wake-on'If the link sits at 5000Mb/s, look at the cable before the card. One ServeTheHome reader saw two RTL8127 cards drop to 5G over a two-pair link, and Realtek itself told Tom’s Hardware to use Cat6 when Cat5e will not hold the link.
Unable to load firmware rtl_nic/rtl8127a-1.fw (-2)
This line in the kernel log means the driver loaded but the firmware file is not on disk. Look for it with:
sudo dmesg | grep -iE 'r8169|rtl8127'The card keeps working without the file, so this is not an emergency, but you’ll want it. On Debian and Ubuntu it comes from firmware-realtek or linux-firmware, on Fedora and RHEL from linux-firmware, and on Proxmox from pve-firmware, so updating that package and rebooting clears the warning on any release new enough to drive the card.
Running the RTL8127 on Proxmox VE
Proxmox is where we see the most confusion, because support arrived between point releases. Proxmox VE 9.0 shipped 6.14, which has no RTL8127 support, while 9.1 moved to 6.17 and 9.2 moved to 7.0. One user in the Proxmox forum thread runs onboard and PCIe RTL8127 ports stably on updated 9.1 kernels, while others in the same thread still had trouble, so update to the latest 6.17 or 7.0 kernel rather than staying on the kernel from the 9.1 installer.
Check which kernel the node is actually booted into, since an upgraded host can still be pinned to an older one:
pveversion -v | grep -E 'proxmox-ve|running kernel'Both routes to the 7.0 series, which is what gets you SFP+ support, work from 9.1. A normal apt full-upgrade moves the host to 9.2 and its 7.0 default kernel, and a host you want to hold at 9.1 can take 7.0 as a standalone kernel package:
apt update && apt install proxmox-kernel-7.0Do that from a console or IPMI session rather than over the RTL8127 port itself. If the new kernel brings the interface up under a different name, the vmbr0 bridge in /etc/network/interfaces still points at the old one, and the node boots with no network. Our guide to Proxmox Linux bridges covers editing that file safely.
Proxmox VE 8.x is the awkward case. Its opt-in 6.14 kernel does not help, so the realistic choices are an upgrade to 9.2 or Realtek’s out-of-tree driver, and we’d only take the second path on a host that cannot be upgraded yet.
When Realtek’s r8127 driver still makes sense
Realtek publishes its own driver, r8127, on its download page; the current release is 11.016.00, which Realtek lists for kernels up to 7.1. It earns its place in three situations: a kernel older than 6.16 that you cannot move off, an SFP+ card you need to run at 1G, and multi-queue receive, since the vendor driver has RSS code that in-tree r8169 does not yet.
What you pay for that is maintenance. The tarball ships an autorun.sh that builds the module, then renames the stock r8169.ko to r8169.bak and loads r8127 in its place. That is not DKMS, so the next kernel update installs a fresh r8169 and the vendor module disappears, and renaming r8169 also takes down any other Realtek NIC in the box that relied on it.
Where a packaged module exists, use it instead. ELRepo ships a kABI-tracking kmod-r8127 for EL9 and EL10, and Arch has r8127-dkms in the AUR, which also blacklists r8169 for you. On Debian 13, take the trixie-backports kernel instead: the script only renames an uncompressed or zstd r8169 module, so it leaves Debian’s r8169.ko.xz in place and the two drivers fight over the card. On Proxmox, which ships r8169.ko uncompressed, you would be building it yourself, and the build needs headers for the running kernel first:
apt install proxmox-headers-$(uname -r) build-essentialRun the next step from a console or IPMI session, not over SSH. The script unloads r8169 as soon as it starts, so a management port on an onboard Realtek chip drops mid-run and stays down after a reboot. RSS is off unless you ask for it, and the script passes its arguments to make, so you can turn on multi-queue receive and transmit at build time from the extracted tarball:
sudo ./autorun.sh ENABLE_RSS_SUPPORT=y ENABLE_MULTIPLE_TX_QUEUE=yWith Secure Boot on, expect the modprobe step in the script to fail, which the next paragraph covers. If the build leaves you without a working port, remove r8127, put the stock driver back and rebuild the initramfs the script changed:
sudo find /lib/modules/$(uname -r) -name 'r8127.ko*' -delete
sudo mv /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/r8169.bak /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/r8169.ko
sudo depmod -a
sudo update-initramfs -u -k $(uname -r)Secure Boot adds one more step. An unsigned out-of-tree module is rejected with Key was rejected by service, so you have to sign the built module with your own key using the kernel’s scripts/sign-file and enroll that key with mokutil --import. Proxmox’s Secure Boot page walks through creating and enrolling the key for DKMS, and the same key works here: sign the installed r8127.ko, then run sudo modprobe r8127. Once the host runs a kernel with native support, delete the r8127 module and restore r8169.bak the same way so r8169 takes over again.
Why iperf3 shows 6 to 8 Gbps instead of 9.4
The single biggest limit on in-tree RTL8127 throughput is that r8169 runs it on one receive queue, so every packet’s interrupt and softirq work lands on one CPU core. Realtek’s own engineers showed the effect in their RSS patch series: on a four-core Ryzen Embedded box, a 20-stream iperf3 run swung between 3.76 and 8.2 Gbit/s with one core at 96% softirq, and held a steady 9.42 Gbit/s with RSS enabled. As of October 2026 that series is on its sixteenth revision and still waiting in netdev review.
Other reports point the same way. A Windows test by Chimolog averaged 6.14 Gbit/s on a single stream and about 9.1 Gbit/s with two parallel streams, though that was Windows with Realtek’s driver, and one STH reader on an X570 board saw 9.9 Gbps receive but only about 5 to 6 Gbps transmit. Fast desktop cores handle the single queue far better than low-power mini PC chips, which is why results vary so much from one build to the next.
The slot is the second limit. The RTL8127 needs a Gen4 x1 link to carry 10G, and a Gen3 x1 slot tops out at about 7 to 8 Gbps according to several STH readers. If your board only has Gen3, the RTL8127AT and ATG variants can also run at Gen3 x2, and one reader reported 8.8 Gbps that way, but they need a physical x2 or wider slot.
To see the card’s real ceiling, start a server on the far end and run parallel streams in both directions from the RTL8127 host:
iperf3 -sThen from the client, four streams for 30 seconds, followed by the same test reversed:
iperf3 -c 10.0.1.50 -P 4 -t 30
iperf3 -c 10.0.1.50 -P 4 -t 30 -RWhile it runs, watch per-core load in top with 1 pressed. One core pinned near 100% in si is the single-queue limit, and a faster CPU, the vendor driver built with RSS, or jumbo frames will move it. Jumbo frames cut the packet rate by roughly six times, and r8169 supports MTU 9000 on this chip, as long as every switch and host on the path does too:
sudo ip link set dev $IFACE mtu 9000Wake-on-LAN is supported but off by default, which surprises people who move a NAS onto the new port. Turn on magic-packet wake with sudo ethtool -s $IFACE wol g, and persist it in your network config, since the setting resets on reboot.
Power, and how it compares to Intel and Marvell
Power is where the RTL8127 makes its case. Realtek rates the chip at 1.95 W according to CNX Software, and ServeTheHome puts a whole card at roughly 2 to 3 W, and under 4 W at most. Nobody has published a wall-meter idle and load measurement yet, so treat the card figure as an estimate rather than a measurement.
| NIC | Ports and host link | Power (rated or estimated) | Linux driver | SR-IOV |
|---|---|---|---|---|
| Realtek RTL8127 | 1x 10GBASE-T, PCIe Gen4 x1 | 1.95 W chip, about 2-3 W card | r8169 (6.16+) | No |
| Marvell AQC113 | 1x 10GBASE-T, PCIe Gen4 x1 | about 2.5 W typical (vendor listing) | atlantic (5.8+) | No |
| Intel X550-T2 | 2x 10GBASE-T, PCIe Gen3 x4 | 11.2 W typical, 13 W max | ixgbe | Yes |
The X550-T2 is dual-port, so per port the gap narrows to roughly 2 to 4 W against 5.6 W, but most homelab boxes only need one 10G port. Intel cards also bring things the RTL8127 does not: SR-IOV, so a Proxmox VM can get its own virtual function, mature multi-queue support, and a decade of driver history. For a deeper comparison, see our 10GbE NIC guide for Proxmox.
Reliability is the other open question. ServeTheHome’s teardown card, the one stripped for photos, did not work afterwards, and one DGX Spark owner saw the onboard RTL8127 vanish on every warm reboot until r8169 was blacklisted in favor of Realtek’s r8127 on NVIDIA’s 6.17 kernel. Neither is a pattern yet, but buy from a seller with easy returns.
RTL8127 cards worth buying
Most RTL8127 cards on Amazon are the same reference design under different brands, so choose on bracket, boot features and the seller’s return policy rather than any performance difference. These three are in stock with listed prices:
| Card | Notes | Price |
|---|---|---|
| BZIZU 10Gb PCIe RTL8127 | The card STH reviewed; full-height and low-profile brackets | about $50 |
| GLOTRENDS LE8127T1 | Listing advertises Wake-on-LAN plus UEFI and legacy PXE boot | about $36 |
| NICGIGA 10Gb PCIe 4.0 x1 | Same Gen4 x1 design, sold by the brand’s own storefront | about $54 |
Check three things before you order. The slot has to be Gen4 to reach full speed, and a chipset-attached x1 slot shares bandwidth with everything else behind the chipset. Low-profile cases need the short bracket in the box. And the far end needs a 10G switch port, which our 10GbE switch guide covers.
Some systems now ship with the chip onboard. The Minisforum MS-S1 MAX has two RTL8127 ports, which our Ryzen AI Max+ 395 mini PC comparison covers, and the same kernel rules apply. If you are planning the whole network, our 10GbE homelab build under $400 pairs a card like this with a switch and cabling.
What the lower wattage is worth on a 24/7 host
The cost angle is easy to overstate, so it helps to run the numbers. Swapping an X550-T2 at 11.2 W for an RTL8127 card at 3 to 4 W saves roughly 7 to 8 W, which is about 61 to 70 kWh a year on a host that never sleeps. At 17 cents per kWh that is around $10 to $12 a year, so the card pays for itself in about four years on power alone, and faster if your electricity costs more.
The bigger saving shows up elsewhere: less heat in a small case, no fan needed in a mini PC, and a card that fits the x1 slot most boards leave empty. We’d reach for the RTL8127 on a single-port node running a modern kernel, and stay with Intel where you need SR-IOV, two ports on one card, or a long-term-support kernel you cannot move off. For a full host build, the mini PCs we recommend for Proxmox are the next stop.
