In this article
An open port does not confirm model performance, and a closed route does not show that the GPU is inadequate. Verify each network hop independently.
If vLLM is unreachable through localhost, first establish where the client runs and where the server runs. 127.0.0.1 refers to the current network environment. A browser, a container and a remote host can therefore mean different machines when they use the same address.
Write down the connection path
Describe the route explicitly: browser on the laptop, host port, container port, then the vLLM process. If the client is another container, include it as a separate node. This often explains why a request to its own localhost never reaches the neighbouring service.
Save the requested URL, the place where the request runs and the expected destination. Avoid changing every firewall rule at once. The Docker deployment configuration and actual serve command are more reliable evidence than an assumed configuration file.
Confirm that the engine is ready
Read the startup log. A container can exist while the model downloads or compilation continues. A process that exited with OOM will not recover because a different port was published. Restarting too early can also begin normal preparation again.
Once ready, check HTTP from the nearest available environment, then request /v1/models and send a short generation request. Preserve the error type. A refused connection is different from an HTTP response reporting an invalid model name, even if both appear as a failed request in the application.
Check both sides of port publication
In -p 127.0.0.1:8000:8000, the first port belongs to the host and the second to the container. If the server listens on another internal port, publication must match it. External and internal numbers need not be identical, but their mapping must be recorded.
The process must also bind to an interface reachable through that route. Binding only to the container’s loopback can prevent traffic through a published port. Inspect the running command and log before changing the bind address.
Separate local testing from remote access
Publishing on the host’s loopback supports a local check. It does not promise access from another computer. A remote client needs its own agreed route and access controls; broadening the interface should be a deliberate decision.
Record three tests: next to the process, from the host and from the intended application. If the first two work, investigate the application’s base URL and endpoint while keeping the server unchanged. Preserve this working network diagram when changing engines or hardware, so a network regression is not mistaken for a compute problem.
Turn the check into a practical next step
An open port does not confirm model performance, and a closed route does not show that the GPU is inadequate. Verify each network hop independently.
For the documented details, consult the primary documentation; configuration reference. Continue with vllm health ready and runpod http port proxy.