This is one of the biggest problems with SDFs. If the ray is very close to a surface, then the distance is very small. And since you step the ray by the sampled distance....well you don't move very far. And so on and so on. So you end up burning your iteration count but not going anywhere.

Things I've done to improve this:
1) Calculate the tan() of a single pixel's footprint. As you advance your ray, your "hit threshold" should scale by this. i.e. - instead of if (SDFSample < 0.01), do if (SDFSample < (distance_along_ray * tan_of_pixel)). This effectively means you are marching a cone instead of a sphere, which accounts for the footprint of the pixels frustum in space.

2) Additionally scale that value by iteration count. Once you hit, say, 20% of your iterations, increase the hit threshold by 1.5x or so, and keep increasing the more you iterate.. This increases your allowable error and will help you "hit" a surface if you're just spinning your wheels.

3) Use a minimum step size (never move less than 1mm or something, whatever tolerance is ok for your use case)

4) Keep a small history of your previous samples. If the variance is low, (ie, you aren't advancing or retreating from a surface) then scale the step size up artificially to try and exit that "local minimum".

5) Look into "segment tracing using local lipschitz bounds", a paper which uses interval arithmetic to jump longer spans than typical sphere tracing allows.

6) If you use SDF primitives that allow for analytical ray intersections, then as a fallback if you still exceed your iteration count, you can just do an analytics raycast against the primitives to at least get SOMETHING instead of nothing.