SoulFire LogoSoulFire

Fake Virtual Host

Change the hostname and port in the login handshake for virtual-host routing.

What this changes

fake-virtual-host changes the hostname and port in the client handshake before login.

That means:

  • SoulFire still connects to the address you configured
  • but the server can be told that the client originally targeted a different hostname and port

Use this on networks that route or authorize connections by the virtual host.

When to use it

Use this plugin when:

  • a proxy or frontend routes players by hostname
  • the backend expects a specific virtual host value
  • you are testing a network that behaves differently depending on the requested host

Typical examples:

  • one proxy IP serving several domains
  • TCP frontends or host-based routing layers
  • server logic that checks the handshake host for branding or access rules

When not to use it

Do not use this as a generic connectivity fix.

It will not repair:

  • broken DNS
  • a dead proxy
  • forwarding misconfiguration
  • invalid credentials
  • wrong target ports at the actual network layer

The plugin cannot fix an incorrect connection address.

Configure fake-virtual-host

Enable the plugin

Open Plugins and enable Fake Virtual Host.

Set the hostname to fake

Enter the hostname you want the server to see in the handshake.

Example:

play.example.net

Set the port to fake

Enter the port you want the server to see alongside that hostname.

Example:

25565

Join with one bot first

Test the route with one bot before changing anything else.

Practical scenarios

Hostname-based proxy routing

If one IP hosts several networks, the proxy can route players by the handshake hostname.

Connect to the shared IP and set the hostname that the proxy expects.

Frontends or reverse proxies

Some infrastructures preserve or inspect the original requested host during the handshake. If SoulFire reaches the frontend through a different address than normal players do, faking the virtual host can restore the expected login context.

Verification checklist

When you test this plugin, make sure that:

  • the target normally works for regular players using that hostname
  • the hostname you configured is exactly the one the network expects
  • the port matches the expected logical entry point
  • the bot reaches the right network path after join

If the connection lands on the wrong backend or gets rejected immediately, the faked host value is likely wrong or unnecessary.

What it cannot fix

  • It does not emulate proxy forwarding.
  • It does not replace Forwarding Bypass.
  • It does not bypass anti-bot systems by itself.
  • It does not change the actual TCP destination SoulFire connects to.

If the problem is about what hostname the server sees, use this page. If the problem is about what player identity or IP the backend expects from a proxy, use Forwarding Bypass instead.

How is this page?

Last updated on

On this page