This is one of those cases where “same region” doesn’t mean “same network path / same public egress identity.”

Even if prod + dev are in us-east4-eqdc4a, they can still end up with different outbound (egress) IPs and sometimes even different routing depending on which host the workload gets scheduled on. Railway’s egress IPs are dynamic by default.

So the most common explanation for prod can reach your n8n, dev gets ETIMEDOUT is:

1) Your n8n side is allowing prod’s egress IP, but not dev’s

This happens when n8n is behind:

• firewall / security group allowlist

• Cloudflare/WAF rules

• provider-level IP reputation blocks

Quick proof test: from each environment, hit an IP echo endpoint and compare results:

• curl https://api.ipify.org

• or log outbound IP via any “what’s my IP” service

If the IPs differ (they usually will), that’s your answer.

If you need a consistent outbound IP for allowlisting, Railway only offers Static Outbound IPs on the Pro plan.

2) DNS / IPv6 edge case (less common, but real)

Railway does not support outbound IPv6 right now. If your dev environment resolves the target to an AAAA record first (or prefers IPv6) and your code/client doesn’t properly fall back, you can see failures. Railway notes IPv6 outbound isn’t supported.

Check: log the resolved IP your app is connecting to, or try forcing IPv4:

• curl -4 https://your-n8n-host/...

3) A routing / transient network issue in the region

This is rarer, but it happens (and you’ll see it as intermittent timeouts). A good tell is: dev can’t reach any external host, not just n8n.

Check: from dev, test 2–3 unrelated hosts:

• curl -I https://example.com

• curl https://api.ipify.org

• curl -I https://cloudflare.com

If those work but n8n doesn’t, it’s almost certainly n8n-side allowlisting / WAF.

What I’d do next (fastest path)

1. Run the “what’s my IP” test from prod and dev and compare.

2. If n8n is protected, temporarily allowlist dev’s IP (or disable the rule briefly to confirm).

3. If you need stable allowlisting long-term: Static Outbound IPs (Pro) is the clean fix.

4. If you find dev is trying IPv6 first, force IPv4 and/or adjust DNS resolution preference.

If you paste:

• the hostname you’re calling (domain only is fine), and

• the result of curl https://api.ipify.org from both envs (prod/dev),
  I can tell you which bucket this falls into immediately.

try using the public url of your n8n instance in your development environment variables.