All of our servers and networks are located in US West 1. We have two private network connectors running version 1.5.4892.0 and several applications configured to use Application Proxy. Direct connections to the servers have about 20 ms latency and more than 20 MB/s throughput, but connections through the proxy consistently exceed 300 ms and deliver less than 1 MB/s.
A packet capture showed that a 20 MB download took roughly 100 ms from the server to the connector, followed by about 200 ms to send the data toward the proxy egress range. However, the client took more than 20 seconds to receive the content. The response included x-ms-proxy-data-center: CUS, so I initially suspected that traffic was being routed through Central US even though the resources are in US West. Creating another connector group did not change the reported data center.
The goal is to place an authentication barrier in front of internal resources before clients can access them. Application Proxy otherwise worked well, but an average speed around 800 KB/s was not acceptable. After opening a support case, Microsoft made a backend change and the performance issue was fixed; it was not caused by the CUS data-center designation.
2 Answers
Application Proxy is generally intended for internal application access, not as a high-throughput customer-facing delivery layer. If this is only for internal resources, it can still be appropriate, but persistent bandwidth limits or latency may require support intervention or a different access architecture. Make sure the service is being used within its intended scenario before investing heavily in workarounds.
This is worth taking to support rather than assuming the data-center header is the root cause. There may be backend routing or service-side configuration that support can adjust, and the connector-side capture can give them useful evidence. In this case, support made a change on the backend and restored the expected performance.
We opened a support case, and they eventually fixed it with a change on their side. The CUS value turned out not to be the cause.
Our use case is limited to internal, non-customer-facing applications. The issue ended up being a service-side problem rather than a limitation caused by the Central US routing label.