Cloud Run V2 (asia-northeast3) Outbound HTTPS Block to Vision API (500 Error)

[Problem Summary] Our Firebase Functions V2 (based on Cloud Run) deployed in asia-northeast3 is failing with an immediate 500 Internal Server Error when sending an outbound HTTPS fetch request to the Google Cloud Vision API (https://vision.googleapis.com).

[Environment Details]

Project ID: (PII Removed by Staff)

Function Name: analyzePetImage

Region: asia-northeast3

Current Settings: Memory 1GiB, IAM Secret Manager Secret Accessor granted.

[Confirmed Diagnostics - Core Evidence]

IAM/Memory Ruled Out: All required permissions are set, and testing with small images (256KB) and high memory (1GiB) still results in failure.

Protocol-Specific Failure:

Requests using the https URL fail (most recently within 55ms) and are caught as a low-level network error (:cross_mark: Fetch 또는 내부 오류 발생).

CRITICAL: When the Vision API URL was temporarily changed to http (for debugging purposes), the immediate block was bypassed, and the function successfully executed the code logic (receiving the expected 400 Bad Request from the API server).

Conclusion: The failure is strictly tied to the https protocol’s outgoing communication at the Cloud Run V2 network layer in the asia-northeast3 region.

[Request to Community] We suspect a hidden firewall rule, TLS/SSL configuration issue, or a specific egress networking policy is blocking the https traffic to Google APIs from this Cloud Run instance. We are unable to create a support case. Are there any known issues or specific Cloud Run configuration steps (VPC/Egress) we may have missed to allow this essential outbound Google API traffic?

Hi Jinwwok,

It looks like your issue is tied specifically to HTTPS egress from Cloud Run V2 in that region. One common cause is that the service is running in a VPC-connected environment with restricted egress, so the Cloud Run instance may not have proper access to the public internet for HTTPS requests. Double-check your egress settings in the Serverless VPC Connector and ensure that “Route all traffic through VPC” isn’t unintentionally blocking external HTTPS. Also, confirming that no organization-level firewall rules or private Google access restrictions are interfering with TLS connections can help pinpoint the root cause.

1 Like