Various unified communications components reserve port 443 for media and signaling.
Container engines may expose a REST API over port 443 for secure remote management.
Example – IIS:
Example – Veeam Enterprise Manager port change (if both Veeam Backup Server and EM on same server):
To confirm exactly which application is holding the port, perform the following steps on the Veeam Backup Server:
Step A: Check Listening Ports
Step B: Identify the Process
When upgrading to Veeam Backup & Replication (VBR) v13 , many users encounter a critical installation block:
"Required port 443 for Veeam Backup & Replication is occupied by another application" In version 13, port 443 is
for the Veeam Web Service/API Gateway. This requirement is strictly enforced by the installer's compatibility check, and there is currently no supported way to change this port within Veeam or bypass the check. Identifying the Conflict
To resolve the block, you must identify which non-Veeam service is listening on port 443. Diagnostic Command netstat -anob
in an elevated Command Prompt to see which Process ID (PID) and executable are using the port. Common Culprits Hyper-V Replication
: If your VBR server also acts as a Hyper-V Replica server, it may be using 443 for replication traffic. IIS / Web Servers : Existing web hosting services or management consoles. Security Agents : Third-party monitoring or security software. How to Resolve the Block
Since Veeam's port 443 requirement is mandatory for v13, the solution involves reconfiguring the application: Reconfigure Hyper-V Replication Navigate to Hyper-V Settings Replication Configuration Change the listening port from to an alternative (e.g., 444).
Update the Replica settings for each individual VM to match this new port to avoid re-replication. Adjust Third-Party Applications
If a third-party service allows it, reconfigure it to use a different HTTPS port (e.g., 8443 or 9443). Temporary Disabling
Some admins report success by temporarily stopping the conflicting service to complete the Veeam upgrade. However, the Veeam Web Service may fail to start afterward if the original application resumes control of port 443. Dedicated Infrastructure
Veeam experts recommend moving the backup server to a dedicated, non-domain-joined environment to avoid conflicts and improve security.
Major Issues After Upgrading to Veeam V13: Port 443 Conflict Example – Veeam Enterprise Manager port change (if
Title: The Sentinel of Port 443
Log Entry: Day 1, 08:00 GMT Administrator: Lena Koh, Senior Cloud Architect Location: Global Data Center, Floor 14
Lena Koh stared at the crimson error message on her RDP session. It was the kind of message that made her left eye twitch—a simple, declarative sentence that carried the weight of a cancelled weekend.
Error: Required port 443 (HTTPS) for Veeam Backup & Replication is occupied by another application. Please free the port and restart the Veeam Backup Service.
She had been planning this migration for six months. The old tape libraries were being retired. The new all-flash object storage array, affectionately nicknamed "The Vault," was racked and stacked. Veeam Backup & Replication v12.1 was the orchestrator, the brain that would move 4.2 petabytes of financial transaction data from the production cluster to immutable cloud storage. And its control heart—the web UI, the REST API, the service endpoint—needed port 443.
But something else had claimed the castle.
Lena opened netstat -ano | findstr :443 with the muscle memory of a concert pianist.
The output was chilling:
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4428
TCP [::]:443 [::]:0 LISTENING 4428
Process ID 4428. She pulled up Task Manager. Right-clicked the PID column. Sorted.
Process Name: AcmeCorp.Unified.Agent.Core.exe
Description: Endpoint Detection & Response (EDR) / Web Filtering Proxy
Memory Usage: 2.1 GB
Status: Running. Immovable. Blessed by the InfoSec team.
Lena groaned. AcmeCorp Unified Agent. The Swiss Army knife of cybersecurity that had been forced onto every server in the fleet three months ago. It intercepted all HTTPS traffic for deep packet inspection, certificate re-signing, and behavioral analysis. And it had planted its flag firmly on port 443.
She opened Teams. Direct message to Raj Patel, Lead InfoSec Engineer.
Lena: Raj. The AcmeCorp agent on VEEAM-SRV-02 is squatting on port 443. Veeam needs that port. Can we rebind the agent to 8443 or something?
Raj’s reply came in 14 seconds. That was never a good sign.
Raj: Negative. Corporate policy M-2024-09. All Windows servers with financial data classification must have AcmeCorp agent bound to default HTTPS port for SSL inspection. No exceptions. Change request would take 3 weeks.
Three weeks. The backup window for the monthly archive was in six days. If she missed this window, the storage array would lock for maintenance, and the auditors would flag the gap.
Lena took a breath. She had three options. And the first two were terrible.
Option 1: The Registry War
She could try to force AcmeCorp to listen on a different IP address (127.0.0.2 vs 0.0.0.0). She navigated to HKLM\SYSTEM\CurrentControlSet\Services\AcmeCorp\Parameters. There it was: ListenAddress = 0.0.0.0. She changed it to 10.24.112.45—the server’s secondary admin IP. A restart of the service later, netstat showed the agent now bound only to the secondary IP. Port 443 on the primary IP was free. Step B: Identify the Process When upgrading to
She held her breath. Started Veeam Backup Service.
Error. Same message.
She realized the truth with a sinking feeling: Veeam, by default, binds to all interfaces. It saw the AcmeCorp agent still technically occupying the port on the secondary IP. Windows Sockets don’t care about your IP segmentation logic—if any process listens on 443 on any IP, no other process can bind to 0.0.0.0. A cold war over a single integer.
She reverted the change.
Option 2: The Reverse Proxy Mirage
She considered running Veeam on port 8443 internally, then setting up an IIS ARR (Application Request Routing) reverse proxy on port 443 that forwarded traffic. Elegant in theory. In practice, Veeam’s API hard-codes redirect URLs in its authentication handshake. The moment the proxy forwarded a request, Veeam would generate a callback URL with :8443, the browser would throw a CORS error, and backup jobs would fail with cryptic "token mismatch" errors.
She had tried this once, three years ago. She still had nightmares about the log files.
Option 3: The Nuclear Option (The One She Chose)
She called a war room. Attendees: Lena (Backup & Storage), Raj (InfoSec), and Priya (Network Engineering, who owed her a favor).
Lena laid out the problem. Raj reiterated policy. Priya listened, sipping cold brew.
Then Priya spoke. "What if AcmeCorp doesn't need to inspect traffic between Veeam and its own repository?"
Raj frowned. "Explain."
Priya drew on the whiteboard. VEEAM-SRV-02 <---> THE VAULT (Storage Array). The traffic was internal. VLAN 104. No internet egress. The financial data was encrypted twice—once by Veeam, once by the array. The AcmeCorp agent was decrypting, inspecting, and re-encrypting backups of encrypted backups. It was theater. And worse, it was slow theater.
"The policy says 'all Windows servers with financial data,'" Priya said. "It doesn't say 'all interfaces on those servers.' Add a second virtual NIC. Dedicate it to VLAN 104. Tell AcmeCorp to ignore that interface. Tell Veeam to bind only to that interface for its service."
Silence.
Raj’s policy brain clicked. "A network-level segmentation exception. That… could work. The agent would still monitor the management NIC. The backup NIC is just a data plane."
Lena’s fingers flew. Two hours later:
She restarted both services. She ran netstat -ano | findstr :443.
Two lines.
TCP 172.18.0.10:443 0.0.0.0:0 LISTENING 7892 (Veeam)
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4428 (AcmeCorp)
Peaceful coexistence. Two different universes sharing the same integer, separated only by a virtual wire.
Log Entry: Day 1, 16:32 GMT
Lena opened the Veeam Backup & Replication console. The green "Ready" status glowed on the dashboard. She created a test job: "Finance_Archive_Test." She pointed it at The Vault. She hit Start.
The progress bar ticked. 1%... 5%... 23%... 47%...
No errors. No port conflicts. Throughput: 1.2 GB/s.
She leaned back. Her phone buzzed. A calendar invite from Raj: "Meeting: Formalize NIC segregation policy – Next Tuesday."
She smiled. Tomorrow's problem. For now, port 443 was no longer a battlefield. It was just a number—two numbers, actually, living in parallel harmony, carrying the future of 4.2 petabytes to safety.
She typed a final note into the change management ticket:
Resolution: Port 443 conflict resolved via multi-homing. Veeam bound to secondary interface. AcmeCorp agent bound to primary. Backup service operational. Recommendation: Update server provisioning standards to include dedicated backup VLAN NICs.
She closed the ticket. The server hummed. And somewhere deep in the logs, a single line of Veeam success code wrote itself to history:
[Info] HTTPS listener started on 172.18.0.10:443. Ready to serve.
This error is a common blocker when upgrading to or installing Veeam Backup & Replication v13 port 443 is now hardcoded and required for the Veeam Web Service and API Gateway
. Unlike previous versions, there is currently no supported way to change this port within the Veeam configuration once the conflict is detected. Veeam Community Resource Hub
To resolve this, you must identify and reconfigure or disable the application currently occupying port 443. 1. Identify the Conflicting Application
Use the command line to find out which Process ID (PID) is using the port: Open Command Prompt as an Administrator. Run the command netstat -ano | findstr :443 Note the PID
: Look for the number in the far-right column for the entry with status Match the PID Task Manager , go to the tab, and find the application matching that PID. Experts Exchange 2. Common Culprits and Fixes
Major Issues After Upgrading to Veeam V13: Port 443 Conflict
If you absolutely cannot free port 443 due to corporate policy (e.g., another critical application must keep it), you can force Veeam to use a different port. However, this is not officially recommended because: go to the tab
Still, if necessary:
You will also need to adjust firewall rules accordingly.