httpd/bind_address change in CouchDB 3.x default binding to loopback

When deploying CouchDB 3.x, the httpd/bind_address setting defaults to 127.0.0.1, which permits local tools such as Futon/_utils to function but blocks external client connections.

The goal is to decide on a production‑ready binding strategy that allows remote access while maintaining security and compatibility with existing upgrade paths.

Operators must weigh the simplicity of keeping the default loopback address and placing a reverse proxy in front against the alternative of explicitly setting bind_address to 0.0.0.0 and protecting the port with firewall rules.

What are the recommended practices for exposing CouchDB 3.x via a reverse proxy without breaking authentication headers?

How should firewall rules be configured if bind_address is set to 0.0.0.0 to prevent unauthorized access?

Does retaining the default bind_address with a proxy introduce any hidden compatibility issues for clients that expect direct HTTP access?