Docs

Troubleshooting

Find the message you see, learn what it means, and fix it. Start with the source IP check from the quickstart: it tells you whether the problem is your setup, your allowlist or the destination.

Proxy errors
WireGuard problems
The destination sees a different address
MTU and MSS
DNS
What to send support

Proxy errors

What you see	What it means	What to do
`CONNECT tunnel failed, response 407`	The proxy did not accept the login: missing, wrong or rotated	Check the username and password of this endpoint (on Pro each address has its own login) and that the secret has no stray space or line break. If the password has special characters, percent-encode it inside a URL. If you rotated it, use the new one. Do not retry in a loop
`CONNECT tunnel failed, response 403`	The destination or port is not on your allowlist, or is never allowed	Compare the host name and the port with your allowlist, character by character. Exact names only: a subdomain is a different name. Connect by name, not by the address behind it. Ports `23`, `25`, `135` to `139` and `445` are never allowed. See Allowlist
`Can't complete SOCKS5 connection to ... (2)`	SOCKS5 reply 2, connection not allowed by ruleset: the same refusal as `403`, on the SOCKS5 port	The same checks as for `403`. Use `socks5h`, so that host name entries can match (see DNS). SOCKS5 is only available on nodes that still offer it; newer nodes keep it on loopback and you use the HTTPS proxy port
A plain `http://` request answers `403`	The HTTP port accepts `CONNECT` only	Use an `https://` destination URL. A plain-HTTP destination is not carried by the proxy port
`503` from the proxy	Too many connections at once, or the proxy is restarting after a change	Retry after a few seconds with a growing pause. Lower the number of parallel connections. If it persists, tell us
`SSL certificate problem`, `certificate verify failed`, `hostname mismatch`, or the action says "the TLS handshake with the proxy failed"	The client does not accept the proxy's certificate: you used the bare IP address instead of the node's DNS name, the clock on your machine is wrong, or the node's certificate has expired	Use the DNS name from your welcome email as the proxy host and keep certificate checking on. If the name is right and it still fails, tell us: the certificate on the node may need renewing
`Failed to connect ... Couldn't connect to server`, or a timeout	Nothing answers on that address and port from where you are	Check the host and the port, and that your network or runner lets you out to them. On Pro, try the other endpoint. If neither works, tell us: the endpoint may be down
The proxy works, the destination answers `403`, `401` or drops the connection	Traffic reaches the destination, and the destination refuses it	Check that it prints your dedicated address (see the source IP check) and that its owner has allowlisted that address, both addresses on Pro. We cannot promise that a third party accepts a given address. If it still refuses, tell us the destination and the time (UTC)

WireGuard problems

Run sudo wg show and look at latest handshake for the peer.

What you see	Likely cause	What to do
No `latest handshake` line	Our endpoint is not reachable, or the keys do not match	Check that outbound UDP to the endpoint and port is allowed (many networks and some CI setups block it). Check the `Endpoint` and that the private key is the one from the current configuration: a rotation replaces the old key. Keep `PersistentKeepalive = 25`, so that a firewall or CGNAT keeps the mapping
A handshake, but connections time out (egress)	The destination is not on your allowlist, or the traffic does not go into the tunnel	Traffic that is not on the allowlist is dropped, and ping never works. Check that the destination address is in `AllowedIPs` (`ip route get ADDRESS` shows the interface it would use) and on the allowlist with the port you use
A handshake, but nothing arrives (IP Tunnel)	Your inbound firewall drops it, or nothing listens on the address	Check `sudo nft list ruleset` and that the service listens on the public address
The connection to the host over its normal address hangs after `wg-quick up`	The tunnel took over the default route (`AllowedIPs = 0.0.0.0/0`)	Use the source-based setup (option B) from the tunnel quickstart, or route only the destinations you need
`RTNETLINK answers: Operation not permitted`, or no such device	Not root, or a container without the `NET_ADMIN` capability or without the WireGuard kernel module	Use `sudo`, add the capability to the container, or run the tunnel on the host

The destination sees a different address

The client ignored the proxy. Not every tool reads HTTPS_PROXY. Check the client's own proxy setting, or use WireGuard mode.
The host matched NO_PROXY. Print the variable and look for the destination or a suffix of it.
Lower-case variables. Some tools read only https_proxy and all_proxy. Set both spellings.
You are on the standby. On Pro, the second address is a different address. The GitHub Action reports which endpoint it chose in the endpoint output.
A WireGuard route is missing. The destination is not in AllowedIPs, so the traffic left through your normal route.

MTU and MSS

Symptoms: small requests work, but a TLS handshake stalls, a large download hangs, or a database connection breaks when the result set grows. The path between you and us cannot carry full-size packets, and the message that would tell your machine is often filtered.

By default the tunnel interface on our side uses an MTU of 1420, which fits a normal 1500-byte IPv4 path, and we clamp the TCP segment size on tunnel traffic to match.
Your side can still be smaller: PPPoE (1492), another VPN or overlay under WireGuard, some cloud and container networks. Lower the tunnel MTU, for example to 1380: add MTU = 1380 to the [Interface] section, or try it live with sudo ip link set dev penduses mtu 1380.
For a host that forwards traffic for VMs or containers, clamp the segment size to the tunnel MTU in your firewall: tcp flags syn tcp option maxseg size set rt mtu in an nftables forward chain.
In proxy mode the proxy connection is an ordinary TCP connection. Path MTU problems there point at your own network, not at the proxy.
Ping does not help: ICMP is dropped on static egress. Test with the real client and a smaller MTU.

DNS

Use socks5h, not socks5. With socks5 your machine resolves the name and sends the proxy an address, which does not match an allowlist entry for a host name and is refused. With socks5h, and with HTTPS_PROXY, the egress node resolves the name.
Our node resolves, not you. Round-robin or geographic DNS can return other addresses to the node than to you. That is fine. A name that resolves to an internal or blocked address is refused with 403.
A name that does not exist fails at the proxy, not on your machine. Check the spelling in the allowlist and in the URL.
WireGuard mode needs addresses. AllowedIPs takes addresses. Your resolver keeps working over your normal route, so leave the DNS line out of the configuration. When the destination changes its addresses, update AllowedIPs and the allowlist, or use proxy mode with a host name entry.
A DNS line in the configuration replaces your resolver with one your host may not be able to reach, and every lookup on the machine then fails. Leave it out.

What to send support

Email support@penduses.com. Send enough to find the problem, and nothing that grants access.

Send	Do not send
Your workspace name, the dedicated address, the destination host and port, the time window in UTC, the exact error message, and what the source IP check printed	Your proxy password, a URL that contains it, a private key, a full WireGuard configuration, a log that shows the `Proxy-Authorization` header, or request and response bodies

If you think a credential was exposed, say only "credential exposure suspected", with the workspace name, the address and the time window. We rotate it, and we cannot and will not ask you to send it. See Security notes.

Support is by email during business hours (Monday to Friday, 09:00 to 17:00 Central European Time). The pilot is best effort with no SLA.