Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- For developers and administrators using Claude Code on enterprise networks, managed development machines, SSH or WSL.
- Claude Code supports HTTP/HTTPS proxies and NO_PROXY, but its official documentation explicitly does not support SOCKS proxies.
- For certificate errors, check system trust, custom CAs, Node versions and variable scope. Do not disable TLS verification.
Scope and stop conditions
This guide is for developers and administrators running Claude Code with enterprise proxies, TLS inspection, custom certificates or mTLS. First determine whether the failure occurs in a local terminal, SSH/WSL, a desktop session or a cloud session, because network-variable scope differs between them.
Stop adjusting proxies if the issue is missing account permissions, organization policy, regional restrictions, a server-side 403, or an incident on the official status page. Changing exits cannot repair certificate trust, account permissions or platform outages, and must not be used to bypass service rules.
Step 1: Separate errors by layer
An unresolvable proxy address, connection timeout or 407 authentication failure usually points to the proxy layer. `SELF_SIGNED_CERT_IN_CHAIN`, `UNABLE_TO_VERIFY_LEAF_SIGNATURE` and certificate-chain errors usually point to enterprise TLS inspection and CA trust. A 403 or sign-in failure is more likely to involve the account, organization or target-service policy. Do not reduce all of these to “change the IP.”
Record the time, execution environment, Claude Code and Node versions, original error code and variable names. For general DNS, TCP, 407 and TLS layers, see the proxy connection troubleshooting checklist, but do not upload real passwords, private keys or complete proxy addresses.
Step 2: Check the officially supported proxy variables
The official enterprise-network documentation says Claude Code reads `HTTPS_PROXY`, `HTTP_PROXY` and `NO_PROXY`; lowercase variants also work. `NO_PROXY` accepts space- or comma-separated entries, and `*` bypasses the proxy for all requests. Claude Code currently does not support SOCKS proxies, so do not put SOCKS addresses directly in these variables. Proxy addresses should include an `http://` or `https://` prefix.
For basic authentication, the official documentation allows usernames and passwords in the proxy URL but explicitly discourages hardcoding passwords in scripts. Use controlled environment variables or secure credential storage. If the address structure is unclear, read the proxy URI format guide first.
Step 3: Handle enterprise CAs and TLS inspection
Claude Code trusts its bundled Mozilla CAs and the operating-system certificate store by default, with `CLAUDE_CODE_CERT_STORE` set to `bundled,system`. Native installations can read the system certificate store. npm installations require Node 22.15 or later; older versions generally rely on bundled certificates and `NODE_EXTRA_CA_CERTS`.
Have an administrator provide the enterprise custom CA as a PEM certificate, and point `NODE_EXTRA_CA_CERTS` to a controlled file. Do not set `NODE_TLS_REJECT_UNAUTHORIZED=0` to disable verification: it hides real problems such as interception, expired certificates or incorrect issuance.
Step 4: Verify mTLS and variable scope
For mutual TLS, the official fields are `CLAUDE_CODE_CLIENT_CERT`, `CLAUDE_CODE_CLIENT_KEY` and the optional `CLAUDE_CODE_CLIENT_KEY_PASSPHRASE`. Keep certificates, private keys and passphrases in controlled locations. Troubleshooting records should state only whether files are readable and the error reason, never their contents.
Set variables before launching Claude Code; an existing session does not automatically pick up later changes to the shell environment. Desktop-managed connections and cloud sessions have additional scope limits. Repository settings cannot arbitrarily redirect TLS or proxy paths for app-managed sessions; consult the current official network-configuration page.
Step 5: Verify with logs and the status page
Launch with `claude --debug` and check the debug file for successful loading of the CA, client certificate and private key. For `Failed to read` or `Failed to load`, correct the path, permissions or file format first. In an interactive session, run `/status` and check the Proxy, mTLS client cert/key and Additional CA cert(s) lines.
Then check the official service status page. If the official service has an incident, retain the time and error evidence and wait for recovery. If only the enterprise network fails, send redacted logs to the network or security administrator. For a fixed PuppyIP exit, first follow the usage tutorials for compliant setup. For the product entry point, visit the PuppyIP website.
Sources
Frequently Asked Questions
Does Claude Code support SOCKS proxies?
The current official enterprise-network configuration documentation explicitly says SOCKS proxies are not supported. Use supported HTTP/HTTPS proxy settings, and do not put a SOCKS address directly in HTTP_PROXY or HTTPS_PROXY.
Should I change proxies after SELF_SIGNED_CERT_IN_CHAIN?
Not immediately. Check enterprise TLS inspection, the system trust store, Node version and NODE_EXTRA_CA_CERTS first. Certificate errors are a different layer from target-site 403 and proxy 407 responses.
Can I temporarily disable TLS verification?
This is not recommended. Disabling verification hides certificate-chain and interception risks. Repair CA trust, certificate files, permissions or the runtime version instead.
Why did an environment-variable change have no effect?
Claude Code generally reads shell variables at startup; a running session does not automatically receive later changes. Desktop and cloud sessions may also accept settings only from specific scopes.