Details
Description
When the proxy_protocol is in use, the IP address of the proxy is replaced with the IP address of the client being proxied for authentication. This replaced IP is then also used in all error messages and other information that is logged. This makes it very difficult to diagnose any network errors that happen for a client that's behind a proxy which uses proxy_protocol.
Here's an example: we have two proxies, proxy A at 192.168.0.200 and proxy B at 192.168.0.300, and a client at 192.168.0.100. If there's a problem on proxy A that results in a network error, the error that is logged is:
[Warning] Aborted connection 123 to db: 'foo' user: 'bar' host: '192.168.0.100' (Got an error reading communication packets)
|
What I think would be an improvement is an error like this:
[Warning] Aborted connection 123 to db: 'foo' user: 'bar' host: '192.168.0.100' proxy: '192.168.0.200' (Got an error reading communication packets)
|
With this, it'd be immediately known that the proxy A is the origin of the error and the link between these two nodes is the problem. With the current error message, all links that connect to the database must be inspected.
As can be seen, for setups where there are multiple proxies, finding out which proxy to look into when looking for related errors takes a lot of work and leads to potentially ambiguous results if the connection IDs on the database aren't logged by the proxy for any errors that it faces. The improved error would both remove the ambiguity and reduce that amount of work that needs to be done to find the proxy to look at.
Attachments
Issue Links
- relates to
-
MDEV-29942 Provide insight on proxy_protocol usage
- Open