If you've upgraded the firmware, but it's made no difference that suggests to me that the most likely candidate is a configuration error. Therefore would need a lot more info than the fact that the hotspot no longer serves web pages.
What else stops? Can the client still ping the IP of the MK Hotspot? Is the client able to resolve any DNS names? What do the logs suggest is going on? If not much, add debug logging and look again at the logs when it stops. What happens if you add a test site into the walled garden? Does that work, but nothing else? Has the firewall been altered or is it still the same default from Mikrotik when you created the Hotspot? Is the Hotspot DNS name in the DNS server as a static entry? Look in the DNS Cache to see if the DNS forwarding for other websites are resolving correctly. Check your primary and secondary external DNS servers. Are they correct / working?
That should give you some ideas for now!
I've been dealing with the hotspot since 2.9.40 and have been able to fix most of the problems I've encountered, theres a couple of things you need to check and we can go from there.
1. If your hotspot uses a dns name, when you go to ip -> dns, does it show up under the static list?
2.a) If you're using a https certificate head to certificates in winbox and confirm the cert shows 'KR' to the left of the listing.
b) Open your hotspot server profile and confirm that the certficate selected there matches the name of the certificate in the previous window
c) Go to the Hotspot server tab and confirm the hotspot server has an 'S' next to it (indicating httpS is enabled)
3. Check under ip -> web-proxy -> connections to see if there is a number of connection with no dst address (0.0.0.0) and very small download amounts (10-1000bytes) as this is normally an indication of the http/proxy service crashing.
You can then try the following:
For 1. disable and re-enable the hotspot without a dns listing (it should recreate it)
For 2. re-add and decrypt the hotspot cert then attach it to the hotspot-server-profile (may need to disable and re-enable the hotspot server)
For 3. ensure that in the web-proxy settings max-cache-size = none
Let me know how you go with this.
In extreme cases (around v3.10 we had this problem) the service would appear to crash and not start working again until we either upgraded or downgraded the device (essentially replacing the affected package)
also, something else I remembered.. check the user-profile and ensure that the "transparent proxy" option (on the general tab of the user profile) also is NOT ticked, I would then recommend a restart if you're able to do so without causing many problems. Let me know how this goes for you.
I face the same problem and it occurs almost 5 times in a 12 hour period. Its definately a problem with the web proxy. I have noticed that if there is 0.0.0.0 in the ip> dns , then people see the "web administrator is webmaster" error. As earlier said, clients on bypass are able to browse and they can get to wall garden sites.
TEMPORARY SOLUTIONS WE HAVE IN PLACE
1: Disable and Enable the HOTSPOT SERVER
When this issue happens, disable and then reenable the hotspot server. If the IP OF DNS NAME shows 0.0.0.0 .By disabing and then immediately reenabling, the ip address will be set to the ip address of the hotspot server and clients can browse.
If this is not the issue
2: CLEAR HOTSPOT COOKIES AND FLUSH CACHE
If the IP OF DNS is normal, i immediately clear all client cookies and then flush cache ip>dns>flush cache. Usually this solves the issue because in there you will probably see some sites tagged with 0.0.0.0 as their ip address.
If this doesnt solve the issue
3: DO A HARD REBOOT
Not just a shut down and restart now. That doesnt solve the problem. You have to reboot, wait for 10 secs or about and then restart. This allows the data to be dumped off memory. THIS ALWAYS WORKS....
However, im still not satisfied. How do we absolutely stop this from happening. Its actually extremely annoying and frustrating. but these are what we do when it happens in our environment.
The truth is that most of omega's recommendations have been applied on the router with no improvements. We are thinking of creating an external cache server maybe on a CF card see if this solves the problem... a this point we have nothing to loose.
An idea i have is to write a script that auto detects when the data entry in the dns is 0.0.0.0 and then either delete those entries or flush the entire cache.
Its interesting thou, I have a couple of machines running 3.13 that had no end of problems with
the 'transparent proxy' option being ticked by default (was a mikrotik change) and since turning it off the machines had other problems for a week or so then settled down, have had 3 high use boxes running for over 130 days without issue then randomly one of them starts acting up again :-/
so I don't know, for routing etc I have no problem with mikrotik devices and bugs that are reported are normally fixed next release, but as for high user hotspots I'm still not convinced that the system is stable.
I don't see these issues at all on small sites with 1-10 users, only on ones where I have 100-500 users online.
You can see connections in the webproxy's connections tab when the hotspot is enabled regardless of if the proxy is turned on or off.The web proxy that you can see and configure via Winbox or command console is not the same proxy that is used by the internal hotspot. In fact, in the Winbox screenshots in hrodriguesvt's post it is clearly showing that the proxy is not enabled, yet there clearly IS a proxy enabled, otherwise the hotspot would not work at all. As said, this is because the screenshots are not of the internal proxy used by the hotspot.