Coordinate PROXY v2 across shared Private Link service backends

Source facts

Private Link service translates consumer source addresses to provider-side NAT addresses. PROXY v2 can convey the original source and endpoint LinkID, but the backend must parse the added header; a mismatch between the service setting and backend expectation causes requests to fail.

Microsoft warns that enabling PROXY v2 affects shared load-balancer and backend arrangements. Other Private Link services sharing them must be configured consistently, or health probes fail. The header is also included in HTTP/TCP health probes. Microsoft Learn.

Applicability

Use this review for standard load-balancer-backed Private Link services, not the separate Direct Connect preview. Map sharing services and backend consumers before considering the setting a change to only one endpoint.

DSE recommendation

DSE recommends a compatibility change plan agreed by the service and application owners. Record which backends expect the header, which services share their pool, and how connection metadata will be interpreted. Preserve the prior configuration and define a coordinated restoration sequence if parsing or probes fail.

Verification

In a representative test, inspect backend request handling, reported connection metadata, and health probes before and after enabling the protocol. Exercise each sharing service rather than just the first one changed. Confirm requests work and the observed source/LinkID correlation is correct; do not treat that correlation alone as application authorization.

Official references

Microsoft Learn: What is Azure Private Link service?. Source retrieved September 9, 2026.