One of the many uses of netstat - or currently the ss command - is to see if I have configured a service to run on a specific interface. Many services ship with configuration files that either listen on localhost only (sendmail and postfix) or on all IPv4 and Ipv6 interfaces (ssh). After changing the configurations and restarting the service, an ss -l command can show me that I am listening. Since I am usually configuring TCP services, I add the -t option and since I usually also want to verify the process that is listening, I add the -p options.
ss -ltp
This will show output like 127.0.0.1:ipp to say that the ipp protocol is listening on the 127.0.0.1 interface.
Once I know that the service started and that I am listening on the correct interfaces, I can then adjust my firewall settings to allow select networks to connect.
If I just test from a remote system and I cannot connect, it can be unclear initially if I have a routing issue, a firewall rule blocking the connection, or if the service is not running or not listening on the a particular interface. Some services are better than others at helping to identify the root cause. The ss (and formally the netstat) command can help identify or rule out one specific possibility.
Again, this is just one of many uses for the ss command. You can get a variety of socket connection information for performance tuning and troubleshooting from this command.
Here are some blog posts on ss. It has been a while since I looked at them closely but they may help.
https://www.linux.com/learn/intro-to-linux/2017/7/introduction-ss-command
https://www.binarytides.com/linux-ss-command/
https://computingforgeeks.com/netstat-vs-ss-usage-guide-linux/
https://www.rootusers.com/21-ss-command-examples-in-linux/
https://pcarleton.com/2018/05/31/netstat-vs-ss/
Stackoverflow and Stackexchange also have threads on ss replacing netstat.
