High latency from Linux machine to Docker services via docker.orb.internal

[W-guofeng]

Describe the bug

I am seeing intermittent high latency when an OrbStack Linux machine accesses services running in OrbStack Docker on the macOS host through docker.orb.internal.

My local development app runs inside an OrbStack Ubuntu Linux machine. MySQL and Redis run as Docker containers managed by OrbStack on the macOS host. The app connects to both services using docker.orb.internal.

After the Mac has been running for a while, simple DB/Redis round trips from the Linux machine become very slow and all Laravel/PHP requests that touch DB/Redis become slow. Restarting the Mac used to restore normal performance. Restarting OrbStack improves the situation, but the latency can remain variable.

Observed symptoms:

• A simple app health endpoint that only returns ok can take around 1.5s to 2.7s from inside the Linux machine.
• A cart/API endpoint that uses Redis/MySQL can take around 2s to 4s.
• Redis PING through Laravel's Redis connection can repeatedly take around 200ms.
• MySQL select 1 through Laravel's DB connection can repeatedly take around 400ms before the connection warms up.
• TCP connect to docker.orb.internal:3306 and docker.orb.internal:6379 is sub-millisecond, so the delay appears to be in protocol round trips over the Linux-machine-to-host-Docker path rather than DNS or TCP connection setup.

This looks like an intermittent performance degradation in the path from an OrbStack Linux machine to Docker published ports on the host via docker.orb.internal.

To Reproduce

1. Start MySQL and Redis as OrbStack Docker containers on macOS.
2. Start an OrbStack Ubuntu Linux machine.
3. In the Linux machine, run a PHP/Laravel app or any client that connects to MySQL/Redis via docker.orb.internal.
4. Measure repeated DB/Redis round trips from the Linux machine.
5. After the Mac/OrbStack has been running for a while, observe that protocol round trips can become very slow.

Example measurements from the Linux machine:

OrbStack: 2.2.1 (2020100)
OrbStack commit: 0e182b501fcd9e05b99ffb363fce03610390c400
Linux machine: Ubuntu 24.04.3 LTS
Kernel: 7.0.11-orbstack-00360-gc9bc4d96ac70 aarch64

App config:
DB host: docker.orb.internal
Redis host: docker.orb.internal
Cache/session/queue: Redis

Before restarting OrbStack:
GET /api/store/cart     total ~= 2.17s - 3.82s
GET /api/store/health   total ~= 1.42s - 2.77s
Redis PING              often ~= 208ms
MySQL select 1          often ~= 416ms

After restarting OrbStack:
GET /api/store/cart     initially ~= 1.65s, later sometimes ~= 0.50s
GET /api/store/health   initially ~= 1.65s, later sometimes ~= 0.50s
Redis PING              still sometimes ~= 200ms
MySQL select 1          still sometimes shows 200ms/400ms steps before warming up

TCP connect checks:
docker.orb.internal:3306    < 1ms
docker.orb.internal:6379    < 1ms

Expected behavior

Accessing Docker services through docker.orb.internal from an OrbStack Linux machine should have stable low latency. Simple Redis/MySQL protocol round trips should not regularly take 200ms to 400ms when TCP connection setup is sub-millisecond.

Diagnostic report (REQUIRED)

I can provide an OrbStack diagnostic report if needed. I did not include it here yet because it may contain private local environment details.

Screenshots and additional context (optional)

This may be related to other reports about OrbStack networking degradation or high network latency, but this case specifically involves:

• Linux machine -> docker.orb.internal -> Docker containers on macOS host
• MySQL and Redis protocol round trips
• Performance improving after restarting OrbStack or the Mac

[W-guofeng]

Additional observation after filing the issue:

The problem reappeared shortly after restarting OrbStack. This makes it look less like a one-time cold-start effect and more like the docker.orb.internal path degrading again after OrbStack has been running for a short while.

Fresh measurements from the same Linux machine:

GET /api/store/cart
  code=200 dns=0.000014 connect=0.000123 start=2.363149 total=2.363221

GET /api/store/health
  code=200 dns=0.000029 connect=0.000070 start=0.563218 total=0.563260

MySQL select 1, same Laravel DB connection:
  [448.7, 418.9, 412.7, 415.2, 416.0, 416.3, 416.1, 0.3] ms

Redis PING, same Laravel Redis cache connection:
  [225.4, 0.2, 208.6, 214.5, 208.6, 210.2, 206.1, 210.6] ms

So the latency is visible again at the MySQL/Redis protocol round-trip layer while TCP connect time remains tiny.