13.4.3 isproxy = false broken

[davhdavh]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

app: System.IO.IOException: 'Failed to bind to address https://127.0.0.1:5001: address already in use.'

browser: The server at localhost:5001 sent back an error: 404 Not Found

Expected Behavior

works like 13.3

Steps To Reproduce

var web = builder.AddProject<Projects.xxx>("web")
                 .WithEndpoint("https", o => {
                    o.IsProxied   = false;
                 }, false)

Exceptions (if any)

No response

Aspire doctor output

Aspire Environment Check

Aspire
✅ Aspire CLI version 13.4.3 (channel: stable)

AppHost
✅ AppHost version 13.4.3 (x.AppHost\x.AppHost.csproj)

.NET SDK
✅ .NET 10.0.300 installed (x64)

Container Runtime
✅ Docker v29.1.3: running (auto-detected (default)) ← active

Environment
✅ HTTPS development certificate is trusted

Summary: 5 passed, 0 warnings, 0 failed

Aspire CLI Installations

╭────────────────────────────────────────────────┬─────────────────────────────────────────────────┬─────────┬───────────┬─────────────╮
│ Path │ Version │ Channel │ Route │ PATH status │
├────────────────────────────────────────────────┼─────────────────────────────────────────────────┼─────────┼───────────┼─────────────┤
│ C:\Users\xxx.aspire\bin\aspire.exe (current) │ 13.4.3+4f218933552e18ff2874d1b6d5dc3fe671e3b6d9 │ stable │ (unknown) │ active │
╰────────────────────────────────────────────────┴─────────────────────────────────────────────────┴─────────┴───────────┴─────────────╯

Anything else?

No response

[joperezr]

🤖 Aspire triage pass — 2026-06-09 06:40 UTC

Area: area-orchestrator, area-app-model
Kind: regression
Repro: yes-minimal — small code snippet (WithEndpoint("https", o => { o.IsProxied = false; }, false)) plus observed address already in use exception
Affected version(s): 13.4.3 (reporter cites generic 13.3 as last-working; latest stable: 13.4.3)
Severity: S2 — proxyless HTTPS endpoint binding fails with port conflict; blocks proxyless-endpoint scenario with no workaround named

Urgency: 🟡 vNext — recommend milestone 13.5
Reason: Symptom strongly matches recent proxyless endpoint allocation changes in 13.4, but reporter did not name a specific prior 13.3.x patch that worked. Per triage policy, servicing (13.4.x) requires confirmed baseline — a human should evaluate against the recent proxyless work and decide whether to escalate.

Suggested owner(s): @danegsta (proxyless endpoint allocation area owner)
Evidence:

• @danegsta merged Add proxyless endpoint on-demand allocation #17851 (Add proxyless endpoint on-demand allocation), Fix proxyless container endpoint tests #17404 (Fix proxyless container endpoint tests), Refine dynamic endpoint allocation #17879 (Refine dynamic endpoint allocation), Fix persistent container endpoint allocation #17960 (Fix persistent container endpoint allocation); several backported to release/13.4 (e.g. [release/13.4] Add proxyless endpoint on-demand allocation #17859)

Confidence: medium
Needs human?: yes — likely 13.4 regression in proxyless endpoint allocation; confirm baseline before promoting to 13.4.x

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[davhdavh]

this was caused by ASPIRE_RESOURCE_SERVICE_ENDPOINT_URL somehow getting the same port as the app