⚠️ Hi, we have production issue with users not being to log in

request to https://api.euc1.descope.com/v1/mgmt/user?userId=U38qYvESg0tvgc3M8hCjRtEijRf3 failed, reason: getaddrinfo EAI_AGAIN api.euc1.descope.com

DNS Resolution Issue The

getaddrinfo EAI_AGAIN

error indicates your server cannot resolve the DNS for

<http://api.euc1.descope.com|api.euc1.descope.com>

. This is a network connectivity issue preventing authentication requests. Immediate Troubleshooting Steps 1. Test DNS resolution from your server:

nslookup <http://api.euc1.descope.com|api.euc1.descope.com>
dig <http://api.euc1.descope.com|api.euc1.descope.com>

2. Check firewall rules - ensure outbound HTTPS traffic on port 443 is allowed to Descope endpoints 3. Verify your project region matches the endpoint - EU projects use

<http://api.euc1.descope.com|api.euc1.descope.com>

Network Requirements • Allow outbound HTTPS (port 443) to

<http://api.euc1.descope.com|api.euc1.descope.com>

and

<http://static.descope.com|static.descope.com>

• DNS resolution must work for Descope endpoints • If using IP-based firewall rules, consider DNS resolution with dynamic updating since Descope uses CDN with dynamic IPs The issue is likely network/firewall related rather than a Descope service problem. Check with your network team about DNS resolution and firewall rules for the Descope endpoints. Firewall Configuration | Descope Documentation Multi-Region Support | Descope Documentation

Project ID: Peuc131pAyHyBVS1qrJMEKYVVZiI9IMu

Project Region Confirmation Your project ID

Peuc131pAyHyBVS1qrJMEKYVVZiI9IMu

starts with "P" followed by "euc1", confirming this is an EU region project that should use

<http://api.euc1.descope.com|api.euc1.descope.com>

. Network Diagnostics Run these commands from your production server to isolate the DNS issue:

# Test DNS resolution
nslookup <http://api.euc1.descope.com|api.euc1.descope.com>
dig <http://api.euc1.descope.com|api.euc1.descope.com>
# Test connectivity
curl -I <https://api.euc1.descope.com/v1/mgmt/user?userId=test>
ping <http://api.euc1.descope.com|api.euc1.descope.com>

Required Firewall Rules Your network must allow outbound HTTPS (port 443) to these EU endpoints: •

<http://api.euc1.descope.com|api.euc1.descope.com>

(API requests) •

<http://static.descope.com|static.descope.com>

(SDK assets) If using IP-based rules, whitelist these EU static IPs : •

3.72.207.40

•

3.74.59.88

•

3.121.31.67

The

EAI_AGAIN

error specifically indicates DNS resolution failure, so focus on DNS configuration and firewall rules blocking DNS queries or HTTPS traffic to Descope's EU endpoints. Multi-Region Support | Descope Documentation Configuring Public Static IPs | Descope Documentation

The request is going from GCP servers, Three Descope projects work and one has transtitive disconnection.

can you share cf-ray for error ?

GCP Intermittent Connectivity Issue Since 3 projects work and only 1 has transitive disconnection from GCP, this points to a specific network routing or DNS caching issue rather than a blanket firewall problem. GCP-Specific Troubleshooting 1. Check GCP DNS resolution consistency:

# From your GCP instance
dig <http://api.euc1.descope.com|api.euc1.descope.com> @8.8.8.8
dig <http://api.euc1.descope.com|api.euc1.descope.com> @169.254.169.254

2. Test from different GCP zones/regions to isolate routing issues:

# Compare DNS responses across zones
nslookup <http://api.euc1.descope.com|api.euc1.descope.com>

Likely Causes • DNS caching inconsistency - GCP's metadata server DNS cache may have stale entries for this specific project • VPC routing differences - The failing project may be in a different VPC or subnet with restrictive egress rules • Regional routing - GCP's network path to EU endpoints may be inconsistent for this specific instance/project Quick Resolution Steps 1. Flush DNS cache on the affected GCP instance 2. Compare VPC firewall rules between working and failing projects 3. Check if the failing project uses different service accounts or IAM policies 4. Test direct IP connection to bypass DNS:

curl -H "Host: <http://api.euc1.descope.com|api.euc1.descope.com>" <https://3.72.207.40/v1/mgmt/user?userId=test>

The intermittent nature suggests network-level routing inconsistencies within GCP rather than a Descope service issue.

looping in @Tom Kaminski

meanwhile, we redeploy related GCP instances

can you run

# Using configured DNS
dig <http://api.euc1.descope.com|api.euc1.descope.com>
# Using Cloudflare DNS
dig <http://api.euc1.descope.com|api.euc1.descope.com> @1.1.1.1

That’s GCP Cloud run, I cannot connect to their terminal

ok, keep us updated

It seems to be GCP network outage for some instances, though we do no host in us-east1 https://status.cloud.google.com/incidents/8cY8jdUpEGGbsSMSQk7J

🙏