# Expose a Pod HTTP service through Runpod Proxy

Publish a Runpod HTTP application using its internal port, a reachable bind address and the correct proxy URL, then verify route and authentication separately.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/runpod-http-port-proxy/
Language: en

Expose a Runpod HTTP service by adding its internal application port to the Pod configuration and using the corresponding HTTP proxy URL. The process must actually be running and normally bind to a reachable container interface such as `0.0.0.0`. The SSH port from Connect is a different parameter.

## Understand the proxy address

The documented pattern is `https://POD_ID-PORT.proxy.runpod.net`, where PORT is the internal HTTP service port. Direct TCP access instead uses an external mapped port. Keep the service, internal listener and publication method together in the project notes.

If several interfaces run in one container, identify each route and its protection separately. A familiar hostname does not show which process is behind it or whether the application has the intended access control.

## Check the process before the route

Read the startup log and make a local HTTP request inside the Pod. A missing configuration file, failed dependency or exited application is not repaired by changing cloud port settings.

If the local service answers, inspect its bind address. A process restricted to the container's loopback may work internally but not through the external proxy. A loopback binding can be deliberate for SSH tunnelling, so select the configuration for the intended route rather than copying it between methods blindly.

## Test a small results dashboard

Suppose a team uses internal port `8080` for a metrics viewer. It first verifies a simple response without working data, publishes the port, and checks the current Pod's proxy URL. After replacement, that URL must be verified again.

Then test the real application and authentication separately. A working HTTPS page confirms transport, not permission to reveal private results. Preserve the startup command without secrets, the expected listener and the method of authenticating users.

## Distinguish the access mechanisms

| Method | What the client uses | What must exist inside |
| --- | --- | --- |
| HTTP proxy | URL with Pod ID and HTTP port | Running HTTP application |
| Direct TCP | Public IP and mapped external port | Service on its internal port |
| SSH tunnel | Local computer address | Suitable SSH and destination service |

For long operations, check proxy limits and client disconnect behaviour. The task should preserve its necessary state independently of one browser tab. If the route fails after a pause, check Pod state and the service before changing the network. A small route test keeps infrastructure diagnosis separate from a complex interface failure.

## Turn the check into a practical next step

Exposing a port creates a route to a process; it does not start that process or configure authentication. Verify the service before testing its external URL.

For the documented details, consult the [primary documentation](https://docs.runpod.io/pods/configuration/expose-ports); [configuration reference](https://docs.runpod.io/pods/configuration/use-ssh). Continue with [runpod private port forward](/journal/runpod-private-port-forward/) and [runpod jupyter files persistence](/journal/runpod-jupyter-files-persistence/).