Sql Server AG assigning wrong listener I have 2 instances of SQL Server on two Windows Servers, namely: 


D-MSSQL01-DE (v.2014)  
D-MSSQL02-DE\SQL2019 (v.2019)


And seperate server for AGs:


D-MSSQL02-DE (v.2014)
D-MSSQL02-DE\SQL2019 (v.2019)


Listeners:


D-AGSQL01-PP (v.2014 listener) 
D-AGSQL04-PP (v.2019 listener)


I'm after setting up new AG and it's listener on SQL server 2019 with new IP:port assigned by networkteam. Now, when I connect to this newely created listener, somehow under "Always On High Availability" I see 2014 AG instance! 
Why is this connecting to SQL2014 instead of 2019?
Both your 2014 &amp; 2019 instances are running on the same hardware--just different ports. 

While you don't specify which ports they are using, the 2014 instance is the default instance, so it's probably running on the default port (1433), and the named instance is running on some other port (who knows... You'd have to check SQL Server Configuration Manager). When you connect to the named instance, the SQL Browser Service helps with name/port resolution, or you can specify the port in the connection string.

It sounds like your AG Listener for your 2019 instance is potentially also using a non-default port (You'd have to check the Listener configuration in SSMS... If both listeners are on port 1433, keep reading). Unfortunately, the SQL Browser Service can't do it's magic on AG Listener names. 

If you look at the related documentation, it explains that using a non default Listener port means you need to include the port in your connection string:


  You can also designate a non-standard listener port; however this means that you will also need to explicitly specify a target port in your connection string whenever connecting to the availability group listener.


SHOULD you be using a non default port? In your case, yes. You have to. In fact, if you are running both listeners on the same port, that would be the problem! The documentation continues: 


  If you use the default port of 1433 for availability group listener VNNs, you will still need to ensure that no other services on the cluster node are using this port; otherwise this would cause a port conflict.


In your case, you are running multiple services (SQL 2014 &amp; SQL 2019) on the same cluster node. This creates a conflict where both sqlservr.exe processes are both trying to listen on 1433, thus causing a port conflict. In this case, you'll need to change one of the listeners to use a different port, and also specify that port when connecting (Ex to connect to D-AGSQL04-PP on port 56789, specify server name in the format D-AGSQL04-PP,56789)