A properly setup reverse proxy doesn't care about absolute/relative URLs, because from the browser's perspective it's just interacting with the public face - it doesn't know/care which server the request is handled by.

Since you mentioned redirecting 80->443 I'm guessing the issue is/was with HTTP vs HTTPS and one of them was generating links that the other wouldn't serve.

Quite possibly.

double reverse-proxy trouble:

I'm trying to add another proxied site, from a different pc behind our our staging server. I duplicated the relevant lines in default-ssl.conf and changed the details thus:

ProxyRequests Off

# reverse proxy to serverA/siteA 022718
<Location "/siteA">
    ProxyPass http://serverA/siteA
    ProxyPassReverse http://serverA/siteA
    Order allow,deny
    Allow from all
    Authtype Basic
    Authname "Restricted Access"
    AuthUserFile /etc/apache2/.htpasswd
    Require user ******
</Location>

# reverse proxy to serverB/siteB 051418
<Location "/siteB">
    ProxyPass http://serverB/siteB
    ProxyPassReverse http://serverB/siteB
    Order allow,deny
    Allow from all
    Authtype Basic
    Authname "Restricted Access"
    AuthUserFile /etc/apache2/.htpasswd
    Require user *******
</Location>

"SiteA" (the original proxied wp site) continues to show the web-facing domain in the address bar

"SiteB" (another cms-y thing) switches from "https://mydomain.com/siteB" to "http://serverB/siteB" upon loading.

Pretty sure I did no special config to the siteA apache instance, or if I did, can't find where it might be.  :-(

Nurmind. Like the wp, I had to modify a base url in the cms-y thing to point to the front-facing server.

All good (but not the >2-hours I wasted before it dawned on me :-/ ).