httpx.ConnectError: [Errno 8] nodename nor servname provided, or not known

Hello Ludwig, Dana,

Welcome to Microsoft Q&A and Thank you for reaching out.

I understand that you're running into a connectivity issue when calling the Azure OpenAI endpoint using the SDK. The error:

httpx.ConnectError: [Errno 8] nodename nor servname provided, or not known

typically indicates a problem with the endpoint URL or with DNS/network resolution on the machine making the request. Below are the key areas to check to troubleshoot and resolve this issue.

1. Verify the Endpoint URL

Please ensure that the base_url is correct and follows this exact format:

https://<your-azure-openai-resource>.openai.azure.com/openai/v1/

Double-check for:

• Spelling mistakes in the resource name

Missing or extra characters

Trailing slashes or hidden spaces

An incorrect hostname will cause the “nodename not known” error immediately.

2. DNS Resolution Check

From your machine, run the following command:

nslookup dana-instance-gpt51-instance2.openai.azure.com

• If this returns no IP address, DNS resolution is failing.
• If DNS cannot resolve the hostname, the SDK will not be able to connect.

3. Network / Private Endpoint Configuration

If your Azure OpenAI instance uses a private endpoint, please verify the following:

Your machine is connected to the same VNet (via VPN/ExpressRoute if required).

NSG rules or firewalls are not blocking port 443.

Private DNS zone is properly linked and resolving the hostname.

You can test connectivity directly using PowerShell:

Test-NetConnection <private-IP> -Port 443

Replace <private-IP> with the private endpoint IP (e.g., 10.0.0.4). This test should return TcpTestSucceeded = True if networking is configured correctly.

4. Firewall & Outbound Internet Rules

Please check if:

A local firewall

Company proxy

Antivirus network filter

Custom security policy

is blocking outbound HTTPS traffic.

Azure OpenAI requires access over port 443, so ensure outbound HTTPS is allowed.

5. Validate API Key Environment Variable

Your script loads the key using:

os.getenv("OPENAI_API_KEY")

Please ensure:

The .env file contains the correct key

The environment variable is actually loaded

No extra quotes or whitespace are present

You can verify by running:

echo $OPENAI_API_KEY

If this returns empty, the SDK may fail before connecting.

6. Azure Deployment Name Check

When using Azure OpenAI, the value for model= must be the deployment name, not the raw OpenAI model name.

Example:

model="gpt51-deployment"

If the deployment name is incorrect, the request may fail as well.

Please refer this

• Configure Azure OpenAI networking
• Connect to Azure OpenAI in Foundry Models using Service Connector

I Hope this helps. Do let me know if you have any further queries.

Thank you!

Hi Ludwig, Dana,

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!

Hi Lakshmi,

Yes, your response was very helpful! Using your troubleshooting method I was able to verify that my problem was in the endpoint URL. It was a typo and I fixed it.

Then I had a second problem which was that I had no GPT-5.1 deployment for that subscription. I missed that bug because I thought I remember an email saying that I did have it, and I couldn't find a place on my dashboard that said I did have the deployment, so I assumed it was hidden. I was also thrown-off by the use of the word "model" and "deployment" interchangeably on the web site. I am also puzzled that I should have to "deploy" gpt-5.1, since I was already naming it in my python script, and that is your main model, right?

I solved the second bug by picking the correct model, and "requesting" it. Then magically I had a new section of "deployments" on my dashboard. Now my test code works!

I was also thrown off by the seemingly inconsistent use of the term "foundry". I didn't want to sign up for the "foundry" but it seems I could only get to gpt-5.1 through clicking "foundry models". My understanding was "foundry models" were limited to accounts that had signed up for the "foundry", and I didn't want to do that. I assumed that "gpt-5.1" would be a Microsoft-exclusive model owned and supported by Microsoft (of course via OpenAI) and would not require use of the "foundry" service. I'm still not sure about that.

These and other things consumed by 15 hours trouble shooting this little "hello world" script. I wish it was easier.

Hi Ludwig, Dana,

Thank you for the detailed follow-up, and I’m really glad to hear you were able to identify and fix both issues. I completely understand how frustrating this can be your feedback is very valid.

Let me address your points one by one and also clarify the confusion around deployments, models, and Foundry.

1. Model vs. Deployment

In Azure OpenAI, the Python parameter model="..." must always refer to the deployment name, not the model family name. Even if you write "gpt-5.1" in your code, Azure cannot route that request unless there is a corresponding deployment with that name. This is why a manual deployment step is required today. You didn’t do anything wrong this is simply how the platform is designed right now.

2. Why GPT-5.1 wasn’t visible until requesting access

GPT-5.1 requires explicit quota approval before it appears in the portal. Once access is granted, the "Deployments" section becomes available. We agree this can feel unintuitive if you're expecting the model to simply appear as soon as you create the resource.

3. Confusion around “Foundry”

You’re absolutely right there is inconsistent wording in the current UI.

“Foundry models” are listed under AI Foundry UI

• Azure OpenAI (the service you're using) also routes some navigation through the same interface This makes it look like Foundry registration is required, even when it isn’t. You do not need a Foundry subscription to use GPT-5.1 in Azure OpenAI. The teams are working on unifying this experience, so it feels seamless.

4. Your feedback on the onboarding experience

I appreciate you sharing this. The learning curve can definitely feel steep, especially for what should be a simple “hello world” test. Your points are 100% reasonable:

• Too many steps before the first successful API call
• Model access not being obvious
• Deployment terminology confusing
• Navigating between Azure OpenAI vs AI Foundry
• Difficulty locating the correct region
• Lack of a clean, guided self-service path
• Feeling like basic help requires a support plan

Thank you!

Hi Ludwig, Dana,

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!