Thanks for sharing your findings.

I may have found a solution, although no understanding the cause of failure still.

The issue may have stemmed from the older hardware/instability in it's setup, 4 dimm ram, bios, etc. I acquired newer hardware to mimic what my original home server was; AM5 socket and DDR5 ram. I also learned about ReFS on windows 11 and converted a drive to it. My uploads and downloads now have matching checksum on any transfer size over SFTP.

I may also be wrong about ECC CPU support, ECC supported memory is extremely expensive right now; The memory in the computer I gave away definitely was not ECC supported.

I am very much at a loss. Any advice, guide/instruction links, or anything else would be greatly appreciated. I have very little practical knowledge on file transfer and am at my limit of understanding nor being able to find information online about my specific issue here that is not 15-20 year old forum posts.

I should have included this information in the first post.
The home server currently is Windows 11, using openSSH optional feature for SFTP. SFTP dir is on a WD RED hard drive.

If the hardware age, ram config, etc matters to this issue:

CPU is an i7-8700k with a 4 dimm 32gb ram. The bios was updated to the newest one for 2026.
The hardware I gave away had an R7 9700x with 2 dimm dual channel 32gb ram.

While on the R7 9700x, I used SMB and don't recall any issues to this extent. Although it was awhile ago.

I may have found a possible cause to the error, the i7-8700k im using for the home server does not support ECC. While the hardware I gave away to family had a cpu with ECC support. This could possibility explain the errors. I wrongly assumed SMB worked correctly as well as the other FTP clients as after more testing they are had a chance of corrupting data.

When i upload large archive files to a home server, the data gets messed up somehow. The md5/sha256 hash does not match the original file on the main computer. More bizarre when downloading the same archive file the checksum is different each time. This occurs from a zerotier vpn and local connection.

I have tried several different 7z and zip compression levels, including just using store. I have tried moving the file uncompressed/unpacked back and forth with similar results. High levels of compression results in 7zip reporting data error, while normal and store report CRC error.

I tried default WinSCP settings, binary transfer mode, turning off optimization of buffer size.

This issue is not occurring on cyberduck, filezilla, or an SMB share on windows.