Looking at the code, this is not the expected behavior. It would always first try GLOO_SOCKET_IFNAME if that’s available. Somehow, it didn’t pick up the env var.

  
      github.com
  
  
    pytorch/pytorch/blob/945d7a7408891e25bc54a65015724f6d2de644e6/torch/csrc/distributed/c10d/init.cpp#L603-L615 4

char* ifnameEnv = getenv(GLOO_SOCKET_IFNAME_ENV);
if (ifnameEnv) {
  for (const auto& iface : split(',', ifnameEnv)) {
    options.devices.push_back(
        ::c10d::ProcessGroupGloo::createDeviceForInterface(iface));
  }
} else {
  // If no hostname is specified, this function looks up
  // the machine's hostname and returns a device instance
  // associated with the address that the hostname resolves to.
  options.devices.push_back(
      ::c10d::ProcessGroupGloo::createDefaultDevice());
}



  
  
    
    
  
  


            char* ifnameEnv = getenv(GLOO_SOCKET_IFNAME_ENV);
            if (ifnameEnv) {
              for (const auto& iface : split(',', ifnameEnv)) {
                options.devices.push_back(
                    ::c10d::ProcessGroupGloo::createDeviceForInterface(iface));
              }
            } else {
              // If no hostname is specified, this function looks up
              // the machine's hostname and returns a device instance
              // associated with the address that the hostname resolves to.
              options.devices.push_back(
                  ::c10d::ProcessGroupGloo::createDefaultDevice());
            }

Can you try reading the GLOO_SOCKET_IFNAME env var immediately before init_process_group from Python and see if that gives the correct result?
Let me check Gloo code.