@deactivated cheers for the technical info, I love stuff like that, but I don’t think it is addressing my actual issue.
It is not important that my traffic is linked to the FQDN itself, only a specific interface. For clarification, the FQDN and 1xx.xxx.xxx.xxx are the same interface and 2xx.xxx.xxx.xxx is another interface. I do not want the 2xx.xxx.xxx.xxx interface used as it needs to be kept clear for other more crucial loads.
As noted, I do realize that binding to a specific IP is not currently available via the PMS software, however, as a workaround what I did was firewall off the interface that I do not want to be used for PMS. I did this by blocking incoming traffic on port 32400. This results in the 2xx.xxx.xxx.xxx connection not being connectable, which is what I desire.
Now, one would imagine that this would end up with one of two things happening. Either Plex would realize it is not connectable and not list it in the connections list of the API OR if listed, once tested and seen as not working the client would try the next one in the list. And here is where the issue lies. With the 2xx.xxx.xxx.xxx address firewalled off, if it is the first item in the list, the Vizio device tries to connect to it, which obviously fails since it is firewalled off. However, if I take down the firewall it works fine as communication over 2xx.xxx.xxx.xxx is available. Now, I’ve ascertained that the issue is that the client is not trying subsequent connections as I can get the order of connections to change by taking down the secondary interface and bringing it back up. Once this is done the 2xx.xxx.xxx.xxx is at the bottom of the connections list and the Vizio can connect regardless of the firewall status as the Vizio is then trying to connect to either the FQDN or the 1xx.xxx.xxx.xxx address.
If the testing and sorting is being done in the manner you suggest then, in theory, the connection should work regardless of the firewall on the 2xx.xxx.xxx.xxx address and regardless of the position of the 2xx.xxx.xxx.xxx address in the API’s connections list, but this is not the case. Again, the only functioning situations are to have the connection not firewalled and available for plex to use, or to massage the 2xx.xxx.xxx.xxx interface into a secondary or tertiary position in the list.
To bring this back around to my original post, if the custom server URLs were given precedence in the connections list, one could add a FQDN to the field and it being at the top of the list would prevent a bad connection from taking the primary position.
I’m hoping this clears up the actual issue at hand.
Update
For clarification I wanted to add the Connection snippets that I see and the results of it.
# While Firewall is up on 2xx.xxx.xxx.xxx: Vizio CANNOT connect to the server
# While Firewall is down on 2xx.xxx.xxx.xxx: Vizio CAN connect to the server
<Device name="SERVER1" ... >
<Connection protocol="http" address="2xx.xxx.xxx.xxx" port="32400" uri="http://2xx.xxx.xxx.xxx:32400" local="0"/>
<Connection protocol="http" address="server1.site.com" port="80" uri="http://server1.site.com" local="0"/>
<Connection protocol="http" address="1xx.xxx.xxx.xxx" port="80" uri="http://1xx.xxx.xxx.xxx" local="0"/>
</Device>
# Regardless of Firewall status on 2xx.xxx.xxx.xxx: Vizio CAN connect to the server
<Device name="SERVER1" ... >
<Connection protocol="http" address="server1.site.com" port="80" uri="http://server1.site.com" local="0"/>
<Connection protocol="http" address="1xx.xxx.xxx.xxx" port="80" uri="http://xxx.xxx.xxx.xxx" local="0"/>
<Connection protocol="http" address="2xx.xxx.xxx.xxx" port="32400" uri="http://2xx.xxx.xxx.xxx:32400" local="0"/>
</Device>
