[hobofan]

I think that puts it into an entirely different category. SOCKS proxies are great, as they don't require you to try and bend all domain names the correct way. In a typical intranet or proxied container cluster setup, you quickly end up hitting some application logic that e.g. returns back an absolute URL (breaking your manual usage of lvh.me), or uses non-default HTTP ports, or one of many other ways that break if you try to use a lvh.me-like setup or remapping DNS entries to localhost.

[CGamesPlay]

You're correct, but in practice I never had that issue. All the applications I used this technique with were easily able to set the "site root URL" via an environment variable or something similar.

To show the other side of the coin: SOCKS proxies are less convenient, as they require you to configure your entire browser (your entire system on macOS) to use it.

[hobofan]

> All the applications I used this technique with were easily able to set the "site root URL" via an environment variable or something similar

Yeah that often works, but also requires running things locally or redeploying them. For quick debugging, trying to use the service without altering it is more convenient.

> as they require you to configure your entire browser (your entire system on macOS) to use it

See my other comment. I'm on macOS, and I'm quite happy with FoxyProxy, which allows for individual pages to use a SOCKS proxy based on a regex (or just via an on/off toggle).

[prmoustache]

> To show the other side of the coin: SOCKS proxies are less convenient, as they require you to configure your entire browser (your entire system on macOS) to use it.

It is no big deal. The blog post shows the usage of a pac file which only redirects the local .podman tld to the socks proxy.

It is only maybe an issue if you are using a company issued computer already using a pac file from a GPO. But in that case you can totally decide to dedicate a browser for it and setup the socks proxy only for it. Choices.