Go agent high_security mode X-NewRelic-Id forwarding with X-Forwarded-For proxy trust

Short answer

High security mode does not suppress outbound forwarding of X-NewRelic-Id. What it tightens is inbound acceptance of trace and forwarding headers. When X-Forwarded-For arrives from a proxy the agent does not trust, the agent treats the forwarded headers as untrusted and drops inbound trace linkage — which looks like broken distributed trace correlation even though the header is still being injected downstream.

Likely explanation vs. confirmed behavior

Confirmed (well-established): New Relic's high security mode restricts inbound header collection and distributed trace context extraction. Outbound injection of trace headers for correlation is retained; inbound acceptance is gated. Separately, use of X-Forwarded-For for client identity and trace linkage is gated by proxy trust.

Likely explanation for your symptom: your proxy chain is not in the agent's trust configuration, so inbound trace context from X-NewRelic-Id is discarded at the receiving service. Correlation breaks at the trust boundary, not at injection time.

Required configuration

The agent on the receiving service must be configured to trust the proxy chain that sets X-Forwarded-For. In practice this means:

1. Configure the trusted account key so cross-application/distributed trace headers from your own account are accepted.
2. Explicitly mark the proxy hops as trusted for forwarded-header handling, so the agent accepts X-Forwarded-For and the accompanying trace headers instead of treating them as client-spoofable input.

Exact key names vary by agent version and deployment method (config file vs. environment variables), so map these generic names to your version's documentation rather than copying keys blindly.

Version sensitivity (8.5–9.2)

Header filter logic was refactored in roughly the 8.5–9.2 range to prioritize proxy trust checks. The practical effect: suppression of inbound trace context under untrusted proxy conditions became more consistent, making proxy trust a hard prerequisite for correlation. If you upgraded into or within this range and correlation broke at the same time, the trust check is the first thing to verify. Treat the exact version boundaries as uncertain until checked against your agent's changelog.

How to verify

1. Confirm the running agent version and effective config (high security flag, trusted account key, proxy trust entries) via the agent's config dump or environment metadata.
2. Capture inbound headers at the service boundary and confirm X-NewRelic-Id actually arrives.
3. Enable agent debug logging and watch header-filtering decisions for the untrusted-proxy path.
4. Run a controlled A/B: add the proxy to the trust list and re-send the same request. If trace linkage appears in the New Relic UI only in the trusted case, the diagnosis is confirmed.

Note: high security also disables custom attributes and some header collection, which can hide the diagnostic signals above — debug logging at the agent level is the most reliable observation point.

One open detail

Which direction is failing for you — inbound linkage at the receiving service, or the header missing on the wire entirely? If a packet capture shows X-NewRelic-Id never leaves the upstream service, the problem is injection-side and this analysis needs revisiting.