How to Set Up Netplay for Online Retro Multiplayer

RetroArch netplay synchronizes instances running the same deterministic core and content to reproduce local multiplayer over a network. It is not a universal implementation of console link cables or original online services. A successful TCP connection is only transport; matching simulation, saves, devices, and settings prevents divergence.

Use lawfully obtained content on each machine. Never send ROMs, disc images, firmware, keys, NAND data, or copyrighted saves to make peers match.

Step 1: define the supported session

Check the current Netplay FAQ for the system/core. RetroArch documents that its general model is unsuitable for several later systems and that link-cable support has specific exceptions. Confirm player count, local multitap/device topology, and whether spectators are intended.

Use a short test game/session before organizing a tournament or long campaign.

Step 2: match software and content exactly

All peers should record the same RetroArch version, core name/version, content hash, region/revision, patch output, firmware hash, core options, cheats, and emulated device types. The official FAQ states same RetroArch, same core, and same exact content.

Obtain RetroArch/cores from official updaters or trusted packages. Do not exchange native core binaries over chat. Disable cheats, rewind, run-ahead, and nondeterministic hacks for the baseline. Start from a clean game or a synchronized in-game save through supported behavior, not an arbitrary state.

Step 3: back up mutable data

Copy Save Files, memory cards, and core options with RetroArch closed. Netplay initial synchronization can involve SRAM, and a session should not endanger the only long-term save.

Use a dedicated test profile if ordinary saves are valuable. Cloud sync should be finished and closed on every peer before the session.

Step 4: configure identity and privacy

Set a nickname under Settings → User that does not reveal a full legal name, email, or account password. For a private session, set a server password and disable Publicly Announce Netplay, or share the room only with intended players.

Do not reuse an important account password. Treat lobby names, public IPs, hostnames, chat, and screenshots as public metadata when announcement is enabled.

Step 5: prefer the relay for the first internet test

Libretro recommends Use Relay Server when router forwarding is unavailable or uncertain. Relay mode avoids exposing an inbound home port and is the safer first test. It adds a network hop and can increase latency, but proves core/content/session configuration before router changes.

On a LAN, connect directly to the host’s private address and do not expose the session to the internet.

Step 6: start hosting in the documented order

The official Getting Started guide says to configure network parameters, choose Start Hosting from the Netplay menu, then load the content and wait for players. Menu wording can vary by RetroArch version; follow the installed interface and current guide.

Check the lobby only if public announcement is intended. A listed room is not proof that the host is reachable; Libretro warns the lobby does not verify inbound reachability.

Step 7: join through lobby or manual load

Clients can refresh the Netplay room list and select the host. If matching content is scanned or in history, RetroArch may connect automatically; otherwise load the exact core/content manually when prompted.

If a password is requested, enter it only in RetroArch. Do not paste credentials into stream chat or screenshots. Confirm the displayed core/content identity before sending input.

Step 8: use manual port forwarding only when necessary

Direct internet hosting generally needs inbound TCP on the configured Netplay TCP Port, commonly 55435. RetroArch may request UPnP mapping but does not confirm success.

If direct hosting is required, create a narrow router rule for TCP only, the chosen external/internal port, and the host’s reserved private IP. Add a narrowly scoped host-firewall allowance for RetroArch on the intended network profile. Test while the host is actually listening.

Never use router DMZ, disable the firewall globally, expose router administration, forward broad ranges, or publish the host IP unnecessarily. Remove temporary rules after the event. If the user does not administer the network, use relay rather than bypassing policy.

Step 9: configure controller ownership

By default, automatic assignment gives the host controller 1 and subsequent clients the next devices when Request Device settings are all off. RetroArch’s multiple-controller guide says that if any client requests a device, automatic assignment is disabled and all clients must request devices explicitly.

For multi-controller households or a multitap game, document physical Device Index, local RetroArch port, and requested netplay device. Test player order before serious play. Use a valid Multitap Device Type only when the core/game requires it.

Step 10: tune latency after synchronization works

Use Ethernet where practical, close background uploads, and display ping. Input-latency frames trade responsiveness for fewer rewind/replay corrections. Increase conservatively only after a clean matched session works.

More input delay cannot repair repeatable divergence caused by content, save, architecture, or settings. If peers see different game states at the same event, stop tuning the network and run the desync checklist.

Step 11: distinguish common failures

Content not found: scan/load exact local content; do not send it.
Failed to initialize: host not listening, wrong address/port/password, firewall, or relay failure.
Port Mapping Failed: UPnP mapping failed; use relay or a narrow manual rule.
Connects then diverges: compare versions, hashes, firmware, saves, device types, cheats, and architecture.
Stalls but stays identical: investigate latency/jitter and input-delay frames.

Generate verbose logs on both peers and compare the earliest error. Sanitize public IPs, hostnames, usernames, local paths, lobby passwords, and content names before sharing.

Step 12: validate and close the session cleanly

Play a repeatable five-minute sequence, verify player order and identical state, then restart both peers and reconnect through the normal path. Test save/quit/relaunch on copies if progress matters.

Afterward, stop hosting, close RetroArch normally, wait for save/cloud sync, remove temporary forwarding/firewall rules, and preserve the configuration manifest. A sound setup works after restart through relay or a narrowly documented direct path and never depends on DMZ, disabled security, or shared copyrighted files.

Related:

Sources: