WordPress is aggressive with redirects (http code 301). It will check for the correct domain by comparing the value of Settings > General > WordPress Address and/or Site Address with the domain from your urls query (as typed into the browser). These settings correspond to the options in the table wpoptions with optionname = ‘siteurl’ and option_name = 'home’. They are probably the same value for any website installation.
I think WordPress will redirect you to the url that results from substituting the domain in Settings/wp_options into the url of the browser’s request. Whatever redirect it does, the domain settings must be correct.
If you have two different WordPress sites and you make each from scratch, you would simply set the domain with the install or soon thereafter in the administration dashboard. Maybe you copied database data from one site to the next. It’s not that simple.
Can you access the admin dashboard at samename.net? If not, try the database over SSH (see the hints at the end of this).
Did you set the 'siteurl’ and 'home’ values correctly?
See the WordPress documentation for function getoption() for common options: https://developer.wordpress.org/reference/functions/getoption/ .
If you copied the database data by dumping a logical backup (with mysqldump) and then put it into the new database (with mysql < [dump-file]), not only will you have copied the siteurl and home option settings, you will have copied any other site urls in your data. Data editing is necessary for a 'WordPress database migration’. You could search on those words and find useful information.
Maybe start with webpage “Move a WordPress Site by Moving the Database and Files” (https://css-tricks.com/moving-a-wordpress-site/). When you get to the bottom of that webpage, there is a hyperlink with the text 'moving WordPress to HTTPS’ which might also be useful. It illustrates an instructive case of editing urls of the data within the database (e.g. the UPDATE command). You may need to edit your urls to swap 'samename.com’ to 'samename.net’. If you have post content with hardcoded links from one webpage to another, that will have to be changed.
I like to make a copy of my dump file and edit it using the document-wide replacement feature of a text editor (e.g. geany). The sed command would work too. A really large text file might be impractical. You could dump different groups of tables and make several smaller dump files. I would get familiar with the values that need to be replaced because it would be easy to screw up the data in the dump text file. Altering the data in the database at the receiving location requires good SQL skills and likely will not facilitate the use of regular expressions (though I believe it can be done).
Some SQL hints:
MariaDB [(none)]> show databases;
MariaDB [(none)]> use some_wordpress_db;
MariaDB [some_wordpress_db]> describe wp_options;
MariaDB [some_wordpress_db]> select * from wp_options where option_name = 'home' or option_name = 'siteurl';
MariaDB [some_wordpress_db]> describe wp_posts;
MariaDB [some_wordpress_db]> select count(ID) from wp_posts where post_content like '%samename.com%';
MariaDB [some_wordpress_db]> select ID, guid from wp_posts;
The post guid is the Globally Unique Identifier. Obviously, it should be globally unique. If you make a duplicate copy, then you want to edit the copy for uniqueness. You might decide the edit the values for sanity as well. See the documentation for WordPress function theguid(): https://developer.wordpress.org/reference/functions/theguid/ .