[BUG] EDITED: Claude Code fails on mobile networks due to IP-based connections instead of hostname-based HTTPS

Environment

• Platform (select one):
• [x] Anthropic API
• [ ] AWS Bedrock
• [ ] Google Vertex AI
• [ ] Other: <!-- specify -->
• Claude CLI version: 1.0.41 (Claude Code)
• Operating System: Ubuntu WSL on Windows 11
• Terminal: WSL Terminal

Bug Description

Claude Code has inconsistent network compatibility due to connecting to IP addresses instead of hostnames. This causes complete service failure on certain networks (like KPN mobile in Netherlands) while working normally on others (home broadband), despite identical underlying connection issues.

Steps to Reproduce

1. Install Claude Code version 1.0.41
2. Test on home/office broadband network - works normally
3. Switch to KPN mobile network (Netherlands) or similar mobile provider
4. Attempt any API request: claude test
5. Observe complete failure with connection errors
6. Network trace shows same IP-based connection attempts on both networks

Expected Behavior

Claude Code should work consistently across all network types by using hostname-based HTTPS connections for reliable certificate validation and network compatibility.

Actual Behavior

Network-dependent behavior:

• Home network: Works perfectly despite underlying connection issues
• KPN mobile network: Complete failure with API Error (Connection error.) and TypeError (fetch failed)

Technical analysis shows identical underlying issues on both networks:

• Connections made to raw IP addresses: 34.36.57.103, 160.79.104.10
• Direct IP connections fail on both networks with certificate/TLS errors
• Some networks allow Claude Code to recover from these failures, others don't

Additional Context

Comparative Network Testing

Network trace (both networks show same behavior):

strace -e trace=network claude test
# Result: connect(33, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("34.36.57.103")}, 16)

Direct IP connection tests (identical failures on both networks):

curl -v https://34.36.57.103/
# ❌ SSL certificate problem: certificate has expired

curl -v https://160.79.104.10/  
# ❌ error:0A000410:SSL routines::sslv3 alert handshake failure

Hostname connections (work perfectly on both networks):

curl -v https://statsig.anthropic.com/
# ✅ SSL certificate verify ok

curl -v https://api.anthropic.com/
# ✅ SSL certificate verify ok  

Root Cause Analysis

The issue stems from Claude Code connecting to resolved IP addresses instead of hostnames, causing:

1. Certificate validation failures - SSL certificates are issued for hostnames, not IP addresses
2. SNI (Server Name Indication) problems - servers can't present correct certificates without hostname
3. CDN/Load balancer issues - modern infrastructure requires hostname-based routing

The critical difference: Claude Code has some fallback/recovery mechanism that works on some networks but is blocked or fails on others (particularly mobile networks with stricter policies).

Network-Specific Observations

KPN Mobile Network (Netherlands):

• Blocks or interferes with Claude Code's recovery mechanism
• May have stricter timeouts, deep packet inspection, or IP-based restrictions
• Affects large user base (~40% market share in Netherlands)

Home Broadband Networks:

• Allow Claude Code's fallback mechanism to function
• More permissive network policies
• Standard residential internet behavior

Impact Assessment

Affected Users:

• Mobile workers using KPN (Netherlands largest mobile provider)
• Potentially other European mobile networks with similar policies
• Any network with restrictive policies around direct IP connections
• Inconsistent user experience across network types

Business Impact:

• Complete service unavailability on major mobile networks
• Unpredictable behavior - works sometimes, fails others
• Reduced confidence in Claude Code reliability
• Mobile/remote work productivity impact

Proposed Solution

Implement hostname-based connections:

1. Always connect to hostnames (https://statsig.anthropic.com, https://api.anthropic.com)
2. Let HTTP client handle DNS resolution instead of pre-resolving to IPs
3. Ensure proper SNI headers with correct hostnames
4. Remove dependency on network-specific fallback mechanisms

This approach would:

• Provide consistent behavior across all networks
• Follow HTTPS best practices
• Eliminate network compatibility issues
• Improve overall reliability and security

Technical Evidence

DNS Resolution (consistent across networks):

nslookup statsig.anthropic.com
# Name: statsig.anthropic.com, Address: 34.36.57.103

nslookup api.anthropic.com  
# Name: api.anthropic.com, Address: 160.79.104.10

Certificate validation with SNI (works when hostname provided):

openssl s_client -connect 34.36.57.103:443 -servername statsig.anthropic.com
# ✅ Valid certificate for statsig.anthropic.com

openssl s_client -connect 34.36.57.103:443  # No SNI
# ❌ Certificate expired (wrong certificate served)

Severity: High - Network compatibility issue causing complete service failure on major mobile networks while appearing to work on others, indicating fundamental architectural problem with current connection approach.