Long time lurker, first time poster. I have a small home network which I've recently started moving over to Mikrotik. I setup containers on the main RB5009 router, running technitium for ad filtering dns with relatively easy pause and caddy for reverse proxy, but I was having some glitches with the caddy container and discovered what looks like a recent native reverse proxy which I set up. I have a simple list of 3 http items which all share the same certificate, and technitium resolves the dns for them back to the RB5009.
The reverse proxy seems unstable - for example right now, it's not routing the http traffic, and if I try to do something as simple as export path=/ip/reverse-proxy or I do a full export, I get back #error exporting "/ip/reverse-proxy" (timeout). Restarting the router resolved this for a while, but then happened again a few hours later. Nothing obvious in the logs. I do have a large amount of change going on with configuring different items (a hAP, a wAP and a CRS310 as well as the RB5009) but that specific behaviour seems really off.
The rules, when I can export them are literally just
I use caddy and have seen no issues with it. It was quite simple to setup for my basic usage, and your usage seems fairly basic as well, given the config shown, so it does concern me a little that you were having issues with caddy as well.
Unfortunately I don't have any experience with the mikrotik proxy as I have been happy with caddy for some time and have seen no need or opportunity yet to try the mikrotik proxy.
Are you certain the caddy issue you were seeing is completely unrelated to the new issue after switching?
This strikes me as a bug. You might want to report it. You do that via email to support@mikrotik.com. Or likely better using the portal, so you can see status/avoid-email-filtering, using link at bottom of help.mikrotik.com page. In either case, make sure to collect a supout.rif and include that with your report.
Now... this strikes me as a firewall and/or potential IPv6 related configuration issue. Maybe post a sanitize :export (or whatever ever you can) as while the failed export seem problematic that may not be effect the core issue (e.g. there may be some export problem, but that may not a generic blocker in reverse-proxy since you seem to suggest it's "flaky").
Thanks, I've gone through and created an account, used supout viewer and submitted a ticket. I will post a full sanitized export in here later today incase there's something obvious, but what jumped out from the supout view, which I hadn't previously looked at was in profile, rproxy eating up most of a cpu.
Here's a redacted version of export, apologies for the length. I've rebooted and disabled my reverse proxy items before this export. The dynamic one to a routingthecloud.com address from Technitium container, on 172.18.0.3 port 5380 is in place, but doesn't show in the export, I believe as it's dynamic.
As advised on here, I have off bridge port for emergency connection in vlan config, have vlans as a work in progress, have CAPsMAN as a work in progress, have back to home vpn and a separate wireguard config for connections that I migrated from my previous setup to ideally not need to reconfigure the client end.
I think I should be dropping default config 192.168.88 completely, but I haven't quite got there yet. ISP arrives on ether1 via their ONT and is PPoE and requires vlan911.
I've got a ticket in with Mikrotik as a potential bug in reverse proxy, but feel free to point out anything obviously stupid I'm doing.
I've just re-enabled caddy app, and the problem that appeared to start after the 7.23.2 upgrade is that my browser now returns SSL_ERROR_NO_CYPHER_OVERLAPand refuses to connect to things being reverse proxy'd by it.
I've resolved my caddy issue by giving it a a dedicated IP on my infrastructure vlan.
Support suggested testing 7.24rc2 as there are apparently changes to rproxy in there, however that made no difference. I've submitted an updated supout.rif after upgrading to the beta.
Talking to myself, but I've narrowed down my issue to one service - having Frigate NVR sat in the background open on a browser tab on a machine on my network seems to be the cause of rproxy hitting 95% CPU usage.
I've switched it over to Caddy and set up metrics monitoring to see if I can determine any spikes in requests under similar circumstances and get some idea for how it can possibly be resolved.
Again talking to myself, but working with support, I've put a nightly build on which has changes in socket freeing up for reverse proxy, which appears to have resolved it and I've been stable for 48 hours now in the same situation.
Hopefully those changes will get into an upcoming sable release.
Thanks for filing a ticket. I thought there was a bug here. I have done a lot of automated/manual testing of /app in some of my OSS projects.... but not the reverse-proxy integration with it... (i.e. my automated tests use a free or trial CHR, neither have /ip/cloud, so use-https=yes cannot be tested)