Bridge troubleshooting

Work down this page in order. Most of what goes wrong is the local port, a firewall, or the address having been paused. The steps and the downloads for the program, the server plugin and the seven mod builds are on the Bridge page.

Windows says it protected your PC

The Windows program is not signed with a certificate yet, so SmartScreen shows a blue box the first time you run it. Choose More info, then Run anyway.

What you can check instead of a signature: the installer and the program’s own updates verify every download against the sha256 the release feed publishes, and the download link on the Bridge page is the only place we hand out builds. A copy of bridge.exe from anywhere else is not ours.

Signing is on the list. Until then the prompt appears once per new version on that machine.

Nothing answers on the local port

The program prints a line like this while it runs:

nothing answers on 127.0.0.1:25565 yet

It means the tunnel is up but your server is not listening where the address expects. Three causes, in the order they happen:

The server is not started yet. The line turns into one saying the server answers, within 15 seconds of the server being up. Nothing to do.
The server listens on another port. Check server-port in server.properties, then set the local port on the address in the panel, or start the program with --java-port 25580.
The server listens on a single interface. A server bound to one LAN address rather than all of them cannot be reached on 127.0.0.1. Leave server-ip empty in server.properties, which is the default.

For games other than Minecraft, the port row in the panel is the one to compare against the game’s own setting.

Players cannot join, and the program looks fine

Did they type the port? Java players type the address alone. Bedrock players need the port from the panel. See what each kind of player types.
Bedrock on a console cannot type an address at all. That is a Bedrock limitation, not a Bridge one; the usual workaround is a LAN entry on the network or a hosted Bedrock server.
They see the offline screen while your server is running. The program is not connected: the address only answers from your machine while the program holds the tunnel. Run bridge status, and if it says the program is signed in but not connected, start it again.
The address is paused. A free address that has used its 300 GB for the month is paused until the next month, and a free address nobody connected to for 30 days is released. Both are on the address’s page in the panel: limits.
Login protection is on and they never registered a password, or have forgotten it. Walk them through the prompt again, or switch the door off for a minute from the address’s Login protection panel.

A Bedrock player cannot join

Two things to check, in this order:

The port. Bedrock clients do not read the SRV record, so a Bedrock player types the address in the Server Address box and the Bedrock port shown on the address in the panel in the Port box. Java players type the address alone; Bedrock players never can.
Something that speaks Bedrock. A Java server needs Geyser in front of it before a Bedrock client can get in at all. The plugin reads Geyser’s port by itself while bedrock-port is auto in its config.yml. A Bedrock dedicated server needs no translation layer, only the UDP port row.

A Bedrock player who types the address with no port reaches the Java port, and the client gives up without a message worth reading.

The panel says offline while the game says connected

Refresh the page once. The Bridge page updates live, the second the program connects or drops, but a page left open for hours can lose its own connection to the panel and then goes on showing the last thing it heard. A refreshed page shows the truth.

Firewalls and restricted networks

The program only makes connections out. You do not need an inbound rule, a forwarded port or a static address.

Windows Defender Firewall may ask once whether to allow the program on your network. Allow it, or dismiss it; outbound traffic works either way. If your server is also meant to be reachable on your own LAN, allow it on the private network.
The game server itself still needs to accept connections from your own machine. A firewall rule that blocks all local connections to port 25565 blocks the tunnel too.
Work, school and some mobile networks allow only web ports out. The program needs one outbound TCP connection to the relay on a port of its own, so on a network like that it cannot connect. A home connection behind carrier-grade NAT is fine; that is the case Bridge is for.
A VPN on the host machine can send the program’s connection somewhere far away and add latency for everyone. Prefer the relay region nearest your real location, with the VPN off for the server.

Reconnects after a drop

The program is built to be left running. When your network drops, or the relay restarts, it keeps retrying and comes back on its own, usually within seconds of the path being there again; the address stays the same throughout. Players who were connected are dropped by the game and can rejoin as soon as it reconnects.

If it has been retrying for several minutes, check your own connection first, then ask in Discord: a relay with a problem is announced there.

To have it start with the machine instead of a terminal window:

bridge service install

It becomes a Windows service, a launchd agent or a systemd user service, and comes back after a reboot. bridge service status says what the system thinks of it, bridge service stop stops it.

Reading bridge status

bridge status answers the four questions worth asking, without the log:

whether this machine is signed in, and to which address,
whether the program is connected to a relay, and which one,
the public address and port for each port row,
whether something answers on each local port right now.

If it says the machine is not signed in, run bridge on its own: with no arguments it signs in and then runs. bridge logout forgets the token on this machine, which is what you want before you pass the machine on to somebody else. Rotating the token in the panel has the same effect from the other end, and every machine using the old token stops.

Updates

The program checks for a new version shortly after it starts and every few hours, verifies the download and replaces itself. On Linux and macOS it is reconnected a few seconds later. As a Windows service it exits and the service manager starts the new one.

bridge update does it immediately. A build you compiled yourself never updates itself.

The server plugin

The plugin printed no claim link

On the first start it downloads the bridge program into plugins/FadeHostBridge/bin/, which needs outbound web access from the machine running the server. The console says what failed. Fix the connection and start the server again; it tries once per start.

The plugin prints nothing at all

On a server hosted at FadeHost that is by design. A hosted server already has a public address, so the plugin stays out of the way and says nothing.

Elsewhere, check that the jar is in plugins/, that the server is Bukkit, Spigot, Paper or Purpur on Java 8 or newer, and that the console does not report it as failed to load. /bridge prints the address or the claim link at any time, and the permission is fadehostbridge.admin, which operators have by default.

My server is Forge, NeoForge or Fabric and the plugin does not load

That is expected. The plugin is a Bukkit plugin, and a Forge, NeoForge, Fabric or Quilt server has no Bukkit plugin loader. A vanilla server.jar loads no plugins at all. What to use instead depends on the loader:

Fabric, on Minecraft 26.1 and up, 1.21.1 or 1.20.1. Take the mod for your version. The same jar that shares a world opened to LAN works in a server’s mods/ folder: drop it in, start the server, and the console prints a link and a code to claim the address once.
NeoForge, on Minecraft 26.1 and up, or 1.21.1. The same thing, with the NeoForge build for your version. The 1.21.1 build is for the NeoForge 21.1 series.
Forge, on Minecraft 1.21.1 or 1.20.1. Take the Forge build for your version, fadehost-bridge-forge-mc1.21.1-0.1.0.jar or fadehost-bridge-forge-mc1.20.1-0.1.0.jar, in the server’s mods/ folder. It needs Forge 52 or newer on 1.21.1 and Forge 47 or newer on 1.20.1, and it serves a server only.
Another Forge version, Quilt, a vanilla jar, or a modded server on any other Minecraft version. Take the bridge program, which is the way that works everywhere: install it on the machine, run bridge login once, start the server, run bridge. Nothing is installed inside the server.

Either way the address and everything around it are the same; the only thing the plugin would have saved is the login step.

The server is a proxy, a Bedrock server, or something else entirely

Same answer. Velocity, BungeeCord, Bedrock Dedicated Server and every non-Minecraft game run the program next to the server. The port rows on the address decide what is carried, so a proxy on 25577 or a Bedrock server on 19132 is a local port in the panel and nothing more.

The Fabric, NeoForge and Forge mods

The mod printed nothing in chat

The address is fetched when a world is opened to LAN, so open one: Escape, Open to LAN, Start LAN World. Check as well that the jar matches the loader and the Minecraft version you are running: Fabric on 26.1 and up, 1.21.1 or 1.20.1, or NeoForge on 26.1 and up or 1.21.1. The Forge builds do not do a LAN world at all: a world opened to LAN on Forge uses the bridge program.

The mod is in mods/ on my server and the console shows nothing from Bridge

The server has to be one the mod runs on. There are seven builds, one per loader and Minecraft line:

Fabric, on Minecraft 26.1 up to 27, on 1.21.1, or on 1.20.1.
NeoForge, on Minecraft 26.1 up to 27, or on 1.21.1 with the NeoForge 21.1 series.
Forge, on Minecraft 1.21.1 with Forge 52 or newer, or on 1.20.1 with Forge 47 or newer.

A Quilt server, a Bukkit-family server and a vanilla server.jar load none of them, whatever the jar is called, and neither does a loader on a version outside the list above. Check the jar in mods/ is the build for your loader and your version: the file name carries both, fadehost-bridge-fabric-mc1.21.1- for Fabric on 1.21.1 and fadehost-bridge-neoforge-mc26- for NeoForge on 26.1 and up. A 1.21.1 or 1.20.1 build loads on that one version and nothing else, so it will not start a server on a neighbouring version. Each build runs on the Java its Minecraft line needs anyway: Java 25 on 26.1 and up, Java 21 on 1.21.1, Java 17 on 1.20.1. The Fabric builds need no Fabric API.

A server that fits none of these runs the bridge program next to it instead, which does not care about the loader or the version.

When the loader and the version are right, the first line in the console is Getting a public address for this server... as the server finishes starting. The mod waits until the server is listening, so the line comes late in the start, not with the first log lines.

It says it could not get a public address

In chat on a client, in the console on a server:

[Bridge] Could not get a public address

The line comes with a reason, and the reason has so far always been the same thing: the machine could not reach FadeHost’s release feed to download the bridge program. Check the connection, then open the world to LAN again, or start the server again.

A claim code appears again for a world or server that was claimed before

The claim lives in the folder it was made in, <game folder>/fadehost-bridge/ on a client and <server folder>/fadehost-bridge/ on a server, so the mod asks again when it cannot find it:

The state folder is gone. Deleting fadehost-bridge/state, or reinstalling the instance, leaves nothing to show for the old claim.
It is a different folder. A second launcher profile, a modpack instance, a copied game folder or a second copy of the server is a different folder, and the address belongs to the folder it was claimed in.

Claiming again is safe. It gives the same account another address rather than taking anything away, and the address you no longer want can be deleted on the Bridge page in the panel.

Friends cannot join a world opened to LAN

The versions have to match. They need the exact Minecraft version the world is running, and the same mods, exactly as they would for any LAN world. The Bridge mod is not one of them: they do not need it.
The world has to stay open. The address answers while the LAN world is open. Closing it, or leaving to the title screen, stops the program, and from that moment players get the offline screen.
The address is the same every session. It belongs to the game folder, so there is no new address to pass around after the first time. A friend whose server list entry stopped working is hitting one of the two causes above, not an address that moved.

Still stuck

Open a ticket from the panel or ask in Discord. Useful in the first message: the address, which way in you are using, the program, the plugin or one of the mods, what bridge status says, and the last twenty lines the program, the console or chat printed.