Share a local PHP application without configuring router port forwarding
A WAMP environment lets you run Apache, PHP, and a database locally on Windows. When a client, teammate, webhook provider, or test device needs to reach that application from outside your network, Localtonet can publish the local web service through an outbound tunnel. This guide explains how to verify the local WAMP site, account for Apache virtual hosts, create an HTTP tunnel, and reduce the risks associated with making a development application publicly reachable.
What WAMP and Localtonet do
WAMP commonly refers to a Windows development stack containing Apache, a MySQL-compatible database, and PHP. Wampserver is one established Windows distribution of that stack. Wamp.NET is a separate project with its own package manager, site configuration, and documentation, so instructions written for one product should not automatically be applied to the other. Confirm which distribution you installed before following product-specific menu paths.
Localtonet does not replace Apache, PHP, or the database. The WAMP site must already work locally. The Localtonet client running on the Windows machine establishes an outbound connection to a Localtonet relay server. An HTTP tunnel then maps a public address to the local IP address and port where Apache is listening. This avoids inbound router port forwarding, firewall changes, VPN setup, and the need for a public IP address.
Authenticating the Localtonet client identifies the device, but it does not publish WAMP by itself. You must create an HTTP tunnel for the correct local target and then press Start. The public endpoint is available only while the selected device is connected and the tunnel is running.
Prepare the local WAMP application
Download your chosen WAMP distribution from its official site and follow that distribution's installation documentation. Start Apache and any database service required by the application. Database access normally remains internal to the PHP application and does not need a separate public tunnel for ordinary browser testing.
Before configuring Localtonet, open the application from a browser on the Windows machine. Depending on the Apache configuration, the address may be http://127.0.0.1, http://localhost, or the same address followed by a nondefault port. If the page does not load locally, correct the Apache, PHP, application, or port configuration first. A tunnel cannot repair a local service that is stopped or listening on a different port.
Understand Apache virtual hosts
Apache can select a site by examining the HTTP Host header. A name-based virtual host may therefore work at a local name such as project.test but return the wrong site when a request arrives with the public tunnel host name. This is not a Localtonet connectivity failure. It means Apache's virtual-host matching rules did not select the intended site.
The simplest test is to publish a site that Apache already serves as its default virtual host. If the application must use a named virtual host, consult the current Localtonet HTTP tunnel interface and documentation for host-header handling. Some client or dashboard versions have displayed a Rewrite Host Header option. If that option is present in your current tunnel settings, its value must exactly match the Apache virtual host's configured server name. Do not assume that an older screenshot represents the current interface or that the option is available on every version or plan.
| Local behavior | Likely configuration | What to check |
|---|---|---|
| The site opens at 127.0.0.1 | Default site or default virtual host | Use the verified local IP address and Apache port as the tunnel target. |
| The site opens only at a custom local name | Name-based Apache virtual host | Check Apache's ServerName and current Localtonet host-header options. |
| The wrong WAMP site appears publicly | Apache selected another virtual host | Review virtual-host order, server names, and the request host sent through the tunnel. |
| No local page opens | Apache is stopped, blocked, or listening elsewhere | Fix local access before changing the tunnel configuration. |
Configure remote WAMP access with Localtonet
Install and run the Localtonet client
Install the Localtonet application on the Windows machine that runs WAMP, or on another device that can reach the WAMP service over the local network. Keep the WAMP application running while testing the tunnel.
Authenticate and select the device
Use the device-specific authentication token through the supported Localtonet client or dashboard workflow. Treat the token as a credential. Do not place it in screenshots, source code, public repositories, support posts, or the web application's files.
Select an available relay server
Choose from the servers or regions currently offered in your dashboard. Available server codes and regions can change, so do not copy a hardcoded value from an old tutorial.
Create an HTTP tunnel
Create an HTTP tunnel and set its local target to the verified WAMP address and port. A common target is 127.0.0.1 on port 80, but use those values only if the application actually works there. HTTP tunnels can provide a generated subdomain, a selected subdomain where supported, or a custom domain, depending on the current configuration and availability.
Start the tunnel
Press Start after reviewing the target. Creating the tunnel does not start it automatically. Wait for both the Localtonet device and tunnel to show that they are connected before testing the public address.
Test and stop access when finished
Open the assigned public URL from a device outside the local network, such as a phone using mobile data. Verify the intended application, authentication flow, static files, and framework-generated links. Stop or delete the tunnel when remote access is no longer required.
For the current product workflow and field names, consult the Localtonet HTTP tunnel documentation. The public endpoint depends on the client remaining connected and the selected tunnel remaining active.
Secure the application before sharing it
Do not expose a WAMP development environment merely because it works locally. Require authentication in the application, use strong unique credentials, remove default accounts, protect sensitive routes, and expose only the service needed for the test. Localtonet connectivity is not a substitute for application authorization or secure coding.
Development systems often reveal more information than production systems. PHP error pages can disclose file paths, source locations, configuration values, database details, and framework internals. Disable public debugging output before sharing the URL. Keep secrets outside the document root, review environment files, and ensure directory listings and backup files are not unintentionally available.
Avoid publishing phpMyAdmin or another database administration interface unless there is a specific, controlled requirement. A browser-accessible database manager is a high-value target. In most WAMP testing workflows, only the PHP application needs to be reachable. Apache, PHP, the application framework, dependencies, and the WAMP distribution should also be kept current with supported security updates.
Test authorization from a private browser window rather than relying on an existing administrator session. If the application accepts file uploads, webhooks, or user-controlled input, validate those paths carefully. Use test data rather than production customer data, and remove the public endpoint as soon as the external test is complete.
Troubleshooting common problems
The public URL returns a connection error
Confirm that Apache is running, the application loads locally, the Localtonet client is connected, and the tunnel has been started. Recheck the target port rather than assuming Apache uses port 80. Security software may also prevent Apache from accepting the local connection, so verify the service directly on the same device first.
The WAMP landing page appears instead of the application
Apache is probably selecting its default site instead of the intended virtual host. Review the site's ServerName, virtual-host order, document root, and any current host-header rewrite setting. A DNS name entered into WAMP is not automatically recognized by requests sent to a different public host name.
Pages load but links or redirects use localhost
The application may have a hardcoded base URL or may generate absolute links from local configuration. Update the application's documented external URL setting for the test, or use relative links where appropriate. Do not globally replace addresses in the database without first understanding the framework's configuration and serialization behavior.
Images, scripts, or styles fail to load
Inspect the browser's developer tools for requests sent to localhost, a custom local virtual-host name, an incorrect port, or an unavailable HTTP address. Correct the application's base URL and trusted-host configuration according to the framework's own documentation.
Frequently asked questions
Do I need to configure router port forwarding?
No. The Localtonet client establishes an outbound connection to a relay server, so this workflow does not require an inbound router port-forwarding rule or a public IP address.
Must WAMP use port 80?
No. Port 80 is common for local HTTP, but Apache may use another port because of configuration choices or a conflict with another service. Set the tunnel target to the port that successfully serves the application locally.
Why does my Apache virtual host show the wrong site?
Apache may be choosing a site according to the request's Host header. Check the virtual host's server name and the host-header behavior available in the current Localtonet HTTP tunnel configuration.
Does authenticating the Localtonet client immediately expose WAMP?
No. Authentication identifies the device. You must also create an HTTP tunnel with the correct local target and press Start. The tunnel remains available only while the device is connected and the tunnel is running.
Is Wamp.NET the same product as Wampserver?
No. They are separate Windows web-development products with different interfaces and configuration workflows. Use the official documentation for the distribution actually installed on your computer.
Should I leave the tunnel running permanently?
Leave it running only for as long as the application needs to be reachable. For temporary review, demonstrations, or webhook tests, stop or delete the tunnel afterward to remove the public path to the local service.
Publish your local WAMP application carefully
Verify the site locally, secure the application, create an HTTP tunnel for the correct Apache port, and stop the tunnel when the remote test is complete.
Get Started Free →
