# mieru Proxy: A Go socks5 and HTTPS Proxy That Skips TLS

> mieru is a Go proxy suite split into a client (mieru) and a server (mita) that carries socks5, HTTP and HTTPS traffic over its own encrypted protocol instead of TLS. This article covers what it does, how to install it, and where it is the wrong choice.

**enfein/mieru** — mieru is a socks5 / HTTP / HTTPS proxy to bypass censorship. 見える是一款 socks5 / HTTP / HTTPS 网络代理翻墙工具。

- Repository: https://github.com/enfein/mieru
- Stars: 2,570 · Forks: 230
- Language: Go
- License: GPL-3.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/enfein-mieru

## What mieru solves, and who it is built for

mieru targets a specific situation: you have a machine outside a filtered network, and you want to reach the web through it without registering a domain, obtaining a TLS certificate, or standing up a decoy website. The README states the software is a "secure, hard to classify, hard to probe, TCP or UDP protocol-based socks5 / HTTP / HTTPS network proxy software." That sentence is the whole pitch. The project does not try to look like ordinary HTTPS. It tries to be unclassifiable.

The suite ships as two programs. The client is called mieru. The server is called mita. That split matters when you plan a deployment, because the two are installed and configured separately, and the user guide lists separate documents for each: docs/server-install.md and docs/client-install.md. There is a third document for OpenWrt clients, which tells you the project expects routers as a real deployment target, not an afterthought.

The audience is narrower than the feature list suggests. If you want a proxy you can subscribe to and forget, mieru is not that. If you are comfortable with a config file, a port number, and a username and password pair, and you already have a server, the design fits. The README also points at third-party clients across desktop, Android and iOS, so you are not forced to use the bundled client everywhere.

## The mechanism: no TLS, XChaCha20-Poly1305, padding and replay detection

The README is explicit that mieru "does not use TLS protocol." That is the design decision everything else follows from. Because there is no TLS handshake, there is no certificate to buy, no domain to point at the server, and no fake website to host. The trade-off is that the traffic does not look like the HTTPS that dominates ordinary browsing, so the burden shifts to making the stream hard to classify by other means.

Encryption is XChaCha20-Poly1305, described in the README as high strength, with keys "generated based on username, password and system time." That last clause deserves attention. Key material is derived from credentials plus system time, which is why docs/security.md exists and why clock behaviour between client and server is worth checking before you blame the network for a failure.

The README lists two additional defences: random padding and replay attack detection. Padding changes packet sizes so length patterns are less informative. Replay detection means a captured stream cannot simply be resent. The README frames the goal as preventing the GFW from detecting the mieru service. The project also publishes docs/traffic-pattern.md, which suggests the authors treat the observable shape of the traffic as a first-class concern rather than an implementation detail.

A separate protocol document, docs/protocol.md, describes the wire format. The README compares the general principle to shadowsocks and v2ray: an encrypted channel between client and server, with the destination hidden from anyone watching the link. That comparison is about the principle, not the wire format, and the project does not claim interoperability with either.

## Installing mita on the server and mieru on the client

The README does not inline installation commands. It points to docs/server-install.md for the server and docs/client-install.md for the client, so those two files are the authoritative source and you should read them before running anything. What the repository does show is a Makefile that builds and packages the suite, with a VERSION variable currently set to 3.38.0 and packaging targets under build/package for both mieru and mita on amd64 and arm64, in deb and rpm form. If you build from source rather than installing a release package, the Makefile is the entry point.

The repository layout is a normal Go project: cmd/, pkg/, apis/, configs/, deployments/, docs/ and test/ at the top level, with go.mod declaring module github.com/enfein/mieru/v3 and Go 1.20. Dependencies are few: google/btree, golang.org/x/crypto, golang.org/x/sys, grpc and protobuf. A small dependency set is a real advantage here, because the server binary is something you leave running on a machine you may not visit often.

Because the install steps live in the docs rather than the README, this article will not invent commands. The one thing the README does tell you to expect is a two-part configuration: the server side needs a port and at least one user, and the client side needs the server address and the same credentials. The README states that multiple users can share a single proxy server, so the server config is where you add them.

Once the server is running, the client exposes socks5, HTTP and HTTPS proxy interfaces, per the feature list. That means any application that can be pointed at a local socks5 or HTTP proxy can use it without a mieru-specific integration. If you would rather run a graphical client, the README lists Clash Verge Rev, Mihomo Party, NyameBox, SlothClash and others on desktop, and a longer list on Android and iOS, including Shadowrocket. The mihomo and enfein/mbox projects are listed as third-party server software, which means mieru's protocol is implemented outside this repository as well.

## Where mieru is the wrong tool

The clearest limitation is stated by the project itself: mieru does not use TLS. In networks where only TLS-shaped traffic leaves the perimeter, a protocol that deliberately does not look like TLS has a harder time. The README's answer is padding and replay detection, not masquerading as HTTPS, and those are different strategies with different failure modes.

Key derivation from username, password and system time is the second thing to think about. It ties credential validity to clocks. docs/security.md is the place the project documents its security guidance, and the existence of that document implies the defaults are not meant to be left untouched.

The third limitation is operational. mita is a server you run. There is no hosted offering in the README, no account system, no subscription. If your server goes down, your access goes down, and nothing in this repository will fail over for you. The user guide does include docs/operation.md for maintenance and troubleshooting, which is where you should look first when something breaks, but that is documentation, not automation.

Finally, the licence. mieru is GPL-3.0. That is a copyleft licence, and it applies to the client and server you deploy. It is not a permissive licence, and it is worth understanding what it means for your distribution before you build it into anything you hand to other people.

## How mieru differs from a TLS-based proxy

The obvious comparison is with proxies that do use TLS, because that choice drives almost every other difference. A TLS-based proxy needs a domain name pointed at the server and a certificate for it, and often a web server behind the same address so the endpoint looks like a real site. mieru removes all of that. The README states plainly that there is no need to register a domain name or set up a fake website.

That is a genuine reduction in setup work and in ongoing cost, since certificates expire and domains need renewing. It also changes what an observer sees. A TLS-based proxy produces a stream that begins like any other HTTPS connection, which is why it is hard to block without collateral damage. mieru produces something else, and relies on encryption plus padding plus replay detection to stay unclassified. Which of those two bets is better depends on the network you are crossing, and no document in this repository makes a claim about relative detection rates.

The second difference is packaging. mieru is a Go project with a small dependency list and a Makefile that produces deb and rpm packages for both binaries on amd64 and arm64. That is a self-contained deployment story. If you want a graphical client on a phone or a laptop, the README points at third-party clients rather than shipping one, so the project's own surface stays at the command line and the config files.

## Maintenance, upgrades and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-26. Releases are frequent: v3.38.0 on 2026-09-24, v3.37.0 on 2026-09-13, and v3.36.1 on 2026-09-05. Whatever else you conclude, this is a project that is being changed, and the version string in the Makefile is kept in lockstep with the packaging metadata. The Makefile comment lists every file that must change when the version changes, including the deb and rpm control files for both mieru and mita and several documents, and points at tools/bump_version.sh to do it in one shot. That is a maintainer who has been burned by a version mismatch before.

For an operator, frequent releases cut both ways. You get fixes, but you also get a stream of upgrades to apply on a machine you may not want to touch often. The project does not document a rollback procedure in the README, so if you upgrade mita and something breaks, the README will not tell you how to go back. Plan for that before you need it.

The licence is GPL-3.0, stated in the README and present as the LICENSE file at the repository root. The Makefile header carries the standard GPL notice with the no-warranty clause. Copyleft obligations attach to distribution, so if you ship a build of mieru or mita to others, the licence terms follow it. This is a description of what the repository says, not legal advice, and if you are distributing anything, read the licence yourself.

## Conclusion

Adopt mieru if you control a server outside the filtered network and you want a proxy that does not depend on a domain name, a TLS certificate, or a fake website, and you are willing to run the mita server yourself. Do not adopt it if you need a hosted service, if your environment only allows TLS-shaped traffic, or if you cannot accept GPL-3.0 terms on the server and client you deploy. Before committing, read docs/server-install.md and docs/client-install.md, confirm the mita port you plan to open is reachable from the client network, and check docs/operation.md for how the project expects you to rotate credentials and keep the server running.

## FAQ

### What does the word "mieru" mean?

The repository does not explain the name's meaning. The README presents mieru as the client half of the proxy suite, with the server half called mita, and the project is also written as 見える in its own documentation.

### What is mieru proxy and what does it do?

mieru is a socks5, HTTP and HTTPS network proxy suite written in Go, split into a client called mieru and a server called mita. The README describes it as a secure, hard to classify, hard to probe proxy that creates an encrypted channel between the client and a server outside the firewall.

### How do I install mieru and mita?

The README does not include install commands. It links to docs/server-install.md for the server and docs/client-install.md for the client, and there is a separate guide for OpenWrt clients. The repository also contains a Makefile that builds and packages both binaries.

### Does mieru use TLS, and do I need a domain name?

No. The README states that mieru does not use the TLS protocol and that there is no need to register a domain name or set up a fake website. Instead it uses XChaCha20-Poly1305 encryption with random padding and replay attack detection.

### What encryption does mieru use?

The README lists XChaCha20-Poly1305 as the encryption algorithm, with keys generated based on username, password and system time. It also states that random padding and replay attack detection are used to prevent the service from being detected.

### Can several users share one mieru server?

Yes. The README lists support for multiple users sharing a single proxy server as a feature, and the server side is configured with the users who are allowed to connect. mieru also supports both IPv4 and IPv6.

## Sources

- [enfein/mieru on GitHub](https://github.com/enfein/mieru)
- [Issues](https://github.com/enfein/mieru/issues)
- [License: GPL-3.0](https://github.com/enfein/mieru/blob/main/LICENSE)
- [README](https://github.com/enfein/mieru/blob/main/README.md)
- [Releases](https://github.com/enfein/mieru/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/enfein-mieru