V2Ray is a proxy construction kit, not a one-button VPN
V2Ray Core gives you a set of network pieces: inbound listeners, outbound connections, routing rules, transports, DNS handling, statistics, and a remote-control API. You assemble those pieces in configuration rather than selecting a country in a desktop app. That distinction matters. A network engineer can send one class of traffic directly, block another, and proxy the rest through a remote node. Someone who only wants every packet sent through one tunnel inherits many decisions they did not need.
The official newcomer guide shows the basic arrangement with 2 configurations. A server listens for VMess traffic and sends it through the freedom outbound. A client exposes a local SOCKS listener, connects to the server, and routes private IP ranges directly. The ID and port must match at both ends, and your browser must use the local proxy. It is understandable once drawn out, but it is still infrastructure you own.
The routing rules can express useful policy without another proxy layer
Routing is the strongest reason to choose this core. Rules can match domains, IP ranges, ports, source addresses, users, inbound tags, and detected HTTP, TLS, or BitTorrent traffic. Domain entries support exact names, subdomains, regular expressions, and maintained geosite lists. The first matching rule selects an outbound or balancer. When no rule matches, traffic uses the first configured outbound, so ordering deserves the same review you would give firewall rules.
That flexibility reaches beyond a simple home tunnel. One process can keep private networks direct, send selected domains through a proxy, and reject unwanted destinations. The documented mph matcher targets large domain sets, while GeoIP and geosite data cover regional choices. Those data files become part of the deployment: an outdated category can produce a technically correct route to the wrong destination. The configuration should therefore be versioned beside the binary and checked after data updates.
What happened when we ran it
Our sandbox installed 429 Go packages in 54 seconds at commit e29ac2e. The build succeeded in 75 seconds, then the test command finished in 234 seconds with 167 passed and 0 failed. This was an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The result says the checked-out source compiled and passed its reported suite in a clean environment. It does not measure proxy throughput, connection latency, or resistance to blocking.
The checkout itself was 6.7 MB, with 1,480 files and roughly 165,436 lines of source. We found 6 CI workflow files, no Dockerfile, and no top-level tests directory. The successful Go test run matters more than the folder name, but container-first teams will need to supply their own image recipe or use a separately published package. No credentials were needed for the source checks. A real route still needs server access and matching configuration.
Built-in DNS handles routing needs, not every resolver job
V2Ray's DNS server exists mainly to resolve connection targets and support routing decisions. The official reference says it handles basic A and AAAA queries. It also documents several ways to send DNS traffic, including local and routed DNS over HTTPS modes, and warns that the freedom outbound uses AsIs by default. If you expect configured DNS rules to affect that outbound, you need to choose the corresponding IP strategy yourself.
The limit is plain: this is not a complete DNS server. The documentation points readers toward a dedicated resolver such as CoreDNS for a fuller DNS setup. That means a sophisticated deployment may have 2 policy systems to inspect, one for name resolution and another for proxy routing. Test both the answer and the chosen outbound for important domains. A connection that succeeds can still have bypassed the resolver or route you intended.
Public HTTP listeners are the wrong edge for this core
The HTTP protocol page says its proxy transport is unencrypted and unsuitable for the public network. It also warns that a public HTTP inbound can become a target for abuse. Keep such listeners on localhost or a controlled LAN, use authentication where the configuration supports it, and place an appropriate encrypted path between untrusted networks. V2Ray provides choices, but it cannot make an unsafe listener safe through naming or default placement.
Transport settings create another paired obligation. The documentation says both ends generally need the same transport, such as WebSocket on each side. TLS certificates, file paths, ports, and stream settings then become operating concerns. Version 5.53.0 added stream-based packet addressing for UDP connections and session work in rrpit, evidence that this layer continues to change. Read release notes before rolling one side forward while leaving the other untouched.
September 2026 activity supports adoption, with configuration still on you
GitHub showed 34,621 stars and 32 open issues and pull requests when we fetched the repository. The last push was September 23, 2026, less than 2 months after v5.53.0 was published on August 2. Recent open work included DNS over HTTP/3 and protocol requests, while the release itself included dependency updates alongside networking changes. That is active maintenance, and the combined open count should not be read as 32 confirmed bugs.
V2Ray Core earns its place when routing policy is the product requirement. The passing 167-test run lowers the risk of building from source, and the active v5 branch shows ongoing work. The cost appears after compilation: every inbound, outbound, DNS choice, and transport pair becomes yours to secure and monitor. If that control solves a real network problem, V2Ray is a serious option. If it does not, WireGuard or a focused Shadowsocks server will be easier to explain at 3 a.m.