AWS Lambda Cannot Reach a Private Proxy: Check the VPC Path
Use the proxy listener's address and port for the first VPC connection, with the correct security-group direction and DNS view.
With Requests configured for a forward proxy, Lambda first connects to that listener. An HTTPS website on 443 does not change a proxy listening on 3128 into the first-hop port 443.
Lambda code → configured VPC path → proxy listener → destinationFor an EC2-hosted private proxy, attach the function to the intended VPC subnets and security groups. Lambda manages network interfaces for the attachment. Different subnets can work when their routing and access controls permit the connection.
| Control | First-hop requirement in a directly routed same-VPC setup |
|---|---|
| Function security group | Outbound TCP to the proxy listener |
| Proxy security group | Inbound TCP on that port from the intended function source/security group |
| Proxy process | Listener on the reachable interface with client access permitted |
An inbound rule on the function group alone cannot authorize this outbound client connection. Include route tables and subnet network ACLs in the path check.
For a private Route 53 proxy name, verify the hosted-zone VPC association and DNS configuration, including enableDnsHostnames and enableDnsSupport. The laptop's successful lookup does not establish Lambda's DNS view. Record whether the failed name is the proxy or website; changing the website to a numeric IP is not a proxy-name fix.
After this hop works, the proxy needs its own onward route. Attaching Lambda to a public subnet does not assign a public IP or automatically supply direct Internet access; decide egress separately for both connections.