Cloudflare does not support port 3000 for incoming HTTP or HTTPS connections through its standard reverse proxy. If your application runs on port 3000, enabling Cloudflare's proxy will not make https://app.example.com:3000 accessible.
You can keep the application running on port 3000 without exposing that port to visitors. The solution is to accept public requests through a supported HTTPS port and forward them to the application using Nginx, a Cloudflare Origin Rule or Cloudflare Tunnel.
The correct method depends on whether your application accepts HTTP or HTTPS and whether Cloudflare can reach its hosting server.
Cloudflare Does Not Support Public Port 3000
Cloudflare's standard reverse proxy accepts HTTP and HTTPS connections on a defined set of ports. Port 3000 is not included, even though applications built with Node.js, Express and other frameworks commonly use it.
Cloudflare supports port 80 for standard HTTP traffic and port 443 for standard HTTPS traffic. It also supports several alternative ports, including 8080 for HTTP and 8443 for HTTPS but changing your application's port is not always necessary.
The important distinction is between the port used by the visitor and the port used by the application.
| Connection | Port | Result |
|---|---|---|
| Browser → Cloudflare | 3000 | Unsupported by the standard proxy |
| Browser → Cloudflare | 443 | Supported HTTPS connection |
| Cloudflare → Nginx | 443 | Supported origin HTTPS connection |
| Nginx → Local application | 3000 | Internal application connection |
For example, visitors can open https://app.example.com while the application continues listening on 127.0.0.1:3000. Nginx receives the HTTPS request and forwards it to the application internally.
This configuration works because visitors never connect to Cloudflare on port 3000.
Confirm That Your Application Works Locally
Before configuring the public connection, check whether the application responds on its existing port.
On the server running the application, execute:
curl -i http://127.0.0.1:3000/
An expected HTTP response indicates that the application is reachable at that address. Depending on its configuration, the response may contain a webpage, JSON data or an authentication redirect.
If the connection is refused, check whether the application is running and listening on port 3000. On Linux, the following command can help identify the listening process:
sudo ss -lntp
If port 3000 is missing, correct the application's startup or listening configuration before changing Cloudflare. A proxy cannot forward requests to a local service that is not accepting connections.
Route HTTPS Traffic to Port 3000 with Nginx
Nginx is a practical solution when your application runs on a VPS or another server that can accept public HTTPS connections.
Instead of asking Cloudflare to accept visitor requests on port 3000, Nginx handles HTTPS on port 443 and forwards requests to the local application.
For this example, assume the following configuration:
| Component | Address |
|---|---|
| Public hostname | https://app.example.com |
| Cloudflare proxy | Enabled |
| Origin HTTPS listener | Nginx on port 443 |
| Internal application | http://127.0.0.1:3000 |
This arrangement allows the application to keep its existing port while Nginx manages the connection arriving from Cloudflare.
Configure the Nginx Reverse Proxy
The following example assumes that Nginx is already installed and that the server has a suitable HTTPS certificate for app.example.com.
Add an HTTPS server block to the appropriate Nginx configuration:
server {
listen 443 ssl;
server_name app.example.com;
ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
The proxy_pass directive tells Nginx to send requests to the application listening on port 3000. Visitors continue using HTTPS while Nginx communicates with the application through its local HTTP connection.
The certificate paths are examples of a common Let's Encrypt installation. Use your server's actual certificate paths rather than assuming those files already exist.
Applications requiring WebSockets or particular proxy headers may need additional configuration. The example establishes the basic HTTP routing needed to resolve the port mismatch.
Apply the Configuration
After saving the Nginx configuration, check its syntax before applying the change:
sudo nginx -t
If the configuration is valid, reload Nginx:
sudo systemctl reload nginx
These commands apply to a Linux environment using systemd. If your server uses another service manager, use its corresponding commands.
In Cloudflare, confirm that the DNS record for app.example.com points to the correct server and remains Proxied. The origin must also accept Cloudflare's HTTPS connections on port 443.
Use Full (strict) SSL/TLS mode when the origin certificate satisfies Cloudflare's requirements. This keeps the connection between Cloudflare and Nginx encrypted and properly validated.
After the configuration is active, open https://app.example.com without appending :3000. The application should respond through Nginx while continuing to run internally on port 3000.
Use a Cloudflare Origin Rule for Port 3000
Cloudflare Origin Rules provide another way to reach an application running on a nonstandard port.
An Origin Rule can accept an HTTPS request on Cloudflare's supported public port 443 and change the destination port used to connect to your origin server.
For example, a visitor requests https://app.example.com but Cloudflare connects to your origin on port 3000.
The Origin Rule changes the destination port, not the public port. Visitors still access the application through the normal HTTPS hostname without specifying port 3000.
Configure the Destination Port
Open your Cloudflare dashboard and select the domain containing your application.
Follow these steps:
Navigate to Rules → Overview.
Select Create rule → Origin Rule.
Enter a name such as
App Port 3000.Under the matching conditions, select a custom filter expression.
Enter
http.host eq "app.example.com".Under Set origin parameters, enable Destination Port.
Select Rewrite to, enter
3000and deploy the rule.
The hostname's DNS record must be proxied for the Origin Rule to apply. Cloudflare supports destination-port overrides on Free, Pro, Business and Enterprise plans.
After deployment, Cloudflare uses the rewritten port when connecting to the matching origin. However, the origin must already be reachable on that port and support the connection protocol Cloudflare uses.
Confirm That Port 3000 Supports the Required Protocol
This is the most important limitation of using an Origin Rule.
Suppose your application listens at http://127.0.0.1:3000. That address accepts ordinary HTTP connections, not HTTPS.
If Cloudflare uses Full or Full (strict) encryption for an incoming HTTPS request, rewriting the destination port to 3000 does not convert the origin connection into HTTP. The destination must accept the HTTPS connection Cloudflare attempts to establish.
The configuration can therefore fail even though the Origin Rule matches correctly.
| Origin configuration | Expected suitability |
|---|---|
| Publicly reachable port 3000 with working HTTPS | Origin Rule can be suitable |
| Local HTTP-only application on port 3000 | Use a reverse proxy such as Nginx |
| Application reachable only inside a private network | Use Cloudflare Tunnel |
An Origin Rule also does not make a localhost address publicly reachable. Cloudflare needs a valid connection to the configured origin server, and 127.0.0.1 on your server is not an address Cloudflare can contact directly.
For a typical HTTP-only Node.js application running on localhost, Nginx is often the more straightforward solution. It handles the external HTTPS connection while forwarding traffic to the local application using HTTP.
An Origin Rule is more appropriate when the origin already supports the required protocol on the destination port.
Access Private Apps with Cloudflare Tunnel
If your application runs inside a private network and does not have a publicly reachable origin, Cloudflare Tunnel provides another way to publish it.
The cloudflared connector establishes an outbound connection to Cloudflare, so the application does not need a publicly exposed port.
A published application route can connect a hostname such as https://app.example.com to an internal service such as http://localhost:3000.
Visitors use HTTPS on the public hostname, while the connector delivers requests to the application's existing local port.
This resolves the port 3000 accessibility problem without configuring a public Nginx listener or exposing the application's port through router forwarding.
For an application that is already configured through Cloudflare Tunnel, check that its published route points to the correct internal service address. A working tunnel cannot deliver requests if its route references the wrong port or a service that has stopped running.
If your application runs on a private network, our guide to publishing an internal web app with Cloudflare Tunnel explains how to connect it to a public HTTPS hostname without opening inbound router ports.
Verify Cloudflare Connection to Your App
After configuring Nginx, an Origin Rule or Cloudflare Tunnel, test the application through its public hostname.
Do not include port 3000 in the browser URL. For example, use:
curl -i https://app.example.com/
An expected application response indicates that the request reached the intended service. Depending on the application, you may receive a successful page response, an authentication challenge or a redirect.
If the request still fails, the specific error can help identify which connection needs attention.
| Error or behavior | Likely cause | What to check |
|---|---|---|
Local port 3000 works but public :3000 fails | Unsupported Cloudflare proxy port | Use the public HTTPS hostname without port 3000 |
| Nginx returns 502 Bad Gateway | Nginx cannot reach the upstream application | proxy_pass address and port |
| Origin Rule matches but HTTPS fails | Destination does not support the required TLS connection | Origin protocol and certificate |
| Cloudflare Error 521 | Origin refuses the connection | Listener and firewall |
| Cloudflare Error 525 | TLS handshake with the origin fails | Origin HTTPS configuration |
| Application redirects to localhost | Incorrect application public URL | Base URL or redirect settings |
The most useful next check depends on which routing method you selected. Avoid changing unrelated Cloudflare settings when the error already identifies a likely connection problem.
Nginx Returns 502 Bad Gateway
A 502 response from Nginx commonly means it can not communicate successfully with the application configured as its upstream.
Test the address used in proxy_pass from the Nginx server. If the configuration contains http://127.0.0.1:3000, confirm that the application actually responds there.
If the application has moved to another port or machine, update the upstream address to its current destination. Test the Nginx configuration again before reloading the service.
Origin Rule Matches but App Fails to Load
If you use an Origin Rule, first verify that the hostname matches the rule's expression. Cloudflare Trace can help determine whether the request is matching the intended Origin Rule.
Next, confirm that the origin server accepts connections on port 3000 using the protocol required by its Cloudflare SSL/TLS mode. A port override cannot repair an unavailable origin service or make an HTTP-only listener accept HTTPS.
If the origin is reachable only through a private network, the Origin Rule is not sufficient by itself. That configuration requires an appropriate network connection, such as Cloudflare Tunnel, rather than another destination-port change.
App Loads but Redirects to Localhost
Some applications use a configured base URL when generating links, authentication callbacks and redirects.
For example, an application may load through https://app.example.com but redirect visitors to http://localhost:3000/login. The initial proxy connection worked but the application generated a URL intended for its local environment.
Check the application's public URL or base URL setting. Where supported, configure it to use https://app.example.com and test the affected redirect again.
This correction belongs to the application configuration rather than Cloudflare's port settings.
Keep Port 3000 Internal When Possible
Port 3000 can remain your application's listening port even when Cloudflare does not support it as a public proxy port.
For a conventional server running an HTTP-only application, Nginx can accept HTTPS traffic on port 443 and forward requests internally to port 3000. If the origin supports HTTPS on port 3000, an Origin Rule can change Cloudflare's destination port instead.
Cloudflare Tunnel is appropriate when the application runs on a private network and needs a public hostname without opening inbound ports.
The working configuration is confirmed when visitors can open the application's public HTTPS hostname without appending :3000 and the request reaches the correct application. The solution is to route traffic from a supported public port to the application's existing port, not to make Cloudflare's standard proxy accept port 3000 directly.
