不過，您必須符合「自訂佇列分配」中指定的條件。舉例來說，如果您未為 VM 所配置的其中一個 NIC 指定自訂佇列計數，就會收到類似下列的錯誤訊息：
ERROR: (gcloud.compute.instances.create) Could not fetch resource:
- Invalid value for field 'resource.networkInterfaces': ''. The total
networking queue number is more than the number of vCPUs. Please specify
the queue count for all of the interfaces.
專案已遷移至可用區 DNS，但新專案中的 VM 仍使用全域 DNS
如果您已完成現有專案的遷移作業，從使用全域 DNS 改為使用區域 DNS，但發現新建立專案中的 VM 具有全域 DNS 名稱，表示您並未在機構或資料夾層級強制執行布林值機構政策 constraints/compute.setNewProjectDefaultToZonalDNSOnly。這項政策會覆寫預設 DNS 設定，讓新建立的專案預設使用內部可用區 DNS。
[[["容易理解","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 (世界標準時間)。"],[[["\u003cp\u003eFirewall rules dictate permitted network traffic to Compute Engine instances, and denying all traffic will block SSH and internal connections.\u003c/p\u003e\n"],["\u003cp\u003eNetwork latency issues can be addressed by optimizing TCP connections, which is detailed in the linked TCP optimization document.\u003c/p\u003e\n"],["\u003cp\u003eIf a VM experiences high latency or dropped packets with high packet rates, it may lack sufficient receive (RX) or transmit (TX) queues.\u003c/p\u003e\n"],["\u003cp\u003ePrivate forwarding rules are restricted to a single region, and only one forwarding rule can target a given instance.\u003c/p\u003e\n"],["\u003cp\u003eTo ensure new projects default to internal zonal DNS, enforce the \u003ccode\u003econstraints/compute.setNewProjectDefaultToZonalDNSOnly\u003c/code\u003e organization policy.\u003c/p\u003e\n"]]],[],null,["*** ** * ** ***\n\nTroubleshoot network latency issues\n\nFor information about the ways you can improve connection latency between\nprocesses within Google Cloud and decrease the latency of TCP connections, see\n[TCP optimization for network performance in Google Cloud and hybrid scenarios](/compute/docs/networking/tcp-optimization-for-network-performance-in-gcp-and-hybrid).\n\nTroubleshooting dropped network traffic\n\nCompute Engine only allows network traffic that is explicitly permitted by\nyour project's [Firewall rules](/vpc/docs/firewalls) to reach your\ninstance. By default, all projects automatically come with a\n[default network](/compute/docs/networks-and-firewalls#networks) that allows\n[certain kinds of connections](/vpc/docs/firewalls#default_firewall_rules).\nIf you deny all traffic, by default, that also denies SSH connections and all\ninternal traffic. For more information, see the\n[Firewall rules](/vpc/docs/firewalls) page.\n\nIn addition, you may need to adjust TCP keep-alive settings to work around the\ndefault idle connection timeout of 10 minutes. For more information, see\n[Communicating between your instances and the internet](/compute/docs/troubleshooting#communicatewithinternet).\n\nTroubleshooting firewall rules or routes on an instance\n\nThe Google Cloud console provides network details for each network interface\nof an instance. You can view all of the firewall rules or routes that apply to\nan interface, or you can view just the rules and routes that the interface uses.\nEither view can help you troubleshoot which firewall rules and routes apply to\nthe instance and which ones are actually being used (where priority and\nprocessing order override other rules or routes).\n\nFor more information, see the troubleshooting information in the Virtual Private Cloud\ndocumentation:\n\n- [Listing firewalls rules for a network\n interface](/vpc/docs/using-firewalls#listing-rules-vm)\n- [Listing routes for a network\n interface](/vpc/docs/using-routes#listing-routes-vm)\n\nTroubleshooting protocol forwarding for private forwarding rules\n\nUse the following sections to resolve common issue related to protocol\nforwarding for private forwarding rules.\n\nRegional restriction\n\nProtocol forwarding for private forwarding rules is a regional product.\nAll clients and target instance VMs must be in the same region.\n\nError message: \"An internal target instance can only be the target of one forwarding rule\"\n\nIf you see the error message `An internal target instance can only be the target\nof one forwarding rule`, you might be trying to configure two forwarding rules\npointing to the same target instance. You cannot point multiple forwarding\nrules to the same target instance.\n\nTroubleshooting latency on Compute Engine instances when processing high packet rates\n\nIf your VM experiences latency, dropped packets, or packet\nretransmissions when processing high packet rates, your VM might not have enough\nreceive queues (RX) or transmit queues (TX) on the network interface (NIC)\nprocessing those packets.\n\nTo resolve these issues, see [Receive and transmit queues](/compute/docs/network-bandwidth#rx-tx) for\ninformation about how Compute Engine allocates RX and TX queues.\n\nTroubleshooting custom NIC queue oversubscription\n\nWith queue oversubscription, the maximum queue count for the VM is: \n\n```\n[maximum queue count per VM] * [number of NICs]\n```\n\nHowever, you must satisfy the conditions specified in\n[Custom queue allocation](/compute/docs/network-bandwidth). For example, if\nyou didn't specify a custom queue count for one of the NICs configured for the\nVM, you get an error similar to the following: \n\n```\nERROR: (gcloud.compute.instances.create) Could not fetch resource:\n - Invalid value for field 'resource.networkInterfaces': ''. The total\n networking queue number is more than the number of vCPUs. Please specify\n the queue count for all of the interfaces.\n```\n\nProjects migrated to zonal DNS but VMs in new project are using global DNS\n\nIf you completed the migration of your existing projects from using global DNS\nto using zonal DNS, but discover that VMs in a newly created project have\nglobal DNS names, you didn't enforce the boolean organization policy\n`constraints/compute.setNewProjectDefaultToZonalDNSOnly` at an organization or\nfolder level. This policy overrides the default DNS setting, so that newly\ncreated projects use internal zonal DNS by default.\n\nFor instructions on enforcing this policy, see\n[Enforce zonal DNS only by default for new projects](/compute/docs/networking/zonal-dns#enforce_dns_by_policy).\n\nIf you aren't using an organization policy, but instead use the metadata entry\n`VmDnsSetting=ZonalOnly` for projects or VMs, check the metadata value for\nthe VM. If the VM has `VmDnsSetting=GlobalDefault` configured in its metadata,\nthis value overrides the metadata value set at the project level.\n\nFor information about how to set project metadata or VM metadata values,\nsee [Setting custom metadata](/compute/docs/metadata/setting-custom-metadata).\n\nHide the zonal DNS migration banner in the Google Cloud console\n\nThe zonal DNS migration notification banner provides assistance in migrating\nyour projects to zonal DNS. If you dismiss the banner, but want it to appear\nagain, you must contact Cloud Customer Care for assistance.\n\nTo hide the zonal DNS migration notification banner, click the **Dismiss**\nbutton in the banner that appears on the **VM instances** page of the\nGoogle Cloud console. If you click the button, the banner no longer\nappears for the project."]]
