Feature Request Discussion: Native Xray-core (VMess / VLESS / Trojan / Shadowsocks) Support in RouterOS

RouterOS
1

Hello MikroTik community,

I would like to start a discussion about a possible future feature for RouterOS: native support for Xray-core based protocols such as VMess, VLESS, Trojan, and Shadowsocks.

XTLS-Xray-core
XTLS-Xray-core100Ă—100 3.36 KB
Xray-core is an open-source network proxy core widely used as the foundation for V2Ray/Xray protocols.

This discussion is not about replacing existing VPN technologies like WireGuard, IPsec, or OpenVPN. Those work very well in many environments. The focus here is a different and increasingly common use case.

In countries with heavy internet censorship (for example Iran, China, and Russia), many traditional VPN protocols are quickly detected and blocked using DPI (deep packet inspection). Because of this, a large number of users rely on Xray-core / V2Ray-based protocols, which are actively developed to operate under these conditions.

Recently, many users in these regions have started using MikroTik routers (especially hAP ax lite LTE6, hAP ax² and hAP ax³) because RouterOS provides powerful routing, firewall, and traffic control features. However, the lack of native Xray-core support is often mentioned as a limitation.

While Docker can be used as a workaround, for home users, small offices, and non-technical users it remains complex to deploy, manage, and troubleshoot.

Native support could potentially:

  • Make RouterOS more usable in heavily filtered networks

  • Reduce deployment complexity for home and small business users

  • Increase MikroTik adoption in censorship-restricted regions

This post is meant to gauge community interest and understand real-world usage patterns.

To support this discussion, I’ve also created a short, anonymous community poll about VPN and tunneling protocol usage:

:backhand_index_pointing_right:t3: Community poll:

https://forms.gle/4AhYBURWyMH7EKc38

If you’re willing, please reply and share:

  • Your use case

  • Which protocols you use (VMess, VLESS, Trojan, Shadowsocks, etc.)

  • Whether native support in RouterOS would be useful for you

Constructive technical feedback is very welcome. Hopefully, this discussion and the collected data can help MikroTik better understand real-world demand and use cases.

Thank you to everyone who participates.

3 Likes
2

This looks like a feature request for users in countries where Mikrotik is unavailable due to sanctions. :slight_smile: Hi Mikrotik, we can't buy your routers. Please add a new feature for us.

3

This is DOA request it’s not that it’s not important look at the IPSEC VTI request it’s been 10 years now still it didn’t find the light of the day given the fact that the kernel space component was there, maybe just maybe if this feature request can improved their bottom line they are going to do it who knows.

I already lost my hope with MT they have an fundamental / identity crisis that’s need to be solved they will rather make storage rather than go back to their grass root to route the world

4

Bolded are the reasons why this would & should not be an integral part of RouterOS and people who need that should continue to use containers instead.

You have something has to be actively updated to quickly react to governments' changing methods of detection and blocking. Do you really expect MikroTik do drop all their release and testing plans to issue RouterOS updates to include the new Xray fixes? Do you also expect millions of MikroTik customers who never have any use for V2Ray seeing tons of new RouterOS releases in short intervals?

If something changes very often, it should not be tied to RouterOS releases and MikroTik should not waste resources maintaining its integration with RouterOS.

1 Like
5

I understand the concern being raised, and it is a reasonable one. However, I think it combines two different topics that should be considered separately: protocol fundamentals and implementation changes.

The fundamental designs of the VPN and proxy protocols used by Xray, such as VLESS, VMess, and XTLS or REALITY, do not change very often. Their core concepts, handshakes, and security models are relatively stable. What changes more frequently are implementation details like optimizations, bug fixes, performance improvements, and optional techniques related to traffic detection and evasion.

This kind of evolution is normal. RouterOS already includes many features that also evolve over time, including IPsec, BGP, firewall behavior, routing logic, and WireGuard. Update frequency alone has never been the deciding factor for whether something belongs in RouterOS.

It is also important to note that integrating protocol support does not mean RouterOS must follow every upstream Xray release. A native implementation can focus on stable protocol behavior with a clearly defined scope, while experimental or fast changing features remain outside the core. MikroTik already takes this approach in other areas of RouterOS.

The point about millions of users not needing the feature is understandable, but RouterOS already ships with many components that most users never use. Optional functionality is common in network operating systems and does not create problems when it is modular and disabled by default.

Containers are a useful option, but they are not ideal for every use case. They add operational complexity, require more resources, and integrate less tightly with RouterOS networking features. For many users, native support would be simpler, more efficient, and easier to manage.

So the disagreement is not about whether Xray changes over time, because it clearly does. The disagreement is about the conclusion drawn from that fact. A changing implementation does not automatically mean the protocol is unsuitable for native support, especially when the core design is stable and the integration is carefully scoped.

In short, change at the implementation level does not mean instability at the protocol level. With a conservative and modular design, native support is technically reasonable, even if MikroTik ultimately decides it is not a priority.

6

It is also important to consider this topic in terms of population size and real market demand. China has a population of approximately 1.4 billion people, Iran around 89 million, and Russia about 146 million. Together, these countries account for more than 1.6 billion people and well over one billion active internet users. Even if only a small percentage of these users require advanced tunneling or circumvention technologies, that still represents tens of millions of users with very specific networking needs.

As internet filtering becomes more sophisticated and traditional VPN protocols are increasingly detected and blocked, demand for Xray-core based solutions continues to grow. This trend directly influences purchasing decisions. Many users in these regions actively look for network devices that can combine strong routing, firewall, and traffic management capabilities with reliable operation under restrictive network conditions. MikroTik routers already meet many of these requirements, which is why their popularity has been increasing in these markets.

This should not be viewed as a zero-sum decision. Native support for such protocols would not reduce value for existing RouterOS users, nor would it impose changes on those who do not need the functionality. When implemented as an optional and modular feature, it can serve a specific and growing user base while remaining invisible to others. From a practical and commercial perspective, this represents potential growth for MikroTik, aligning user needs with increased hardware adoption, rather than a trade-off between different groups of users.

7

The components you mentioned include a large amount of third-party code from all over the world and rely on many external libraries. This is very different from something like WireGuard. Just performing a proper security audit on such a codebase would be a massive effort, and there could be unknown vulnerabilities or even backdoors, creating real supply-chain risk.

If MikroTik were to officially include this in RouterOS, they would be responsible for it. As we’ve seen before, even when an issue is not caused directly by MikroTik’s own code, the CVE is still assigned to MikroTik (for example, CVE-2025-10948: Cve-2025-10948
). RouterOS is released to all customers, including governments and enterprises, so the bar for security and liability is extremely high.

Using containers is not difficult anymore. If you’ve watched MikroTik’s recent container tutorial videos, you’ll see that using containers together with Socksify is already quite straightforward:
https://www.youtube.com/watch?v=ECRjxpb5IgE

On normal devices (including generic Linux, OpenWRT, etc.), deploying similar client or server software is also quite complex, and in many cases even harder to troubleshoot than on MikroTik. If you haven’t experienced that complexity, it’s usually because someone else has already done the work for you—by providing prebuilt packages, system images, or one-click scripts. RouterOS can do the same (not by Mikrotik, but by community, creating useful script, container image); it just requires people to build and maintain those solutions. There are already many container images on the forum optimized specifically for running on RouterOS.

Additionally, you can even run OpenWRT, Linux, or any environment you like inside a container, and operate your services there in whatever way you prefer.

2 Likes
8

Thank you for taking the time to lay out these concerns in detail. I agree that security responsibility, audit scope, and supply-chain risk are critical considerations for RouterOS, especially given its use by governments, enterprises, and critical infrastructure. Those risks should not be minimized, and they deserve careful treatment.

At the same time, I think it is important to look at the full context and the trade-offs involved, rather than treating this as a binary choice between “safe core feature” and “everything belongs in containers.”

Xray-core is not a small or obscure project. It is the result of years of work by a large and diverse group of contributors from many countries, including security researchers, network engineers, and developers who operate in highly restricted network environments. Much of its maturity comes precisely from this global participation. The codebase has been exercised in real-world conditions at very large scale, often under active adversarial pressure, which is something few networking projects ever experience. While this does not eliminate risk, it does mean that many issues are discovered, discussed, and fixed in the open, often faster than in closed or niche systems.

It is also worth noting that native support does not require MikroTik to import and maintain the entire upstream codebase as-is. There is a wide spectrum of possible approaches. RouterOS could implement only well-understood, stable protocol behavior, limit feature scope, and avoid experimental transports or rapid-change components. This would significantly reduce audit complexity and long-term liability while still addressing the most common real-world use cases. RouterOS already makes similar design decisions in other subsystems, where not every upstream feature or extension is included.

Regarding containers, I agree that MikroTik has made real progress in making them more accessible, and for experienced users they are a workable solution. However, containers still shift a large amount of responsibility to the user: image trust, update cadence, debugging, logging, and recovery all become manual tasks. For many home users, small offices, and constrained environments, this added operational burden is significant. In regions with heavy filtering, even pulling images, watching tutorial videos, or accessing documentation can be unreliable, which makes container-based solutions harder in practice than they appear in ideal conditions.

Running full Linux or OpenWRT environments inside containers demonstrates flexibility, but it also illustrates the underlying inefficiency. Users are effectively rebuilding an entire operating system stack on top of RouterOS just to gain access to a small set of protocols. That approach works, but it increases complexity, resource usage, and failure points, and it weakens the tight integration that RouterOS normally offers.

From a broader perspective, demand for these protocols is being driven by external forces, not by fashion or preference. Large populations in multiple regions now live under increasingly sophisticated network filtering. The developers and volunteers contributing to Xray-core are responding to that reality, and their work has made the project what it is today. This demand is not static, and it is not limited to a small niche. It directly influences hardware purchasing decisions, and MikroTik routers are already being chosen because of their strong networking capabilities in these environments.

This is also not a zero-sum decision. Optional, well-scoped native support would not reduce security or value for existing RouterOS users, nor would it force changes on those who do not need it. When designed conservatively, it can coexist with containers, not replace them. Containers remain ideal for rapid experimentation and advanced setups, while native support can serve users who need stability, simplicity, and tight integration.

I fully understand that MikroTik may ultimately decide that containers remain the preferred solution, and that is a defensible position. The key point is that the question is not whether containers are possible, but whether they are the best long-term answer for all users in all environments. Given the scale of demand, the maturity of the ecosystem, and the real operational challenges faced by users, I believe this is a discussion worth continuing in a nuanced and balanced way.

9

bro, you're writing reply like my final essay or use too much GPT...

"containers still shift a large amount of responsibility to the user", that's true, conf or deploy service is user's resonsibility, not mikrotik. even openwrt did not maintain third party package, that's all from other community repos.

about “implement limit feature scope”, license is also a problem, mikrotik need to release their part of source code for these feature, I can't see that's possible.

if your internet can't pull image or access docs, then you're putting mikrotik's cloud service like update / license check / ddns as a risk to block by asking them to release software for break your region rules.

community can maintain a list of receipe, that can be a list of one-click-script to create specfic container rules, templated for specfic device, with offline package indeed, or even dev webui specfic for some usecase, but that's not mikrotik's job, they got more important things todo.

1 Like
11

I completely agree with your opinion and support it.

1 Like
12

Haha, fair enough :slightly_smiling_face:
Yeah, I went a bit long there. That’s on me. I was trying to paint the full picture, not submit a thesis. Sorry about that.

I’m not saying containers don’t work, or that MikroTik is suddenly responsible for fixing the internet. Containers clearly work, especially for advanced users. My point is just that in some parts of the world this use case has stopped being niche and theoretical. It’s daily life, and it already affects how people choose their hardware. Containers solve the problem on paper, but in practice they still add friction for a lot of normal users.

Community scripts, images, and one-click setups absolutely help, and I agree MikroTik has bigger and more important priorities on their plate. I just don’t think this demand can be dismissed as “not our problem” anymore. Especially if you look at it from the perspective of people living in hostile network environments, constantly playing a cat-and-mouse game just to stay connected. That pressure doesn’t disappear, it builds up, and over time it spreads.

Sometimes it’s smart to lean into reality early, while there’s still room to shape things thoughtfully instead of reacting later under pressure. Exploring a path doesn’t mean committing to everything at once. It just means being open to where the world is clearly heading.

And honestly, this feels very much in the spirit of how MikroTik started. A small group of motivated people building something useful while others said it wouldn’t matter or wouldn’t work. Fast forward a few years, and here we are.

That’s really all I’m trying to say. Let’s keep the discussion open and grounded in how people actually use these tools today.

13

The main problem with containers is not that they’re difficult to set up - it’s that they add a lot of overhead (presumably due to TUN, double NAT, etc), which, in my tests, resulted in 4x worse performance compared to Xray with TPROXY running natively in OpenWrt on the exact same router. A lot of my problems would be solved if MikroTik were to just add a faster way of routing traffic through containers.

14

I think one of the hesitation for MT on considering this is how large the binary it will become if they put it in the core routeros package because of the 16MB flash mistake they have done.

They can not or will not create a separate package just for this because they fear that when they do give a go on this what stop other people of asking the same thing (exemption) and they don’t want to put themselves in that position because for sure when you open the flood gates it can’t be stopped

VTI request this request and other valid feature request is the casualty of this 16MB flash mistake imho not unless someone can order a million units of MT across products (guaranteed) for 3 years minimum to swallow and accept this fault

They will do this if they can write this from scratch and the resulting binary will fit on that damn 16MB storage until then it’s no go hahaha

15

If/when MT implements UDP support for Socksify it should be easier to setup forwarding traffic to Xray running in container without need to create tunnel interface along with routing rules inside container.

Regarding performance, not sure there will be significant difference when running Xray inside container or as native process because Xray doesn’t have its kernel module, as for eg. Wireguard, where some performance can be achieved when running on kernel level.