How JD’s ‘localhost’ Tool Enables Seamless Remote Debugging of Local Code

Background and Pain Points

Developers often struggle with debugging code locally while needing to test it in a real remote environment, leading to repetitive build‑deploy‑test cycles and wasted time, especially when dealing with mobile device compatibility or backend API changes.

Idea Exploration

Inspired by a cloud‑native development talk, the author considered several approaches: direct code synchronization to remote containers, cloud IDEs, and existing proxy‑based solutions like Carefree, ultimately deciding that a simple, lightweight network‑tunneling tool would best address the need.

What Is “localhost”?

“localhost” is a minimal internal‑network‑penetration utility written in Go. It maps a service running on a developer’s local machine to a remote server, allowing remote clients to access the local service through an established tunnel. Go was chosen for its easy cross‑compilation and lack of runtime dependencies.

Usage

The tool is distributed as a single executable. It requires only two command‑line arguments:

# windows
localhost.exe -token xxxxxxxx -port xxxx
# mac
localhost -token xxxxxxxx -port xxxx

The -token identifies the user (valid for 30 minutes) and the -port specifies the local service port.

Architecture

The system consists of three components: a server side, a client side, and a web side. The server and client handle tunnel creation and data forwarding, while the web component provides APIs for client registration and reverse‑proxy routing.

Core Logic

When the client starts, it contacts the web service, which launches a corresponding server instance. The server opens two listening ports: one for incoming user requests and another for the client’s tunnel connection. Once the tunnel is established, any request arriving at the server is forwarded through the tunnel to the local service, and the response travels back the same way, making the local service appear as if it were hosted remotely.

Routing and Reverse Proxy

The web side records the user’s ERP identifier and creates a reverse‑proxy rule mapping the ERP to the server’s port. Subsequent requests matching the ERP (or the recorded IP) are routed to the appropriate client, enabling seamless access to static assets and supporting history‑mode routing.

Future Plans

Planned improvements include supporting HTTPS without manual configuration, handling history‑mode routing via wildcard domain resolution, and further simplifying the user experience.

Conclusion

The “localhost” tool demonstrates how a focused, Go‑based tunneling solution can dramatically reduce the friction of remote debugging, integrate smoothly with JD’s cloud‑testing platform, and evolve to meet broader development scenarios.