Can't use IPv6 to connect to an IPv4-only server in the sandbox

[sirknigget]

Tested v0.33.0 and v0.34.0.
Port publishing doesn't work.
I tried restarting and also recreating the shell sandbox.

Any attempt to invoke
sbx ports <sandbox name> or sbx ports sbx ports <sandbox name> --publish 3000
either fails with:
ERROR: list published ports: runtime not found

Or reports success but ports aren't really published, attempting curl from host leads to:
curl: (56) Recv failure: Connection reset by peer

I have a simple HTTP server running on port 3000 inside the sandbox and curl inside it simply returns the 200 response.

It used to work in the past and a certain sbx upgrade destroyed this feature.

[robmry]

Hi @sirknigget - which address is the server inside the sandbox listening on?

I'm wondering if you're seeing this, https://docs.docker.com/ai/sandboxes/usage/#accessing-services-in-the-sandbox ...

For a service to be reachable, it must listen on all interfaces inside the sandbox, not only 127.0.0.1. Bind it to 0.0.0.0 for IPv4 or [::] for both IPv4 and IPv6; most dev servers need a flag like --host 0.0.0.0 to do this. On the host, --publish listens on both 127.0.0.1 and ::1, so a client resolving localhost might pick IPv6 and fail with "connection reset by peer" if the sandboxed service only listens on IPv4 — even when http://127.0.0.1:/ works. To fix that, bind the service to [::], or pin the published port to one family with --publish 8080:3000/tcp4 or /tcp6.

If it's not that - please could you run sbx diagnose --upload and send the id, I'll take a look at the logs.

[sirknigget]

Hi @sirknigget - which address is the server inside the sandbox listening on?

I'm wondering if you're seeing this, https://docs.docker.com/ai/sandboxes/usage/#accessing-services-in-the-sandbox ...

For a service to be reachable, it must listen on all interfaces inside the sandbox, not only 127.0.0.1. Bind it to 0.0.0.0 for IPv4 or [::] for both IPv4 and IPv6; most dev servers need a flag like --host 0.0.0.0 to do this. On the host, --publish listens on both 127.0.0.1 and ::1, so a client resolving localhost might pick IPv6 and fail with "connection reset by peer" if the sandboxed service only listens on IPv4 — even when http://127.0.0.1:/ works. To fix that, bind the service to [::], or pin the published port to one family with --publish 8080:3000/tcp4 or /tcp6.

If it's not that - please could you run sbx diagnose --upload and send the id, I'll take a look at the logs.

It works, but it's messy.
So now I need to find a way to bind every little thing I run to 0.0.0.0?
What If just download some open-source frontend project i need to examine and run, do I need to modify it to bind to 0.0.0.0? And also every kind of arbitrary dashboard or backend?

This is very bad UX.
I expect a fix to abstract and streamline this for developers.

[robmry]

So now I need to find a way to bind every little thing I run to 0.0.0.0?

Or, as the docs say, publish IPv4 only? --publish 8080:3000/tcp4

[sirknigget]

So now I need to find a way to bind every little thing I run to 0.0.0.0?

Or, as the docs say, publish IPv4 only? --publish 8080:3000/tcp4

Doesn't work. Tried using /tcp4.
Only binding to 0.0.0.0 solved it.

[robmry]

So, which address was the server listening to inside the sandbox? (The sandbox has its own 127.0.0.1, so listening there won't work.)

[sirknigget]

So, which address was the server listening to inside the sandbox? (The sandbox has its own 127.0.0.1, so listening there won't work.)

Normal tiny react app, served on localhost:some port.

curl from inside sbx - works
Publish the port + /tcp4 and curl from host - doesn't work
Serving explicitly with 0.0.0.0 as host - works

For UX I would expect the same publishing / port exposing that works on normal Docker - to work here seamlessly.

[robmry]

Ok, so which address are you listening on inside the sandbox? Or, which address do you "curl" inside the sandbox?

(Ports on 127.0.0.1 inside a Docker container can't be published either. The containerised application has to listen on a specific interface address, or 0.0.0.0/::.)

[sirknigget]

Ok, so which address are you listening on inside the sandbox? Or, which address do you "curl" inside the sandbox?

(Ports on 127.0.0.1 inside a Docker container can't be published either. The containerised application has to listen on a specific interface address, or 0.0.0.0/::.)

Localhost inside the sandbox. Curl inside the sandbox to localhost.

I'm not sure why you claim this about Docker, on a normal Docker i never needed to do this host binding.
When I have the time I will create an isolated teat and comparison for this.

[robmry]

I'm not sure why you claim this about Docker, on a normal Docker i never needed to do this host binding.

Maybe you used --network=host, so the container is sharing the host's networking stack? (That's not the default for a docker container, and it can't be used for sandboxes because it'd break the isolation.)

[sirknigget]

I'm not sure why you claim this about Docker, on a normal Docker i never needed to do this host binding.

Maybe you used --network=host, so the container is sharing the host's networking stack? (That's not the default for a docker container, and it can't be used for sandboxes because it'd break the isolation.)

Absolutely not, using default docker bridge network.

I will verify this by an isolated experiment later.

[sirknigget]

I'm not sure why you claim this about Docker, on a normal Docker i never needed to do this host binding.

Maybe you used --network=host, so the container is sharing the host's networking stack? (That's not the default for a docker container, and it can't be used for sandboxes because it'd break the isolation.)

OK, I verified this for real.
Binding to 0.0.0.0 is needed even on normal Docker, but some frameworks like Node simply default to that if nothing is provided at serving time.
Some frameworks don't default to that (example: vite), so in those cases it doesn't work by default.

Also - only publishing ports to /tcp4 for this simple services works, without it will fails as you mentioned.

So in regards to the need to bind to network interface 0.0.0.0 I take it back, seems like a standard requirement even in Docker.
For publishing specifically to /tcp4 I think it's bad UX, I don't need to do it in Docker and reaching that exact paragraph in the sbx docs in time consuming and not intuitive.

[robmry]

For publishing specifically to /tcp4 I think it's bad UX, I don't need to do it in Docker

You don't need to do it in Docker if the container is only connected to a single-stack docker network.

If the container's connected to a dual-stack network, it'll behave the same as the sandbox ... the sandbox's network is always dual-stack.

We could change the default protocol for bindings to "tcp4", but that'd surprise people by diverging from Docker's behaviour. We could try to detect whether a client is listening on the sandbox-side port for IPv4/IPv6 and only listen on the corresponding host port, but the listener may not be active all the time while the port is published, so we'd hit timing issues. We could receive traffic on either address family on the host, and try both families in the sandbox, but that may also be surprising.

So it's working as intended, the sandbox's behaviour is intentionally aligned with docker's, and it's documented.

But I agree it's difficult to work out what's happening (without resorting to reading documentation) when the sandbox is only listening on IPv4 and a client using "localhost" on the host hits the IPv6 dead-end.

[sirknigget]

For publishing specifically to /tcp4 I think it's bad UX, I don't need to do it in Docker

You don't need to do it in Docker if the container is only connected to a single-stack docker network.

If the container's connected to a dual-stack network, it'll behave the same as the sandbox ... the sandbox's network is always dual-stack.

We could change the default protocol for bindings to "tcp4", but that'd surprise people by diverging from Docker's behaviour. We could try to detect whether a client is listening on the sandbox-side port for IPv4/IPv6 and only listen on the corresponding host port, but the listener may not be active all the time while the port is published, so we'd hit timing issues. We could receive traffic on either address family on the host, and try both families in the sandbox, but that may also be surprising.

So it's working as intended, the sandbox's behaviour is intentionally aligned with docker's, and it's documented.

But I agree it's difficult to work out what's happening (without resorting to reading documentation) when the sandbox is only listening on IPv4 and a client using "localhost" on the host hits the IPv6 dead-end.

If you don't plan to change any behavior -
I think it would be great to display explicit warnings/errors somewhere during the publish process.
Example - if I run --publish 3000:3000 and the sandbox detects some service listening only on tcp4, display a warning that the publishing will lead to a dead end and suggest publishing with /tcp4. and vice versa.
Consider adding extended diagnostics in sbx ls so in addition to seeing published ports, we can also see listening ports in the sandbox and on which protocol.

Another thing - I am already letting my host-side agent read sbx docs and diagnose things using sbx CLI.
It would be nice to just auto-generate a common skill from all your docs so we don't have to scrape it every time / reinvent the wheel.