<div dir="ltr">Hey Alex,<div><br></div><div>Thanks for the quick and detailed response! I inherited this service recently - would you recommend upgrading to 5? My configs are fairly simple, so upgrade should be easy.</div><div><br></div><div>Here's my desired flow - let "reverse" and "parent" represent the IPs of those proxies, and "target" represent the target API hostname.<br><br>Application sends GET (POST, PUT, etc) <a href="http://reverse/some/path">http://reverse/some/path</a><br>(Note: Application doesn't know target, and couldn't reach it if it did.)</div><div><br>Reverse adds headers to the request<br>Reverse sends the request to <a href="https://target/some/path">https://target/some/path</a>, using parent as a forward proxy.</div><div><br></div><div>The parent proxy in my test case accepts TCP, although if possible I would like to support parent TLS proxies as well - this reverse proxy is deployed in different environments where the parent proxy may differ.</div><div><br>I set this up outside of a docker and without trying to force ssl. The config below was my first attempt - it works <i>if</i> the reverse proxy has direct internet access, but just hangs otherwise; my understanding is that requests that use the first cache_peer do not use the second to proxy.</div><div><br></div><div># Reverse proxy to <a href="http://google.com">google.com</a><br>http_port 80 accel vhost defaultsite=<a href="http://www.google.com">www.google.com</a><br>cache_peer <a href="http://google.com">google.com</a> parent 80 0 no-query originserver forceddomain=<a href="http://www.google.com">www.google.com</a> name=target<br>request_header_add Joel Joel<br><br># Simplified acl<br>http_access allow all<br>cache_peer_access target allow all<br><br># Parent proxy<br>cache_peer 10.60.4.178 parent 3128 0 no-query default<br>acl all src <a href="http://0.0.0.0/0.0.0.0">0.0.0.0/0.0.0.0</a><br>never_direct allow all<br><br>This was my second attempt, using forceddomain to replace the host header but sending the request directly to the parent proxy. This results in the parent receiving GET /, which it does not understand (it expects GET target/somepath).</div><div><br></div><div># Reverse proxy directly to forward proxy <a href="http://google.com">google.com</a><br>http_port 80 accel vhost defaultsite=<a href="http://www.google.com">www.google.com</a><br>cache_peer 10.60.4.178 parent 3128 0 no-query originserver forceddomain=<a href="http://www.google.com">www.google.com</a> name=parent<br>request_header_add Joel Joel<br><br># Misc<br>cache deny all<br>shutdown_lifetime 1 seconds<br></div><div><br></div><div>I suspect this would need a url rewriter to force the url to target - I'm failing to get any of the example rewriters working (maybe due to the old squid version?) so I haven't been able to test that yet. But I suspect it will fail for HTTPS, because the rewritten URL will be sent as GET target/something to the parent proxy, instead of CONNECT target/something - I still think I'm missing something to get my squid to use the forward <i>as a proxy</i> while itself functioning in reverse.</div><div><br></div><div>I'll rewrite these for squid 5 and try to get URL rewriting working. In the meantime, could you let me know if either of these two general approaches is remotely correct and if so, what I can do to get further with them?</div><div><br>Thanks so much! If you happen to be on StackOverflow, I've asked the question with a bounty <a href="https://stackoverflow.com/questions/73286678/reverse-proxy-with-http-inbound-https-outbound-and-parent-proxy/73293978?noredirect=1#comment129465312_73293978">there</a> as well (although less squid-specific).</div></div>