Why are my Tailscale proxy Pods in CrashLoopBackOff?

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:

kubectl logs --namespace "[NAMESPACE]" "[PROXY-POD]" --container tailscale --previous

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. CoreWeave’s customized proxy image supports TS_CGNAT_OVERRIDE_RANGE to exempt the CKS range from this drop rule. This setting is separate from the Tailnet ipPool, which controls address allocation to Tailnet devices. Check the configuration in your Helm values or GitOps repository:

Use CoreWeave’s tailscale-operator chart and customized images. If an image doesn’t implement the extension, setting TS_CGNAT_OVERRIDE_RANGE doesn’t provide the exemption.
Identify the ProxyClass selected by the resource that creates the failing proxy. The chart supplies a default ProxyClass with the override, but a resource-specific class replaces that selection rather than inheriting its settings.
In the selected ProxyClass, set TS_CGNAT_OVERRIDE_RANGE to 100.124.0.0/18 while preserving its other configuration. Apply the change through your deployment’s source of truth.

The override belongs in the proxy container’s environment configuration:

ProxyClass specification excerpt

spec:
  statefulSet:
    pod:
      tailscaleContainer:
        env:
          - name: TS_CGNAT_OVERRIDE_RANGE
            value: "100.124.0.0/18"

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

The operator reconciles ProxyClass changes into the proxy’s StatefulSet. Environment changes require replacement Pods, and StatefulSets use rolling updates by default. Before recreating a Pod, confirm that the StatefulSet’s Pod template contains the corrected proxy image and environment configuration. Inspect the rollout and affected Pod for errors:

kubectl get statefulset --namespace "[NAMESPACE]" "[STATEFULSET]" -o yaml
kubectl rollout status statefulset/"[STATEFULSET]" --namespace "[NAMESPACE]" --timeout=120s
kubectl describe pod --namespace "[NAMESPACE]" "[PROXY-POD]"

If a failed rollout remains blocked after the template is corrected, recreate only the affected proxy Pod. Recreation can interrupt traffic through that proxy:

kubectl delete pod --namespace "[NAMESPACE]" "[PROXY-POD]"

Check that the replacement Pod becomes Ready and its logs no longer show the API connection timeouts:

kubectl get pod --namespace "[NAMESPACE]" "[PROXY-POD]"
kubectl logs --namespace "[NAMESPACE]" "[PROXY-POD]" --container tailscale

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:

kubectl get pods --namespace "[NAMESPACE]" \
  -o custom-columns='NAME:.metadata.name,IMAGES:.spec.containers[*].image'

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

​Check the proxy logs

​Check the carrier-grade NAT configuration

​Check the rollout before recreating a Pod

​Check image versions if crashes continue

Check the proxy logs

Check the carrier-grade NAT configuration

Check the rollout before recreating a Pod

Check image versions if crashes continue