I specifically said "counter" not "prevent". I explained in another post.

Running your own node neither counters nor prevents front running your transactions. If you send tx to standard mempool, the tx can be seen and front run.

There are existing solutions for the narrow use case you seem to have - flashbots and a few others. And they have cost savings to you of not running your tx (saving eth gas fees) if your tx submission does not win.

I explained in my other comment, but I see no mention any of those aspects of countering a sandwich botter.

Front run + back run is sandwich. Front running has also been called miner extractable value. This is now called maximal extractable value.

You may want to look a little further, or not.

https://github.com/flashbots/pm

'... mitigating the negative externalities of Maximal Extractable Value ...'

Can you not you "see" more transactions, faster...?

The block producer chooses transaction ordering. They control who gets sandwiched. Running your own node won't change anything.

The trading site's performance is quite high latency, and uses a 3rd party endpoint (I forget which one) that doesn't emphasize performance. You reduce the latency of your orders, acquire real-time price information, notification of liquidity changes faster, etc.

If you think it's to prevent attacks in some absolute sense, that isn't the goal. Your goal is to make life more difficult for them and/or decrease profit incentives.

You only need to remove some of the profit to make it not worth someone's time to maintain, and at least you're bleeding less money if they do continue. You get to be more strategic in how you place orders and make it really annoying for a botter or force the botter to blacklist your trades from your attacks (something that has happened before). You can also identify flaws in the bot and exploit them to make it bleed money(this has been demonstrated as possible many times).