Apache ProxyPass to IIS results in 503 or complete timeout

I have an IIS machine on LAN behind an Apache machine which is exposed to the internet. I have a simple proxy set up, which is intended to pass traffic to the IIS machine directly from the Apache machine.

<VirtualHost *:80>
        ServerName <domain>.<tld>
        ProxyPass / http://192.168.1.7:8080/
        ProxyPassReverse / http://192.168.1.7:8080/
        ProxyPreserveHost On
        ProxyAddHeaders On
        RequestHeader set X-Forwarded-Proto "http"
</VirtualHost>

This previously worked, when the IIS instance contained nothing but the default page.

After installing a website, I can access said website from another on-network machine by browsing to http://192.168.1.7:8080. This demonstrates that the site works, and that an appropriate firewall entry is present and active.

However, attempting to access the site externally, via the URL, results in a 503 Unavailable error. This error is presented by Apache, not IIS - and, looking at IIS logs, I can see no requests made to the IIS machine.

I have another forwarding setup for a mailserver, which functions normally. Additionally, I exposed the IIS server on port 8080 to the internet, and was able to access it by the URL with the appended :8080 port - demonstrating that the bindings work.

Pinging the IIS machine from the Apache machine is successful. I can RDP to the IIS machine. Every guide I have read tells me what I have set up should work.

The only thing I can think of is that Apache is changing the headers somehow - however, I have commented out the RequestHeader value and have seen no difference in behaviour. What am I doing wrong?

It turns out that creating the virtual host in Apache before putting the IIS site together worked against me.

My configuration relies on a certificate that covers my entire domain, which included the subdomain on which the IIS machine is intended to run. I achieved this with LetsEncrypt - which creates a separate configuration file in sites-avaiable. Despite having an entry for the non-ssl site in the original conf, the presence of the entry in the replacement conf was, combined with the tendency of modern software to default to HTTPS, enough to send every request to the SSL URL - despite this not being bound in IIS, as I had not yet created the certificate.

The solution was to add the following configuration entries to the SSL vhost:

SSLProxyEngine on
SSLProxyVerify none 
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off

This prevents Apache from checking that the certificate on the target server is valid, permitting me to use a self-signed one. This doesn't affect the security of the site externally, as Apache is still supplying a LetsEncrypt certificate from its own store. However, it does permit me to now create a new certificate that is properly valid - which would be important in a scenario where the target server is elsewhere on the internet. Since the target machine is on the local network, this is not a problem.