Skip to content

Conversation

@craigvandotcom
Copy link

Problem

When using self-hosted Happy Server instances accessible via Tailscale or local networks, the iOS app fails to connect with "failed to connect" errors, even though the server is accessible in Safari and other browsers.

This occurs because iOS App Transport Security (ATS) blocks HTTP connections to local network IP addresses by default, including:

  • RFC1918 private IPs (10.x.x.x, 172.16.x.x, 192.168.x.x)
  • Tailscale CGNAT range (100.64.0.0/10)

Solution

Add NSAllowsLocalNetworking: true to the iOS App Transport Security configuration in app.config.js.

This is the official Apple-recommended approach for apps that need to communicate with local network servers over HTTP.

Changes

  • Added NSAppTransportSecurity configuration with:
    • NSAllowsLocalNetworking: true - Allows HTTP to local networks
    • NSAllowsArbitraryLoads: false - Maintains security by still requiring HTTPS for public internet

Security

This change maintains security by:

  • Only allowing HTTP for local network addresses
  • Still requiring HTTPS for all public internet connections
  • Following Apple's documented best practices for local network communication

Testing

Tested with self-hosted Happy Server on:

  • ✅ Local WiFi (192.168.x.x)
  • ✅ Tailscale (100.x.x.x)
  • ✅ Localhost (127.0.0.1)

Fixes #319

Add NSAllowsLocalNetworking to iOS App Transport Security configuration.
This allows the Happy iOS app to make HTTP connections to:
- RFC1918 private IP ranges (10.x.x.x, 172.16.x.x, 192.168.x.x)
- Tailscale IPs (100.64.0.0/10 CGNAT range)
- Other local network addresses

Previously, iOS App Transport Security would block HTTP connections to
these local network IPs, preventing users from connecting to self-hosted
Happy Server instances over Tailscale or local networks.

This change maintains security by keeping NSAllowsArbitraryLoads set to
false, only allowing local networking while still requiring HTTPS for
public internet connections.

Fixes slopus#319
@mike2153
Copy link

mike2153 commented Jan 2, 2026

Sorry but this has been quoted as a fix for launching the CLI tool resulting in a 404. I don't believe this would fix that unless I am mistaken. The cli issue is connecting to the happy server?

@AventusM
Copy link

AventusM commented Jan 2, 2026

Sorry but this has been quoted as a fix for launching the CLI tool resulting in a 404. I don't believe this would fix that unless I am mistaken. The cli issue is connecting to the happy server?

Would think so since my attempts to set up self hosted version fails due to this. Perhaps they have similar on their end.

@craigvandotcom
Copy link
Author

craigvandotcom commented Jan 2, 2026 via email

@mikeyward
Copy link

Were you able to work around it? I encountered the same issue (self-hosted Happy server, connecting over tailscale), and when I encountered the error, I set it up to operate via SSH, to dodge the iOS ATS issue, but am still experiencing silent failures. It seems like the authentication links / qr codes are not respecting the custom server and directing straight to the Happy cloud version.

@craigvandotcom
Copy link
Author

craigvandotcom commented Jan 6, 2026 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Error: Request failed with status code 404

5 participants