MikroTik Proxy Setup: Step-by-Step RouterOS, Mangle and Policy-Based Routing for Beginners

Introduction: what you'll end up with

This article is a hands-on, step-by-step guide to setting up a proxy on MikroTik. We'll work exclusively with RouterOS, the stock operating system for MikroTik routers. We have separate blog posts on Keenetic, OpenWrt and other platforms, so we won't touch on those here.

By the end of this guide you'll have a working setup where the router itself decides which devices in the office or at home connect to the internet directly and which go through a mobile proxy. You'll configure the built-in Web Proxy in RouterOS with a parent proxy, learn how to mark traffic in the mangle section, and build policy-based routing, meaning routing by rules, not just by destination address.

Specifically, you'll get:

• a list of devices whose traffic goes through the proxy, with everything else working as before;
• a configured Web Proxy on MikroTik that forwards client requests to an external mobile proxy;
• mangle rules that mark the right connections and routes;
• a separate routing table for marked traffic so it goes out through the right interface, such as a second WAN or an LTE modem;
• firewall protection so nobody outside can use your proxy;
• a set of checks and a breakdown of typical mistakes.

Who this guide is for

This guide is written for marketers, affiliates, developers and owners of small teams who work with mobile proxies and want to move some of the setup off each computer and onto the router. If you have five or fifteen workstations running antidetect browsers, scrapers and ad accounts, it's easier to configure the proxy on MikroTik once than to manually enter settings on every new laptop.

The level is for beginners. We don't assume you've configured RouterOS before. Every step is shown both through the graphical WinBox interface and as a terminal command. There's a dedicated section for advanced users at the end: containers, automatic proxy settings delivery to clients, and switching scripts.

What you should know in advance

Basics are enough: what an IP address, port, local network and gateway are. You should be able to log into the router's web interface or connect to it with WinBox. We'll explain everything else along the way.

How long it will take

The actual setup takes about 40-60 minutes. Including reading, backups, firmware updates and testing, budget 1.5-2 hours. If you have two internet connections and will be setting up policy-based routing between them, add another 30 minutes for checks.

Preliminary preparation

Before changing anything on the router, let's gather everything we need. This saves time and prevents the situation where you discover mid-setup that you don't have the right access.

Required tools and access

• A MikroTik router running RouterOS version 7.x. Popular models like hAP ac2, hAP ac3, hAP ax2, hAP ax3, RB4011, RB5009, and any CCR will work. Models with a USB port or built-in LTE module give you extra options, but they're not required.
• WinBox at the current version (in 2026 that's WinBox 4, with builds for Windows, macOS and Linux). Alternatively, the WebFig web interface at the router's address in a browser, which has the same menus.
• Administrator access to the router: a login and password for a user with full rights.
• Your mobile proxy details: server address (IP or domain name), HTTP proxy port, and the authentication method. For the Web Proxy on MikroTik setup you need IP-based authentication, because the built-in RouterOS proxy can't pass a username and password to the parent proxy. Practically all mobile proxy providers let you enable IP authorization in your account panel.
• Your router's external IP address. You'll need to add it to the whitelist at your proxy provider. We'll show you how to find it in the first step.
• A computer on the local network where you'll test the result.

System requirements

The Web Proxy and mangle setup works on any device running RouterOS 7. 128 MB of RAM is enough for a dozen active clients if you disable caching. For the advanced section with containers, you'll need a model with an ARM, ARM64 or x86 architecture and at least 256 MB of memory, and preferably 1 GB plus external storage.

Check the RouterOS version: in WinBox, open the System menu, then Resources. The Version field should show 7.x. If you're on 6.x, some of the routing commands will differ, and it's best to upgrade first.

What to prepare in advance

1. Install WinBox and make sure it sees the router in the Neighbors tab.
2. Log into your mobile proxy provider's account panel and find the connection settings section. Write down the address, HTTP port and enable IP authorization mode.
3. Make a list of devices that should work through the proxy. Write down their names and MAC addresses or current IPs.
4. Decide whether you'll have a second internet connection. If your router has an LTE module or a USB modem with a SIM card connected, write down the interface name, usually lte1.

Backup

A backup is a must. This is the first practical step of the guide, and we'll cover it in detail. For now, just remember the rule: no changes to the firewall or routing without a fresh backup. A mistake in a NAT rule or a route can cut off your access to the router, and then you'll have to reset it to factory settings.

Core concepts: proxy, mangle and routing in plain language

The topic seems complicated because of the terminology. Let's break it down without excess theory, just what you'll need for the steps.

Proxy and mobile proxy

A proxy server is an intermediary. Your browser sends a request not directly to the site but to the proxy server, which then goes to the site under its own name and returns the response. The site sees the proxy's address, not yours. A mobile proxy is a proxy that connects to the internet through a cellular carrier's network, so sites see a regular mobile subscriber's address. These addresses are used for working with ad accounts, multi-accounting and scraping, where IP reputation matters.

A router and a proxy are different things

It's important to understand: a router can't by itself funnel all traffic into an HTTP or SOCKS proxy. A router works at the IP packet level, while a proxy works at the application level. Packets can be directed through one interface or another, but for an application to speak through a proxy, something has to establish a connection to the proxy server using its protocol. In RouterOS, that's what the built-in Web Proxy is for, a full-fledged HTTP proxy inside the router that can forward requests to an upstream, so-called parent proxy. It's exactly what will become the bridge between your local network and the mobile proxy.

Address list

An address list in RouterOS is a named list of IP addresses or subnets. Instead of writing five rules for five computers, you put their addresses into a list called proxy-clients and reference it in a single rule. Add a sixth computer to the list and the rule works for it too.

Firewall: filter, NAT and mangle

The RouterOS firewall consists of several tables. Filter decides whether to pass or drop a packet. NAT rewrites addresses and ports, e.g., redirecting a connection on port 80 to the local proxy port 8080. Mangle neither blocks nor rewrites anything; it places a mark on a packet or connection. The mark lives only inside the router and is later used by other subsystems, primarily routing.

There are two marks in mangle that interest us. A connection mark is placed on the whole connection: mark the first packet and all subsequent packets of that connection are automatically considered marked. A routing mark tells the router: for this packet use this table, not the main routing table.

Routing tables and policy-based routing

A regular router decides where to send a packet based only on the destination address. That's the main table. Policy-based routing (PBR) adds a second criterion: where the packet came from, what type it is, what mark it has. For example: send packets from computers in the proxy-clients list through the LTE modem, and everything else through the wired provider. In RouterOS 7, you create a separate routing table for this, add your own default route to it, and mangle places a routing mark with that table's name on the desired traffic.

Prerouting, output and forward chains

Firewall rules are tied to chains. Prerouting processes packets that have just arrived at the router, before a routing decision is made. This is a convenient place to mark traffic from local network clients. Output handles packets the router generates itself, such as its Web Proxy's requests to the parent mobile proxy. Forward handles transit packets from the local network to the internet. Understanding this difference will save you from half the mistakes when setting up a proxy on MikroTik.

How it all comes together

The setup we'll build looks like this. Computers in the proxy-clients list contact the Web Proxy on the router on port 8080. The Web Proxy forwards requests to the provider's mobile proxy, which authorizes the router by its external IP. The router's requests to the mobile proxy are marked in mangle and sent out through the desired WAN interface. All other devices work as usual and notice nothing.

Step 1: Backup and RouterOS preparation

Goal of this stage: get a saved copy of the current configuration, the current RouterOS version, and find the router's external IP for the proxy provider's whitelist.

Creating a backup

1. Open WinBox. In the Neighbors list, select your router, enter your login and password, and click Connect.
2. In the left menu click Files. A window opens with a list of files on the router.
3. Click the Backup button at the top of the window. In the dialog that appears, enter a clear name in the Name field, e.g., before-proxy. In the Password field you can set a password for the archive or leave it empty. Uncheck Don't Encrypt if you want encryption, or leave it as is; for home use it's not critical.
4. Click Backup. A file called before-proxy.backup appears in the list.
5. Drag this file with your mouse from the Files window to your computer's desktop. The file will download to your PC. A copy on the router itself won't save you if the router ends up needing a reset, so keep it on your machine.
6. Additionally, make a text export. Open New Terminal in the left menu and enter the command:

/export file=before-proxy

A file called before-proxy.rsc appears in Files. It's plain text with all your configuration commands. It's convenient to open in Notepad and compare what changed. Download it too.

Updating RouterOS

1. In the left menu open System, then Packages.
2. Click Check For Updates. In the Channel field select stable.
3. If a new version is available, click Download&Install. The router will download the package and reboot. This takes 2-5 minutes and the WinBox connection will drop, which is normal.
4. After the reboot, connect again, open System, then RouterBOARD, and click Upgrade to update the bootloader. Then reboot the router via System, Reboot.

Warning: don't update the router remotely if you don't have physical access to it or a backup management channel. If the update fails you can lose contact with the device.

Finding the router's external IP

1. Open New Terminal.
2. Enter the command:

/tool fetch url=https://ifconfig.me/ip mode=https output=user

The response's data string will be your external IPv4 address. Alternatively, open IP, then Cloud and enable DDNS Enabled: the Public Address field will show the current address. Write it down.

1. Log into your mobile proxy provider's account panel, find the authentication settings for the selected proxy, and add this address to the whitelist. Changes typically take effect within a minute.

Tip: if your ISP gives you a dynamic external IP, ask your proxy provider whether authentication by multiple addresses or via a DDNS name binding is possible. Otherwise, after the IP changes the setup will stop working and you'll have to update the whitelist.

Check: the computer has the before-proxy.backup and before-proxy.rsc files, System, Resources shows a current RouterOS 7 version, and the router's external IP has been added in the proxy provider's account panel.

Possible problems

• The fetch command returns an error. Check that the router has internet access and DNS is configured: IP, DNS, the Servers field isn't empty, and Allow Remote Requests is checked.
• WinBox doesn't see the router. Connect directly with a cable to port ether2 and try the Neighbors tab again, or enter the router's address manually, by default 192.168.88.1.

Step 2: Deciding whose traffic will go through the proxy

Goal of this stage: create the proxy-clients address list and pin permanent IPs to the right devices so the rules don't break after reconnecting.

Pinning IP addresses to devices

By default, the router's DHCP server may give a computer a different address tomorrow. To keep the rules working reliably, let's bind addresses to MACs.

1. Open IP, then DHCP Server, the Leases tab. You'll see the list of current leases: IP address, MAC address, hostname.
2. Find the right computer by hostname or MAC. Double-click the row.
3. In the window that opens, click the Make Static button. The lease status changes from D (dynamic) to blank, and the address is pinned.
4. If you like, change the Address field to something more memorable, say 192.168.88.101, and click OK. The device will get the new address after reconnecting to the network.
5. Repeat for all devices that should work through the proxy.

The terminal command if you know the MAC in advance:

/ip dhcp-server lease add address=192.168.88.101 mac-address=AA:BB:CC:DD:EE:01 server=defconf comment="PC-marketing-1"

The server name defconf is the default DHCP server's name; look it up in the DHCP tab of the same window.

Creating an address list

1. Open IP, Firewall, the Address Lists tab.
2. Click the blue plus.
3. In the Name field enter proxy-clients. In the Address field enter 192.168.88.101. Click OK.
4. Repeat for each address, selecting the same proxy-clients name from the dropdown each time.

In the terminal:

/ip firewall address-list add list=proxy-clients address=192.168.88.101 comment="PC-marketing-1"
/ip firewall address-list add list=proxy-clients address=192.168.88.102 comment="PC-marketing-2"

If a whole subnet should work through the proxy, add it as a single entry, e.g. 192.168.88.128/25.

Tip: also create a second list called direct-clients for devices that must never go through the proxy under any circumstances: a video surveillance server, a printer, a smart home hub. Even if the list isn't used yet, it'll come in handy for debugging and expanding the setup.

Check: the Address Lists tab has entries named proxy-clients, and those devices have no D flag in DHCP Leases. Run ipconfig on Windows or ip addr on Linux on the computer and confirm the address matches the pinned one.

Possible problems

• After Make Static the computer kept its old address. Disconnect and reconnect the network cable or Wi-Fi, or run ipconfig /release and ipconfig /renew.
• The device isn't in Leases. That means it has a static address set manually. Just add that address to the address list.

Step 3: Configuring the Web Proxy and the parent mobile proxy

Goal of this stage: enable the built-in RouterOS HTTP proxy, point it at the mobile proxy as its parent, and restrict access to the local network only.

Enabling the Web Proxy

1. Open IP, then Web Proxy. The Web Proxy Settings window appears.
2. Check Enabled.
3. In the Src. Address field leave 0.0.0.0 or enter the router's local network address, e.g. 192.168.88.1. The second option is safer: the proxy will listen only on the local interface.
4. In the Port field enter 8080. This is the port clients will contact.
5. In the Parent Proxy field enter the mobile proxy's IP address from the provider's account panel. If the provider gave you a domain name, first look up its IP via the terminal command :put [:resolve name], and enter the resulting address. The field accepts only IP.
6. In the Parent Proxy Port field enter the HTTP proxy port, e.g. 8000 or whatever is listed in the panel.
7. You can fill the Cache Administrator field with your email or leave it as is.
8. Uncheck Cache On Disk. We don't need caching; it only uses resources and can serve stale pages.
9. In the Max. Cache Size field select none. The Max. Cache Object Size field can be left at default; it does nothing with caching disabled.
10. Check Anonymous. Then the proxy won't add Via and X-Forwarded-For headers with your local network addresses. For working with ad accounts this matters.
11. Click Apply, then OK.

In the terminal, all of this is done with one command:

/ip proxy set enabled=yes src-address=192.168.88.1 port=8080 parent-proxy=203.0.113.10 parent-proxy-port=8000 cache-on-disk=no max-cache-size=none anonymous=yes

Replace 203.0.113.10 and 8000 with your real mobile proxy details.

Restricting access to the proxy

An open proxy is a gift to attackers: they'll quickly start pushing someone else's traffic through it and your mobile proxy's limits will burn out within hours. So let's configure the access list right away.

1. In the Web Proxy Settings window click the Access button. The Web Proxy Access rule list opens.
2. Click plus. In the Src. Address field enter 192.168.88.0/24, which is your local subnet. Verify it in IP, Addresses. In the Action field select allow. Click OK.
3. Click plus again. Leave all fields empty and select deny in Action. Click OK. This rule will deny everything not allowed above.
4. Make sure the allow rule is above the deny rule. You can change the order by dragging.

In the terminal:

/ip proxy access add src-address=192.168.88.0/24 action=allow comment="LAN allow"
/ip proxy access add action=deny comment="deny all others"

If you want to allow the proxy only for devices in the proxy-clients list rather than the entire subnet, add separate lines for each address instead of the first rule: the Src. Address field in Web Proxy Access doesn't support an address list directly. We'll do a more flexible restriction with the firewall in step 7.

Warning: never leave the Web Proxy without access rules and without blocking port 8080 from the WAN side. An open proxy on MikroTik gets found by scanners within a day.

First check from the terminal

You can test the link to the parent proxy without touching the computers. In the router's terminal, enter:

/tool fetch url=http://ifconfig.me/ip http-method=get output=user

This command goes directly and will show the regular external IP. Now, on a computer from the proxy-clients list, open a browser, set the proxy to 192.168.88.1 port 8080 in your network settings (in Windows: Settings, Network & Internet, Proxy, Use a proxy server manually) and visit any IP-check site. You should see the mobile carrier's address, not your own provider's.

Check: in IP, Web Proxy the Status button shows Running, the connection counter grows as sites open from the client, and the IP-check site shows the mobile proxy's address.

Possible problems

• A site won't open and the browser reports a proxy error. Open Log in the left menu: entries with the web-proxy topic will tell you what's happening. A connection refused or timeout error to the parent proxy means the router's IP isn't whitelisted or the port is wrong.
• It opens but the IP stayed the same. Most likely the Parent Proxy field is empty or the Enabled checkbox didn't save. Open the settings again.
• HTTPS sites won't open but HTTP works. Check that the proxy is set for HTTPS too in the browser settings, not just HTTP. The RouterOS Web Proxy handles the CONNECT method and passes it to the parent proxy.

Step 4: Routing client traffic to the proxy

Goal of this stage: make clients in the proxy-clients list reach the Web Proxy while others don't. We'll cover two approaches: transparent redirection via NAT and explicit client configuration.

Approach A: transparent HTTP redirection via dst-nat

Transparent mode means the client configures nothing: the router itself intercepts connections to port 80 and funnels them into its proxy. This method has a fundamental limitation: it only works with unencrypted HTTP. HTTPS traffic, which is nearly the entire internet today, can't be transparently redirected through the Web Proxy because the router can't decrypt the connection and figure out where to send it. So we use approach A as a supplement, and approach B as the main one.

1. Open IP, Firewall, the NAT tab. Click plus.
2. On the General tab: Chain - dstnat, Protocol - 6 (tcp), Dst. Port - 80.
3. On the Advanced tab: Src. Address List - proxy-clients. This is the key condition: the rule fires only for devices on the list.
4. On the Action tab: Action - redirect, To Ports - 8080.
5. On the General tab, in the Comment field write Redirect HTTP to proxy. Click OK.
6. Drag the rule up above the masquerade rule if it ended up below. NAT rules are processed top to bottom, and order matters.

In the terminal:

/ip firewall nat add chain=dstnat protocol=tcp dst-port=80 src-address-list=proxy-clients action=redirect to-ports=8080 comment="Redirect HTTP to proxy" place-before=0

The place-before=0 parameter puts the rule first in the list.

Approach B: explicit proxy configuration on clients

This is the main working option for HTTPS. The client knows there's a proxy and sends requests to it itself, including CONNECT for encrypted sites. The upside is that each browser or antidetect profile can be configured separately.

1. On a Windows computer, open Settings, Network & Internet, Proxy. Under Manual proxy setup, turn on the Use a proxy server toggle.
2. In the Address field enter 192.168.88.1, and in Port enter 8080.
3. In the exceptions field add 192.168.*.* so requests to local resources don't go through the proxy. Click Save.
4. On macOS: System Settings, Network, select the connection, the Details button, the Proxies section, enable Web Proxy (HTTP) and Secure Web Proxy (HTTPS), enter the same address and port.
5. In your antidetect browser, when creating a profile select proxy type HTTP, address 192.168.88.1, port 8080, leave the login and password fields empty: the router handles authorization by IP.

Tip: to avoid manually configuring every computer, you can hand out proxy settings automatically via DHCP. This is covered in the advanced section, along with the WPAD file.

Why you need both approaches

The transparent NAT rule is a safety net for when someone on a proxy-clients computer forgot to set the proxy: at least HTTP traffic will go through the mobile proxy rather than directly. Explicit configuration makes HTTPS work. For strict scenarios, in step 7 we'll additionally block direct internet access for proxy-clients with the firewall so traffic bypassing the proxy becomes impossible.

Check: on a computer from the list, open an HTTPS IP-check site with the proxy configured; you'll see the mobile carrier's address. Open IP, Firewall, NAT: the Packets counter on the Redirect HTTP to proxy rule grows when you visit an HTTP site. On a computer not on the list, the IP stays normal.

Possible problems

• The NAT rule doesn't fire, counters stay at zero. Check that the computer's address is really in the proxy-clients list and that the rule is above masquerade.
• After enabling redirection, the router's web interface stopped opening. Add the condition Dst. Address Type - !local on the Advanced tab to the redirect rule so requests to the router itself aren't intercepted.

Step 5: Mangle - marking traffic for policy-based routing

Goal of this stage: mark connections so the router understands which traffic should go out through an alternative interface. This is the core of policy-based routing on MikroTik.

When this step is needed

If you have one provider and just want some devices to work through an external mobile proxy, steps 3 and 4 may be enough. But mangle and PBR solve several important tasks:

• you have two connections, e.g. a wired provider and an LTE modem with a SIM card, and you want to send requests to the proxy provider or traffic from specific devices strictly through one of them;
• you want devices in the proxy-clients list to reach the internet through the router's LTE interface, getting a mobile IP directly, without an external proxy. This is also a mobile-address scenario;
• you need strict traffic separation so even stray connections bypassing the proxy don't go through the main connection.

From here on we assume the main connection is the ether1 interface with the provider, and the alternative is lte1. If you don't have a second connection, read this section anyway: its mangle rules will come in handy for debugging and advanced scenarios.

Creating the routing table in advance

In RouterOS 7 you can't assign a routing mark until a table with that name exists. So we create the table first, then the mangle rule.

1. Open Routing, then Tables. Click plus.
2. In the Name field enter via-lte. Check FIB. Click OK.

/routing table add name=via-lte fib

Rule 1: marking client connections

1. Open IP, Firewall, the Mangle tab. Click plus.
2. General tab: Chain - prerouting. In. Interface - bridge (your local interface, called bridge in the default configuration). Connection Mark - no-mark so already-marked connections aren't marked again.
3. Advanced tab: Src. Address List - proxy-clients. Dst. Address Type - !local. The exclamation mark means negation: the rule shouldn't fire on traffic to the router itself, otherwise clients will lose access to its web interface and DNS.
4. Action tab: Action - mark connection. New Connection Mark - enter conn-lte. Leave the Passthrough checkbox on: the packet will continue through the rules and get a routing mark too.
5. Comment: Mark connections from proxy clients. Click OK.

Rule 2: marking the route by connection mark

1. Click plus again. Chain - prerouting. In. Interface - bridge. Connection Mark - conn-lte.
2. Action tab: Action - mark routing. New Routing Mark - select via-lte from the list. Uncheck Passthrough: the route is assigned, there's nothing more to process.
3. Comment: Route marked connections via LTE. Click OK.

Both commands for the terminal:

/ip firewall mangle add chain=prerouting in-interface=bridge src-address-list=proxy-clients dst-address-type=!local connection-mark=no-mark action=mark-connection new-connection-mark=conn-lte passthrough=yes comment="Mark connections from proxy clients"
/ip firewall mangle add chain=prerouting in-interface=bridge connection-mark=conn-lte action=mark-routing new-routing-mark=via-lte passthrough=no comment="Route marked connections via LTE"

Rule 3: the router's own requests to the mobile proxy

The Web Proxy runs inside the router, so its connections to the parent proxy are born in the output chain, not prerouting. If you want the router to contact the proxy provider through a specific connection, add a separate rule.

1. Plus. Chain - output. Protocol - tcp. Dst. Address - the mobile proxy's IP, e.g. 203.0.113.10. Dst. Port - the proxy port, e.g. 8000.
2. Action - mark routing. New Routing Mark - via-lte or another table this traffic should go through. Passthrough - uncheck.
3. Comment: Router to parent proxy. OK.

/ip firewall mangle add chain=output protocol=tcp dst-address=203.0.113.10 dst-port=8000 action=mark-routing new-routing-mark=via-lte passthrough=no comment="Router to parent proxy"

Warning: the order of mangle rules matters. The mark-connection rule must be above mark-routing. If you added them via the terminal one after another, the order will be correct. If you added them through WinBox, check the Mangle tab and drag the rows if needed.

Tip: mangle has a safe debug mode. Create a rule with Action - passthrough and the desired conditions, but no mark. Its counters will show how many packets match the conditions, so you'll know whether the filter is set correctly without breaking anything.

Check: in the Mangle tab the Packets counters on both rules grow when a client from the list opens sites. Open IP, Firewall, Connections: connections from proxy-clients addresses show conn-lte in the Connection Mark column. If you don't see the column, right-click the table header and enable it.

Possible problems

• via-lte isn't in the New Routing Mark list. You didn't create the routing table or didn't check FIB. Go back to Routing, Tables.
• Clients lost access to the router and DNS. You forgot the Dst. Address Type - !local condition. Add it to the first rule.
• Counters are at zero. Check the local interface name: in Interfaces it might be called not bridge but bridge1 or bridgeLocal.

Step 6: Routing tables and routes for marked traffic

Goal of this stage: tell the router where to send packets marked via-lte, and configure NAT for the alternative interface so traffic actually reaches the internet.

Adding a default route to the via-lte table

1. Open IP, then Routes. Click plus.
2. In the Dst. Address field enter 0.0.0.0/0, which means any destination.
3. In the Gateway field enter the interface name lte1. For LTE interfaces, RouterOS accepts the interface name instead of a gateway IP. If your second connection is wired, enter the second provider's gateway IP, e.g. 10.20.0.1.
4. In the Routing Table field select via-lte.
5. In the Check Gateway field select ping. The router will verify the gateway is reachable, and if it goes down the route becomes inactive.
6. Leave Distance at 1. Comment: Default via LTE for marked traffic. Click OK.

/ip route add dst-address=0.0.0.0/0 gateway=lte1 routing-table=via-lte check-gateway=ping distance=1 comment="Default via LTE for marked traffic"

If you use a wired second provider with a gateway, when entering the gateway IP RouterOS may ask you to specify the interface with a percent sign: 10.20.0.1%ether2. This is needed when identical subnets exist on multiple interfaces.

Configuring NAT for the second interface

Client packets will go out through lte1 with private 192.168.88.x addresses and the carrier will drop them. We need source address translation to the interface address, i.e. masquerade.

1. Open IP, Firewall, NAT. Check whether there's a masquerade rule with Out. Interface - lte1 or Out. Interface List - WAN that includes lte1.
2. If the default configuration's rule uses Out. Interface List - WAN, add lte1 to the list: Interfaces, the Interface List tab, plus, List - WAN, Interface - lte1.
3. If the rule is tied to a specific ether1 interface, create a second one: plus, Chain - srcnat, Out. Interface - lte1, Action - masquerade.

/interface list member add list=WAN interface=lte1
/ip firewall nat add chain=srcnat out-interface=lte1 action=masquerade comment="NAT for LTE"

Fallback path if LTE is unavailable

If lte1 goes down and the route in the via-lte table becomes inactive, marked packets will have no path and client traffic will stop. Decide what you need: either let it stop (strict mode, traffic bypassing the mobile connection is unacceptable) or let it go through the main connection (soft mode). For soft mode, add a second route with a higher distance to the same table:

/ip route add dst-address=0.0.0.0/0 gateway=ether1 routing-table=via-lte distance=10 comment="Fallback via main WAN"

Enter the main provider's gateway IP instead of ether1 if the interface doesn't support a name as a gateway. For strict mode, don't add a fallback route.

Tip: strict mode is the best choice for working with ad accounts. Better a page fails to open than an account sees your home IP. In soft mode, be sure to set up an LTE-down notification via Tools, Netwatch so you can stop work in time.

Check: in IP, Routes the route in the via-lte table is active and has no X flag or blue inactivity color. In the terminal run:

/ip route print where routing-table=via-lte
/tool traceroute 8.8.8.8 routing-table=via-lte

The traceroute should go out through the LTE carrier's gateway, and the first hops will differ from a traceroute without the routing-table parameter. From a client in the proxy-clients list, open an IP-check site with no proxy configured; it should show your SIM card's cellular address.

Possible problems

• The route is inactive. Interface lte1 isn't up or hasn't received an address. Check Interfaces, LTE, status and APN settings.
• The route is active but sites won't open. No masquerade for lte1. Check NAT.
• They open but show the main provider's IP. The mangle rules aren't firing. Go back to step 5 and check the counters.
• DNS doesn't work for clients. Clients use the router as DNS, and we excluded requests to the router via !local, so this is normal. If clients use an external DNS, the router will send DNS queries through LTE, which is also acceptable.

Step 7: Protecting the setup with the firewall and closing leaks

Goal of this stage: make sure the proxy isn't reachable from the internet and that devices in the proxy-clients list can't accidentally reach the network bypassing the proxy.

Closing the proxy port from the WAN side

1. Open IP, Firewall, the Filter Rules tab.
2. Find the default rules. The standard configuration has a rule with Chain - input, In. Interface List - !LAN, Action - drop. It already blocks all incoming traffic from outside, including port 8080. If it exists and is enabled, that's sufficient.
3. If the default rules are gone or you changed them, add an explicit one: plus, Chain - input, Protocol - tcp, Dst. Port - 8080, In. Interface List - WAN, Action - drop. Put it above any accept rules for input.

/ip firewall filter add chain=input protocol=tcp dst-port=8080 in-interface-list=WAN action=drop comment="Block proxy from WAN" place-before=0

Allowing the proxy only for clients on the list

Additionally, let's restrict access to port 8080 inside the network: only devices in proxy-clients can reach the proxy.

/ip firewall filter add chain=input protocol=tcp dst-port=8080 in-interface=bridge src-address-list=!proxy-clients action=drop comment="Proxy only for listed clients"

Through WinBox: plus, Chain - input, Protocol - tcp, Dst. Port - 8080, In. Interface - bridge, Advanced tab: Src. Address List - proxy-clients with negation enabled (click the small square to the left of the field and an exclamation mark appears), Action - drop.

Blocking direct internet access for proxy-clients

This step is for those who chose strict mode: devices on the list should reach the internet only through the router's Web Proxy and no other way. Then even an app without proxy settings can't leak the real address.

1. Plus. Chain - forward. Advanced tab: Src. Address List - proxy-clients. General tab: Out. Interface List - WAN.
2. Action - reject, Reject With - icmp network unreachable. Reject is better than drop: the app gets an error immediately instead of hanging waiting.
3. Comment: Block direct internet for proxy clients. OK.

/ip firewall filter add chain=forward src-address-list=proxy-clients out-interface-list=WAN action=reject reject-with=icmp-network-unreachable comment="Block direct internet for proxy clients"

Note: if you're using the LTE scenario from steps 5-6, where clients go out through lte1 directly without the Web Proxy, this rule needs to be softened: add Out. Interface - ether1 instead of the WAN list so only the main connection is blocked.

Warning: add blocking rules in forward only after you've confirmed the proxy works. Otherwise you'll block your own internet on the work computer and think the proxy broke, when the real problem is the order of operations.

What about DNS

When working through an HTTP proxy with explicit configuration, the browser doesn't resolve domains itself: it sends the site name to the proxy, and the mobile proxy resolves the name on its side. That's good, there's no DNS leak. But other apps on the computer keep asking the router for DNS, and the router goes to its DNS servers through the main connection. For ad scenarios this isn't critical, since sites only see the proxy's address. If you want DNS queries from listed devices to go through LTE too, they already fall under the mangle rules from step 5 when using external DNS servers on the client.

Check: from a phone on mobile data, try opening an address like http://your-external-IP:8080 - the connection should fail. On a computer not in proxy-clients, trying to set the proxy to 192.168.88.1:8080 should end in an error. On a computer from the list, if strict mode is enabled, any app without proxy settings shouldn't be able to reach the internet.

How to roll back changes

If something went wrong, the fastest path is to disable rules rather than delete them. In any firewall tab, select a rule and click the red Disable cross. That restores access while keeping the settings for analysis. Full rollback: Files, select before-proxy.backup, click Restore, confirm the reboot. In two minutes the router returns to its state before this guide.

Verifying the result: checklist and tests

Go through the list in full. Each item is a separate check; tick off the ones you've done.

Checklist

• Files contains backups copied to the computer.
• IP, Web Proxy shows status Running, with Parent Proxy and Parent Proxy Port set, and cache disabled.
• Web Proxy Access has an allow rule for the local subnet and a closing deny.
• Address Lists has a proxy-clients list with the right devices' addresses, pinned in DHCP.
• NAT has a rule redirecting port 80 to 8080 for proxy-clients, above masquerade.
• Mangle has mark-connection and mark-routing rules in the right order, with growing counters.
• Routing, Tables has a via-lte table with FIB, and IP, Routes has an active 0.0.0.0/0 route in that table.
• NAT has masquerade for the second interface.
• Filter Rules closes port 8080 from the WAN side.

How to test

1. On a computer from the proxy-clients list with the proxy configured, open two or three different IP-check sites over HTTPS. All should show the same mobile carrier's address and its name in the provider field.
2. On the same computer, open any HTTP site without the proxy configured. It should open via redirect, and IP, Web Proxy, Connections will show an entry with your source address.
3. On a computer not on the list, open an IP-check site. The address should be your regular provider's.
4. In WinBox open Tools, Torch, select the lte1 or ether1 interface and click Start. You'll see a live traffic stream: from which address, to which port. This makes it easy to see which interface each client's traffic goes through.
5. Open Log and filter by the web-proxy topic. There should be no parent proxy connection failed errors.
6. Start downloading a 100-200 MB file on the client and check the speed. It'll be limited by the mobile proxy's speed, not your connection's, which is expected.

Success indicators

• IP-check sites consistently show the mobile carrier's address for listed devices.
• Other devices not on the list behave unchanged.
• The router doesn't respond on port 8080 from outside.
• Router CPU load while the proxy runs stays under 30-50 percent (System, Resources, CPU Load field).
• When the second interface is disconnected, marked traffic behaves as you decided in step 6: it stops or falls back to the backup path.

Typical mistakes and solutions

The MikroTik proxy is on but clients get a connection error

Cause: the router can't connect to the parent proxy. Most often the router's external IP isn't whitelisted at the provider or changed after a reconnect. Solution: run /tool fetch url=https://ifconfig.me/ip mode=https output=user, compare the address with what's in the provider's panel, update the whitelist. Check the Parent Proxy Port and that the provider gave you an HTTP port, not SOCKS.

HTTP sites work, HTTPS won't open

Cause: the proxy is set only for HTTP on the client, or you're counting on transparent redirection of port 443. Solution: enable the proxy for HTTPS too in your system or browser settings. Transparently redirecting 443 through the Web Proxy is impossible; don't try adding a redirect for port 443, it'll break all encrypted sites.

After adding mangle rules, clients lost access to the router

Cause: the Dst. Address Type - !local condition is missing, so requests to the router's web interface, DNS and DHCP also get marked and go into a different table. Solution: add the condition to the mark-connection rule. Clear connections that are already marked: IP, Firewall, Connections, select the client's rows and click Remove.

Routing mark doesn't appear in the dropdown

Cause: in RouterOS 7, tables are created in advance in Routing, Tables. Solution: create the table with the FIB checkbox, then return to the mangle rule.

Traffic is marked, the route is active, but there's no internet

Cause: no masquerade for the interface the marked traffic goes through. Solution: add lte1 to the WAN Interface List or create a separate srcnat rule with Out. Interface - lte1.

The site sees the mobile proxy's address but sometimes the home IP slips through

Cause: some apps or a separate browser on the computer don't use the proxy, and strict firewall mode isn't enabled. Solution: enable the reject rule in forward from step 7 for proxy-clients, and verify that antidetect profiles use the proxy 192.168.88.1:8080 rather than system settings.

The router is slow, CPU at 100 percent

Cause: disk caching is on, or too many clients for a weak model. Solution: disable Cache On Disk and set Max. Cache Size - none. Disable logging in Web Proxy Access if you enabled it for debugging. For dozens of simultaneous users, consider a model with an ARM64 processor, such as hAP ax3 or RB5009.

Wrong NAT rule order

Cause: the redirect rule is below masquerade or below another dstnat rule that intercepts traffic earlier. Solution: drag the redirect to the top of the list. Remember that the srcnat and dstnat chains are processed separately, but within dstnat the order is critical.

Everything broke after a reboot

Cause: mangle references the mobile proxy's IP and the proxy provider changed the address, or the lte1 interface takes longer to come up than check-gateway takes to fire. Solution: check the address in the provider's panel, update Parent Proxy and the output rule. For LTE, add a task in System, Scheduler that runs at startup and restarts the lte1 interface after 60 seconds with the command /interface lte set lte1 disabled=yes; :delay 5; /interface lte set lte1 disabled=no.

Extra capabilities for advanced users

Automatic proxy settings delivery via DHCP and WPAD

To avoid manually configuring every computer, you can publish a wpad.dat autoconfiguration file. It's a small JavaScript script that tells the browser: use the proxy for these addresses, go direct for the rest. The file goes on any web server on the local network or on the router itself in the Files section, served by RouterOS's built-in www service. Then in IP, DHCP Server, Options you create an option with code 252 and the value being the file's URL, and bind the option to the DHCP network. Windows and most browsers pick it up automatically when auto-detect proxy is enabled. The upside: a new laptop gets the settings the first time it connects to Wi-Fi.

Containers: SOCKS5 and username/password authentication

The built-in Web Proxy only understands an HTTP parent and doesn't pass a username and password. If your mobile proxy is only available via SOCKS5 or requires username authentication, the Container package for RouterOS 7 helps. On ARM, ARM64 and x86 models you can run a lightweight container with software like redsocks or gost, which accepts transparently redirected traffic and wraps it in SOCKS5 with authentication. The setup is: the container gets an address on a separate veth network, a dstnat rule redirects TCP traffic from proxy-clients to the container's port, and the container talks to the mobile proxy. Setup requires enabling container mode via the terminal with physical confirmation via a button on the device and careful attention to memory, so it's for those already comfortable with RouterOS.

Multiple proxies for different device groups

RouterOS has one Web Proxy and one parent proxy for it. If different workstations need different mobile proxies, use a combination: some clients go through the router's Web Proxy, and for other groups create separate address lists and separate routing tables with routes through different interfaces, a second LTE modem or a second provider. In mangle each group gets its own connection mark and routing mark. This way you can run three or four independent exits on one router.

Script to switch the parent proxy on a schedule

If the provider gives you several addresses and you need to rotate them periodically, write a short script in System, Scripts that changes the parent-proxy parameter with the command /ip proxy set parent-proxy=new-address, and attach it to System, Scheduler at the desired interval. Remember that each new proxy address must be authorized by your IP in the provider's panel, and the mangle output rule must account for all possible addresses. It's more convenient to replace its Dst. Address field with an address list of proxy addresses.

Monitoring and notifications

In Tools, Netwatch add a TCP port reachability check for the mobile proxy's address at 30-second intervals. In the Down Script field specify a command to send a message via /tool e-mail send or a log entry marked critical. That way you'll learn about a problem before your ad accounts notice it.

Speed limits and priorities

A mobile proxy is usually slower than a wired connection. To keep one client from hogging all resources, create a Simple Queue in Queues for the proxy-clients subnet with a limit, e.g. 20 Mbps for the whole list, or individual queues per address. Then a scraper on one computer won't leave a manager on the next one without connectivity.

Logging for audits

In Web Proxy Access you can enable the Log field on the allow rule. Then with the web-proxy topic configured in System, Logging the client's address and the requested resource's address will be logged. For long-term storage, send logs to a remote syslog server via System, Logging, Actions. Keep load in mind: on weak models, logging every request noticeably eats CPU.

FAQ: common setup questions

Can I route all of a computer's traffic through the mobile proxy without configuring the computer itself?

For HTTP, yes, via redirect in NAT. For HTTPS with stock RouterOS tools, no, because the Web Proxy can't transparently handle encrypted traffic. A fully transparent setup is possible via a container with a SOCKS5 adapter; this is described in the advanced section. In most cases it's easier to set the proxy 192.168.88.1:8080 on the client once or distribute settings via WPAD.

Why doesn't the Web Proxy accept a username and password for the parent proxy?

RouterOS simply doesn't have such a field. So the mandatory condition for the setup is IP-based authorization on the proxy provider's side. If your plan doesn't allow it, contact the provider's support or use a container.

Do I have to configure mangle and routing tables if I have one provider?

No. For a single connection, steps 3, 4 and 7 are enough. Mangle and PBR are needed when there's a second interface or strict traffic path separation is required. But learning them is worthwhile: it's a universal RouterOS tool that'll come in handy for other tasks too.

How do I tell which interface a client's traffic actually goes through?

Open Tools, Torch, select the WAN interface you're checking and enable a filter by source address. If the client's traffic shows on lte1 and not on ether1, policy-based routing is working. The second way is IP, Firewall, Connections: the right connections should carry the conn-lte mark.

What happens if the router's external IP changes?

The parent proxy stops letting the router through, and clients get errors. Update the whitelist in the provider's panel. To automate this, enable IP, Cloud and set up authorization by DDNS name with your proxy provider if it supports that option.

Can I use the SOCKS server found under IP, SOCKS?

That section is a SOCKS server, not a client. It lets other devices connect to the router as a SOCKS proxy, but it can't forward traffic to an external SOCKS proxy. It doesn't fit this guide's task, and it's best kept disabled.

How do I add a new computer to the setup?

Pin its address in DHCP Leases via Make Static, add the address to the proxy-clients address list, and set the proxy 192.168.88.1:8080 on the computer. Nothing else needs changing, all rules reference the list.

Can I exclude specific sites from the proxy for clients on the list?

With explicit client configuration, add the domains to the proxy exceptions field in the system or browser. On the router side, for transparent HTTP you can add a rule in Web Proxy Access with Dst. Host and Action - deny, but that blocks the site rather than letting it through directly. For PBR routing, add the site's addresses to a separate address list and a mangle rule above the main one with Action - accept, so traffic to them isn't marked.

How do I fully remove the proxy and restore everything?

Quick option: disable the redirect, mangle and reject rules via Disable, and uncheck Enabled in Web Proxy. Full option: restore the before-proxy backup via Files, Restore.

How legal and safe is this?

Using proxies to manage your own ad accounts, testing and separating traffic is standard technical practice. You must comply with the rules of the platforms you work with and your agreement with the proxy provider. From a security standpoint, the main thing is not to leave the proxy open to the internet and not to store unencrypted backups in publicly accessible places.

Conclusion

You've gone the whole way: made a backup, updated RouterOS, pinned device addresses, enabled the built-in Web Proxy and linked it to the provider's mobile proxy. Then you routed client traffic to the proxy via NAT and explicit settings, learned to mark connections in mangle, created a separate routing table and set up policy-based routing through the second interface. Finally, you protected the setup with the firewall and confirmed everything works using the checklist.

Now the proxy on MikroTik lives at the network level rather than on each individual computer. A new employee connects to Wi-Fi, lands on the list, gets the settings, and works with the right IP without any extra explanation. At the same time, the rest of the network noticed nothing.

What to do next

• Set up automatic proxy settings delivery via DHCP option 252 so new devices connect without manual configuration.
• Add proxy availability monitoring via Netwatch and notifications.
• Split devices into several groups with different address lists and work out separate routing tables for each.
• If you need SOCKS5 or username-based authentication, explore the Container package and try the adapter setup on a test router.

Where to grow

RouterOS is a deep system, and mangle with policy-based routing is just one part of it. Logical next topics after this guide: queues and traffic prioritization, scripts and the scheduler for automating routine tasks, connection failover with automatic switching, and working with multiple LTE modems on a single device. Each of them builds on the concepts you've already mastered: address lists, marks, routing tables. Come back to this guide as a reference, experiment on a test configuration, and don't forget backups before every serious change.