For any halfway decent hash function, even hashes that are completely unsuitable for cryptography, if you look for collisions by brute force, it doesn't matter how you explore the search space. Keeping a fixed prefix and changing the suffix, or keeping a fixed suffix and changing the prefix, are as good as any other method. That's because all hash functions are designed to produce distinct results for similar inputs.
If there are N possible hash values, you need about to calculate and store about √N hashes until you have a good chance of finding a collision (the birthday bound). For a 32-bit hash as used in hash tables, N = 232 so √N = 216 which is reached very quickly. For a 128-bit hash such as older cryptographic hashes, √N = 264. A GPU these days can calculate something like 234 (16 billion) MD5 hashes per second, which means it calculates 264 hashes in about 230 seconds ≈ 34 years).
But that's not all: to find a collision, you need to store the result of all these calculations, so the limiting factor will be memory bandwidth. And once your RAM fills up, that'll be storage bandwidth. You aren't going to find a collision in a 128-bit hash in your lifetime.
Hashcat is designed to find hash preimages, not to look for collisions. Hashcat is designed to reverse password hashes (and ordinary hashes that are misused for passwords), and collisions are not relevant for that. But even with an optimized tool, what you're trying to do is not feasible for any cryptography-sized hash.
If you want to find a collision for a 128-bit hash, you need to understand its structure. There are known methods to find collisions for MD4 and MD5, for example. These methods are practical because they don't use brute force over the whole search space.
By the way, you're calling the hash inputs ”passwords“, but password hashes are different from “ordinary” cryptographic hashes. They're slower, and salted. The use of a random salt means that with a password hash, you don't get the same output twice, not even if you use the same password twice.