Overview
Reference this document when you see unexpected or incorrect flag evaluations and believe network connectivity is at fault. Follow the steps below chronologically to uncover the specific issue and pinpoint where it occurs. At any point, if you need assistance, reach out to Technical Support.
Solution
Part 1: Identify
If you answer NO to any of the following, the problem is likely not coming from the LaunchDarkly products or services but from your internal networking architecture.
-
Have you successfully used LaunchDarkly in this area of your application before the error(s) occurred?
-
If YES, proceed to step 2.
-
If NO, review Part 2: Investigate with the engineering teams that manage your infrastructure. You may need to inform these teams that your team or department uses LaunchDarkly and explain how it’s used in your application or server.
-
-
Does the network request make it from the SDK to the Relay or the LaunchDarkly streaming or polling endpoints? ~ You can enable debug logging to make the relay print a log if it received the request.
-
If YES, proceed to step 3.
-
If NO, something in the architecture is likely blocking the request. Proceed to Part 2: Investigate.
-
-
Did the destination encounter an error? ~ To locate the error, check the logging for the Relay or SDK. Check the network connectivity through the appropriate cURL (or the Windows equivalent), and see if you encounter the same error in your logs.
-
If YES, reach out to Technical Support for further assistance.
-
If NO, something in the architecture is likely severing the request. Proceed to Part 2: Investigate.
-
Part 2: Investigate
- Is the issue explained by our common misconceptions about LaunchDarkly architecture documentation? ~ Review, Common misconceptions about LaunchDarkly architecture
-
Do you see SSL errors or mentions of a certificate issued in the error logs?
-
Check with the team that manages the application to verify you use a managed trust store or certificate authority. ~ You may need to update the certificates to recognize LaunchDarkly.
-
-
Does all your network traffic from your corporate/organizational servers go through a web proxy or web server that proxies requests?
-
Confirm whether this web proxy or server allows a long-lived connection between the SDK and Relay/LaunchDarkly. ~ This is where your architecture could block or drop between the SDK and Relay/LaunchDarkly.
-
Confirm that the web proxy or server doesn’t terminate connections before the heartbeat interval. ~ Some web proxies, by default, will not allow a long-lived connection and will silently sever it.
-
-
Do you have different firewalls or web proxies based on the app environment (e.g., one firewall for dev and a different firewall for production)?
-
Compare the configurations of a working environment against those of the non-working environments to identify differences. ~ If it is not happening consistently, this indicates that the problem is due to different firewalls that are not configured the same way.
-
-
Do you have a load balancer between the SDK and the Relay Proxy connections?
-
Confirm whether the connectivity is lost when there is a change to the Relay Proxy instance. ~ If the Relay array is downscaled and the load balancer is not rebalanced, traffic will be routed to a no-longer-existing node, causing the SDK to lose connectivity.
-
-
Is the issue occurring for an end-user?
-
Confirm that the end user had/has stable network connectivity when the LaunchDarkly errors occurred. ~ If they had other limited network availability or no network connection, LaunchDarkly has no control over the end user’s network.
-
If the end user uses the application within a secure, locked-down environment, check whether they have a firewall that blocks connections to LaunchDarkly client-side streaming endpoints. ~ Similarly to points 2, 3, & 4 above, the end user's architecture could drop or block the connection.
-
