The Intel X520 is a SFP+ 10GbE adapter from Intel, on PCIe 2.0 x8, using the ixgbe driver that ships in the mainline Linux kernel. It is not marked end-of-life by its maker. 5 listings in stock, from $39.99.
Prices updated · live figures update every 4-5 hours
Both kinds of listing are in stock for this card right now. The cheapest Intel card is $39.99; the cheapest third-party board asserting the same silicon is $49.99, a 25% differencechipset attribution is the seller's. Which is right for you is a judgement about how much the maker's own board is worth to you, not a question we can answer from a listing.
Passive direct-attach copper, by length. A DAC is a fixed-length cable with the transceivers moulded on - you buy the whole run at once rather than a cable plus two modules.
Every "compatible with" phrase below is the seller's own wording, recorded as a claim and badged. We have not tested any module against any switch.
| Module | Type | Brand | Seller compatibility claims | Price | |
|---|---|---|---|---|---|
| SFP+ 10GBASE-SR module | 10GBASE-SR | QSFPTEK | none stated | $9.99 | Buy |
| SFP+ 10GBASE-SR module | 10GBASE-SR | 10Gtek | none stated | $10.42 | Buy |
| SFP+ 10GBASE-LR module | 10GBASE-LR | 10Gtek | none stated | $12.59 | Buy |
| SFP+ AOC 5m | AOC | 10Gtek | none stated | $15.39 | Buy |
| SFP+ AOC 1m | AOC | 10Gtek | none stated | $18.99 | Buy |
| SFP+ AOC 20m | AOC | 10Gtek | none stated | $27.99 | Buy |
| SFP+ 10GBASE-T module | 10GBASE-T | H!Fiber | Cisco SFP-10G-T-S, D-Link, Merakiseller claim | $29.99 | Buy |
| SFP+ 10GBASE-T module | 10GBASE-T | 10Gtek | none stated | $31.49 | Buy |
| SFP+ 10GBASE-T module | 10GBASE-T | 10Gtek | none stated | $35.99 | Buy |
| SFP+ 10GBASE-T module | 10GBASE-T | 10Gtek | none stated | $39.99 | Buy |
| SFP+ 10GBASE-T module | 10GBASE-T | 10Gtek | Intelseller claim | $42.39 | Buy |
The X520 is the Intel counterpart to the ConnectX-3 and occupies the same place in the market: an old, enormously deployed enterprise SFP+ card that is now inexpensive. It runs on ixgbe, one of the most widely exercised network drivers in the kernel, and its support across operating systems is about as broad as 10GbE support gets.
It has one well-known quirk that shapes buying decisions, and it is worth stating plainly because it is the thing people get caught by. Intel-branded X520 cards have historically been particular about which SFP+ modules they accept, rejecting modules that do not identify as Intel-approved parts. This is documented behaviour rather than a defect, and it is a firmware policy rather than an electrical limitation.
The practical consequences are that a direct-attach copper cable is the path of least resistance with this card, and that if you intend to use third-party optical modules you should buy from a seller who will take them back. Third-party board makers building on the same 82599 silicon frequently do not implement the same whitelist, which is one reason the tier-2 boards in our table are popular rather than merely cheaper.
For a two-machine build with a DAC between them, none of this is likely to trouble you, and the X520 is a perfectly sensible choice at the price.
The X520 is built on Intel's 82599 controller and runs on the ixgbe driver, which ships in the mainline Linux kernel and also covers the X540 and X550. That matters more than any marketing claim, because a card whose driver is in the mainline kernel is a card your Linux-based NAS or hypervisor recognises without you doing anything.
We state in-kernel driver names as documented facts because they are - they come from the kernel's own driver documentation, not from a forum thread reporting that something worked. Where community experience is the only evidence available for something, we say so rather than dressing it up.
This card is not marked end-of-life by its maker, which is the main practical argument for it over the older generation in the same interface family.
Windows support is a separate question from Linux support and varies by card age. Check the maker's current driver page for your specific part number before buying if Windows is the target, because an in-kernel Linux driver tells you nothing about it.
Dell and HPE branded X520 cards are common and cheap. Intel-branded cards historically enforced a whitelist of approved transceivers in firmware, which is the single most reported frustration with this card and the reason the compatibility question below matters more here than on the Mellanox cards.
The general shape of the crossflash question is the same across every card in this category: an OEM board carries the server maker's firmware, that firmware sometimes behaves differently from the silicon vendor's, and there is a community practice of replacing it. We link the maintained community documentation rather than reproducing the procedure here. A stale copy of a flashing guide is actively dangerous, and the people who maintain the canonical versions do so because the details change.
If you are buying an OEM-branded card specifically because it is cheaper, factor in the possibility that you will need to do this. If that prospect does not appeal, the vendor-branded card at a higher price is buying you the absence of that job.
This is a SFP+ card, so the port is a cage rather than a socket and you choose what goes in it. For two machines near each other, a passive direct-attach copper cable is the cheapest, coolest and simplest answer, and it is what most builds using this card should use.
For longer runs you need optics - a module at each end plus a fibre between them - or an active optical cable, which packages the same thing as a single sealed object. Both cost more than direct-attach copper and both go much further.
The compatibility question belongs here rather than being buried. Third-party module sellers list the equipment they claim compatibility with, and those are claims we record and badge rather than verify. Vendor coding is a documented phenomenon: cards and switches can and do refuse modules that do not identify as approved parts. A direct-attach cable avoids the entire question, which is another reason it is the default recommendation for a two-machine build.
The cabling guide covers every SFP+ DAC, AOC and optic in one place · The 10GbE hub compares every card we track and covers the SFP+ versus 10GBASE-T decision · the two-machine build prices two of these plus a cable, with no switch · used servers almost always have a spare PCIe slot for one · NAS devices is usually what sits at the other end · rack disk shelves are the other common thing on the far end of a fast link.
Not necessarily. Intel-branded X520 cards have historically enforced a whitelist of approved transceivers in firmware and reject modules that do not identify as approved parts. It is documented behaviour, not a fault. A direct-attach copper cable is the simplest way around it, and buying from a seller with a return policy is sensible if you are using third-party optics.
Port count - DA1 is single-port SFP+, DA2 is dual-port. For a point-to-point link between two machines, one port per machine is all you need, so DA1 is usually the cheaper sufficient choice.
They are close in age, price and capability, and both use in-kernel drivers. The practical differences are the transceiver whitelist on Intel-branded X520s, which the Mellanox cards do not impose in the same way, and the fact that ConnectX-3 carries an end-of-life notice while the X520 does not. Our compare page puts live prices for both side by side.
ixgbe, in the mainline Linux kernel. The same driver covers the X540 and X550, which is why Intel's 10GbE line has such consistent support across Linux-based platforms including TrueNAS and Proxmox.
The X520 is a PCIe 2.0 x8 card. What matters is that the slot provides enough lanes; an x8 card in an electrically x4 slot is a common cause of a card underperforming its specification. Check the electrical width of the slot, not just its physical size.
They are built around the same Intel controller, according to their sellers, and they frequently do not implement the transceiver whitelist that makes the Intel-branded card fussy. We badge that chipset attribution as a seller claim because it is one - it is what the listing asserts about its own board, and we have not opened one.
Specification claims on this page were checked against the pages below on 4 August 2026. Where a widely-repeated figure did not survive that check, we report what the source says now and say so in the text rather than repeating the familiar number.