How to Fix "Missing Mods" or Mod Mismatch When Joining a Modded Server

When a Forge or NeoForge server kicks you with Missing Mods or Connection closed - mismatched mod channel list, your client and the server are running different mods, and the fix is to run the server's exact modpack at the exact same version rather than hand-picking jars. On connect, Forge compares both sides' mod lists; if a required mod is missing, extra, or a different version on either side, it refuses the join. That's a parity problem, not a broken install, and you almost never solve it by reinstalling Minecraft. The cleanest route is to grab the pack the server uses from its modded server listing or the owner's page and let a launcher install it whole. Note up front that this only happens on actual modded servers — plugin servers running Paper or Spigot want a plain vanilla client and never send a mod list at all.

What the handshake is actually checking

After a Forge client and server finish the normal vanilla login, Forge runs a second handshake of its own over channels like fml:loginwrapper and fml:handshake. The two sides exchange their mod lists and their block and item registry IDs, then compare them. If your client is missing a mod the server requires, has one the server doesn't, or has the right mod at a different version, the comparison fails and you get dropped. It isn't enough to have the same mod names — the versions have to line up, and the loader build itself has to match, because content mods register IDs that both sides expect to find in the same order.

The exact disconnect wording shifts between loader generations. Older Forge throws a MissingModsException with a Missing Mods list, and the log shows a line like Attempting connection with missing mods [minecraft, mcp, FML, forge] at CLIENT. Newer Forge and NeoForge tend to render a more detailed reasons screen, and the generic case shows up as Connection closed - mismatched mod channel list. Treat those strings as representative rather than byte-for-byte identical to what you see. The timing moved too: older Forge runs this check during the login phase, while newer Forge and NeoForge run it in the config phase, just after login succeeds. Either way the cause is the same, and so is the fix.

A separate thing the screen might be telling you: This server requires FML/Forge to be installed. Contact your server admin for more details. That one means you hit a Forge server with a plain vanilla client and no Forge at all — a different starting point from having the wrong mods while already on Forge, but the same destination, which is installing the server's pack.

Fix it by matching the whole pack

The real fix is to install the server's modpack at its exact version, loader and all, instead of assembling mods yourself. Picking individual jars by hand is how you end up one version off on a single mod and back at the same kick screen.

Get the pack from the same source the server uses

Modded servers almost always run a published pack, and you want the same one from the same place — its CurseForge or Modrinth page, or a file the owner hands you directly. On a pack's Files tab you'll usually see two separate downloads: the client pack (something like Pack-X.X.X.zip or a .mrpack) and a Server Files / -server.zip bundle. You want the client pack. Match the version number to whatever the server is on; if the listing or the owner names a specific build, download that exact one and not the newest on the page.

Let a launcher install it whole

Use a launcher that reads pack files rather than dropping jars into .minecraft/mods yourself. The CurseForge App imports a .zip, and the Modrinth App or Prism Launcher import a .mrpack. The launcher reads the manifest, installs the correct Forge or NeoForge build, and pulls every mod and config file at the versions the pack specifies. That single step is what gets the loader build to match — installing Forge by hand at the wrong build can still fail the handshake or break registry sync even when your mod folder looks right.

Reconcile by hand only if there's no pack

If the server genuinely isn't running a published pack and the owner just gives you a mod folder, compare yours against theirs jar by jar. Every file in your mods/ has to be the identical version of theirs. Add anything you're missing, remove anything the server doesn't have, and delete old duplicates of a mod you've already updated — two versions of the same mod in the folder is its own failure. Restart the client fully afterward so it rescans the folder.

What you don't need to match

Not every mod has to exist on both sides, and knowing which is which saves you from chasing a mismatch that was never the problem.

Client-only mods register no network channels, so the server never asks about them and they can't cause a mismatch. Minimaps, shader loaders, Sodium and the OptiFine-style rendering mods, FPS and tweak tools — run those even when the server doesn't have them, and they won't show up in the handshake. They're also why the best modded servers for low-end PCs writeup leans on performance mods you add purely client-side. The mismatch only ever comes from gameplay and content mods that talk between client and server.

Server-side-only mods go the other way and must not land on your client. Backup tools, anti-grief, and many performance mods run only on the server — on Fabric that's declared in fabric.mod.json as "environment": "server". The server won't request those from you, and adding them to your client just creates the extra-mod case that gets you kicked. The "environment" field is exactly how a mod says where it belongs: "*" for both sides, "client" for client-only, "server" for server-only.

Fabric behaves differently

Base Fabric Loader does not send or enforce a server-side mod list, so a Fabric server generally won't reject you just for having different mods the way Forge does. There's no blanket parity check. Instead, missing a required client mod tends to surface as that one mod's networking failing, visual or gameplay desync, or a kick from that single mod rather than a global Missing Mods screen. Some individual Fabric mods can still disconnect a client that lacks their companion, but that's mod-specific behavior, not a loader-wide handshake.

The screen people confuse with a join error is Incompatible mods found!, often with Some of your mods are incompatible with the game or each other! under it. That's a game-launch error, not a join error — Fabric throws it at startup when it finds unmet dependencies or a version that doesn't fit. The usual line is a mod that requires any version of fabric-api, which is missing!, or one that requires version <x> of 'Minecraft' (minecraft), but only the wrong version is present: <y>!. Fix it by installing the missing dependency, which is most often fabric-api, then matching every mod to your Minecraft version and using the right Java version. Update Fabric API first, then bring the other mods in line behind it.

Don't confuse this with a version mismatch

A mod mismatch and a protocol mismatch are separate problems with separate fixes, and the screen tells you which you've got. Missing Mods or mismatched mod channel list is about mods. Outdated client! or Outdated server! is about the network protocol — your client and the server are on different game versions. Under our versioning, 26.1 is protocol 775 and 26.2 is protocol 776, and the two sides have to share the same number to connect. Outdated server! is what you usually see right after you update your client past the server. Reinstalling the pack fixes a mod mismatch and does nothing for a protocol gap, so read the actual string before you act. If you're weighing an update, whether plugins break on 26.2 covers the version side, and the version 26.1 listing shows the servers on the version many modded packs still target.

FAQ

Where exactly do I look to see which mod is wrong?

Read the disconnect screen first — Forge and NeoForge name the offending mod IDs and versions, either in a Missing Mods: list or in the channel-mismatch detail. If the screen is terse, open the client log at .minecraft/logs/latest.log and search for Missing Mods, mismatched mod channel list, or the at CLIENT line; it spells out which side has the extra or absent mod. Match each ID and version it names, then reinstall the pack so you're not fixing them one at a time.

Can a server make my client auto-download its mods so I never have to match by hand?

Yes, but only the owner can set that up. Mods like AutoModpack — which run on Fabric, Forge, NeoForge, and Quilt — let a server distribute its pack to clients on join, so the client auto-pulls the matching files and the versions line up for you. It's the owner's choice to install on their server; a player can't add it to someone else's. ViaVersion-style multi-version bridging is the same deal — an owner-side option you can't bolt onto a server you don't run.

I'm on the exact same pack version and still get kicked — what's left?

First confirm you actually launched the pack's own profile or instance, not a default .minecraft that's still carrying stray jars — running the wrong instance is an easy way to be "on the pack" yet load the wrong mods folder. Then check for a jar in your mods/ that isn't part of the pack, since an extra mod fails the handshake just as surely as a missing one. A second copy of a mod at an old version does it too, so delete duplicates. If you installed the loader yourself, that's the usual culprit — reinstall the pack through the launcher so the Forge or NeoForge build matches the pack's manifest instead of whatever you grabbed separately. Then restart the client fully so it rescans before you reconnect.

Do I need any of this to join a Paper or Spigot server?

No. Paper, Spigot, and Bukkit run their plugins entirely server-side, and the client connects with plain vanilla Minecraft — you install nothing locally. All you need is a Minecraft version on the same network protocol as the server, the same rule that governs every join. Handshake and Missing Mods screens only come from Forge and Fabric modded servers; if a plugin server won't let you in, it's a version or connection problem, not a mods one. The default port doesn't change either — modded or plugin, Java servers still use 25565, Bedrock 19132.