v2ray-core: a Go library whose README is a redirect and whose last release is from 2020

The first line of the README is a move notice

The document opens with a single instruction, Move To https://github.com/v2fly/v2ray-core, separated from everything after it by a rule and a heading for Project V. What follows is the older text: a paragraph describing Project V as a set of network tools that help you build your own computer network, that secure your network connections and thereby protect your privacy, a pointer to v2fly.org, a license section, and a credits list. The badges repeat the message of the first line. The test badge points at the actions page for v2fly/v2ray-core, the coverage badge at codecov for the same repository, the GoDoc badge at v2ray.com/core, and the two download counters cover both the v2ray and the v2fly release pages. The license link resolves the same way, to raw.githubusercontent.com/v2fly/v2ray-core/master/LICENSE. So a reader who arrives here and follows any of the project's own pointers ends up in a different repository, and the badges on this page report that repository's state rather than this one's.

The last release is v4.31.0 from 2020, and master was pushed on 2026-08-31

The release history and the commit history disagree by roughly six years. The three most recent releases are v4.31.0 dated 2020-10-10, v4.28.2 dated 2020-09-18, and v4.27.5 dated 2020-09-02, all of them from 2020. The repository is not archived, and the default branch master was last pushed on 2026-08-31, so commits are still landing on it. Both facts sit in the record and the project does not explain the gap, because the README is a redirect rather than a changelog. The disagreement cuts both ways, and each route has a cost. Pin a published artifact and you are pinning code from 2020 with a dependency graph resolved in the same month. Track master and you are running code that was never cut as a release, so there is no version to quote in a bug report and no tag to roll back to. This repository does not document which of the two is intended, and the redirect sends you elsewhere to find out.

go.mod declares go 1.15 under the module name v2ray.com/core

The dependency manifest is a snapshot of 2020, and the module identity predates the move. The module is named v2ray.com/core, the language directive is go 1.15, and the require block pins quic-go at v0.18.1, grpc at v1.32.0, protobuf at v1.25.0, golang/protobuf at v1.4.2, gorilla/websocket at v1.4.2, miekg/dns at v1.1.31, testify at v1.8.1, golang/mock at v1.4.4, and go-cmp at v0.5.3, alongside go.starlark.net, cuckoofilter, go-proxyproto, and xiaokangwang/VSign, with the golang.org/x modules held at October 2020 pseudo versions. Two things follow. Building master means compiling against that 2020 graph rather than against current versions of anything, and the go directive names a toolchain generation far behind the commit dates on the branch. The import path also still says v2ray while the project, the badges, the license link, and the Docker build all say v2fly, so module identity and project identity have drifted apart without a note saying which one a consumer should import.

The Dockerfile has its entrypoint commented out and expects a config file it never creates

The final stage of the image is three lines, and one of them is disabled:

#ENTRYPOINT ["/usr/bin/v2ray/v2ray"]
ENV PATH /usr/bin/v2ray:$PATH
CMD ["v2ray", "-config=/etc/v2ray/config.json"]

The binary is found through PATH rather than through an entrypoint, so the image runs the bare command v2ray and depends entirely on CMD for its arguments. The configuration path is hard coded to /etc/v2ray/config.json, and neither build stage creates that directory or writes that file. The second stage only extracts the release tarball into /usr/bin/v2ray and installs ca-certificates. So a container started from this image has no configuration, and the repository supplies no schema to write one against: there is no sample config and no configuration documentation, only config.proto with its generated config.pb.go describing internal message types. Starting the image is the easy half, and supplying a working configuration is left entirely to you.

The image clones the v2fly repository, so what you get depends on when you built it

The builder stage does not build this repository. It installs git, bash, wget, and curl into a golang:alpine image and then clones the other project:

RUN git clone --progress https://github.com/v2fly/v2ray-core.git . && \
    bash ./release/user-package.sh nosource noconf codename=$(git describe --abbrev=0 --tags) buildname=docker-fly abpathtgz=/tmp/v2ray.tgz

Three consequences sit in those two lines. The clone takes a branch head, so the artifact is whatever master happened to be at build time and two builds a week apart need not match. The version label comes from git describe, which reports the most recent tag rather than the commit being built, so an image can carry a name taken from 2020 while containing 2026 code. And the build needs the network, since it fetches the repository and runs apk update. The nosource and noconf arguments are the release script's packaging switches, and abpathtgz=/tmp/v2ray.tgz is the path the second stage copies from. Building this Dockerfile from this repository does not build this repository.

The credits name four third-party projects; go.mod requires twenty

The credits section splits third party projects into two groups. In production it names gorilla/websocket and gRPC, linked to the gorilla repository and to google.golang.org/grpc. For testing only it names miekg/dns and h12w/socks. The require block in go.mod tells a longer story, listing twenty modules that include quic-go, both protobuf modules, the golang.org/x set, go.starlark.net, cuckoofilter, go-proxyproto, xiaokangwang/VSign, and github.com/xtls/go. The mismatch is the point. A reader auditing what this code pulls in from the README comes away with four names and a much smaller picture of the surface area than the build actually has, while a reader reading go.mod gets the full pinned inventory. The production and testing split is worth respecting on its own, because h12.io/socks and miekg/dns sit on the test side and are not part of a release build. Versions appear in go.mod and nowhere else in the repository.

The root mixes go.mod with a WORKSPACE file, and much of it is generated

Look at the top level and the build story is ambiguous. There is go.mod and go.sum, which is the Go module build, and there is also a WORKSPACE file, which is the marker for a Bazel workspace. Continuous integration is configured in azure-pipelines.yml with a .dev/ directory beside it, while the GitHub Actions badge in the README points at the v2fly repository's actions page rather than at anything here. Alongside that, much of the root is generated code: config.proto with config.pb.go next to it, plus annotations.go, proto.go, and errors.generated.go, with core.go, functions.go, context.go, and mocks.go as the hand written surface, and directories for app/, common/, features/, infra/, main/, proxy/, release/, testing/, and transport/. Nothing at the root says which build path is authoritative, and the configuration surface is machine generated, so reading config.pb.go describes generated types rather than the file a user would actually write.

Editorial conclusion

Treat v2ray/v2ray-core as a pointer rather than a source of truth. The working project is the v2fly repository named by the README's first line, the license link resolves there, and the Docker build clones it, so anything you intend to run, build, or audit belongs to that repository rather than this one. What is genuinely useful here is the shape of the codebase: a Go module named v2ray.com/core, a generated protobuf surface in config.proto and config.pb.go, and a root that mixes go.mod with a WORKSPACE file. Before depending on it, confirm which repository the binary you actually run came from, because the release list here stops in 2020 and the branch did not.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes