Question about p2p.mcraft.fun and self-hosting a compatible PeerJS server

[eliasempresas]

Hello!

I am studying the self-hosting options for Minecraft Web Client and would like to understand how https://p2p.mcraft.fun is configured.

1. Is p2p.mcraft.fun running the standard PeerJS server (peerjs-server)?
2. Does it use any custom modifications or additional services?
3. Which exact host, port, path, and security settings should be used by a self-hosted client?
4. Is a custom PeerJS key required?
5. Which PeerJS server version is compatible with the current Minecraft Web Client?
6. Are STUN or TURN servers required or recommended?
7. Is there an example configuration or documentation for hosting a compatible replacement?

For example, would a configuration similar to this be correct?

const peer = new Peer({
  host: "my-peerjs-server.example.com",
  port: 443,
  path: "/",
  secure: true
});

I would appreciate any clarification or example configuration for reproducing the functionality of p2p.mcraft.fun in a self-hosted setup.

Thank you!

[eliasempresas]

Analysis performed by Manus AI:

https://manus.im/share/file/622e762b-f96b-4da1-b0b8-922bdfe39cf6

https://manus.im/share/k2VlcM4bn39baB5RdCcdmt

[eliasempresas]

Technical response for issue #602

Conclusion

The Minecraft Web Client’s P2P multiplayer feature uses the standard PeerJS client. The signaling service does not carry game traffic: it provides peer IDs, maintains PeerJS signaling, and helps the two browsers negotiate a WebRTC connection. Once the WebRTC connection is established, data is sent directly between the browsers whenever the network allows it.

In the current client code, the locked dependency is peerjs@1.5.4. Peer creation is implemented in src/localServerMultiplayer.ts. The client enables secure: true when opening a WAN session, accepts a server configured by URL, and includes that server in the generated invitation link. The current public configuration contains:

{
  "peerJsServer": "",
  "peerJsServerFallback": "https://p2p.mcraft.fun"
}

There is no evidence in the analyzed code of a proprietary PeerJS modification, a required key other than the default peerjs, or an additional service specific to the Minecraft Web Client. The p2p.mcraft.fun domain could not be used as a reliable source of configuration during testing: one attempt returned a 404 response and another presented a TLS certificate that did not match the hostname. Therefore, its current production configuration cannot be confirmed from the public endpoint.

Ready-to-publish answer for the issue

The current Minecraft Web Client implementation uses the standard PeerJS client (peerjs@1.5.4) and a standard PeerServer-compatible signaling service. There is no Minecraft-specific P2P protocol involved.

The relevant code is src/localServerMultiplayer.ts. For the host, the client creates the peer approximately as follows:

const peer = new Peer({
  debug: 3,
  secure: true,
  ...parseUrl(configuredServerUrl)
})

The configured server URL is also placed in the generated join link, so the joining browser uses the same signaling server. The server is only used for PeerJS signaling and peer discovery; it is not a Minecraft proxy and does not relay game data after WebRTC connects.

A self-hosted replacement can therefore be run with the official PeerJS server package:

mkdir -p /opt/minecraft-peerjs
cd /opt/minecraft-peerjs
npm init -y
npm install peer@latest
npx peerjs --port 9000 --path / --key peerjs --proxied

For a public HTTPS hostname, it is preferable to keep PeerServer bound to localhost and put it behind Nginx. For example:

server {
    listen 443 ssl http2;
    server_name peer.example.com;

    ssl_certificate     /etc/letsencrypt/live/peer.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/peer.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The client-side server URL should then be:

https://peer.example.com/

In the project’s config.json, a self-hosted deployment can use:

{
  "peerJsServer": "https://peer.example.com/",
  "peerJsServerFallback": ""
}

The equivalent direct PeerJS configuration is:

const peer = new Peer({
  host: "peer.example.com",
  port: 443,
  path: "/",
  secure: true,
  key: "peerjs"
})

key: "peerjs" is the default PeerServer key, so it normally does not need to be specified. If the administrator starts the server with another key, the same key must be included in the client URL, for example:

https://peer.example.com/?key=my-secret-key

The key is not a cryptographic authentication mechanism and should not be treated as a password. It is primarily used as the PeerServer API/routing key.

If a subpath is desired, keep the path identical on both sides. For example, configure PeerServer with --path /mcraft and use:

https://peer.example.com/mcraft/

in the client. Do not configure one path in Nginx and a different path in PeerJS.

Before using the server in the web client, verify that the PeerServer root returns JSON rather than an HTML 404 page. With the default key, also test:

curl -fsS https://peer.example.com/
curl -fsS https://peer.example.com/peerjs/id

The second command should return a peer ID. Also verify the WebSocket upgrade through Nginx; PeerJS requires WebSocket support.

STUN and TURN are separate from PeerServer. STUN is recommended for discovering public network candidates, but it does not relay traffic. TURN is only needed when the two browsers cannot establish a direct WebRTC path because of restrictive or symmetric NATs or firewalls.

A TURN service must be configured in the PeerJS client’s iceServers option. PeerServer itself does not provide TURN. The current Minecraft Web Client does not expose a general iceServers setting in config.json, so requiring a private TURN server would require a small code/configuration change in localServerMultiplayer.ts.

In summary, a standard PeerJS-compatible server, HTTPS, a correctly configured reverse-proxy WebSocket connection, and matching host/path/key values are sufficient for the basic self-hosted setup. The exact production settings of p2p.mcraft.fun cannot be confirmed unless its maintainer publishes them; the public endpoint did not provide a valid PeerServer response during testing.

Recommended production procedure

1. Create an A/AAAA DNS record for peer.example.com pointing to the server.
2. Install Node.js 18 or later and the peer package.
3. Run PeerServer on 127.0.0.1:9000, preferably as a systemd service.
4. Configure Nginx with a valid TLS certificate and WebSocket upgrade support.
5. Set peerJsServer in the build or config.json to https://peer.example.com/.
6. Test the JSON response from the root endpoint, the /peerjs/id endpoint, and a real connection between two browsers on different networks.
7. If connections fail only on specific networks, add TURN; changing the PeerServer port will not solve NAT traversal problems.

Important notes

The secure: true option is required when the web client is served over HTTPS, because browsers block mixed content and signaling must use HTTPS/WSS. PeerServer does not need to listen directly on port 443 when Nginx terminates TLS.

The signaling server does not host the world, replace a Minecraft server, or act as a TCP game proxy. The host continues to run the local world in the browser, while other players connect through WebRTC.

Sources

• Minecraft Web Client P2P multiplayer code
• Public client configuration
• PeerJS Server
• PeerJS documentation
• Project technical documentation
• Issue #602

Accuracy note: this answer describes behavior verified in the source code and configuration documented by PeerJS. It does not attribute any unpublished configuration to the maintainer of p2p.mcraft.fun.

[eliasempresas]

Is the information provided by Manus AI correct?

[eliasempresas]

Is the information provided by Manus AI correct?

@zardoy

[zardoy]

Yes and p2p.mcraft.fun is just one line peerjs server , peerjs works badly and will be replaced with trystero which works more reliably

[eliasempresas]

Thanks for the clarification!

So, as I understand it:

• p2p.mcraft.fun is just a simple PeerJS server.
• There are no special Minecraft-specific services required for it.
• A self-hosted PeerJS server can therefore reproduce the current P2P signaling functionality.
• However, since PeerJS is planned to be replaced with Trystero due to reliability issues, I’ll wait for the Trystero migration before setting up a permanent self-hosted P2P server.

Thanks for confirming!

[zardoy]

Why would you need a permanent p2p hosting server? Just use p2p.mcraft.fun

[desenvolvedor-ee]

Since you mentioned that PeerJS will be replaced by Trystero because PeerJS works poorly, I'm preparing a separate experimental p2p-trystero implementation for a self-hosted Minecraft Web Client deployment.

Do you already know how the Trystero migration will work in terms of signaling/discovery?

In particular:

Will Trystero use a centralized signaling server?

If so, will it be possible to self-host that component?

Or will the new implementation rely entirely on Trystero's existing public infrastructure/providers?

Will the Minecraft Web Client expose a configurable endpoint similar to the current peerJsServer / peerJsServerFallback?

I'm asking before implementing anything because I don't want to assume that a Trystero-based setup requires or supports a PeerServer-like backend.

[zardoy]

I'm asking before implementing anything because I don't want to assume that a Trystero-based setup requires or supports a PeerServer-like backend.

Yea I can provide that feel free to do the PR with all the changes required I need to support

[desenvolvedor-ee]

I wrote it wrong, I'm trying to find out how the p2p implementation will work in mcraft with Trystero, so I can host my own server for users whose internet connection is blocking mcraft.fun and its subdomains.

[zardoy]

Use discord unblockers like doge unblocked or host proxy server so can join real servers like play.mcraft fun you don't need p3p for it

[desenvolvedor-ee]

Since you mentioned that PeerJS will be replaced by Trystero because PeerJS works poorly, I'm preparing a separate experimental p2p-trystero implementation for a self-hosted Minecraft Web Client deployment.

Do you already know how the Trystero migration will work in terms of signaling/discovery?

In particular:

Will Trystero use a centralized signaling server?

If so, will it be possible to self-host that component?

Or will the new implementation rely entirely on Trystero's existing public infrastructure/providers?

Will the Minecraft Web Client expose a configurable endpoint similar to the current peerJsServer / peerJsServerFallback?

I'm asking before implementing anything because I don't want to assume that a Trystero-based setup requires or supports a PeerServer-like backend.

I wrote it wrong, I'm trying to find out how the p2p implementation will work in mcraft with Trystero, so I can host my own server for users whose internet connection is blocking mcraft.fun and its subdomains.

Could you answer my question about how TrysTero will work in MCraft?

Use discord unblockers like doge unblocked or host proxy server so can join real servers like play.mcraft fun you don't need p3p for it

I still want to host my fallback p2p server.