First, your measurement is definitely wrong.
There is no way an ESP32 is drawing 250nA, no matter how deep a sleep it is in. It is specced to draw between 150µA to 10µA depending on what you disable in addition to deep sleep.
Regardless, that is still far too low to drain your battery.
When you say, 'most of its time in deep sleep', this is all you really need to know - how much time is it really spending asleep or awake. How sure are you that it is correctly entering sleep a second time, or a third, or whatever?
It is just a bit suspicious, as 800mAh/48 hours is about 33mA. The nominal power draw of the ESP32 when not using either of its radios is about 30mA. That might just be a coincidence, and I don't think you meant it died exactly 2 days later, but the point is the approximate scales here are about right for it to not be quite as sleepy as you think it is.
You don't need any measurement device to do this. The ESP32 has an RTC, so you can simply write a bit of code that will actually log how long it is spending awake, and from that, you can extrapolate how long its been asleep as well.
I think if you do that, the results should be fairly eye opening. It is important to realize how power hungry the ESP32 actually is. If it is sending packets over WiFi, you can expect the current draw to be 260mA. And if you are also using bluetooth at the same time (which you probably aren't but just in case), it can hit peak draws of 780mA(!).
Wifi is not energy efficient by design and prioritizes throughput and range at the cost of power use. Also, keep in mind that if you are putting your ESP in deep sleep and having it wake up periodically to transmit something over Wifi, it has to start from scratch each time. It has to find the SSID, do the handshaking and authentication then get an IP address (if it isn't statically set) and the entire process of connecting to a network as if it was the first time.
That can take a while and is potentially even more power hungry than simply transmitting data alone. Transmission will be done at maximum power until link quality is established.
It is hard to say much more since you didn't really provide any useful information about what you're doing. But this is a processor with well-defined power states and an RTC. You already have everything you need to measure the current more than well enough to figure out what the problem is.
Also keep in mind that battery voltage drops as it is discharged, so be sure you're actually using all of the batteries capacity. It is possible the voltage drops too far for the ESP32 to function (like during a wifi current spike), but a large portion of the battery charge remains unspent.
If you really want to get an accurate current measurement over time, this will not be easy or cheap unfortunately.
This isn't some analog circuit with relatively slow and small changes in power consumption.
This is a CPU with millions of CMOS charge-actuated transistors inside as well as some RF transistors that are consuming current with all the wiggliness of WiFI in its 2.4 billion wiggles per second of glory.
You need something that can sample current (or voltage - is really just voltage when you measure current, but you measure the drop across a resistor) fast and data log it all. Or you can heavily filter the power input instead, but then you are also destroying the information about the actual shape and timing of the current consumption to varying degrees, and are only seeing something like a moving average.
Digital stuff can easily confuse any 'simple multimeter' as well. You need a true (actually, really, seriously true, and with high bandwidth) rms multimeter to accurately measure anything to do with something digital like this.
Honestly, the thing you want is a multimeter with data logging. There are quite a number of them, but the one I am familiar with is the Fluke 289. It is not cheap. I don't think any of them are. But they're cheaper than an oscilloscope, and most oscilloscopes aren't going to do data logging for 2 days, but a data logging multimeter sure will.
That said, I strongly recommend you not buy anything you don't need. There is no reason you can't figure this out simply by writing code and then using the typical current consumption specs (like this one) to get a 'good enough' picture of what is going on and it won't cost you a cent.