Changing the code in any way imposes a risk of introducing new bugs into the code. The bigger the changes, the bigger the risk. You can mitigate that risk via unit (and integration/system/...) testing (but can't ever eliminate it completely).
Obviously, a total rewrite has a significantly higher risk than just fixing a specific bug. In order to create a proper fix, you have to understand the problem and the solution well enough so that fixing one issue doesn't break some other use case. But so is the case for a rewrite. If you don't understand what's going on during debugging, obviously the code in question is complex, so rewriting it is going to be far from trivial, and usually takes way more time you would assume. Which, under a tight deadline, is not good news...
Moreover, being tired and under pressure always increases the risk of making bad decisions and mistakes, thus causing more bugs.
So I personally would strongly prefer debugging and fixing the concrete bug rather than rewriting, except when the code in question is really really terrible and I have a clear specification (in the form of documents and/or unit tests) of what it is supposed to do and I have enough time to do it properly.
(Note also that if the code is really so terrible, it is exceedingly rare that it is properly documented and/or unit tested. In this case, one needs even more time to first construct a proper unit test suite to "record" the behaviour of the current code, to be able to verify that the new implementation reproduces it faithfully in every aspect except the bug fix.)
If you are stuck with your current approach, it is indeed a good idea to take a rest and do something else to relax your brain and allow your subconscious to work on the problem in peace. It is also useful to ask help from a colleague (or StackOverflow). See this earlier related thread for more details:
Dealing with frustration when things don't work