[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# Detect invalid or inconsistent configurations\n\n| **Note:** Connectivity Tests performs a [static analysis](/network-intelligence-center/docs/connectivity-tests/concepts/overview#no-data-plane-testing) of the resource configurations in your VPC network. This analysis does not represent the actual condition of the network data plane.\n\nThis page shows examples of invalid or inconsistent configurations of\nGoogle Cloud resources that you might encounter when troubleshooting your\nnetwork with Connectivity Tests.\n| **Note:** The configuration failure examples shown in this document are a subset of all issues that Connectivity Tests can discover through its analysis. For the complete list of failure causes, see [Configuration analysis states](/network-intelligence-center/docs/connectivity-tests/concepts/state-tables).\n\nFor instructions about how to run tests, see\n[Create and run\nConnectivity Tests](/network-intelligence-center/docs/connectivity-tests/how-to/running-connectivity-tests).\n\nFor a description of testing to and from common network source\nand destination types, see\n[Common use cases](/network-intelligence-center/docs/connectivity-tests/concepts/common-use-cases).\n\nDetect an invalid configuration\n-------------------------------\n\nThere are many different types of invalid configurations; that is,\nconfigurations that are not correct or that have been updated and are no longer\nvalid.\n\nOne example is a virtual machine (VM) instance that has been\n[configured as a NAT gateway](/vpc/docs/special-configurations#natgateway),\nbut which has been\ndeleted\nor migrated. In this case, the route to the VM instance still exists.\n\nIn the following diagram, `VM1` in `Network 1` should be able to access data on\n`VM2`, `VM3`, and `VM4` in `Network 2` through a VM instance named `nat_vm_1`.\nHowever, `nat_vm_1` no longer exists because it has migrated to a new VM,\n`nat_vm_2`.\n\nThe configured route from `VM1` to the other three VM instances still\npoints to `nat_vm_1` as the next hop. However, because `nat_vm_1` no longer\nexists and there is no route to `nat_vm_2`, `VM1` can't communicate with the\nother VM instances.\n\nA Connectivity Test run from`VM1` to `VM2` reveals that the\ntraffic between `VM1` and the other VM instances has been dropped due to an\ninvalid next hop for the route to the other VMs.\n\n\n[](/static/network-intelligence-center/docs/connectivity-tests/images/invalid-route-configuration.svg) An invalid route configuration for Cloud NAT\n\n\u003cbr /\u003e\n\nIn contrast, in the use case for an\n[inconsistent configuration](#inconsistent-config),\n`VM3` is missing a network tag, making the load balancer configuration\ninconsistent\nacross the load balancer backends. However, the configuration for `VM3` itself\nis valid because configuring a VM instance doesn't require a tag.\n\nDetect an inconsistent configuration\n------------------------------------\n\nYou can also use Connectivity Tests to routinely validate\ninconsistent\nconfigurations. These configurations might not be causing any current\nconnectivity issues, but might unintentionally reduce network redundancy or\ncause performance issues in the future.\n\nThe load balancer is configured to send traffic to an external IP address of\n`35.184.176.28`. The traffic to that address is distributed across three\nbackends: `VM1`, `VM2`, and `VM3`. However, because of a missing network tag\non\n`VM3`, the Virtual Private Cloud (VPC) firewall rule allows traffic from\nexternal IP ranges to `VM1` and `VM2`, but denies that traffic to `VM3`.\n\nThe following trace from the allowed source ranges configured for the load\nbalancer to the destination external IP address of the load balancer shows the\nintended configuration and the inconsistency. `VM1` and `VM2` are reachable,\nbut\n`VM3` is unreachable. Only the two backends are reachable because `VM3` has\nfailed the health check.\n\n\n[](/static/network-intelligence-center/docs/connectivity-tests/images/external-https-lb-inconsistent-backend-config.svg) An external Application Load Balancer with an inconsistent backend configuration\n\n\u003cbr /\u003e\n\nWhat's next\n-----------\n\n- [Learn about Connectivity Tests](/network-intelligence-center/docs/connectivity-tests/concepts/overview)\n- [Troubleshoot Connectivity Tests](/network-intelligence-center/docs/connectivity-tests/support/troubleshooting)"]]