Apache reverse proxy - URL without / is refused

I use reverse proxy to show backend server content for a subdomain. The subdomain.mydomain.com (server A) should display content of server with IP 123.123.123.123 port 1111 (server B).

Virtual host of subdomain.mydomain.com (server A):

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName subdomain.mydomain.com

SSLEngine on
SecAuditEngine On
RewriteEngine On
SSLProxyEngine on
ProxyPreserveHost On
LogLevel warn

<Directory />
    Options -Indexes +FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

<Location />
    ProxyPass https://123.123.123.123:1111
    ProxyPassReverse https://123.123.123.123:1111
</Location>

ErrorLog /var/log/apache2/error.log

SSLProtocol             all -SSLv2 -SSLv3
SSLHonorCipherOrder     on
SSLVerifyClient none
SSLVerifyDepth 1

SSLCertificateFile /etc/apache2/cert.site/chain_wildcard_site_combined.crt
SSLCertificateKeyFile /etc/apache2/cert.site/key_wildcard_site.key
 
SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

</VirtualHost>                                  
</IfModule>

Virtual host of 123.123.123.123:1111 (server B):

<IfModule mod_ssl.c>
    <VirtualHost 123.123.123.123:1111>
        DocumentRoot /srv/www/site/htdocs

SSLEngine on
RewriteEngine On
SSLProxyEngine on
ProxyPreserveHost On
LogLevel warn

<Location "/">
   Require ip 222.222.222.222
</Location>

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

<Directory /srv/www/site/htdocs>
    Options -Indexes +FollowSymLinks +MultiViews
    DirectoryIndex index.php
    AllowOverride None
    Require all granted
</Directory>

ErrorLog /srv/www/site/log/error.log
CustomLog /srv/www/site/log/access.log combined
CustomLog /srv/www/site/log/ssl_request_log \
            "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

SSLProtocol             all -SSLv2 -SSLv3
SSLHonorCipherOrder     on
SSLVerifyClient none
SSLVerifyDepth 1

SSLCertificateFile /etc/apache2/cert.site/chain_wildcard_site_combined.crt
SSLCertificateKeyFile /etc/apache2/cert.site/key_wildcard_site.key

        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

    </VirtualHost>
</IfModule>

If I load URL: https://subdomain.mydomain.com/dir/

it loads successfully.

If I load URL (without trailing slash): https://subdomain.mydomain.com/dir

it results error page: ERR_CONNECTION_REFUSED.

EDIT1:

I execute command:

curl -IL https://subdomain.mydomain.com/dir

and I get this result:

HTTP/1.1 301 Moved Permanently
Date: Mon, 23 Aug 2021 13:45:13 GMT
Server: Apache
Strict-Transport-Security: max-age=15768000; includeSubDomains
Strict-Transport-Security: max-age=15768000; includeSubDomains
Location: https://subdomain.mydomain.com:1111/dir/
Content-Type: text/html; charset=iso-8859-1

curl: (7) Failed to connect to subdomain.mydomain.com port 1111: Connection refused

EDIT2:

I added trailing slash

<Location />
    ProxyPass https://123.123.123.123:1111/
    ProxyPassReverse https://123.123.123.123:1111/
</Location>

But I still get the Connection refused error.

Any idea why is it resulting error, when trailing slash is missing?

Thanks!


Solution 1:

Although it's really difficult to correlate subdomain.domain.com, 123.123.123.123, and 222.222.222.222, two issues jump out at me. Here's my take on what I think you're telling us.

  1. ProxyPass directives must always have a trailing slash:

     <Location />
         ProxyPass https://123.123.123.123:1111/
         ProxyPassReverse https://123.123.123.123:1111/
     </Location>
    

    You corrected this in an edit/update but there are no new testing results to show the effect of the fix.

  2. You're proxying to the host 123.123.123.123, and the VirtualHost directive expects this, but there's no ServerName entry to match the original servername as required by ProxyPreserveHost.

    • Remove ProxyPreserveHost from Server B
    • Add ServerName to Server B to match the IP address defined in Server A's ProxyPass URI

Don't forget to look carefully at the access and error logs generated by Server A and Server B; they exist for good reason.