2 months ago
I had a lot of trouble for the past days in our boocs / dev (and the resulting preview environments).
It seems to be some kind of networking issue?
When I set S2_BASIN_ENDPOINT to http://${{8042e8af-242d-4835-b201-3b8e2e1346b3.RAILWAY%5FPRIVATE%5FDOMAIN}}:80 it resolves to http://s2.railway.internal:80 but is not reachable (see the attachment).
After I set public networking on s2-dev:
shortline.proxy.rlwy.net:24334 to port :80
and change the S2_BASIN_ENDPOINT to shortline.proxy.rlwy.net:24334 it works.
I think this is some kind of internal networking issue. Our dev-environment is also having this trouble on the service 67e68b8e-cf2c-40b9-93de-4c3cc784bcd8 (s2-basin-creator) which is failing to connect to an s2-dev there.
I could not find any other way to fix this than to set public networking on the service.
Attachments
6 Replies
2 months ago
I tried some more debugging and found this:
❯ await fetch("http://s2.railway.internal:80")
error: Unable to connect. Is the computer able to access the url?
path: "http://s2.railway.internal/",
errno: 0,
code: "ConnectionRefused"
❯ await fetch("http://shortline.proxy.rlwy.net:24334")
Response (0 KB) {
ok: false,
url: "http://shortline.proxy.rlwy.net:24334/",
status: 404,
statusText: "Not Found",
headers: Headers {
"vary": "origin, access-control-request-method, access-control-request-headers",
"access-control-allow-credentials": "true",
"content-length": "0",
"date": "Wed, 18 Mar 2026 23:06:39 GMT",
},
redirected: false,
bodyUsed: false,
Blob (0 KB)
In combination with the screenshot, this does not make any sense since it should both be the same?
Attachments
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open brody • 2 months ago
2 months ago
Can it be, that is has something todo with one environment being on IPv6 and the other one on IPv4?
It works on the one on IPv4:
❯ dns = await import('dns'); console.log(await dns.promises.lookup('s2.railway.internal'))
{
address: "10.196.138.196",
family: 4,
}
undefined
❯ await fetch("http://s2.railway.internal:80")
Response (0 KB) {
ok: false,
url: "http://s2.railway.internal/",
status: 404,
statusText: "Not Found",
headers: Headers {
"vary": "origin, access-control-request-method, access-control-request-headers",
"access-control-allow-credentials": "true",
"content-length": "0",
"date": "Wed, 18 Mar 2026 23:15:24 GMT",
},
redirected: false,
bodyUsed: false,
Blob (0 KB)
On the IPv6-Env it fails:
❯ dns = await import('dns'); console.log(await dns.promises.lookup('s2.railway.internal'))
{
address: "fd12:d4c2:e018:0:1000:85:673a:e37c",
family: 6,
}
undefined
❯ await fetch("http://s2.railway.internal")
error: Unable to connect. Is the computer able to access the url?
path: "http://s2.railway.internal/",
errno: 0,
code: "ConnectionRefused"
2 months ago
Hello,
so when s2.railway.internal resolves to ipv4 it connects fine, but when it resolves to ipv6 you get connectionrefused. the railway ui also shows ipv6 next to the private domain. so the private networking is giving you an ipv6 address but something is breaking the connection on that path. what address and port is your s2 service actually binding to when it starts up?
2 months ago
I figured it out: It is a bug in the "IPv6 Egress" feature flag. Disabling this re-enables IPv4 connectivity to other services within the project.
I had the IPv6-Egress disabled in the service, however. This seems to also apply to local-connections which is unexpected.
I donot think this is a public discussable topic but rather should be treated as a bug report for the "IPv6 Egress" feature, @brody.
niklasdah
I figured it out: It is a bug in the "IPv6 Egress" feature flag. Disabling this re-enables IPv4 connectivity to other services within the project. I had the IPv6-Egress disabled in the service, however. This seems to also apply to local-connections which is unexpected. I donot think this is a public discussable topic but rather should be treated as a bug report for the "IPv6 Egress" feature, @brody.
2 months ago
yes i think this looks like something railway needs to fix or at least clarify on their end since private networking should just work internally regardless of ipv4/ipv6 , correct me if i'm wrong ?
Status changed to Open sam-a • 2 months ago
Status changed to Solved sam-a • 2 months ago