How many hex digits do I need to compare when manually checking hash functions? I sometimes run sha256sum on large files after transferring them from one place to another, and will just skim the hash output to verify it's correct. But, I usually just look at the first/last 5 or 6 hex digits and call it good enough. 

I know that the chances of collision are something like 1 / 2^64, but what are the chances of a "near collision"? E.g. only one or two hex digits are different.



As a related topic,
If you have a binary sequence and just change one bit, you get a completely different hash, correct? So is it possible for random errors to result in nearly identical hashes? I'm aware that MD5 is 'cracked' such that a malicious agent could append whatever necessary data to a file to make it have the same hash output- but is this within any reasonable realm of possibility to have happen stochastically?

EDIT: This topic has spawned some discussion below that was just as (if not more!) informative than the scope of my original question. With that said- I am referring only to using hash functions as a file integrity check, not as protection against attacks.
How many hex digits do I need to compare when manually checking hash
  functions?


If you actually want the full security guarantees of the hash function to apply: all of them.


  I usually just look at the first/last 5 or 6 hex digits and call it
  good enough.


This effectively reduces the security of the hash function to that of one that only outputs 10-12 hex digits, a.k.a. 40-48 bit, for which we can easily find collisions in about $2^{24}$ evaluations which is easily doable.


  what are the chances of a "near collision"? E.g. only one or two hex
  digits are different.


As discussed in this answer the probability for at most $t$ bits difference between two hashes with $n$ bit output-length is $$p_t=\sum^t_{k=0}{n\choose k}2^{-n}$$ which means you need about $\sqrt{1/p_t}$ evaluations to come up with a desired near-collision. Strategies to finding these values can be found in this answer (including low-memory approaches).