Native Reverse Proxy in MikroTik RouterOS 7.22+: Complete Setup Guide

MikroTik administrators have long faced a classic architectural dilemma. Imagine this: you have a single public IP address, but behind it you need to publish several web services on the standard HTTPS port 443.

For example:

• cloud.example.com → Nextcloud
• wiki.example.com → BookStack knowledge base
• pihole.example.com → AdGuard Home or Pi-hole dashboard
• ha.example.com → Home Assistant smart home

Regular Destination NAT (Port Forwarding) is useless here. It only forwards ports blindly: all traffic on WAN:443 goes to a single internal IP. NAT cannot inspect packets and analyze domain names.

Before RouterOS 7.22, admins had to work around this by deploying third-party proxy servers (Nginx, HAProxy, Caddy, Traefik) on separate virtual machines or packaging them as containers inside the router itself.

In RouterOS 7.22, MikroTik finally introduced a built-in, native Reverse Proxy. It doesn’t turn the router into a full replacement for heavy-duty web servers, but it provides a simple and elegant tool for basic HTTPS service publishing.

How it works

The built-in reverse proxy in RouterOS operates at the application layer (L7). It accepts encrypted HTTPS traffic from the internet, inspects it, and routes it to the appropriate internal servers or application containers (RouterOS Apps).

The traffic flow looks like this:

Client from the internet
        |
        | HTTPS (port 443)
        v
MikroTik RouterOS (reverse-proxy service)
        |
        | SNI inspection from TLS ClientHello
        v
Internal service in LAN (or local container)

Key point: Because the traffic is encrypted, RouterOS cannot read standard HTTP headers (e.g., Host:). Instead, the router looks at SNI (Server Name Indication) — a field the client sends in plaintext during the very first stage of the TLS handshake. By matching this SNI against its rules table, MikroTik instantly knows where to send the request.

Configuration anatomy

The proxy setup in RouterOS is split into two logical levels:

1. Global service (/ip/service/reverse-proxy) This is a system service like winbox, ssh, or www-ssl. It manages starting the proxy engine, choosing the TCP port (default: 443), and binding the default SSL certificate.

2. Rules table (/ip/reverse-proxy) This is where you create a routing map: which domain (SNI) should be forwarded to which internal IPv4 address and port.

Step-by-step setup guide

Step 1. Preparation and backup

Before changing network services and the firewall, always save your configuration:

/system/backup/save name=before-reverse-proxy
/export file=before-reverse-proxy

Step 2. Free up port 443

By default, the built-in web management interface (WebFig) runs on HTTPS on the same port 443 (www-ssl). If you don’t separate them, the proxy server simply won’t start due to a port conflict.

You have two options:

• Option A (Recommended): Move WebFig to an alternative port (e.g., 8443) and restrict access to your trusted local network only:

/ip/service/set www-ssl port=8443 address=192.168.88.0/24

• Option B: Completely disable WebFig (both HTTP and HTTPS) if you manage the router only via WinBox:

/ip/service/disable www
/ip/service/disable www-ssl

Step 3. Prepare SSL certificates

To prevent browser security warnings, the proxy server needs valid SSL certificates.

Option 1. Your own domain with Let’s Encrypt

Make sure your domains (cloud.example.com, pihole.example.com) resolve to the public IP of your MikroTik. You can issue a free official certificate directly through the router’s built-in ACME client:

/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=cloud.example.com,pihole.example.com

RouterOS will automatically create the certificates and renew them before expiry (at 80% of their lifetime).

Option 2. MikroTik Cloud DDNS

If you don’t have your own domain, you can use a free MikroTik name in the format xxxxx.sn.mynetname.net:

# Enable DDNS
/ip/cloud/set ddns-enabled=yes update-time=yes

# Request a Let's Encrypt certificate for this cloud name
/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=[/ip/cloud/get dns-name]

Step 4. Enable the global Reverse Proxy service

Check the certificate name with /certificate/print, then activate the proxy service:

/ip/service/set reverse-proxy port=443 certificate=letsencrypt_cloud.example.com disabled=no

Step 5. Create proxy rules

Now link external domain names to internal servers. Say Nextcloud is at 192.168.88.10 and Pi-hole at 192.168.88.20, both running plain HTTP (port 80) inside the network:

# Route cloud.example.com to Nextcloud
/ip/reverse-proxy/add sni=cloud.example.com ip-address=192.168.88.10 port=80 comment="Nextcloud proxy"

# Route pihole.example.com to Pi-hole
/ip/reverse-proxy/add sni=pihole.example.com ip-address=192.168.88.20 port=80 comment="Pi-hole proxy"

If you leave the certificate parameter as none, MikroTik will automatically use the global certificate set in Step 4.

Step 6. Configure the firewall

Because the Reverse Proxy runs on the router itself, incoming traffic is addressed directly to it. This means rules go into the input chain, not the usual forward.

Allow incoming HTTPS traffic on the WAN interface:

/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=443 in-interface-list=WAN comment="Allow HTTPS reverse-proxy from WAN"

If you use Let’s Encrypt with HTTP validation (HTTP-01 challenge), the router also needs port 80 open for certificate authority requests:

/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=80 in-interface-list=WAN comment="Allow HTTP for ACME challenge"

⚠️ Warning: Make sure these rules are at the very top of /ip/firewall/filter/print — strictly before any drop rules.

Step 7. Fix internal access (Split-Brain DNS)

If you now try to open cloud.example.com from inside your home or office network (connected to the same router’s Wi-Fi), you’ll likely get an error. Local clients will try to reach the router’s external IP, which is often blocked by the firewall or causes incorrect routing (NAT loopback issues).

To make everything work seamlessly from both the internet and inside the network, configure Split-Brain DNS. Add static local records on MikroTik so these domains resolve to the router’s LAN IP:

/ip/dns/static/add name=cloud.example.com address=192.168.88.1
/ip/dns/static/add name=pihole.example.com address=192.168.88.1

Where 192.168.88.1 is your MikroTik’s LAN IP address. The built-in proxy will intercept this local traffic on port 443 exactly the same way it handles external traffic.

Configuring backend applications

After MikroTik accepts the encrypted HTTPS traffic, terminates TLS, and forwards the request to your internal server over plain HTTP, the backend application may be confused. Web application security services often block requests when they think they’re being accessed through a third-party proxy.

The built-in RouterOS Reverse Proxy automatically adds the standard headers X-Forwarded-For (passes the real client IP) and X-Forwarded-Proto (indicates the original request came over HTTPS). You just need to tell your applications to trust these headers.

Nextcloud example (config.php)

Add the router’s LAN IP to the list of trusted proxies, otherwise you’ll get a security error:

'trusted_domains' => [
  'cloud.example.com',
],
'trusted_proxies' => [
  '192.168.88.1', // Your MikroTik LAN address
],
'overwritehost'     => 'cloud.example.com',
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://cloud.example.com',

Integration with RouterOS Apps (Containers)

RouterOS 7.22 introduced a layer on top of containers — the /app menu. The developers tightly integrated it with the built-in proxy.

If you deploy an application directly on the router through the apps menu, you just need to enable a single parameter: use-https=yes. RouterOS will automatically create a dynamic rule in /ip/reverse-proxy, link it to the cloud DDNS certificate, and generate a ready-to-use secure URL for the container.

Limitations: when the built-in proxy isn’t enough

The built-in tool is lightweight and convenient, but it’s not for large-scale production. Key constraints to keep in mind:

1. IPv4 only for backend servers. The ip-address field in the rules table only accepts IPv4. Proxying traffic to internal backends over IPv6 is not supported yet.

2. CPU load. TLS encryption and decryption runs on the router’s CPU. On weaker devices (hEX, hAP) heavy request loads can push CPU usage to 100%. Modern ARM/ARM64 chipsets (hAP ax, RB5009, CCR) and CHR have access to hardware-accelerated HTTP/2.

3. Minimal web features. MikroTik offers no deep header manipulation, advanced access logging, built-in WAF, proxy-level authentication, or complex load balancing. If you need WebSocket, gRPC, sticky sessions, or sophisticated traffic distribution rules — a full Nginx/Caddy/HAProxy is still irreplaceable.

Troubleshooting

If things aren’t working, check the chain step by step:

• Check the service port: /ip/service/print where name=reverse-proxy

• Check from the outside: curl -vk https://cloud.example.com

• Check the certificate chain: openssl s_client -connect cloud.example.com:443 -servername cloud.example.com

• Check backend reachability: /ping 192.168.88.10

Quick-start checklist

# 1. Disable conflicting WebFig HTTPS
/ip/service/disable www-ssl

# 2. Issue certificates for your domains
/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=cloud.example.com,pihole.example.com

# 3. Enable the proxy (use the exact certificate name from /certificate print)
/ip/service/set reverse-proxy port=443 certificate=letsencrypt_cloud.example.com disabled=no

# 4. Add forwarding rules for LAN services
/ip/reverse-proxy/add sni=cloud.example.com ip-address=192.168.88.10 port=80
/ip/reverse-proxy/add sni=pihole.example.com ip-address=192.168.88.20 port=80

# 5. Allow incoming HTTPS traffic to the router from the internet
/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=443 in-interface-list=WAN comment="Allow HTTPS reverse-proxy"

# 6. Configure Split-Brain DNS for access from inside the Wi-Fi/LAN network
/ip/dns/static/add name=cloud.example.com address=192.168.88.1
/ip/dns/static/add name=pihole.example.com address=192.168.88.1