HTTP ERROR $CODE$ $Message$ RequestURI=/index.html

This looks to be a connectivity issue, and not an Apache error; something upstream from Apache.

IIS and Apache cannot AFAIK operate on the same host or within the same VM guest, as both want port 80 and as IIS is a Microsoft Windows package and AFAIK not available on other platforms. It is possible to see these mixed when one is used as a reverse proxy server, but that's multiple hosts. Regardless, most folks don't tend to mix Apache (which has its own forward proxy and reverse proxy capabilities) with IIS, typically preferring to use one or the other.

I'd probably look to whatever is providing the reverse proxy server (IIS? Apache?) here (if any?), and at whether the particular network is authorized for in-bound connections; that there is a business-class ISP connection with static IP addresses, etc.

There are various reports of this footprint with web activities on T-Mobile networks. Nothing to do with Apache, based on what is available in Google.

The likely troubleshooting approach would be to test local connectivity and to check the Apache logs, and to get as much stuff (reverse proxy servers, etc) out of the way of the incoming connections. See if there are connections arriving at the web server at the same time the errors are visible. If there are no hits in the Apache logs that match the attempted accesses, you have a reasonable indication the error is upstream.

If this site is intended to be available to and visible to the world, post up the IP address or the domain and we'll take a look at what's going on.

ISP does allow incoming connections, I can VPN, ARD, RDC/RDP, etc.

I could infer from your phrasing that you don't have a business-class connection here. That's a potential problem area. ISPs tend to vary on what access is technically allowed through at the ISP firewall in practice and what access is administratively permitted by the ISP customer agreement, and what is blocked here can be varied at the whim of the ISP. And in this case, it's in-bound port 80 that's interesting here and not in-bound remote desktop nor VPN; this case could well be triggered by a port 80 block at the ISP. If you can reach the host via an inbound remote desktop or VPN or other such connection (and there's no hit in the Apache logs), then this further points to a port-specific reverse proxy or firewall or routing issue.