ViaProxy: one proxy for every Minecraft protocol from Classic to Bedrock

The client and server version matrix is the product

ViaProxy is described as a standalone proxy which allows players to join every Minecraft server version, and the two lists below are the entire scope of the project.

The supported server versions are Release from 1.0.0 to 26.3, Beta from b1.0 to b1.8.1, Alpha from a1.0.15 to a1.2.6, Classic from c0.0.15 to c0.30 including CPE, the April Fools versions 3D Shareware, 20w14infinite and 25w14craftmine, the Combat Test 8c snapshot, and Bedrock Edition 1.26.51, which is marked work in progress with many features missing.

The supported client versions are narrower on the old end and wider at the top: Release from 1.7.2 to 26.3, the April Fools versions 3D Shareware and 25w14craftmine, Bedrock Edition, which requires the Geyser plugin, Beta 1.7.3, which requires the Beta2Release plugin, and Classic, Alpha, Beta and Release 1.0 to 1.6.4, which is passthrough only.

And the rule that makes it a proxy rather than a set of translators: ViaProxy supports joining to any of the listed server versions from any of the listed client versions. That is the cross product, and it is the thing to evaluate. A modern server can accept a 1.7.2 client, and an Alpha server can accept a current client.

Two of the listed combinations are explicitly passthrough only, which is the honest limit of the old client support. And the Bedrock entry is a work in progress rather than a finished feature.

The five translation engines each have their own config file

The protocol translation is not configured in one place, and this is the detail that trips people up when they first set the proxy up.

The main settings live in the viaproxy.yml config file, and most of the settings are configurable through the GUI. But the protocol translation settings and features live in the ViaLoader folder, where you will find five config files: viaversion.yml for ViaVersion, viabackwards.yml for ViaBackwards, viarewind.yml for ViaRewind, vialegacy.yml for ViaLegacy and viabedrock.yml for ViaBedrock.

Five engines, and each one covers a direction. ViaVersion handles the modern protocol range, ViaBackwards handles going backwards to older release versions, ViaRewind handles the older versions that sit outside the range ViaVersion covers, ViaLegacy handles the pre-release eras of Classic, Alpha and Beta, and ViaBedrock handles the Bedrock side.

That structure is a direct consequence of the version matrix. A single translation table cannot cover a fifteen year span of protocol changes, so the work is split by era and the proxy loads whichever engines the chosen client and server versions need.

The naming of the ViaLoader folder is also the hint that this is a modular pipeline rather than a monolith. Each engine contributes its own transformations, and a version pair is handled by combining the relevant ones.

The Bedrock engine is the one to be careful about, since the server version list marks Bedrock Edition 1.26.51 as work in progress with many features missing, and the linked ViaBedrock documentation is where the feature list lives.

Running it: a jar with three modes, or a Docker image

The distribution is deliberately simple, which is the right choice for a tool that non-administrators also run.

The executable jar comes from GitHub Releases for a stable version, from GitHub Actions for the latest dev build, or from the ViaVersion Jenkins. The Docker image is on GitHub Packages, and running the latest version looks like this:

docker run -it -v /path/to/run:/app/run -p 25568:25568 ghcr.io/viaversion/viaproxy:latest

The volume is where the ViaProxy data is stored and the port 25568 is the one ViaProxy should listen on. The Dockerfile shows the shape of the image, based on eclipse-temurin:25-jre-alpine with the jar copied to /app/ViaProxy.jar and the entrypoint set to run the config command against viaproxy.yml, which is what generates the configuration on first start.

There are three ways to run the jar, and they produce different artefacts.

The GUI mode is for players. You download the jar, put it into a folder where it will generate its config files and store data, run the jar, fill in the server address and version, add your Minecraft account in the Accounts tab if you want to join an online mode server, click Start, and then join with your client on the displayed address.

The config mode is for server owners. You run the jar with the config command, it generates a viaproxy.yml file in the same folder and exits, you edit that file with the most important options at the top, and then you start the proxy with the start command.

The CLI mode is the third. Running the jar with the cli argument and the help flag prints the CLI usage and exits, and you configure the proxy from there, optionally putting the finished start command into a script.

The features that decide whether your server will accept the client

The special features list is short and each item is a specific compatibility problem that has been solved.

Support for joining online-mode servers is the first, and it is the one that separates a serious proxy from a toy. In online mode the server itself authenticates the player, which normally means the client has to talk the server's protocol version, including the encryption handshake, so a translated client would fail. ViaProxy handles this, and the GUI has an Accounts tab where you add your Minecraft account for exactly that case.

Chat signing is the second and the more technical. Servers with chat signing enabled require the client to sign chat messages with a key the server can verify, and a client from 2013 does not know how to do that. The list states support for joining on servers which have chat signing enabled from all listed client versions, which is a genuinely hard problem rather than a feature flag.

The third item is version specific. Supports transfer and cookies for <=1.20.4 clients on 1.20.5+ servers, which is about the client transfer mechanism that changed in 1.20.5, and the workaround is to pass transfer and cookies for the older clients.

Then there are two items about what a player can do once connected. Joining Minecraft Realms with any supported client version, and the Simple Voice Chat mod.

The Bedrock side is separate from all of this. Supporting Bedrock Edition clients requires the Geyser plugin, and Beta 1.7.3 clients require the Beta2Release plugin, so those two paths are not self contained in ViaProxy alone.

Extending it, translating it, and the licensing

The project has a plugin API, which is what makes the tool adaptable to a server that needs something specific.

ViaProxy has a plugin API which allows you to extend and modify the behaviour of ViaProxy, with the documentation on creating plugins in the project wiki and a list of available plugins in another wiki page. For a server owner whose community is stuck on one particular version, that is the extension point where a workaround can live.

Translation is handled through Crowdin, so the interface is localised, and contributions are welcome in the form of pull requests. The contribution guidance asks for code style consistent with the rest of the project, code that is easily maintainable, and for large scale changes to open an issue or join the Discord first rather than sending a large pull request cold.

The licence is GPL-3.0, and that is worth pausing on for an organisation. A proxy is a network-facing server component, and GPL-3.0 means that if you modify ViaProxy and distribute the modified version, the source has to be made available under the same terms. Running the unmodified jar, or the official Docker image, as part of your own service is a different question from shipping a modified copy, and the specifics deserve a legal review rather than an assumption.

The repository layout is a standard Gradle project with a Dockerfile, build.gradle, buildSrc/, settings.gradle, the gradle wrapper and the gradlew scripts, gradle.properties, a .idea/ directory, and src/. The release history shows v3.4.14 on 2026-09-27, v3.4.13 on 2026-09-18 and v3.4.12 on 2026-06-29, and the last push was on 2026-10-19. Issues go to the issue tracker, and there is a ViaVersion Discord for questions.

Editorial conclusion

ViaProxy suits a server owner who wants to open a modern server to players on old clients, or a player who wants to join an old server from a current client, and the cross product of the supported client and server versions is the feature that makes it useful. It does not suit you if you only need one protocol version, since the translation layer is pure overhead in that case, and it does not suit you if you need Bedrock support to be complete, since Bedrock 1.26.51 is marked work in progress with many features missing. Before you deploy it, read the five files in the ViaLoader folder, because the protocol translation behaviour is configured there and not in viaproxy.yml, and note the licence is GPL-3.0.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. ViaVersion/ViaProxy on GitHub