[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[[["\u003cp\u003eIn migration scenarios where direct connectivity between source and destination databases is not possible, a TCP proxy VM is recommended for routing traffic.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service can generate a script to automate the setup of a Compute Engine VM instance, which acts as a transparent TCP proxy, within the same project and VPC as the destination database.\u003c/p\u003e\n"],["\u003cp\u003eWhen setting up connectivity, users can select "Proxy via cloud-hosted VM - TCP" and specify the Compute Engine VM's configuration, such as name, machine type, and subnetwork.\u003c/p\u003e\n"],["\u003cp\u003eBy default, the proxy VM is assigned both private and public IP addresses, but users can configure it with only a private IP by enabling Private Google Access and modifying the generated script.\u003c/p\u003e\n"],["\u003cp\u003eAfter setting up the proxy, it's essential to update security settings, such as \u003ccode\u003epg_hba.conf\u003c/code\u003e or security groups, to accept connections from the TCP proxy's outgoing IP address, and test the connection before creating the migration job.\u003c/p\u003e\n"]]],[],null,["# Configure connectivity using a TCP proxy through a cloud-hosted VM\n\n\u003cbr /\u003e\n\nMySQL \\| PostgreSQL \\| PostgreSQL to AlloyDB\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nIn [certain migration scenarios](/database-migration/docs/postgresql-to-alloydb/networking-methods#common_connectivity_scenarios_and_solutions)\nit might not be possible to establish direct connectivity between the source and\nthe destination databases. In such cases we recommend using a TCP proxy VM for\nrouting traffic. You can set up a TCP proxy VM with an automated script\ngenerated by Database Migration Service.\n[](#lightbox-trigger) **Figure 1.** Connectivity example: TCP proxy used for routing traffic when [migrating from a Cloud SQL instance in the old producer network architecture](/database-migration/docs/postgresql-to-alloydb/networking-methods#migrate_from_a_cloud_sql_instance_in_the_old_producer_network_architecture) (click to enlarge)\n\nWhen you create a migration job, Database Migration Service collects the required information\nand generates a script that sets up the proxy VM. This script runs\nseveral Google Cloud CLI commands that perform the following:\n\n1. Creates and configures a Compute Engine instance in the same project\n and VPC as the destination database.\n\n This VM runs a transparent TCP proxy that by default has private and public\n IPs. The proxy starts serving incoming connections immediately after booting.\n2. Creates a firewall rule to allow connections from the AlloyDB for PostgreSQL\n destination database to the proxy.\n\nSet up the TCP proxy VM\n-----------------------\n\nIn the Google Cloud console, when you [set up connectivity between the source and destination](/database-migration/docs/postgresql-to-alloydb/create-migration-job#setup-connectivity), perform the following steps:\n\n1. From the **Connectivity method** drop-down menu, select **Proxy via cloud-hosted VM - TCP**.\n\n2. Specify the following configuration parameters of the Compute Engine instance that will serve as the bastion host:\n\n - **Compute Engine VM instance name**: The name for the Compute Engine instance.\n - **Machine type** : The Compute Engine machine type, for example `n1-standard-n1`.\n - **Subnetwork**: The subnet of the destination VPC.\n\n \u003cbr /\u003e\n\n | Note: The Compute Engine VM instance created by the script isn't managed by Database Migration Service. Your organization is charged for the instance based on standard [pricing](/database-migration/pricing), and is responsible for its management, including deleting the instance when it's no longer needed.\n3. Click **View script** to view the generated script.\n\n | By default, the script generates a public IP address for the Compute Engine VM server. If your organization doesn't permit creating a proxy with a public IP address, or you have security concerns, then perform the following steps to disable the option to generate the address:\n | 1. Enable [Private Google Access](/database-migration/docs/postgresql-to-alloydb/vpc/docs/configure-private-google-access#enabling-pga) on the subnet used for the proxy. This is required to allow the Compute Engine instance to download the necessary Docker images from the Google Cloud repository.\n | 2. Append the `no-address` key to the `--network-interface` argument of the [`gcloud compute instances create-with-container`](/sdk/gcloud/reference/compute/instances/create-with-container) command in the script:\n |\n | `gcloud compute instances create-with-container ... --network-interface subnet=SUBNET-NAME,no-address`\n4. Run the script on a machine that has access to the Google Cloud project of the destination database.\n\n5. Make sure that the following settings are updated to accept connections from\n the outgoing IP address of the TCP proxy:\n\n - The replication connections section of the `pg_hba.conf` file (for a self-managed source instance).\n\n - The security group definitions (for an Amazon RDS/Aurora source instance).\n\n6. Click **Configure \\& continue**.\n\n7. If your source is within a VPN (in AWS, for example, or your own on-premises VPN), see [Configure connectivity using VPNs](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-vpns#vpc-vpn) for more information about configuring the source VPN and Google Cloud VPN to work with each other.\n\n8. [Test and create your migration job](/database-migration/docs/postgresql-to-alloydb/create-migration-job#test-create)."]]