The Problem
X-Plane 12 ships with a built-in WebSocket server at /api/v3. It's the modern way to read datarefs and send commands — fast, event-driven, and well documented. There's just one catch: it only binds to 127.0.0.1.
That means if your cockpit software — a hardware bridge, an EFB app, a logging tool, anything — runs on a different machine than X-Plane, it simply cannot reach the API. No setting to change, no config file to edit. It's localhost-only by design.
For a single-PC setup this is fine. But a lot of home cockpit builders run their simulator on a dedicated SimPC and their hardware controllers, displays, and bridge software on separate machines. In that setup you're stuck.
The Solution
We built xplane-proxy: a small, standalone Node.js utility that runs on the same machine as X-Plane and re-exposes both the WebSocket API and the HTTP REST API (/api/v1/datarefs) on 0.0.0.0 — so any machine on your local network can connect as if it were localhost.
No installation required. Download a single binary for your platform, run it, and point your bridge at the proxy's IP and port instead of X-Plane directly.
[2026-05-29T10:00:00.000Z] X-Plane proxy listening on 0.0.0.0:8087
[2026-05-29T10:00:00.000Z] Forwarding to X-Plane at 127.0.0.1:8086
[2026-05-29T10:00:01.200Z] Client connected — opening ws://127.0.0.1:8086/api/v3
[2026-05-29T10:00:01.215Z] X-Plane WebSocket connected
[2026-05-29T10:00:01.220Z] → X-Plane: dataref_subscribe_values — 3 dataref(s) [1042, 1043, 1107]
[2026-05-29T10:00:01.250Z] → Client: dataref_update_values (3 key(s))
What It Proxies
WebSocket — Every path is forwarded. Each incoming client gets its own dedicated upstream connection to X-Plane, so multiple clients work independently. One subtle detail: a client's WebSocket open event fires as soon as the proxy accepts the upgrade — before the proxy has finished its own handshake with X-Plane. The proxy buffers any messages that arrive during that gap and flushes them the moment X-Plane's connection is ready, so subscriptions are never silently dropped.
HTTP — All requests are forwarded transparently. This covers REST API calls like dataref ID lookups (/api/v1/datarefs), which CockpitConnect uses to resolve dataref names to numeric IDs before subscribing.
Why We Open-Sourced It
xplane-proxy has no CockpitConnect-specific logic. It's a generic network proxy for X-Plane's API — useful to anyone building tools that talk to X-Plane from a remote machine. Keeping it inside the CockpitConnect codebase would have been selfish, and the flight simulation community has a long tradition of sharing tools openly.
It's published on GitHub under the MIT license. Single-file prebuilt binaries for Windows, Linux x64, and Linux ARM64 are on the Releases page — no Node.js installation needed.
Getting Started
Download the binary for your platform, run it on the X-Plane machine, and you're done.
Windows (PowerShell)
.\xplane-proxy-win-x64.exe
Linux
chmod +x xplane-proxy-linux-x64
./xplane-proxy-linux-x64
The proxy listens on port 8087 by default and forwards to X-Plane on 8086. Both are configurable via environment variables (XPLANE_HOST, XPLANE_PORT, PROXY_PORT) if you need non-standard ports.
For CockpitConnect Users
If your bridge runs on a different machine than X-Plane, set the X-Plane WebSocket Host in CockpitConnect's settings to your SimPC's local IP address (e.g. 192.168.1.110) and the port to 8087. That's it — the proxy handles the rest.
The proxy also gives you visibility into what's being sent: you can see every dataref subscription and command that flows between the bridge and X-Plane, which makes diagnosing issues considerably easier.
Source Code
The full source is on GitHub: github.com/cockpitconnect/xplane-proxy. Contributions and issues welcome.