📝 Description
I have observed that when adding nodes in host, the resulting nodes are displayed in all internal subscription groups that utilize the same Configuration File, rather than being restricted to the specific Host/Connection settings used for their creation.

🐞 Steps to Reproduce

1. Create two internal subscription groups: GROUP1 and GROUP2.
2. Configure both groups to use the same base configuration file. For example, the configuration file is named SelfUSE and uses the ShadowSocks (SS) protocol structure.
3. Add two different nodes via the Host interface, using the same configuration file (SelfUSE), but specifying different connection IP addresses for the Hosts (e.g., using $iptables$ forwarding to direct different IPs to different backend services).Host A $\to$ Node A (IP A connection)
   Host B $\to$ Node B (IP B connection)
4. Check the node list for GROUP1.
5. Check the node list for GROUP2.

💡 Expected Behavior
I expect the nodes added by a specific Host to be bound to that Host's specific connection configuration and only appear in internal subscription groups that are configured to use that Host's unique connection identifier (e.g., IP address).

GROUP1 should only see Node A (as it connects via IP A).

GROUP2 should only see Node B (as it connects via IP B).

💥 Actual Behavior
Regardless of the distinct connection IP addresses used, as long as the Hosts utilize the same configuration file (SelfUSE), the added nodes appear simultaneously in both GROUP1 and GROUP2.

GROUP1 actually sees Node A and Node B.

GROUP2 actually sees Node A and Node B.

I found that the current way to allow different internal groups to have different host nodes is by creating multiple listening ports or multiple configuration files, and then binding the different internal groups to those specific ports or files. However, this increases significant memory overhead and manual effort. I hope that, referencing Xboard, the same node can achieve multiple entry points for different groups.