Endpoint protection
Protect a shared localhost URL with authentication and access rules
Use Free Basic Auth or Plus/Pro Bearer, IP and country policies to protect development tunnels, and verify that denied requests do not reach localhost.
Written and reviewed by: ProxlaneOperated by CloudruUpdated:
Basic Auth
Free / Plus / Pro
Bearer
Plus / Pro
IP and country rules
Reserved Plus / Pro endpoints
Before you start
Install and authenticate the CLI
Install the Windows or Linux CLI, run proxlane login as the same OS user, and approve the device in your browser. Start the local service you want to publish.
Read the installation guideChoose who needs access
Decide whether your caller can send Basic Auth or Bearer credentials. Webhook providers may require their own signature verification instead. Create real passwords privately in your terminal or Dashboard; the examples use placeholders.
Step by step
- 01
Add Basic Auth for a local HTTP app
Replace the placeholder with your own username and password before running this command in your terminal. Free supports Basic Auth. Avoid placing real secrets in shared scripts, screenshots, chat, or shell history where possible.
proxlane http --basic-auth 'user:REPLACE_WITH_PRIVATE_PASSWORD' 3000 - 02
Or use Bearer on Plus or Pro
Choose Bearer instead of Basic Auth when the caller supports it. They cannot be enabled together. Keep the token private and supply it through the caller's secure configuration.
proxlane http --bearer REPLACE_WITH_PRIVATE_TOKEN 3000 - 03
Save policies for a reserved endpoint
On Plus or Pro, open Dashboard → Endpoints and select the reserved HTTP endpoint. Save Basic Auth or Bearer there to reuse it without putting the endpoint secret into an AI conversation. IP/CIDR and country policies also apply to reserved TCP/UDP endpoints.
- 04
Test allowed and denied requests
Check the public URL without credentials first, then with the intended caller's credentials. Confirm rejected traffic in Logs or Safety and verify the local app only receives allowed requests.
Understand HTTP authentication behavior
The relay validates Basic Auth or Bearer before forwarding to localhost. After successful endpoint authentication, its Authorization header is not forwarded to your local service. If your application also needs that header, account for this behavior before enabling relay authentication. Basic Auth and Bearer protect HTTP tunnels, not arbitrary TCP or UDP.
Use IP and country rules deliberately
Reserved Plus/Pro HTTP, TCP, and UDP endpoints offer unrestricted, allow-listed, or block-listed modes for IP/CIDR and country separately. Both conditions must pass. Unknown countries are denied in country allow mode and pass country block mode. Switching modes clears the previous list.
- Saved IP and country changes normally apply to new traffic within seconds, without a tunnel restart.
- Existing TCP connections remain open. Saved Basic Auth and Bearer changes apply on the next tunnel start.
- VPN, public proxy, and Tor blocking matches known source IPs; it is best-effort and does not detect every VPN.
Keep application checks enabled
A tunnel policy does not replace application authorization or webhook signatures. Some providers cannot send Basic Auth credentials, so placing Basic Auth in front of them can prevent delivery. Verify the provider's signed payload in your handler and avoid sharing sensitive local services unnecessarily.
Troubleshooting
Webhook requests receive 401
Confirm the provider can send the configured credentials. If it cannot, use its application-level signature verification and any compatible source restrictions.
A policy change seems delayed
Restart the tunnel after changing saved Basic Auth or Bearer. IP/country changes apply to new traffic; an existing TCP connection is not disconnected by the update.
An allowed address is blocked
Check the caller's public IPv4/IPv6 address, CIDR, and country conditions. Both IP and country policies must pass, and a country allowlist rejects unclassified addresses.
Frequently asked questions
Is an unguessable random URL authentication?
No. Anyone who learns a reachable URL can connect unless your tunnel or application enforces access control.
Can I share a tunnel through MCP without putting a secret in chat?
Yes. Set a policy on a reserved HTTP endpoint in the Dashboard, then request that hostname through MCP. If you use a CLI-protected profile instead, manage it with MCP status/verify/stop and do not republish it without its protection settings.
Proxlane