Skip to main content
Tailscale proxy Pods can enter CrashLoopBackOff when carrier-grade network address translation (CGNAT) filtering prevents access to the Kubernetes API. Start with the affected Pod’s logs to distinguish this connectivity problem from other causes. Then check its configuration and rollout. In the following commands, replace [NAMESPACE] with the operator’s namespace, [PROXY-POD] with the affected proxy Pod, and [STATEFULSET] with its owning StatefulSet. The chart guide uses the tailscale namespace.

​
Check the proxy logs

To inspect the failure that caused a restart, read the previous container’s logs:
Connection timeouts to kubernetes.default.svc or the API server ClusterIP can indicate a CGNAT configuration problem. These timeouts can appear during permission checks or reads of the proxy’s state Secret. A timeout while checking permissions doesn’t establish that Kubernetes denied access. If the logs report a permissions denial or an out-of-memory failure, investigate that error separately.

​
Check the carrier-grade NAT configuration

Tailscale’s CGNAT drop rule matches traffic from 100.64.0.0/10 arriving outside the Tailscale interface. CoreWeave Kubernetes Service (CKS) uses 100.124.0.0/18 within that range for internal services. This filtering can prevent a proxy from reaching the Kubernetes API. Use Tailscale’s standard chart and images with the required CKS networking policy. Confirm that the tailnet policy includes both disable-linux-cgnat-drop-rule and ipPool: ["100.64.0.0/13"] and that the attributes apply to the affected proxy. The drop-rule attribute disables the filtering that blocks CKS internal services. The IP pool controls address allocation to tailnet devices. The IP pool alone doesn’t disable the drop rule. API-server health problems can coexist with a Tailscale configuration problem. If other workloads also lose API access, investigate the control plane as well.

​
Check the rollout before recreating a Pod

If you also changed the proxy image or Pod configuration, check the resulting StatefulSet rollout. Tailnet policy changes are separate from the StatefulSet’s Pod template. Before you recreate a Pod, confirm that the StatefulSet’s Pod template contains the intended proxy image and configuration. Inspect the rollout and affected Pod for errors:
If a failed rollout remains blocked after the template is corrected, recreate only the affected proxy Pod. Recreation can interrupt traffic through that proxy:
Check that the replacement Pod becomes Ready and its logs no longer show the API connection timeouts:

​
Check image versions if crashes continue

If API connectivity is restored but the proxy still crashes, inspect the current error and compare the running operator and proxy images with your intended chart configuration:
Check for custom image tags or digests in Helm values and the selected ProxyClass. These can override chart defaults, so a chart upgrade alone doesn’t establish that every proxy image changed. Apply any upgrade through your Helm or GitOps configuration and verify the resulting images and rollout. If the Pods still crash, contact Support with the Pod logs, chart version, running images, and relevant ProxyClass configuration.
Server Errors
Last modified on September 30, 2026