Risks and safeguards

Understand which access you are granting, where encryption begins and ends, and what to check before sharing a connection or changing network settings.

Network exposure and authentication

Risks of listening on 0.0.0.0

0.0.0.0 means listening on all IPv4 interfaces, not only the current Wi-Fi network. It does not make the port publicly reachable by itself; router port forwarding, firewall rules and network routing determine who can reach it. If reachable without authentication, it can become an open proxy: others may consume your bandwidth, access destinations available to your Mac or proxy routes, and generate abuse attributed to your public IP. Prefer a specific private interface address. If you need 0.0.0.0, enable authentication and restrict source addresses with a firewall; do not expose the plaintext HTTP/SOCKS listener directly to an untrusted network. Authentication alone does not encrypt the connection.

Without authentication

Without authentication, any client admitted by the listener’s network checks can use the proxy without credentials. A private address or shared Wi-Fi is not proof of trust. Requests cannot be reliably attributed to individual users; other users may consume your bandwidth or access reachable resources, with abuse associated with your public IP. Enable authentication unless access is restricted to trusted devices on an isolated network.

Forwarding and SOCKS listeners

A local forward exposes the target service through your Mac. A remote forward exposes a service reachable from your Mac through the SSH server. A remote loopback bind is local to that server, not your Mac; other permitted server users may still reach it. Broader remote binds also depend on the server’s SSH policy and firewall. Keep application-level authentication on databases, desktops and web services.

The ordinary SSH SOCKS listener is separate from authenticated Network Sharing. Do not assume shared proxy credentials protect it. Prefer 127.0.0.1; review listeners, server permissions and firewall rules before widening access. :: is an IPv6 wildcard, not a private-address guarantee. See port forwarding and remote forwarding.

Encryption and SSH server identity

SSH encrypts the tunnel between the Mac and SSH server. It does not automatically encrypt the client-to-listener link or the server-to-destination link. Use end-to-end HTTPS or the target protocol’s own encryption where needed. The SSH server and destination remain trust boundaries; a tunnel does not make an untrusted service safe or provide anonymity.

Verify the first host-key fingerprint through a trusted channel. Investigate changed keys before resetting trust; do not disable strict checking to bypass a warning. Passwords, private keys and OTP authenticate you, while host keys authenticate the server. See SSH host trust.

Routing and DNS coverage

Review rule order, the Default rule and the DNS setting of the matched rule. DIRECT intentionally uses a direct path; configure fallback explicitly rather than assuming a failed PROXY will switch to DIRECT. Domain resolution and the application connection can follow different paths. Proxy-side DNS does not turn ordinary TCP/53 upstream DNS into DoH.

Do not treat a manual HTTP proxy, an SSH SOCKS listener or transparent routing as a universal VPN or kill switch. Apps may ignore proxy settings, use their own DNS, reuse old connections or send unsupported traffic. HTTP CONNECT does not provide general UDP forwarding. Check the actual app, protocol and IPv4/IPv6 path. See routing rules, DNS and SOCKS limits.

Gateway Mode risks

Gateway Mode is experimental and does not support username/password or multi-user authentication. Proxy Mode authentication does not protect gateway traffic; IP filtering restricts devices but does not verify user identity. Use only on a trusted, isolated LAN and restrict allowed source IPs. It requires administrator authorization to change IP forwarding and packet-filter rules, which may interrupt networking. It does not encrypt the device-to-Mac link, and IPv6 may bypass gateway rules. In multi-gateway networks, asymmetric outbound/return paths can cause timeouts, disconnections or port-forwarding failures. Mac sleep, app exit or address changes interrupt sharing; restore clients’ original gateway and DNS settings when stopping. This notice describes risks, not a verified gateway setup procedure.

Enterprise management and certificates

Enterprise Settings is available only in the Enterprise edition. Web/API access can expose configuration and permitted control actions; console or file-access permissions are especially sensitive. Initialize the administrator locally, restrict network reachability and roles, and grant control access only when needed. The app’s interface lock is not a substitute for API, administrator or proxy authentication.

Use verified HTTPS on untrusted paths. A private CA must be trusted by the client and the certificate must cover the name used to connect. Import only trusted identities and protect their private keys. HTTPS proxy TLS protects its own listener; it does not encrypt the separate HTTP/SOCKS listener or add UDP support. Resetting the API token is separate from administrator browser sessions. See Enterprise access and TLS.

Credentials, backups and connection sharing

Copied proxy URLs and shell commands may include passwords; clipboard sync, terminal history and logs can expose them. Redact credentials, tokens, addresses and personal data before sharing diagnostic material. Protect SSH keys and use separate credentials with only the permissions needed.

A configuration backup can contain credentials in its password-encrypted payload. Store the backup and password securely and separately. It does not include private-key file contents, TLS identities/CA private keys, administrator accounts/API tokens, enterprise activity or app-unlock credentials. Plan separate recovery. QR shares omit credentials but disclose configuration; anyone with the QR and share password can import it. Expiry does not revoke an already imported copy. See backup coverage and QR sharing.

Automation and unattended connections

Review local/remote scripts and completion actions before enabling them: they run with the relevant Mac or SSH account’s permissions. Trust imported profiles only after checking targets, listeners, rules and scripts. Startup groups and automatic retries can reopen multiple connections without another manual click. An app-interface lock does not disconnect active tunnels. Review group membership and startup/retry settings before leaving the Mac unattended. See automation.

Availability, privacy and responsibility

Sleep, network changes, upstream limits and too many simultaneous connections can interrupt service or exhaust resources. A green SSH status does not prove destination availability. Traffic totals and connection records are operational indicators, not proof of security or complete billing records. Share only networks and services you are authorized to share; destination providers still apply their own access rules, and abuse can be associated with the exit IP. See troubleshooting.

Before making a service reachable

• Identify who can reach each listener, including routed networks and remote-server users.
• Enable appropriate authentication and target-service encryption; verify SSH/TLS identity.
• Check source restrictions, route order, Default and DNS; test one authorized client first.
• Review startup, retries, groups and scripts; prepare original network settings and separate key/certificate recovery.
• Monitor resource use and connection records, and stop sharing when it is no longer needed.

If you suspect unauthorized use

1. Stop the affected sharing/listener or connection; stop the management service if management access is affected.
2. Restrict firewall/router exposure and revoke affected accounts, credentials or tokens. A token reset alone is not browser sign-out.
3. Preserve necessary logs privately, check server and destination access, and review rules, groups and startup actions.
4. Restore clients’ original gateway/DNS settings where changed, then re-enable only the required access and verify with a trusted client.