After the update to the latest datadog agent (v6), we discovered that metadataproxy would not forward the correct status code for proxied requests.
In our specific case, the datadog agent would use the metadata API for Azure and GCE to detect hostnames. Azure and GCE use the same endpoint as AWS does (169.254.169.254) but different routes. The way datadog implemented the code is: if status code 404 discard response, if not, use response without further validation. So we ended up having hosts named after a 404 page which would break the Datadog UI. Forwarding the status code as well for proxied requests fixed the issue for us.
I am happy to open an issue if further discussion is required.
After the update to the latest datadog agent (v6), we discovered that metadataproxy would not forward the correct status code for proxied requests. In our specific case, the datadog agent would use the metadata API for Azure and GCE to detect hostnames. Azure and GCE use the same endpoint as AWS does (169.254.169.254) but different routes. The way datadog implemented the code is: if status code 404 discard response, if not, use response without further validation. So we ended up having hosts named after a 404 page which would break the Datadog UI. Forwarding the status code as well for proxied requests fixed the issue for us.
I am happy to open an issue if further discussion is required.