Sorry for being so late to this thread.
In Spain we use a saying that goes, “Mal de muchos, consuelo de tontos.” (pain of many, consolation of fools?). It says little about me but the truth is that I feel a little comforted to see that I am not the only one who has struggled with this.
In confidence, writing rules for mod_rewrite are by far the most time consuming (and annoying) thing I’ve done in all the years I’ve been using OJS.
I try to summarize my findings on this topic:
- OJS can be run as webApp, but also from command line, or as API calls and the behavior of OJS can vary because the contexts are different (reverse proxy) and also because different libraries and strategies have been used to discover the url or protocol.
- OJS is designed to work as “multi-tenant”, so when we run it as “single-tenant” (one ojs for each journal) we have to play with the urls (I’ve been doing it for more than 10 years: it’s not impossible, but very uncomfortable).
- OJS prefers not to use clean_URLs.
In any of the 3 scenarios you will have to struggle, but if (as in my case) you want to use OJS behind a reverse proxy, with single-tenant and with resftulURLs, I can tell you that it will make you sweat… but hey, we are engineers, right? 
The solution we have found (while waiting for someone to come up with something better), consists of a combination of configuration variables (config.inc.php, apache…) and rewrite rules.
Unfortunately I haven’t come up with universal rewrite rules, but I do have some templates that work well for each casuistry:
https://github.com/marcbria/dojo/tree/main/templates/ojs
The templates indicate:
- domain/folder: Is it going to run on a
domain(or subdomain) or is it installed on afolder? - no-slug: If you don’t want to show the /journalContext/ slug (common in single-tenant installations)
To check that the redirects go where they should, I made this little script:
https://forum.pkp.sfu.ca/t/check-if-your-ojs-urls-are-healthy
Any suggestion or improvement proposal is welcome.