1. XFF stands for X-Forwarded-For it is data that is supposed to show the trail of IPs that have been used to show the real client IP that is editing when we are seeing the proxy ip as the editing ip. That does not mean its an open proxy though because many isps or companies will send a group of customers through the same IP (proxy) to save money. The XFF data is useful to show ISPs who was editing through their proxy at the time, they can often find the information in their logs but it much harder when they could have countless users using the web at that time, through the same proxy. It can also be useful to find the actual isp involved. There is a growing trend of proxy services actually passing along XFF information because of abuse problems and so are much less anonymous then users may think.

The data is of course only as trusty as the source, the information is passed along in the form of a header from the proxy, which could put any information it wants into it. That of course means you have to trust the proxy. Schools and governments are usually fairly trustworthy but you have to be able to make a bit of a judgment call on anyone. If you look at an XFF header you will see something like: XFF: client1, proxy1, proxy2. The last one will be OUR proxy which of course means we can trust that it has passed along the information before it correctly, so we have to look at proxy1 (which is the ip that we see as the editor) to decide if its trustworthy enough to pass on the client correctly, on occasion you can see it go through multiple proxies (or certain routers) and have to again decide if you trust each one in turn.

XFF data can be helpful (if you trust it, and if that server gives it to) to help determine if its the same person editing (or for a collateral damage check to see when it possibly ISN'T them) but unfortunately we can not block it directly, we can only block the proxy. There are exceptions of course, certain trusted sources (most notably America Online (AOL)) are recorded at meta and the server actually uses the client ip as the editing ip (so we can block it) but that's not connected to CU.

2. The main reason is just when I see something obvious to me and generally happening right there and then. If we are having an ongoing account attack finding IPs or a range that can be blocked can be time sensitive to prevent further disruption. The other reason is when requested by an outside checkuser or steward to help with crosswiki abuse and I agree with the concern. In the end I think I should only do a checkuser when I personally think there is enough evidence to warrant it. If something happened while I wasn't there I would most likely wait for a request for the community (something that usually happens here) since it isn't as time sensitive or talk with other CUs for a second opinion.

3. As I said above the biggest thing is that I don't feel I should do any CUs where I don't personally feel that the evidence isn't available. CU isn't a tool for fishing, sometimes people can get frustrated with a user or users and either see something that isn't there or be looking for a reason to ban a user where there isn't one. If I can't be comfortable doing a check then I'm not going to do it regardless of who the user is.