The 10GbE and SFP+ articles on this site both assume you already have a network card worth plugging something into. That’s not always true. Plenty of homelab trouble that looks like a cabling problem, a switch problem, or a flaky driver is actually a bad NIC choice from the start, usually an onboard chipset that was never meant to run under constant load with a hypervisor’s network stack sitting on top of it. This is the piece that covers the card itself: which chipsets to trust, which to avoid, and what actually matters when you’re picking an add-in NIC for Proxmox, TrueNAS, or any other self-hosted box.

Why the chipset matters more than the spec sheet

Every NIC box says “Gigabit” or “10 Gigabit” and most buyers stop reading there. The chipset controlling that port determines three things the spec sheet never mentions: how well the driver is maintained in Linux, whether the card can split traffic across multiple CPU cores, and whether it holds up under sustained load instead of dropping packets or resetting under a kernel driver bug. Two cards with identical port counts and identical rated speeds can behave completely differently once a few VMs are pushing real traffic through them.

This is also a case where “it works in Windows” tells you almost nothing. Consumer NIC chipsets are frequently designed and tested against Windows drivers first, with Linux support as an afterthought maintained by volunteers or shipped years later than the hardware itself. Proxmox, TrueNAS, and most other homelab platforms are Linux (or BSD, for TrueNAS CORE) under the hood, so the quality of that non-Windows driver is the thing that actually determines your experience.

Intel: the safe default, for good reason

Intel’s server and workstation NIC chipsets (the e1000e and igb families for Gigabit, ixgbe and i40e/ice for 10GbE and above) have the longest, most boring, most reliable track record in Linux of any NIC vendor. “Boring” is the compliment here: these drivers have been in the mainline kernel for well over a decade, they’re maintained by Intel directly, and the failure modes are well documented because millions of servers run them.

Specific cards worth knowing by name on the used market:

  • Intel I350 series (dual/quad-port Gigabit) - the default recommendation for any homelab wanting more Gigabit ports than a motherboard provides, cheap and plentiful used.
  • Intel X520/X540 series (dual-port 10GbE, SFP+ or RJ45 depending on model) - the most common used 10GbE card in homelab builds, wide driver support going back to very old kernels.
  • Intel X710/XL710 series (10/40GbE) - newer, more capable, costs more used, worth it if you’re also running SR-IOV or need higher port density.

The downside is mostly about availability and heat, not reliability: genuine Intel cards on the used market carry a premium over generic off-brand boards using the same chipset, and the higher-end X710/XL710 parts run hot enough that airflow matters in a tight case.

Realtek: fine on a desktop, a liability on a hypervisor

Realtek chipsets are on the overwhelming majority of consumer motherboards because they’re cheap to license, not because they’re good. The Linux driver situation has genuinely improved over the years, but Realtek NICs (especially the RTL8111/8168 Gigabit family and various 2.5GbE parts like the RTL8125) still have a disproportionate history of driver bugs that show up specifically under the kind of sustained, bursty load a hypervisor generates: random link drops, the interface disappearing until a reboot, and features like TSO/checksum offload that have to be disabled to get a stable connection.

None of this makes a Realtek NIC useless for a desktop or a lightly-loaded box. It does mean that if your Proxmox host’s onboard NIC is a Realtek chip and you’re seeing intermittent networking weirdness that doesn’t correlate with anything else you’ve changed, the chipset itself is a reasonable first suspect, and a $20-40 used Intel card in a spare PCIe slot is often the fix, not a config change.

Mellanox/NVIDIA ConnectX: the homelab’s 25/40/100GbE on-ramp

Mellanox (acquired by NVIDIA, still branded ConnectX on most used listings) built its name on data center interconnects, and the used market is flooded with ConnectX-3 and ConnectX-4 cards from decommissioned enterprise gear at prices that make 25GbE and even 40/100GbE realistic for a homelab in a way that would have been unthinkable a few years ago.

The tradeoffs that keep these out of the “default recommendation” slot:

  • ConnectX-3 cards are aging out of mainline kernel support. They still work today, but newer kernel releases have started dropping or deprecating the driver, so treat these as a “works now, budget for replacement eventually” purchase, not a long-term platform.
  • Firmware and mode switching (Ethernet vs InfiniBand) trips up first-time buyers. Many ConnectX cards pulled from decommissioned clusters ship configured for InfiniBand, not Ethernet, and need a firmware tool (mstflint or NVIDIA’s MFT) to switch modes before they’ll work on a normal network. Check the listing or ask the seller before buying if this isn’t mentioned.
  • ConnectX-4 and newer have better long-term driver support and are worth the extra cost over ConnectX-3 if the card will be a permanent fixture rather than a cheap experiment.

If you’re chasing real bandwidth past 10GbE on a budget, this is where to look. Just go in knowing you’re buying genuinely secondhand enterprise gear with a shorter clock on long-term support than a current Intel part.

Multi-queue, RSS, and why it matters once you’re running VMs

A single network connection on an old-style NIC gets processed by one CPU core, which becomes the actual bottleneck on a fast link long before the wire itself does. Modern NICs support multiple queues and Receive Side Scaling (RSS), which split incoming traffic across several CPU cores automatically. This matters a lot more in a hypervisor than on a desktop, because a Proxmox host isn’t handling one connection, it’s handling the aggregate traffic of every VM and LXC’s virtual NIC riding on top of the same physical port.

Checking whether a card is actually using multiple queues under Linux is one ethtool -l <interface> away, and it’s worth checking after any NIC swap rather than assuming the driver defaults are doing the right thing. A card that reports a single combined queue when it’s capable of more is usually a driver or firmware configuration issue, not a hardware limitation.

SR-IOV: giving VMs a slice of the NIC directly

SR-IOV (Single Root I/O Virtualization) lets one physical NIC port present itself to the hypervisor as several virtual functions, each of which can be passed directly into a VM, bypassing the host’s virtual network stack entirely for that VM’s traffic. This gets most of the throughput and latency benefit of full PCIe NIC passthrough (covered from the GPU side in this site’s Proxmox passthrough article) while letting multiple VMs share one physical card instead of each needing a dedicated port.

Support isn’t universal. Intel’s X520 and newer, and Mellanox’s ConnectX-3 and newer, support SR-IOV with mature Linux driver support for it. Consumer-grade NICs, including most Realtek chips, don’t support it at all. If SR-IOV is part of the plan, confirm it on the specific card and firmware revision before buying, since “supports SR-IOV” on a spec sheet sometimes means “supports it in Windows Server” and not in the Linux kernel driver you’ll actually be running.

What to actually buy

For a Proxmox or TrueNAS box that just needs reliable Gigabit beyond what the motherboard offers: a used Intel I350 card, full stop, cheap and essentially bulletproof. For 10GbE: a used Intel X520 or X540, paired with the DAC or SFP+ transceiver guidance already on this site. If the onboard NIC is a Realtek chip and the box is doing anything more than light desktop duty, swap it for an Intel card before chasing any other networking problem, since it’s the cheapest variable to eliminate. And if the goal is real bandwidth past 10GbE on a budget, look at ConnectX-3/4 cards from the used enterprise market, with eyes open about firmware mode-switching and the shrinking support window on the oldest parts.