Direct HTTPS setup for ChatGPT
Set up RepoTunnel Direct HTTPS for ChatGPT local projects on Linux, with routing, hostname and TLS checks, screenshots, provider links and troubleshooting.
Guides follow the current project source. Check the release notes for your installed version.
Connect ChatGPT without a monthly tunnel quota
Use Direct HTTPS to connect ChatGPT Web to your approved local projects through your own running RepoTunnel endpoint. RepoTunnel adds no monthly tunnel request quota or connection-credit allowance to this connection.
This guide covers the network setup and verification. Keep RepoTunnel, the public route and the trusted HTTPS endpoint running while you work.
Choose the right network path
Direct HTTPS puts TLS on your RepoTunnel computer and requires a reachable public route. The documented Linux Mint path uses Route64 and WireGuard for public IPv6, DuckDNS for the hostname, an IPv4-to-IPv6 frontend when needed, and Let’s Encrypt for a trusted certificate.
If your ISP already provides usable public IPv6, you may be able to use that route instead of Route64. A router behind CGNAT cannot provide normal inbound public IPv4 simply by adding a forwarding rule.
The computer must stay powered on, connected to the internet and running RepoTunnel. Free-service availability and limits are controlled by their providers.
1 Check local requirements
Open HTTPS Setup in RepoTunnel. Its four stages are Local requirements, Internet connection, Choose a hostname and Finish Direct HTTPS. Start with the reported prerequisite checks.
On the documented Linux setup, check WireGuard tools, nftables, OpenSSL, certificate tooling and the system service manager. Use your distribution’s installation instructions for missing components and refresh the screen’s checks.
command -v wg
command -v wg-quick
command -v nft
command -v openssl2 Create the public IPv6 route
If using the documented Route64 path, open its Manager/Portal, create or sign in to your own account, and create a WireGuard tunnel. Choose an appropriate hub and obtain the generated configuration.
In RepoTunnel’s Internet connection stage, choose Import WireGuard config and use that configuration. The Linux helper can configure the WireGuard service and port redirect rules; inspect the local privileged prompt and the screen’s result.
Keep the generated address prefix, peer values and AllowedIPs as provided. WireGuard private keys belong only in the local configuration. If you configure Linux manually, use an interface name of at most 15 characters, such as rt-direct.
Route64’s public portal, captured 9 October 2026. The tunnel configuration is obtained inside your own account after signing in.
3 Verify routing and port redirects
Confirm that the tunnel interface is active and has the assigned global IPv6 address. For a manual setup using the example interface name rt-direct, the following commands inspect the service and route.
The documented public mappings are TCP 443 to RepoTunnel’s HTTPS listener on 43183, and TCP 80 to its ACME listener on 43184. The raw MCP origin on 127.0.0.1:43182 stays loopback-only.
systemctl is-active wg-quick@rt-direct
sudo wg show rt-direct
ip -6 addr show dev rt-direct
sudo nft list table inet repotunnel_directReplace rt-direct with your own configured interface name. These commands inspect the setup; the guided import is the setup action.
4 Create the DuckDNS hostname
Open DuckDNS and sign in using an available provider. Add your own unused subdomain and configure its IPv6/AAAA value to the globally routed IPv6 address from your tunnel or ISP.
Save the DNS configuration. Enter only your hostname, such as your-name.duckdns.org, in RepoTunnel’s Choose a hostname stage and select Verify hostname. The hostname input is not saved until you choose Configure Direct HTTPS.
DuckDNS’s signed-out page, captured 9 October 2026. Sign in to create and edit your own subdomain; account tokens are not shown here.
5 Check IPv4 compatibility
Some clients need an IPv4 route even when the computer’s origin is IPv6-only. The documented setup uses Netiter’s IPv4-to-IPv6 frontend alongside the hostname’s existing AAAA record.
Read the frontend’s current instructions and terms, then set the hostname’s A/IPv4 record to the address it currently publishes. Keep the AAAA record pointing to your real IPv6 origin. Re-run Verify hostname and inspect both IPv6 and IPv4 results.
Use the provider’s live address instead of copying a permanently hard-coded IP from an old screenshot. TLS still terminates on your RepoTunnel instance in this documented path.
6 Configure Direct HTTPS
- Return to HTTPS Setup and confirm the public route and hostname checks have passed.
- Choose Configure Direct HTTPS to save the selected hostname and start the local frontend.
- Inspect the HTTPS listener, redirect-rule checks and external reachability results.
- Copy the app’s endpoint only after the trusted HTTPS checks complete.
A self-signed test certificate confirms local TLS only. It does not establish a trusted remote MCP connection.
7 Obtain a trusted certificate
Once the public hostname resolves correctly and public TCP 80 reaches the ACME challenge listener, use Get trusted certificate in HTTPS Setup. RepoTunnel’s documented hostname setup performs HTTP-01 validation through public port 80 to local port 43184.
Check that TLS certificate becomes Trusted and the HTTPS listener is online. A validation failure needs investigation of DNS, routing, the public port 80 path or the current Certbot error before another attempt.
8 Test health and OAuth discovery
Replace your-name.duckdns.org with your own hostname. A health check should return a trusted HTTPS response from RepoTunnel. Check IPv4 and IPv6 separately when both are expected to work.
The two OAuth metadata responses must reference the same public hostname and MCP resource that your AI client uses. These requests inspect public discovery endpoints and contain no private token.
curl -4 -i https://your-name.duckdns.org/health
curl -6 -i https://your-name.duckdns.org/health
curl -sS https://your-name.duckdns.org/.well-known/oauth-protected-resource/mcp
curl -sS https://your-name.duckdns.org/.well-known/oauth-authorization-server9 Connect the AI client
Use the exact HTTPS MCP endpoint displayed by RepoTunnel, complete OAuth, discover tools and perform list_workspaces followed by a permitted project read. A responding /health route alone does not prove the authenticated workspace path.
After a reboot or network change
Keep the WireGuard service enabled according to the guided setup. After a reboot or Wi-Fi change, check the tunnel’s status, the app’s gateway/provider state and the public health response before asking the AI client to continue.
A stable hostname can remain the same while the local network changes, provided the public tunnel, DNS route and provider remain valid. The app’s checks are the evidence of recovery.
Fix the specific failed check
- No global IPv6: inspect the WireGuard import, service, assigned address and peer handshake.
- Missing IPv4 compatibility: follow the frontend instructions and recheck the hostname’s A record.
- Certificate validation failure: verify hostname DNS and the public port 80 → 43184 ACME path.
- TLS EOF or connection refused: inspect the route, redirects, frontend listener and certificate state.
- Host-header 403: inspect the reverse-proxy configuration; keep the loopback gateway’s Host validation enabled.
- No actions in the client: confirm OAuth metadata, finish authorization and refresh tool discovery.